Butuh 6 Hari untuk Mengubah Satu Baris Kode (2015)

• Pabrik dimanfaatkan kurang dari 10%.
• Kebijakan perusahaan membatasi pembuatan backlog lebih dari 3 bulan.
• Mengubah kebijakan menjadi 4 bulan akan menyelesaikan masalah.
• Mengubah pengaturan pada perangkat lunak legacy mengharuskan perubahan satu baris kode.
• Proses penerapan perubahan mencakup pengajuan tiket, menyelesaikan bagian yang diperlukan, dan mendapatkan persetujuan direktur.
• Perubahan ini mendesak untuk menghindari pemutusan hubungan kerja.
• Programmer berhasil mengubah kode, tetapi masalah muncul karena variabel yang di-hardcode dan kesalahan lainnya.
• Kode memerlukan review salinan dan pengujian, dan hanya setelah itu dapat dipindahkan ke production.
• Akses ke lingkungan pengujian yang diperlukan tertunda karena masalah otorisasi dan ketersediaan.
• Rekaman parameter harus diganti namanya dan memiliki jejak audit.
• Programmer melakukan perubahan yang diperlukan dan mengajukan kembali kode untuk direview.
• Pengujian memerlukan rencana uji yang tepat, termasuk test case yang dipilih pengguna dan hasil yang diharapkan.
• Setelah 6 hari, program disetujui untuk dipindahkan ke production.

[GN⁺]

Komentar Hacker News

• Masalah utamanya adalah menolak ketika reviewer meminta perubahan yang memengaruhi bagian lain dari codebase.
• Pull request yang terfokus dan penolakan terhadap scope creep adalah pelajaran penting.
• Proses code review bisa dipenuhi kritik yang rewel dan komentar sepele.
• Tim keamanan mungkin tidak merespons permintaan izin dengan cepat.
• Judul artikelnya bisa menyesatkan, dan selama 6 hari itu ada perbaikan tambahan.
• Perubahan satu baris dapat menimbulkan konsekuensi yang tidak terduga.
• Proses code review bisa menjadi gatekeeper dan menunda progres.
• Mengizinkan komentar tanpa memblokir commit dapat menghasilkan pengembangan yang lebih efisien.
• Berpindah dari tim yang melakukan code review formal ke tim yang tidak melakukannya bisa terasa menyegarkan dan memberdayakan.
• Ada perbedaan dalam cara mengelola pekerja pabrik dan pengembang perangkat lunak.
• Menahan perubahan berdasarkan ideal tim yang terus berubah adalah hal yang disfungsional.
• Masalahnya ada pada proses perusahaan, bukan pada code review itu sendiri.