6 Kebiasaan Baik yang Saya Pelajari dalam Membangun Software

https://unsplash.com/photos/FCHlYvR5gJI

Dulu sebagai software developer, kebahagiaan saya adalah ketika bisa menyelesaikan sebuah fitur sebanyak-banyaknya. Butuh fitur A? sikat! Fitur B, C, D, lembur!. Ini juga pernah saya tuliskan kebiasaan-kebiasaan buruk developer yang biasanya dianggap remeh.

5 Kebiasaan (tidak) Baik Programmer

Kemudian tidak lama fiturnya berubah spesifikasi bahkan ada yang harus diselipkan di antara fitur A dan B. Karena awalnya dibuat tanpa perencanaan yang matang maka ada banyak technical debt atau abstraksi tidak penting sehingga mengakibatkan penambahan fitur kecil pun menjadi sangat sulit.

Kita sebagai software developer setidaknya pernah merasakan hal ini kan? Sebagai kaum yang menjadikan “long live learner” sebagai salah satu jalan ninjanya tentu ini adalah hal normal kan? Jadi saya ada beberapa kebiasaan baik dalam membuat software yang bisa saya bagikan di sini.

Pahami Tujuan Sebuah Fitur atau Perubahannya

Seberapa sering kita mengerjakan sebuah fitur yang kita ketahui hanya spesifikasinya tanpa tau tujuan dibuatnya fitur itu untuk apa? Sekarang ini saya harus terlebih dahulu mencari tahu tujuan dari sebuah fitur tersebut sebelum memulai untuk membangun.

Beberapa poin yang biasanya saya gali, diantaranya:

• Mengapa fitur atau perubahan ini dibutuhkan?
• Seberapa penting fitur ini dibutuhkan?
• Apakah ada keterkaitan dengan fitur lain?
• Apakah fitur ini sifatnya sementara atau jangka panjang?

Dua pertanyaan awal tadi bisa membantu saya untuk mengetahui apakah fitur tersebut memang benar diperlukan atau tidak.

Hei bagaimana bisa ada fitur yang ternyata tidak diperlukan?

Bisa jadi yang diminta memiliki tujuan yang cukup sederhana tapi pemilik produk atau klien terlalu rumit dalam berpikir. Meminta otomasi yang rumit padahal yang dibutuhkan dapat diselesaikan dengan Excel / Spreadsheet. Tentu ya harus didiskusikan agar jalan tengahnya dapat ditemukan. Ini membantu kita untuk terhindar dari pnegerjaan yang berujung sia-sia.

Tugas kita adalah problem solver kan?

Mulai dengan Perencanaan

Akhir-akhir ini saya mulai meninggalkan kebiasaan coding tanpa perencanaan matang. Berdasarkan pengalaman, coding tanpa perencanaan berakhir dengan:

• Over engineering / Unnecessary abstraction
• Technical debt

Over engineering / pembuatan abstraksi yang tidak perlu karena “ingin terlihat keren” terlahir akibat tidak memikirkan trade off dari sebuah metode. Pernah saya melakukan rewrite hasil pekerjaan satu sprint (2 minggu) karena langsung melakukan coding berdasarkan design pattern yg muncul di pikiran saya saat itu juga.

Butuh hampir satu sprint untuk menyadari jika apa yang saya lakukan justru lebih banyak trade off negatif daripada positifnya. Weekend saya habis untuk rewrite ini, untunglah integration test membuat rewrite menjadi lebih cepat.

Technical debt? Sudah pasti.

1 jam perencanaan bisa jadi menghemat banyak jam nanti untuk kita memperbaiki kesalahan apa yang seharusnya bisa kita hindari.

Perencanaannya tidak perlu lama dan bertele-tele. Saat ini batasan perencanaan saya mencakup:

• Menghindari abstraksi terlalu dini. KISS (Keep It Simple Stupid) tapi ya tidak bodo-bodo amat. Sesuaikan sama tujuan fitur dan relasi antar modulnya.
• Pilih metode yang memiliki resiko paling minim. Utamakan delivery karena lebih cepat feedback yang didapat lebih baik karena kita masih punya waktu untuk iterasi melakukan perbaikan.
• Menentukan exit strategy dengan menyediakan beberapa rencana cadangan jika dalam pelaksanaannya tidak sesuai rencana awal. Ini penting agar delivery kita tidak terhambat atau dapat mengkomunikasikan roadblock kepada stakeholder.

Self Code Review Sebelum PR / MR

Saat bekerja bersama tim atau sendiri, saya merasakan pentingnya untuk melakukan code review mandiri sebelum melakukan merge. Biasanya dilakukan saat Pull Request / Merge Request dengan melakukan inspeksi sederhana pada hasil coding yang sudah dibuat.

Kenapa saat PR / MR? Karena di sana saya bisa fokus memeriksa perubahan hanya pada berkas yang akan di-merge saja sehingga lebih menghemat waktu daripada harus mengingat berkas apa saja yang sudah dirubah saat coding berlangsung.

Beberapa hal yg saya periksa di sini biasanya:

• Typo dan dead code
• Code smell yang bisa dilihat secara kasat mata
• Beberapa perubahan yang mungkin tidak diinginkan

Jika sudah melakukan perencanaan di awal biasanya saat review mandiri tidak akan banyak ditemukan masalah kecuali typo dan dead code. Hasilnya? Meminimalisir bug dan memastikan code quality dalam keadaan baik.

Implementasikan Test

Ini sampai sekarang masih susah didisiplinkan karena:

• Pengetahuan teknis masih terbatas.
• Deadline sering tidak negotiable.

Tapi manfaat test ini yang saya rasakan sampai sekarang terasa besar sekali dalam menjaga level ke-pede-an seorang developer dalam membangun software. Tidak perlu lagi was-was modul X rusak karena kita membangun modul Z yang sama-sama memiliki keterkaitan dengan modul Y. Tinggal jalankan automated test, kita langsung tahu apakah semua berjalan dengan semestinya atau tidak.

Asumsikan waktu saya tidak banyak untuk menulis tes maka prioritas saya:

1. Integration test / functional test dengan scope positif test. Kalau dalam pengerjaan API kita test pengiriman request, response yang diharapkan, dan data yang tersimpan di database.
2. Tambahkan negatif test yang mungkin umum terjadi seperti pengiriman invalid data.
3. Unit test pada class jika dibutuhkan.

Dengan mengetahui tujuan fitur dan melakukan perencanaan yang baik, implementasi test ini bisa jadi lebih mudah dilakukan karena kita sudah memiliki gambaran dari input dan output yang diharapkan.

Small Refactor

Kunci efektifitas refactor sebenarnya ada pada test yang sudah dibuat tadi. Dengan test kita bisa cepat mengetahui dengan cepat apakah hasil refactor tidak merusak keseluruhan atau sebagian codebase.

Small refactor biasanya lebih kepada perbaikan-perbaikan yang minim resiko dan bertujuan untuk meningkatkan readability seperti penyesuaian variable, docblock, dan faktor lain yang tidak mengganggu alur proses.

Ini biasanya saya lakukan ketika:

1. Code review mandiri
2. Menulis integration test / unit test.
3. Ada waktu senggang (emang ada? :D)

Seperti yang saya bilang tadi, small refactor ini memang lebih saya tujukan agar hasil coding saya lebih mudah dibaca dan dipahami oleh developer yang lain.

Menulis Dokumentasi

Saya baru merasakan pentingnya dokumentasi pada masa-masa WFH yang mana semua tim harus bekerja remote sehingga mau tidak mau async work harus bisa dilakukan kalau tidak mau energi habis untuk online meeting. Inilah peran dokumentasi menjadi penting.

Dokumentasi yang saya buat bukan dokumentasi formal dan bertele-tele, melainkan dokumentasi teknis sederhana yang dapat straightforward dengan permasalahan dan solusi yang sedang dikerjakan.

Paling mudah bisa kita dokumentasikan di aplikasi task management yang kita gunakan biasanya.

Biasanya yang saya dokumentasikan:

• Ringkasan tujuan fitur
• Ringkasan perencanaan pembuatan sebuah fitur bisa berupa flowchart, diagram arsitektur, atau aturan-aturan tertentu dalam pengerjaan suatu fitur.
• To do list roadmap pengerjaan fitur agar tim atau saya sendiri dapat mengetahui state pengerjaan sudah sampai mana.

Manfaatnya?

• Anggota tim atau developer baru cukup melihat dokumentasi yang kita buat, jika sudah paham maka tidak perlu membuang waktu untuk bertanya atau setup meeting sehingga waktu bisa lebih banyak dialokasikan untuk membangun software.
• Dokumen untuk diri sendiri jika suatu saat harus melihat fitur-fitur lama yang mungkin kita lupakan teknisnya seperti apa.
• Jika suatu saat kita tidak available, tim atau atasan tinggal melihat dokumentasi yang kita buat kemudian melanjutkan apa yang sudah kita lakukan.

Penutup

Kebiasaan-kebiasaan baik ini memang tidak bisa dilakukan secara instan. Perlu disiplin dan evaluasi secara bertahap apakah memang bermanfaat dalam memberikan hasil baik dalam proses pembuatan software itu sendiri.

Kalau kebiasaan-kebiasaan baikmu apa saja? Yuk share di komentar ya atau mention saya di twitter @didikz

Happy coding!