jadi beberapa pengembang / manajer melihat nilai dalam menulis lebih sedikit kode untuk menyelesaikan sesuatu sehingga kita memiliki lebih sedikit kode untuk dipelihara
Ini adalah masalah kehilangan pandangan pada tujuan yang sebenarnya.
Yang penting adalah menurunkan jam yang dihabiskan untuk pembangunan . Itu diukur dalam waktu (atau upaya yang setara), bukan dalam baris kode.
Ini seperti mengatakan bahwa pabrikan mobil harus membuat mobil mereka dengan sekrup yang lebih sedikit, karena dibutuhkan jumlah waktu yang tidak nol untuk memasukkan setiap sekrup. Walaupun itu benar benar, nilai pasar mobil tidak ditentukan oleh berapa banyak sekrup yang dibuatnya. atau tidak punya. Di atas segalanya, mobil harus performan, aman, dan mudah dirawat.
Sisa dari jawabannya adalah contoh bagaimana kode bersih dapat menyebabkan perolehan waktu.
Penebangan
Ambil aplikasi (A) yang tidak memiliki pendataan. Sekarang buat aplikasi B, yang merupakan aplikasi yang sama tetapi dengan logging. B akan selalu memiliki lebih banyak baris kode, dan dengan demikian Anda perlu menulis lebih banyak kode.
Tetapi banyak waktu akan menyelidiki masalah dan bug, dan mencari tahu apa yang salah.
Untuk aplikasi A, pengembang akan terjebak membaca kode, dan harus terus-menerus mereproduksi masalah dan melangkah melalui kode untuk menemukan sumber masalah. Ini berarti bahwa pengembang harus menguji dari awal eksekusi hingga akhir, di setiap lapisan yang digunakan, dan perlu mengamati setiap bagian logika yang digunakan.
Mungkin dia beruntung menemukannya segera, tetapi mungkin jawabannya ada di tempat terakhir yang dia pikirkan.
Untuk aplikasi B, dengan asumsi logging sempurna, pengembang mengamati log, dapat segera mengidentifikasi komponen yang salah, dan sekarang tahu ke mana harus mencari.
Ini bisa berupa hitungan menit, jam atau hari yang disimpan; tergantung pada ukuran dan kompleksitas basis kode.
Regresi
Ambil aplikasi A, yang tidak ramah sama sekali.
Ambil aplikasi B, yang KERING, tetapi akhirnya membutuhkan lebih banyak garis karena abstraksi tambahan.
Permintaan perubahan diajukan, yang membutuhkan perubahan logika.
Untuk aplikasi B, pengembang mengubah logika (unik, dibagi) sesuai dengan permintaan perubahan.
Untuk aplikasi A, pengembang harus mengubah semua instance dari logika ini di mana ia mengingatnya sedang digunakan.
- Jika dia berhasil mengingat semua kejadian, dia masih harus menerapkan perubahan yang sama beberapa kali.
- Jika dia tidak berhasil mengingat semua kejadian, Anda sekarang berurusan dengan basis kode tidak konsisten yang bertentangan dengan dirinya sendiri. Jika pengembang lupa sepotong kode yang jarang digunakan, bug ini mungkin tidak menjadi jelas bagi pengguna akhir sampai jauh di masa depan. Pada saat itu, apakah pengguna akhir akan mengidentifikasi apa sumber masalahnya? Bahkan jika demikian, pengembang mungkin tidak ingat apa perubahan yang terjadi, dan harus mencari cara untuk mengubah potongan logika yang terlupakan ini. Mungkin pengembang bahkan tidak bekerja di perusahaan saat itu, dan kemudian orang lain sekarang harus mencari tahu semuanya dari awal.
Ini dapat menyebabkan pemborosan waktu yang sangat besar. Tidak hanya dalam pengembangan, tetapi dalam berburu dan menemukan bug. Aplikasi dapat mulai berperilaku tidak menentu dengan cara yang tidak mudah dipahami pengembang. Dan itu akan menyebabkan sesi debugging yang panjang.
Pertukaran pengembang
Pengembang Aplikasi yang dibuat A. Kode tidak bersih atau dapat dibaca, tetapi berfungsi seperti pesona dan telah berjalan dalam produksi. Tidak mengherankan, tidak ada dokumentasi juga.
Pengembang A tidak ada selama sebulan karena liburan. Permintaan perubahan darurat diajukan. Tidak bisa menunggu tiga minggu lagi untuk Dev A kembali.
Pengembang B harus melakukan perubahan ini. Dia sekarang perlu membaca seluruh basis kode, memahami bagaimana segala sesuatu bekerja, mengapa itu bekerja, dan apa yang ingin dicapai. Ini membutuhkan waktu lama, tetapi katakanlah dia bisa melakukannya dalam waktu tiga minggu.
Pada saat yang sama, aplikasi B (yang dev B buat) memiliki keadaan darurat. Dev B ditempati, tetapi Dev C tersedia, meskipun ia tidak tahu basis kode. Apa yang kita lakukan?
- Jika kita terus B bekerja di A, dan menempatkan C untuk bekerja di B, maka kita memiliki dua pengembang yang tidak tahu apa yang mereka lakukan, dan pekerjaan itu dilakukan secara optimal.
- Jika kita menarik B menjauh dari A dan membuatnya melakukan B, dan sekarang kita menempatkan C pada A, maka semua pekerjaan pengembang B (atau sebagian besar darinya) mungkin akan dibuang. Ini berpotensi sia-sia beberapa hari / minggu.
Dev A kembali dari liburannya, dan melihat bahwa B tidak memahami kode itu, dan karenanya menerapkannya dengan buruk. Itu bukan kesalahan B, karena ia menggunakan semua sumber daya yang tersedia, kode sumber tidak cukup dapat dibaca. Apakah A sekarang harus menghabiskan waktu memperbaiki pembacaan kode?
Semua masalah ini, dan banyak lagi, akhirnya membuang - buang waktu . Ya, dalam jangka pendek, kode bersih membutuhkan lebih banyak upaya sekarang , tetapi akan membayar dividen di kemudian hari ketika bug / perubahan yang tak terhindarkan perlu ditangani.
Manajemen perlu memahami bahwa tugas singkat sekarang akan menyelamatkan Anda beberapa tugas panjang di masa depan. Gagal merencanakan adalah rencana untuk gagal.
Jika demikian, argumen apa yang dapat saya gunakan untuk membenarkan fakta bahwa lebih banyak LOC telah ditulis?
Penjelasan goto saya bertanya kepada manajemen apa yang mereka inginkan: aplikasi dengan basis kode 100KLOC yang dapat dikembangkan dalam tiga bulan, atau basis kode 50KLOC yang dapat dikembangkan dalam enam bulan.
Mereka jelas akan memilih waktu pengembangan yang lebih pendek, karena manajemen tidak peduli dengan KLOC . Manajer yang fokus pada KLOC mengelola mikro sementara tidak mendapat informasi tentang apa yang mereka coba kelola.