Kebiasaan Baik dalam Pengembangan Perangkat Lunak

• Tulisan ini bukan nasihat, melainkan uraian tentang kebiasaan pengembangan yang saat ini diterapkan oleh penulis
• Ini adalah rangkuman pengalaman berupaya menghindari kebiasaan buruk dan membangun kebiasaan baik, yang membahas 10 kebiasaan yang membantu meningkatkan produktivitas dan menjaga kualitas

1. Menjaga commit tetap kecil

• Commit harus dijaga sekecil mungkin. Commit kecil memungkinkan kita membatalkan hanya commit tertentu saat bug muncul, sehingga bisa menghindari konflik merge yang rumit
• Penulis menjadikan "perangkat lunak harus bisa di-commit saat berhasil dikompilasi" sebagai aturan

2. Refactoring berkelanjutan

• Saran Kent Beck: "Ketika Anda menginginkan perubahan, terlebih dahulu buat perubahan menjadi mudah, lalu buat perubahan itu."
• Setidaknya separuh dari commit diupayakan mengandung refactoring. Refactoring kecil sangat membantu saat ada kebutuhan besar yang masuk
• Refactoring besar sebaiknya dihindari. Sebagai gantinya, lakukan perbaikan kecil secara terus-menerus yang bisa diselesaikan dalam waktu kurang dari 10 menit

3. Pentingnya deployment kode

• Kode itu sendiri adalah utang potensial, dan kode yang belum di-deploy adalah utang terbesar
• Testing memberi rasa percaya diri, tetapi deployment nyata berarti persetujuan yang sesungguhnya
• Semakin sering deployment dilakukan, biaya hosting bisa meningkat, tetapi memastikan pekerjaan terbaru benar-benar berjalan adalah keuntungan yang penting

4. Jangan menguji fungsi framework

• Tidak perlu menguji fungsi framework. Framework sudah cukup tervalidasi
• Jika komponen dijaga tetap kecil, framework akan menangani sebagian besar pekerjaan sehingga jumlah testing berkurang
• Komponen besar menambah kompleksitas, dan akibatnya membutuhkan banyak testing

5. Membuat modul baru

• Jika suatu fungsi tertentu tidak cocok dengan modul yang ada, lebih baik membuat modul baru
• Daripada memaksakan penambahan fungsi ke modul yang sudah ada, lebih baik membiarkannya sebagai modul yang independen

6. Penerapan fleksibel test-driven development (TDD)

• Jika desain API belum jelas, tulis testing terlebih dahulu agar bisa berpikir dari sudut pandang "pelanggan"
• TDD tidak diikuti sebagai prinsip yang dogmatis. Jika perlu, kita bisa bekerja dalam unit yang lebih besar terlebih dahulu lalu menulis testing
• Kode dalam unit kecil tidak harus dibuat gagal terlebih dahulu, dan tidak perlu terikat pada dogmatisme yang menurunkan produktivitas

7. Copy-paste hanya diizinkan sekali

• Satu kali menyalin tidak masalah, tetapi mulai salinan kedua akan muncul duplikasi
• Pada titik ini, duplikasi harus dihilangkan melalui abstraksi yang tepat. Meskipun parameterisasi terlihat agak aneh, itu tetap lebih baik daripada menggabungkan beberapa implementasi

8. Menerima perubahan desain

• Desain akan menua seiring waktu. Refactoring bisa memperlambat penuaan, tetapi pada akhirnya perubahan tidak bisa dihindari
• Jangan terlalu terobsesi pada desain sebelumnya, dan kita perlu menerima perubahan
• Tidak ada desain yang sempurna, dan kemampuan menghadapi perubahan dengan baik adalah inti dari pengembangan perangkat lunak

9. Tiga jenis technical debt

• Technical debt dapat diklasifikasikan menjadi tiga jenis:
  1. Hal yang menghambat pekerjaan saat ini
  2. Hal yang berpotensi menghambat pekerjaan di masa depan
  3. Hal yang mungkin saja berpotensi menghambat
• Utang jenis pertama harus diminimalkan, fokus pada jenis kedua, dan jenis ketiga sebaiknya diabaikan

10. Hubungan antara testability dan desain yang baik

• Jika sulit diuji, besar kemungkinan ada masalah pada desain
• Desain testing juga bisa menjadi objek perbaikan. Misalnya, jika terasa sulit membuat mock untuk em.getRepository(User).findOneOrFail({id}), sebaiknya pisahkan ke fungsi terpisah atau gunakan utility testing
• Alasan testing tidak ditulis adalah karena sulit diuji, dan ini bisa jadi merupakan masalah desain

[yangeok]

Tampaknya yang lebih penting daripada DRY adalah tercapainya SRP, jadi bahkan kalau diserahkan ke AI, dia tidak akan mengeluarkan omong kosong.

[progdesigner]

Menurut saya, yang paling penting adalah seberapa baik kita membangun kode dan lingkungan yang bisa cepat beradaptasi terhadap perubahan.

Lalu, melalui abstraksi yang tepat, kita bisa meningkatkan reusabilitas dan skalabilitas kode, serta memanfaatkan alat AI untuk memaksimalkan kecepatan pengembangan.

[pcj9024]

Tulisan yang sangat bagus. Rasanya ingin merekomendasikannya ke sana-sini.

[tsboard]

Terima perubahan, cukup copy-paste sekali, buat pengujian berjalan lebih baik, dan buat commit lebih kecil...!

[aer0700]

Tulisan yang bagus.

[puersum]

Menurut saya, akan sangat baik kalau Anda melihat versi aslinya.
Kalau ada berita yang menarik perhatian, saya biasanya melihat sumber aslinya, dan untuk yang ini rasanya terutama begitu. Jika melihat poin 1, di teks asli tertulis
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. tetapi di sini diringkas menjadi "komit harus dijaga sekecil mungkin"..

[ilbanin00]

Tulisan yang sangat bagus.

[joon14]

Nomor 7 benar-benar bagus.

[GN⁺]

Opini Hacker News

• Sebaiknya gunakan parameter untuk menghindari banyak implementasi. Memperbaiki parameter lebih mudah daripada menyatukan banyak implementasi.

  • Jika "parameter aneh" tidak bisa dihindari, lebih baik pisahkan kodenya. Hindari flag boolean dan beberapa parameter enum.
  • Signature fungsi yang kompleks membuat pemeliharaan menjadi sulit.

• Menyalin kode sekali masih tidak masalah, tetapi mulai kali kedua sebaiknya hindari duplikasi. Abstraksi yang baik harus dibuat saat sudah ada cukup data point.

  • Meski kode pada awalnya terlihat sama, saat perubahan diperlukan, fokuslah pada apakah keduanya memang harus berubah bersama.
  • Tujuannya bukan menghindari duplikasi kode, melainkan menjaga agar kode yang harus berevolusi bersama tetap dikelola bersama.

• DRY (jangan mengulang) atau WET (tulis semuanya dua kali) bukan aturan yang absolut. Memahami duplikasi kode dan kapan harus menggabungkannya adalah persoalan yang sulit.

• Sebagai alternatif untuk commit kecil, Anda bisa menambahkan commit baru yang memperbaiki bug tanpa membatalkan commit besar.

  • Tidak jelas mengapa refactoring besar itu buruk.
  • Membuat struktur yang independen lebih baik daripada memaksakannya ke modul yang sudah ada.
  • Saat merancang API, Anda bisa mengadakan sesi desain alih-alih hanya mengandalkan unit test.

• Kemudahan untuk diuji berkaitan dengan desain yang baik. Jika sesuatu tidak mudah diuji, itu bisa menjadi sinyal bahwa desainnya perlu diubah.

  • Kode pengujian juga perlu ditinjau dengan cara lain.

• Berhati-hatilah saat menguji fitur framework. Framework dapat berubah seiring waktu.

  • Memastikan keamanan saat melakukan upgrade dependensi adalah peran penting dari pengujian.

• Soal ukuran commit, sebaiknya targetkan commit yang mudah dibatalkan jika suatu perubahan tertentu perlu dikembalikan.

• Perusahaan menginginkan codebase yang stabil, tetapi refactoring berkelanjutan tetap diperlukan. Hal ini bisa bertentangan dengan stabilitas.