Pendahuluan
Yang penting koding, masalah error atau jalan itu program gak masalah deh.
Begitulah kira-kira ucapan saya sebagai mahasiswa pemula yang saat itu sedang mendalami ilmu programming. Alhasil nyaris burnout karena kebingungan sendiri menentukan apa yang harus dilakukan ketika negara api menyerang, eh error menyerang. Jangankan error, saat satu tugas atau task selesai, pasti akan kelimpungan untuk menentukan arah selanjutnya yang harus dituntaskan.
Hidup saya berubah ketika mendapatkan proyek freelance dari seorang teman kuliah setelah lulus (saat itu menggunakan React untuk sisi frontend dan Express JS untuk sisi backend). Karena teman saya ini adalah orang yang "selalu tertata rapi dalam bekerja", dari struktur source code saja sudah membuat mata jadi terbuka lebar bak orang yang baru melihat kodingan surga. Semua folder dan file sudah ditentukan tempatnya dan direncanakan dengan matang.
Kami saat itu menggunakan metode Kanban dalam pengerjaan proyek ini. Setiap sebulan sekali, diadakan update progress dan task apa saja yang sudah selesai dan akan diselesaikan. Ini tentu sangat memberikan dampak bagi saya yang awalnya seorang programmer bar-bar.
Kami bisa menghabiskan sekitar 2-3 jam sendiri untuk planning task bahkan detail alur cara pengerjaan setiap task pun bisa memakan sekitar satu minggu sendiri. Bagi saya saat itu, terkesan jadi lama sekali proses perencanaan ini. Tetapi saya baru merasakan efeknya kemudian ketika saya memulai mengetikan kode di text editor.
Tak perlu panjang-panjang menjelaskan dampak dari Planning Before Coding ini. Sederhananya, terasa sulit dan lama di awal saat merencanakan apa saja yang akan dikerjakan dan bagaimana nanti cara pengerjaannya. Tetapi, semua akan terasa lancar ketika diimplementasikan dalam bentuk kode. Ya, itu semua karena semuanya telah terencana sejak awal, kalaupun menemui hambatan tentunya akan jauh lebih mudah menanganinya karena arahnya sudah jelas dari semula.
Lalu, bagaimana cara menerapkan teknik Planning Before Coding ini? Ada beberapa langkah yang kami terapkan yang bagi kami, ini sangat membantu. Dalam hal ini mungkin saya akan fokus dalam konteks frontend development dikarenakan saat itu role saya sebagai frontend developer.
1. Menentukan Requirement Apa Saja yang Dibutuhkan
Dengan adanya Product Requirement Document (PRD), kami sebagai programmer menjadi terbantu untuk memahami apa saja yang user kami butuhkan. Tak hanya itu, semua kesepakatan awal telah tertulis untuk mencegah perubahan yang bersifat mayor yang terjadi di tengah development.
Sebagai programmer, hal ini tentunya sangat membantu ketika development. Dari awal, kami sudah mendapatkan gambaran umum akan proyek ini ketika sudah selesai nanti. Dengan demikian, menentukan fitur apa saja yang akan dikerjakan akan sangat mudah.
2. Menentukan Fitur dan Pembagian Task
Dari sisi backend, kami pun membuat API Contract sebagai pedoman dalam pengembangan API. Sang backend engineer dalam tim kami pun merasa terbantu dengan adanya dokumen ini. Kami bisa menghabiskan waktu 2-3 hari sendiri untuk menentukan endpoint dan response API-nya.
Untuk sisi frontend, tentunya teman saya telah membuatkan beberapa mockup untuk memudahkan frontend development. Tak hanya itu, component UI yang sekiranya bisa dibuat menjadi reusable sudah di-define sejak awal, sehingga ini bisa mengurangi resiko terjadinya redudancy.
Setelah dokumen-dokumen tersebut selesai, tiba saatnya untuk pembagian tugas menggunakan Clickup. Proses task splitting ini sendiri hampir memakan waktu semalaman untuk satu kali planning dalam sebulan. Belum lagi, beberapa hari kemudiannya, kami harus menentukan lagi alur atau cara kami menyelesaikan satu task. Di sini prosesnya juga menyita waktu, karena metode atau cara yang digunakan untuk menyelesaikan satu task haruslah cara yang clean, sehingga ketika melanjutkan task berikutnya, tentunya akan memudahkan.
Bisa dibilang, dalam satu bulan kami bisa menghabiskan 1 minggu pertama hanya untuk planning. Terkesan melelahkan di awal bagi saya saat itu. Tetapi justru dampaknya akan terasa ketika mulai mengerjakan.
3. Memulai Koding
Di sinilah efeknya mulai terasa. Seorang backend engineer dalam tim kami entah bagaimana bisa, dia berhasil menyelesaikan nyaris 90% API yang telah ditentukan dalam API Contract kurang dari sebulan. Ketika kami tanya, ia hanya menjawab Ya gimana, semuanya dah clear sejak awal, palingan kalau bingung ya bingung hal-hal yang baru kepikiran aja.
Dari sisi frontend, karena saya saat itu saya juga masih belajar React, saya merasa agak lambat dalam memahami bagaimana struktur project React dan syntax-syntax-nya. Namun, karena semua telah direncanakan sejak awal, bahkan cara pengerjaan tiap task pun terdeskripsikan dengan baik, saya pun yang seorang pemula bisa dengan lebih cepat memahami dan menyelesaikan task yang ada.
Memang minggu pertama saat pengerjaan dimulai, saya masih kelimpungan. Tetapi, semuanya mulai terasa ringan di minggu-minggu berikutnya karena sebelum mengerjakan, saya membiasakan membaca deskripsi tiap task. Ketika saya paham, barulah saya mulai mengetikan kode di text editor saya. Syukurlah saya bisa menyelesaikannya tepat waktu.
4. Code Review
Setiap kali satu task selesai, saya harus melakukan Merge Request di Gitlab agar teman saya bisa mengulas kembali isi kode yang telah saya tulis. Awalnya, saya sering sekali mendapatkan komentar dan harus revisi kembali karena banyak kode yang bisa dijadikan reusable dan lebih efektif.
Bak bimbingan dosen saat skripsi, proses revisi pun bisa terjadi lebih dari sekali. Ini semata-mata bukan untuk menghambat, tetapi untuk jangka panjang agar kodingan yang ditulis bisa tetap maintainable dan tidak membuat pusing diri sendiri ketika melanjutkannya. Justru pada proses inilah, saya jadi mengerti bagaimana cara membuat kode yang efektif dan maintainable. Tenang saja, semakin sering di-review justru semakin tahu apa saya yang harus di-improve di waktu mendatang.
5. Retropective
Proses retrospective sederhananya adalah refleksi kebelakang dan perencanaan ke depan. Apa saja yang terjadi di masa lalu, dievaluasi dan dicatat. Mulai dari hal positif, hingga hambatan yang sempat terjadi.
Tak hanya itu, setelah evaluasi, kami pun kembali merencanakan apa yang akan dilakukan di masa mendatang untuk penyelesaian proyek ini. Ini contohnya:
Di Kanban kemarin, ada beberapa task yang deskripsinya belum tertulis. Jadi bingung deh cara kerjainnya, makanya ada task yang belum selesai.
Berarti, next planning pastiin semua task nya dah jelas ya. Kalau ada yang belum jelas bisa sambil jalan aja biar gak blocking satu sama lain.
Setelah proses ini selesai, kami kembali ke langkah pertama di bulan berikutnya untuk menyelesaikan sisa task yang ada.
Terkesan simpel, tetapi ini termasuk hal yang fundamental. Inilah sebagian pengalaman pribadi saya saat mengerjakan sebuah proyek. Mohon maaf apabila masih ada kekurangan atau kesalahan dalam artikel ini. Semoga pengalaman ini bisa menginspirasi teman-teman pembaca sekalian.
Discussion