Bagaimana cara berdebat dengan menurunkan standar kualitas untuk basis kode warisan? [Tutup]

Kami memiliki basis kode legacy besar dengan kode buruk yang tidak dapat Anda bayangkan.

Kami mendefinisikan beberapa standar kualitas sekarang dan ingin mendapatkan yang dipenuhi dalam basis kode yang sama sekali baru, tetapi juga jika Anda menyentuh kode lawas.

Dan kami menegakkan mereka yang menggunakan Sonar (alat penganalisa kode), yang sudah memiliki ribuan pelanggaran.

Sekarang diskusi muncul untuk menurunkan pelanggaran-pelanggaran untuk warisan. Karena itu warisan.

Pembahasannya adalah tentang aturan keterbacaan. Seperti berapa banyak nested ifs / for .. yang bisa didapat.

Sekarang bagaimana saya bisa membantah menurunkan kualitas pengkodean kami pada kode lama?

Kode hanyalah sarana untuk mencapai tujuan. Apa akhir itu mungkin bervariasi, tetapi biasanya itu untung.

Jika itu untung; kemudian dengan berhasil memperdebatkan apa pun yang Anda ingin tunjukkan bahwa itu akan meningkatkan laba - misalnya dengan meningkatkan penjualan, mengurangi biaya perawatan, mengurangi biaya pengembangan, mengurangi upah, mengurangi biaya pelatihan ulang, dll. Jika Anda tidak dapat / tidak menunjukkan bahwa itu akan meningkatkan laba; maka Anda kebanyakan hanya mengatakan itu akan menjadi cara yang menyenangkan untuk menyiram uang ke toilet.

Saya, saya sendiri, dan saya, telah menjadi produser dan pemelihara kode warisan. Jika alat Anda menghasilkan "ribuan pelanggaran" (atau bahkan ratusan dalam hal ini), lupakan alat itu, itu tidak dapat diterapkan pada situasi ...

Saya menganggap pengembang asli sudah lama hilang dan tidak tersedia untuk diskusi. Jadi tidak ada orang di sekitar yang mengerti mengapa dan karenanya dari gaya desain dan pengkodean. Memperbaiki ratusan atau ribuan pelanggaran tidak akan menjadi masalah menulis ulang beberapa baris kode di sana-sini. Sebaliknya, itu tidak diragukan lagi membutuhkan refactoring / re-fungsional-dekomposisi. Anda mencoba melakukan itu pada basis kode besar yang ada, tanpa memahami desainnya saat ini, dan Anda pasti akan memperkenalkan serangkaian bug / masalah / dll. Hanya satu kaleng cacing yang lebih buruk dari yang Anda miliki sekarang (atau lebih buruk dari alat Anda >> pikir << sekarang Anda miliki).

Satu-satunya pendekatan yang masuk akal untuk mengatasi "ribuan pelanggaran" adalah menulis ulang dari awal. Upaya yang panjang dan mahal, dan hampir mustahil untuk dijual kepada manajemen. Dan dalam hal ini mereka mungkin benar ...

Kode lama biasanya hanya membutuhkan tweak. Seperti untuk y2k, atau ketika saham beralih dari 256 ke desimal. Saya melakukan banyak kedua cr * p itu. Dan banyak hal serupa lainnya. Biasanya cukup "tepat" di mana Anda dapat "membaca" gaya kadang-kadang buruk, dekomposisi fungsional buruk, dll buruk, dan menemukan kumpulan tempat yang perlu dimodifikasi. Dan kemudian, apa yang terjadi "antara tempat-tempat itu", yaitu, apa yang lebih banyak aliran tingkat tinggi, dapat tetap menjadi misteri bagi Anda. Pastikan Anda memahami fungsi terlokalisasi yang Anda ubah, dan kemudian menguji, menguji, menguji segala efek samping, dll., Pengetahuan lokal Anda tidak akan dapat diantisipasi.

Jika Anda tidak dapat melihat jalan Anda melalui kode seperti itu, maka Anda mungkin bukan orang terbaik untuk mempertahankan kode lama. Beberapa orang dapat mulai dengan layar kosong dan menulis program yang indah, tetapi tidak dapat memulai dengan basis kode besar kode orang lain dan memeliharanya. Orang lain dapat mempertahankan kode, tetapi tidak dapat memulai dari awal. Beberapa dapat melakukan keduanya. Pastikan orang yang tepat mempertahankan kode lawas Anda.

Saat-saat sesekali Anda mungkin ingin mendesain ulang dan menulis ulang basis kode warisan Anda dari awal adalah ketika persyaratan bisnis (atau lainnya) berubah sedemikian rupa sehingga "tweaks" kursi-of-the-celana tidak bisa mengakomodasi persyaratan yang diubah lagi . Dan pada titik itu, Anda mungkin juga memulai dengan menulis dokumen persyaratan fungsional baru, memastikan semua pemangku kepentingan ada di dalamnya. Ini pada dasarnya adalah ballgame yang benar-benar baru.

Satu-satunya-satunya >> yang salah << yang harus dilakukan adalah mencoba memperlakukan pemeliharaan kode lama dengan cara yang sama seperti Anda melakukan pengembangan baru. Dan satu hal yang salah itu tampaknya adalah jalan yang ingin Anda lewati :) Terima kata-kata saya untuk itu, itu bukan yang ingin Anda lakukan.

Pertanyaannya bukan seberapa baik atau buruk kode itu. Pertanyaannya adalah berapa banyak manfaat yang Anda dapatkan dari berapa banyak investasi.

Jadi, Anda memiliki alat yang menemukan ribuan hal yang tidak disukainya. Anda memiliki pilihan untuk mengabaikan hasil alat, atau menginvestasikan pekerjaan untuk mengubah ribuan hal. Itu banyak hal. Orang tidak akan fokus, tidak saat membuat perubahan, tidak saat meninjau mereka, dan ini tidak akan diuji dengan baik karena butuh waktu lama untuk mengetahui cara menguji (atau hanya untuk mencoba) setiap perubahan, sehingga akan ada bug. Jadi, sampai Anda menemukan dan memperbaiki bug itu, Anda menginvestasikan banyak waktu dan uang dengan hasil negatif secara keseluruhan.

Di sisi lain, alat dapat menemukan hal-hal yang mereka tidak hanya "tidak suka", tetapi itu adalah bug atau bug potensial. Jika kode lawas masih digunakan secara luas, maka alat yang tepat dapat benar-benar menemukan bug. Jadi menyalakan peringatan kompiler satu per satu, memeriksa apakah itu berguna (tidak semua berguna) dan memperbaiki peringatan itu bisa bermanfaat.

Jika tidak rusak jangan memperbaikinya

Ini praktis harus ditato pada setiap pengembang dan manajer perangkat lunak sehingga mereka tidak pernah melupakannya.

Ya, itu merusak semua konvensi pengkodean modern. Ya, ini ditulis dalam FORTRAN-77 dengan pembungkus dalam C sehingga dapat dipanggil dari Python. Ya, itu adalah GOTO yang tidak terstruktur. Ya, ada satu subrutin yang panjangnya tiga ribu baris. Ya, nama variabel hanya masuk akal bagi orang Kroasia. dll. dll

Tetapi jika itu telah diuji dalam kemarahan selama lebih dari satu dekade atau lebih dan telah berlalu, biarkan saja! Jika modifikasi yang dibutuhkan kecil, maka simpan sekecil mungkin dan sekecil mungkin. Hal lain yang beresiko lebih besar untuk merusak sesuatu yang tidak perlu diperbaiki.

Tentu saja, kadang-kadang Anda menemukan bahwa itu benar-benar kluge yang tidak dapat dipelihara dan satu-satunya cara untuk mengakomodasi modifikasi "kecil" adalah menulis ulang dari awal. Dalam hal ini Anda harus kembali ke siapa pun yang meminta perubahan dan katakan kepadanya berapa biayanya (baik dalam dolar atau jam kerja untuk penulisan ulang, dan dalam keringat darah dan air mata untuk bug baru yang tak terhindarkan).

Dahulu kala ada ruam kegagalan salah satu drive disk Digital. Mereka akhirnya mengingat dan mengganti mereka semua di gorden tahu berapa biayanya. Rupanya ada gumpalan lem yang memegang filter di dalam HDA. Manifes rekayasa mengatakan lem "Tidak ditentukan secara parametrik, TIDAK ADA PENGGANTI DAPAT DITERIMA". Penghitung kacang "disimpan" di bawah satu sen per drive disk dengan sumber lem lainnya. Itu mengeluarkan uap di dalam HDA yang membunuh drive setelah beberapa tahun dalam pelayanan. Itu tidak rusak sampai dia memperbaikinya. Tidak diragukan lagi "itu hanya perubahan kecil ..."

Jelas tidak ada gunanya mengurangi tingkat kualitas untuk kode legacy. Tidak perlu segera memperbaiki peringatan. Pastikan bahwa semua perubahan "baru" Anda di setiap komponen proyek Anda mengikuti standar kualitas tinggi. Yaitu tidak ada komitmen harus meningkatkan jumlah peringatan.

Ini adalah pendekatan sederhana yang seragam dan mati.

Ini memungkinkan kode lawas lama berfungsi sebagaimana mestinya (karena tidak ada modifikasi yang tidak perlu dilakukan untuk itu). Ini memastikan kode baru berkualitas tinggi. Tidak ada biaya tambahan.

Pengendalian risiko ....

• Kode dalam basis kode warisan besar telah diuji setidaknya dengan penggunaan kehidupan nyata dari perangkat lunak.
• Sangat tidak disukai kode dalam basis kode warisan besar ditutupi oleh tes unit otomatis.
• Oleh karena itu setiap perubahan pada dingin di basis kode warisan besar berisiko tinggi.

Biaya….

• Membuat kode melewati pemeriksa kode saat Anda menulis kode itu murah
• Melakukannya pada kondisi selanjutnya jauh lebih mahal

Manfaat

• Anda berharap bahwa menjaga standar pengkodean mengarah pada desain kode yang lebih baik.

• Tetapi sangat tidak mungkin bahwa seseorang menghabiskan beberapa minggu untuk mengubah kode hanya untuk menghilangkan peringatan dari alat pengecekan standar pengkodean, akan menghasilkan perbaikan pada desain kode.

• Kode sederhana lebih jelas dan cenderung lebih mudah dipahami, kecuali kode kompleks dibagi menjadi metode pendek oleh seseorang yang tidak memahaminya ....

Rekomendasi….

• Jika bagian kode ditampilkan memiliki banyak bug di dalamnya, atau membutuhkan banyak perubahan untuk menambahkan fungsi tambahan, maka habiskan waktu 100% untuk memahami apa yang dilakukannya.
• Juga habiskan waktu dengan menambahkan tes unit yang baik ke bagian kode itu, karena Anda sudah terbukti membutuhkannya.
• Anda kemudian dapat mempertimbangkan refactoring kode (Anda sekarang mengerti) sehingga lulus memeriksa kode baru juga.

Pengalaman pribadi ....

• Dalam 20 tahun bekerja sebagai programmer, saya belum pernah melihat kasus di mana perubahan yang lama untuk menghapus semua output dari pemeriksa standar pengkodean baru memiliki manfaat selain dari meningkatkan pendapatan kontraktor yang telah diperintahkan untuk melakukannya.
• Demikian juga ketika kode lama harus dibuat untuk melewati ulasan kode (TickIt / ISO 9001 melakukan kesalahan) yang mengharuskan kode lama terlihat seperti standar pengkodean baru.
• Saya telah melihat banyak kasus di mana menggunakan alat bantu pengecekan standar pada kode baru memiliki manfaat besar dengan mengurangi biaya berkelanjutan.
• Saya belum pernah melihat perusahaan gagal biaya mempertahankan kode lama yang digunakan dalam produk dengan banyak pelanggan.
• Saya telah melihat perusahaan gagal karena tidak mendapatkan pendapatan dari pelanggan karena terlalu lambat ke pasar….

Apakah diskusi tentang menurunkan ambang batas alat? ... atau saya salah paham. Itu ditulis dengan cara yang membingungkan. Jika tidak, harap abaikan jawaban saya.

IMHO itu akan menjadi ide yang baik untuk mengurangi sensibilitas alat. Mengapa? Karena itu akan menyoroti potongan kode yang paling berbulu. Alternatifnya adalah menghasilkan laporan dengan ribuan pelanggaran, menjadi tidak berguna karena ukurannya yang tipis.

... selain itu, bicarakan saja dengan orang-orang yang terlibat dan dengarkan alasan mereka juga.

Saya akan mencoba memisahkan kode warisan dari kode bersih baru. Dalam contohnya Eclipse Anda bisa melakukan ini dengan meletakkannya di proyek yang berbeda yang saling menggunakan. proyek 'bersih' dan proyek 'warisan ' .

Dengan cara ini Anda dapat menganalisis kedua proyek di sonar dengan standar kualitas yang berbeda. Standar seharusnya hanya berbeda dalam pentingnya aturan. Aturannya sendiri harus sama. Dengan cara ini Anda dapat melihat di proyek 'legacy' apa yang perlu 'diperbaiki' untuk memenuhi standar proyek 'clean' .

Setiap kali Anda berhasil mengangkat beberapa kode lawas ke standar yang lebih tinggi, Anda dapat memindahkannya ke proyek 'bersih'.

Dalam setiap hari kerja Anda tidak dapat menyelesaikan untuk mengangkat setiap kelas yang Anda sentuh ke standar proyek 'bersih' karena jeda waktu. Tetapi Anda harus mencoba untuk sampai ke sana dalam langkah-langkah kecil dengan mencoba meningkatkan kode legacy sedikit setiap kali Anda menyentuhnya.