Algoritma Pengembangan Perangkat Lunak Kami

• Dalam percakapan baru-baru ini dengan seorang CEO teknologi ternama dan seorang insinyur, saya mendengar metodologi pengembangan perangkat lunak yang menarik. Metodologi ini membuat saya memikirkan heuristik dan generalisasi lainnya.

Metodenya

• Mulai mengerjakan sebuah fitur di awal hari. Jika belum selesai hingga akhir hari, hapus semuanya dan mulai lagi keesokan harinya. Unit test yang sudah ditulis boleh dipertahankan.
• Jika setelah beberapa hari fitur itu masih belum bisa diimplementasikan, pikirkan fondasi, infrastruktur, atau refaktorisasi yang memungkinkan fitur tersebut, implementasikan itu terlebih dahulu, lalu kembali ke fiturnya.
• Metode ini mirip dengan gerakan extreme programming pada akhir 1990-an dan awal 2000-an.

Pemikiran tentang metode ini

"Tulis semuanya dua kali"

• Nasihat untuk insinyur junior: selesaikan masalahnya, simpan kodenya di branch, lalu tulis ulang.
• Saya menemukan metode ini secara kebetulan setelah laptop saya rusak. Penulisan ulang hanya memakan 25% dari waktu implementasi awal, dan hasilnya jauh lebih baik.
• Dengan waktu 1,25x, Anda bisa mendapatkan kode dengan kualitas 2x lebih tinggi. Berguna untuk proyek yang membutuhkan pemeliharaan jangka panjang.
• Metode "mulai lagi setiap hari" bahkan lebih ekstrem daripada ini. Setiap kali menulis ulang, Anda cenderung menemukan solusi yang lebih mulus.

"Kuantitas memiliki kualitas"

• Kutipan Stalin ini berlaku untuk insinyur perangkat lunak. Bagi insinyur junior, 100 ribu baris kode pertama itu penting.
• Metode "mulai lagi setiap hari" membantu Anda menulis 100 ribu baris itu lebih cepat.
• Menyelesaikan masalah yang sama berulang kali bermanfaat untuk mengingat pola.
• Dengan 5 ribu baris kode yang sempurna, Anda bisa melihat semua pola utama. Sisa 95 ribu baris menata ulang neuron melalui pengulangan.

Perbandingan dengan heuristik "senjata di kepala"

• Kepada orang yang mengusulkan solusi untuk suatu masalah, tanyakan: "Jika harus selesai dalam 24 jam, apa yang akan Anda lakukan?"
• Metode ini memecah bias framing dan anchoring. Sering kali ini dapat menghasilkan rencana yang bisa selesai dalam sehari hanya dalam beberapa menit.
• Dalam praktiknya, itu bukan rencana yang benar-benar bisa selesai dalam sehari, tetapi solusi baru tersebut sering kali bisa diselesaikan dalam beberapa hari.
• Tujuan eksperimen pikiran ini bukan untuk menghasilkan solusi yang benar-benar siap pakai, melainkan untuk menetapkan batas bawah solusi.

Menemukan jalur

• Kuncinya adalah menemukan jalur dalam ruang masalah. Setiap jalur adalah solusi, dan peran insinyur adalah menemukan jalur terbaik.
• Layak untuk memikirkan kemiripan antara heuristik semacam ini dan berbagai algoritme pencarian jalur.
• Hal yang sama berlaku untuk heuristik engineering: menjadi insinyur yang lebih baik berarti menemukan jalur yang lebih baik dalam ruang masalah.

Ringkasan GN⁺

• Tulisan ini mengeksplorasi metodologi dan heuristik yang efisien dalam pengembangan perangkat lunak.
• Metode "mulai lagi setiap hari" dan "tulis semuanya dua kali" berguna untuk meningkatkan kualitas kode.
• Pemecahan masalah secara berulang membantu pengenalan pola dan penataan ulang neuron.
• Heuristik "senjata di kepala" berguna untuk menetapkan batas bawah solusi.
• Menemukan jalur terbaik dalam ruang masalah adalah peran inti seorang insinyur.

[ahwjdekf]

Gila? Hanya orang-orang yang punya waktu segunung yang mungkin bisa melakukan ini; apakah ini masuk akal untuk dilakukan di dunia nyata?

[dlehals2]

Di lingkungan SI Korea, ini mungkin tidak bisa ya.. hehe paling cuma untuk proyek pribadi

[kaistj]

Pendekatan ini benar-benar cara yang sama sekali tidak pernah terpikirkan.
Sepertinya saya harus mencobanya hehe

[eususu]

Saya sangat setuju soal menulis ulang.
Dulu saya pernah tidak sengaja menghapus kode yang sedang saya kerjakan, lalu saat menulisnya kembali
saya jadi membuatnya dengan mempertimbangkan hal-hal yang sebelumnya saya abaikan karena malas mengubah desain di tengah jalan,
dan hasilnya justru lebih baik.

[GN⁺]

Opini Hacker News

• Menulis fitur baru dua kali adalah strategi yang baik. Namun, bagi developer bisnis atau manajer proyek, ini bisa terlihat sebagai penundaan yang tidak perlu

  • Menulis fitur dari awal sampai akhir membantu merapikan logika dan melakukan refactor
  • Menulis ulang membantu memperjelas alur logika dan memungkinkan rencana diikuti dengan lebih linear
  • Ini cenderung mengurangi kebutuhan akan refactor besar di kemudian hari

• Pertanyaan seperti "bagaimana kalau harus selesai dalam 24 jam?" adalah pertanyaan yang tidak bisa diajukan manajer proyek

  • Ini adalah latihan pembelajaran pribadi, bukan cara untuk menyelesaikan pekerjaan lebih cepat

• Kode yang baik ditulis dengan memilih abstraksi yang tepat

  • Untuk memilih abstraksi yang tepat, kita harus memahami keseluruhannya
  • Di bidang rekayasa lain, ada paradigma blueprint yang baik seperti layout CAD
  • Di perangkat lunak, blueprint semacam ini masih kurang
  • Itulah sebabnya pengalaman penting untuk menjaga keseimbangan

• Jika ada rekan kerja yang kompeten, mereka bisa menunjukkan apa yang dapat dilakukan dalam waktu singkat

  • Ada banyak alasan mengapa bekerja cepat itu penting
  • Sama seperti memperbaiki mobil, makin lama waktunya, makin besar kemungkinan kita lupa cara merakitnya kembali
  • Jika sebuah fitur diimplementasikan dalam satu hari, risikonya berkurang
  • Dibutuhkan pemahaman yang kuat terhadap alat yang digunakan serta proses CI/CD yang andal

• Saya setuju dengan pendapat bahwa perangkat lunak sebaiknya ditulis dua kali

  • Setelah kehilangan kode yang pernah ditulis sekali, motivasi untuk menulisnya lagi jadi hilang
  • Saat mencoba menulis ulang, sulit fokus dan pendekatannya pun tidak lagi diingat

• Jika bahkan setelah beberapa hari sebuah fitur masih belum bisa diimplementasikan, maka infrastruktur atau refactor yang dibutuhkan harus dikerjakan lebih dulu

  • Penting untuk membangun dan memelihara 'kosakata' alat yang digunakan

• "dalam 24 jam" dan "menulis semuanya dua kali" saling berkaitan

  • Jika kode ditulis asal-asalan, pada akhirnya kita akan menulis ulang juga

• Postingan ini adalah salah satu "nasihat pemrograman" terbaik

  • Mirip dengan saran dari grug brained developer

• Terkadang perlu menjalankan thread latar belakang untuk menyelesaikan masalah

  • Orang yang lebih berpengalaman bisa mengidentifikasi masalah seperti ini lebih cepat
  • Kadang lebih baik membiarkan masalah itu sebentar dan mengerjakan hal lain dulu

• Pendekatan berikut berguna

  • Tulis dulu beberapa ide untuk menyelesaikan masalah
  • Bagi pekerjaan menjadi bagian yang 'bisa selesai dalam satu sesi'
  • Implementasikan sedemikian rupa sehingga kode selalu 'berfungsi' di akhir setiap sesi
  • Di akhir setiap sesi, tuliskan brain dump di komentar atau README