Bagaimana menentukan prioritas dan tingkat keparahan “peningkatan kode”?

Kami memiliki bidang "prioritas" dan "keparahan" di sistem pelacakan bug kami. Kami mendefinisikan tingkat keparahan sebagai "bagaimana hal itu berdampak pada pengguna" dan prioritas sebagai "bagaimana hal itu berdampak pada produk".

Pertanyaan saya adalah tentang bagaimana mengkategorikan tugas "perbaikan kode" dalam tingkat keparahan dan prioritas. Misalkan peningkatan tidak mengubah perilaku apa pun tetapi menjadikannya "kode yang lebih baik". Kami mengantisipasi peningkatan pemeliharaan jangka panjang secara keseluruhan tetapi sulit untuk diukur.

Ketika kami menggunakan definisi kami untuk prioritas dan tingkat keparahan, peningkatan kode mendapatkan nilai terendah untuk keduanya kecuali Anda memperkenalkan beberapa sulit untuk memprediksi manfaat jangka panjang ke dalam gambar. Oleh karena itu itu menyiratkan bahwa perbaikan kode adalah tugas sembrono dan tidak boleh dicoba.

Namun saya percaya sangat jahat untuk terus memperbaiki dan memperbaiki kode, karena:

• Pengembangan perangkat lunak itu sendiri merupakan proses pembelajaran yang berkelanjutan dan tanpa meningkatkan kode Anda tidak bisa menjadi lebih baik.
• Sebuah tim harus bangga dengan kode mereka.
• Pemeliharaan di masa depan akan memakan waktu lebih sedikit dan penghematan jangka panjang akan signifikan.

Atau apakah menurut Anda tugas seperti itu seharusnya tidak pernah dibuat dan perbaikan seperti itu hanya dilakukan "sesuai permintaan", "ketika dikaitkan dengan bug"? Bahkan jika itu terkait dengan bug, bukankah itu akan menjadi titik diskusi pada tinjauan kode, misalnya "mengapa Anda melakukan perubahan struktur yang drastis ini?".

Biasanya saya tidak suka melihat kegiatan "peningkatan kode" sebagai tugas yang dapat ditugaskan terpisah karena peningkatan kode itu sendiri tidak pernah secara langsung membawa Anda lebih dekat untuk menyelesaikan cerita atau persyaratan pengguna. Inilah sebabnya mengapa tugas peningkatan kode akan selalu menjadi prioritas rendah sehingga mereka tidak pernah ditugaskan.

Saya melihat peningkatan kode sebagai konstanta, sesuatu yang harus dilakukan setiap pengembang secara alami seperti mengetik pada keyboard. Saya memasukkannya ke dalam perkiraan saya untuk tugas apa pun. Jika tugas saya melibatkan saya menyentuh kelas atau beberapa kode sumber yang belum lama dilihat, maka saya akan berasumsi bahwa beberapa pekerjaan kebersihan mungkin dilakukan dan menambah perkiraan saya.

Skenario kasus terbaik Saya menyelesaikan tugas lebih awal dan dapat menggunakan waktu yang tersisa untuk memperbaiki kode atau bahkan mendesain. Skenario kasus terburuk, tugas ini membutuhkan waktu lebih lama dari yang diharapkan, tetapi saya memiliki waktu ekstra sebagai penyangga.

Jika Anda ingin memperbaiki kode Anda, tetapkan prioritas tugas sesuai dengan definisi Anda (yaitu "bagaimana hal itu berdampak pada produk"). Beberapa refactoring tidak akan banyak mempengaruhi produk dan beberapa akan, tergantung pada ruang lingkup pekerjaan yang diperlukan. Menetapkan prioritas yang lebih tinggi akan menunjukkan bahwa lebih banyak pengujian perlu dilakukan setelah refactoring selesai untuk memastikan tidak ada yang tak terduga terjadi.

Anda mungkin juga ingin memperkenalkan kategori baru dalam sistem pelacakan bug Anda untuk mengkategorikan jenis tugas ini sebagai tugas "Refactoring". Dengan cara ini Anda akan tahu bagaimana menafsirkan nilai prioritas; yaitu, prioritas yang lebih tinggi berarti dampak yang lebih besar dan oleh karena itu diperlukan lebih banyak pengujian.

Yang hilang adalah memverifikasi asumsi Anda tentang kode yang ada: lebih sedikit waktu dan penghematan yang signifikan dapat dicapai jika kami memperbaiki kode. Apakah ini kosmetik atau ada masalah serius?

Periksa perkiraan debugging dan peningkatan Anda. Jika mereka membutuhkan waktu lebih lama dan ada komentar terus menerus tentang harus memperbaiki kode terlebih dahulu atau membersihkannya, itu mungkin merupakan pengukuran terbaik Anda. Kemudian Anda dapat mengidentifikasi basis kode Anda sebagai: Baik, perlu pengerjaan ulang kecil atau refactoring serius diperlukan.

Semua ini bersifat relatif. Sulit untuk memberikan prioritas tinggi ini ketika ada pelanggan yang menginginkan lebih banyak fitur dan bersedia membayar segera untuk jam yang dapat ditagih.

Pertanyaan menarik.

Saya pikir Anda harus memperkirakan berapa baris kode dan berapa banyak modul yang mungkin mempengaruhi perubahan.

Mungkin Anda bisa melihat berapa banyak unit test, jika Anda memilikinya, akan rusak dengan melakukan perubahan. Ini mungkin berarti mencoba mengubah cabang terlebih dahulu untuk mendapatkan ide.

Kemudian miliki ambang batas untuk tingkat dan keparahan tingkat pencocokan ini.

Anda juga harus mempertimbangkan memiliki banyak pengujian tester yang perlu dilibatkan. Jika perubahan menyentuh area permukaan aplikasi yang luas, maka banyak pengujian sistem mungkin perlu ditinjau kembali.

Mari kita mulai dengan dua asumsi di sini.

1. Untuk setiap cerita baru, Anda menulis kode sesuai kemampuan Anda, mungkin ditopang dengan pengetahuan ambient dari tim Anda.
2. Setiap kali Anda memiliki cerita yang mengubah fungsionalitas kode yang ada, Anda menggunakan pengetahuan baru Anda tentang sistem dan keterampilan yang lebih baik untuk meningkatkan kode dalam proses penerapan cerita baru.

Mengingat kedua asumsi itu, tidak pernah ada kebutuhan untuk upaya "peningkatan kode" yang eksplisit. Kode Anda meningkat saat Anda menulis sistem. Ini berarti bahwa tidak semua kode memenuhi standar terbaru dan terhebat untuk pemeliharaan, tetapi "Jika tidak rusak jangan diperbaiki." Saya menganggap kode refactoring yang tidak perlu diubah menjadi "pelapisan emas" sebanyak menambahkan fungsi yang tidak dibutuhkan terlihat. Jika kode rusak dalam beberapa cara, tulis tes valid yang gagal; mencatat bug; dan kemudian refactor untuk mengatasi bug itu.

Saya akan mencuri suara dari gerakan Agile:

Masukkan bug, buat tebakan kasar untuk tingkat keparahan dan prioritas,

Kemudian, setiap hari, tinjau mingguan atau bulanan semua bug baru, dan berikan suara pada peringkat mereka. Idealnya Anda melakukan ini selama pertemuan perencanaan sprint dengan pengguna akhir. Kemudian Anda dapat berbicara tentang fitur-fitur selanjutnya pada saat itu juga dan menjadi positif,