Apakah ada studi kasus yang secara meyakinkan menunjukkan bahwa kode bersih meningkatkan pembangunan? [Tutup]

Saya dalam pekerjaan nyata pertama saya sebagai programmer dan apa yang saya lihat hanyalah kode "Big Ball of Mud" (tanpa komentar yang berguna juga), tapi saya suka melakukan kode bersih, dan sangat sulit bagi saya untuk membuat kode yang lebih buruk cara.

Saya mencari beberapa studi kasus di mana penggunaan kode bersih (saya melihat berbagai definisi di sini tentang apa itu kode bersih) meningkatkan pengembangan dan pemeliharaan.

Sebuah cepat (tapi tidak berarti lengkap) mencari dari Google Scholar muncul banyak artikel yang mengacu pada Bob Martin Bersih Kode , tapi saya pribadi tidak melihat surat-surat yang mencakup hubungan antara "kode yang bersih" dan pengembangan ditingkatkan.

Namun, pikirkan pertanyaan Anda sejenak. Anda bertanya tentang pengembangan yang lebih baik, dan itu sendiri adalah area subyek yang sangat luas yang tidak hanya dicakup dengan menulis kode yang lebih baik, tetapi juga oleh banyak faktor lain seperti komunikasi, mengelola harapan, metodologi dan proses perampingan, pengujian, integrasi berkelanjutan, dan benar-benar seluruh kotak dan dadu ketika Anda mempertimbangkan berapa banyak hal masuk ke dalam membuat proyek pengembangan perangkat lunak berhasil, apalagi meningkatkannya.

Jadi pertanyaan Anda mungkin seharusnya: apakah menulis kode bersih berkontribusi pada peningkatan pengembangan perangkat lunak? Untuk menjawab itu, satu-satunya "bukti" yang bisa saya berikan akan sepenuhnya anekdotal, dan untuk itu saya pikir buku Kode Bersih akan menjadi referensi yang sangat baik, karena ditulis tidak hanya oleh Bob Martin sendiri, tetapi juga dengan banyak bab yang berkontribusi oleh beberapa pengembang perangkat lunak paling cerdas di luar sana. Jika itu tidak membantu, maka mungkin sedikit logika keras yang dingin mungkin berlaku.

Jika Anda membuat kekacauan di rumah Anda, dan Anda tidak pernah membersihkannya, maka tinggal di rumah Anda akan menjadi tugas. Menjadi lebih sulit untuk menemukan hal-hal, lebih sulit untuk bergerak, dan tidak ada orang waras yang mau mengunjungi Anda jika Anda tinggal di lingkungan yang kotor. Sama juga dengan kode. Jika kode Anda berantakan, Anda merasa lebih sulit menemukan masalah, apalagi memperbaikinya. Menjadi lebih mudah untuk membenarkan suatu penyelesaian yang mungkin tidak melakukan pekerjaan, tapi hei, itu pasti mengalahkan harus mengarungi semua kotoran lama, kan? Pada akhirnya, sama seperti tidak pernah merapikan rumah Anda, membiarkan kode Anda menjadi berantakan akan menghabiskan waktu, dan usaha, dan menciptakan kesulitan untuk Anda dalam jangka panjang. Namun menjaga kode Anda tetap bersih akan memberi Anda platform yang lebih baik untuk bekerja, membuat refactoring dan men-debug sedikit dari tugas,

Tidak, saya tidak memiliki bukti langsung untuk diberikan kepada Anda, dan ini hanyalah pemikiran dari seseorang yang telah melakukan hal ini untuk waktu yang sangat lama, dan yang semoga telah memperoleh sedikit kebijaksanaan pengembangan perangkat lunak di sepanjang jalan. :-)

Yang perlu Anda pahami adalah bahwa tidak ada perusahaan yang menetapkan untuk menulis kode biasa-biasa saja. Masalahnya adalah bahwa 50% dari kode, memberi atau menerima, ditulis oleh programmer di bawah rata-rata perusahaan Anda. Anda mengabar ke paduan suara ketika Anda menguraikan manfaat kode bersih. Kuncinya adalah bagaimana melakukannya. Lakukan riset tentang hal-hal seperti alat peer review, analisis statis, pengujian otomatis, integrasi berkelanjutan, TDD, scrum, pemrograman ekstrem, dll. Dan sajikan solusi potensial alih-alih hanya menjelaskan mengapa masalahnya buruk.

Saya tahu ini akan bertentangan dengan butir di sini tetapi waktu untuk memasarkan, mendapatkan persyaratan yang tepat, memiliki dana yang tepat, pemasaran yang baik, titik harga yang tepat dan keberuntungan yang baik jelas memiliki pengaruh yang lebih besar pada keberhasilan produk perangkat lunak daripada kualitas kode.

Ini BUKAN untuk mengatakan kualitas kode harus diabaikan, tetapi, Anda harus mengakui itu hanya salah satu dari banyak faktor.

Ada banyak contoh kode yang benar-benar mengerikan dalam produk yang sangat sukses (misalnya OS Apple asli yang menyerahkan manajemen utasnya ke aplikasi).

Saya tidak dapat memikirkan contoh kode yang indah untuk mengatasi produk yang dikonsep dengan buruk atau terlalu mahal.

Jadi, jika saatnya memasarkan vs kode cantik, waktu ke pasar harus diprioritaskan!

Anda harus memisahkan kode bersih dari sasaran sebenarnya: mengurangi biaya memperbaiki cacat setelah pemasangan dan mengurangi pengerjaan ulang yang tidak perlu. Ketika Anda berbicara tentang "menulis kode bersih agar lebih sedikit bug", Anda sedang berbicara tentang agama. Ketika Anda berbicara tentang "mengurangi tingkat cacat sebesar 10%, menghemat 2 bulan kerja manusia di proyek", Anda berbicara manajemen. Kode bersih adalah alat untuk meningkatkan kualitas awal basis kode dan dengan demikian menurunkan total biaya, tetapi merupakan salah satu dari banyak.

Makalah berikut menjelaskan mengapa memperbaikinya pertama kali penting dari perspektif biaya: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

Saya tidak mengetahui adanya studi khusus, tetapi periksa pekerjaan oleh Steve McConnell .

Jika ada yang memilikinya, dia akan melakukannya. Misalnya pemindaian dua menit ditemukan ini (16 tahun tetapi masih relevan hari ini).

Untuk menambah jawaban mattnz, jika Anda belum melakukannya, saya akan mengatakan secara khusus periksa Kode Selesai: Buku Pegangan Praktis Konstruksi Perangkat Lunak oleh Steve McConnell. Selain fakta bahwa itu kemungkinan akan meningkatkan pengkodean Anda, ia mengutip banyak penelitian di seluruh buku tentang bagaimana berbagai praktik pengkodean mempengaruhi kualitas program.

Sebagai contoh (dari buku):

Studi lain dari 450 rutin yang berbeda (yang hanya kebetulan yang tidak biasa) menemukan bahwa rutin dengan rasio kopling terhadap kohesi tertinggi memiliki kesalahan 7 kali lebih banyak dibandingkan dengan rasio kopling-ke-kohesi terendah dan 20 kali lebih mahal. untuk memperbaikinya (Selby dan Basili 1991).

Juga digunakan sebagai jawaban nomor satu untuk pertanyaan Apa buku tunggal paling berpengaruh yang harus dibaca setiap programmer? (meskipun saya melihat jawaban untuk pertanyaan ini baru-baru ini ditata ulang dengan cara yang lemah)