Bagaimana cara menangani TODO dalam permintaan tarik?

Ketika saya meninjau perubahan dalam permintaan tarik, kadang-kadang saya menemukan komentar dengan catatan "TODO" yang mungkin ada karena alasan yang berbeda, dalam kasus kami sebagian besar karena:

• solusi yang digunakan untuk menyelesaikan suatu masalah dapat diperbaiki tetapi akan membutuhkan investasi waktu yang jauh lebih besar. Seorang penulis memilih solusi yang lebih cepat tetapi memberi komentar bahwa opsi yang lebih baik berpotensi tersedia
• ada kode sementara untuk mengatasi bug yang ada yang harus segera diperbaiki

Mengetahui bahwa TODOumumnya tinggal di basis kode untuk seumur hidup basis kode, bagaimana saya harus bereaksi terhadap mereka dalam permintaan tarik? Bagaimana saya bisa dengan sopan meminta untuk menghindarinya, atau jika benar-benar dibenarkan, bagaimana saya bisa memastikan penulis PR akan menindaklanjutinya di kemudian hari?

Ketika Anda mengatakan bahwa mereka "umumnya tinggal di basis kode untuk seumur hidup dari basis kode" di tim / departemen / organisasi Anda, pertimbangkan hal berikut:

• Menuliskannya di Anda DoD yang TODO, FIXME, atau tag serupa harus dihindari.
• Gunakan alat analisis kode statis seperti SonarQube untuk secara otomatis menandai build tidak stabil.
• Biarkan sementara mereka jika, dan hanya jika, ada tiket yang sesuai di pelacak masalah Anda. Kemudian, kodenya mungkin terlihat sepertiTODO [ID-123] Description ...

Seperti disebutkan dalam komentar saya , pernyataan terakhir mungkin hanya masuk akal di lingkungan yang tidak membiarkan tiket membusuk (misalnya jika Anda mengikuti kebijakan zero-bug ).

Secara pribadi, saya pikir kadangTODO - kadang masuk akal, tetapi orang tidak boleh menggunakannya secara berlebihan. Diambil dari Robert C. Martin "Clean Code: A Handbook of Agile Software Craftsmanship" (p. 59):

TODOIni adalah pekerjaan yang menurut programmer harus dilakukan, tetapi untuk beberapa alasan tidak dapat dilakukan saat ini. Ini mungkin merupakan pengingat untuk menghapus fitur yang sudah usang atau permohonan agar orang lain melihat masalah. Mungkin permintaan orang lain untuk memikirkan nama yang lebih baik atau pengingat untuk melakukan perubahan yang bergantung pada acara yang direncanakan. Apa pun yang TODOterjadi, itu bukan alasan untuk meninggalkan kode buruk dalam sistem.

TODO sendiri tidak jahat. Saya penggemar berat tidak pernah pergi lebih dari satu lapisan dalam, dan selalu memperbaiki 1 masalah per tiket pelacak.

Saya sering menggunakan TODO atau FIXME sebagai cara untuk mengingatkan diri saya bahwa saya perlu atau ingin kembali untuk memperbaiki masalah.

Sebagai contoh, saya dapat memanggil add (a, b) dan menambahkan TODO untuk memperbaiki metode add. Saya tidak ingin mengerjakan metode add sekarang, tetapi saya ingin kembali ke sana.

Jadi dalam permintaan tarik, Anda akan melihat TODO atau FIXME. Saya menggunakan FIXME misalnya untuk memperingatkan pengembang lain dari bidang kode yang mereka tanggung jawab, yang tidak boleh saya mainkan. Misalnya, penambahan FIXME tidak dapat menerima angka negatif.

Untuk mengatasi masalah mereka yang tidak terlihat atau diabaikan, saya menggunakan skrip yang mencantumkan semua baris TODO FIXME dan DEGUG. Dan itu akan ditambahkan ke pesan komit.

Sulit untuk mengabaikan pesan komit 400 baris yang semuanya adalah TODO. Jadi orang memperbaikinya, baik ketika sudah menyentuh kode yang dimaksud atau dengan membuat tiket baru dan memperbaiki kode masalah mandiri.

Agar adil, saya juga memastikan bahwa setiap proyek memiliki kode waktu pembersihan. Ya dapat siap diluncurkan pada tanggal 15, tetapi sedang melakukan pembersihan kode dari tanggal 15 hingga tanggal 30. (tampak aneh tetapi jika Anda pernah mengelola suatu produk, Anda tahu bahwa jika Anda mencoba untuk memiliki tugas visibilitas rendah sebelum diluncurkan, Anda tidak akan pernah diizinkan untuk mendapatkannya. Sesuatu yang lain akan mendapat prioritas.)

Itu akan terjadi bahwa ada permintaan tarik yang tidak sempurna. Saat ini saya sedang melakukan beberapa pekerjaan yang dapat dilakukan "cukup baik" pada waktu yang tersedia, tetapi tidak sempurna. Jadi saya mengirimkan permintaan tarik, saya menempatkan TODO dengan komentar di tempat yang tepat dalam kode, dan pada saat yang sama saya menambahkan permintaan perubahan lain untuk mengubah hal-hal dari "cukup baik" menjadi "sempurna".

Permintaan perubahan baru ini kemudian dapat diprioritaskan, dan akan ditangani ketika itu adalah item prioritas tertinggi. Jika diputuskan bahwa itu harus sempurna sekarang , maka itu akan menjadi hal berikutnya yang diserahkan.

Sekarang pertanyaan Anda: "Bagaimana saya bisa dengan sopan meminta untuk menghindarinya, atau jika benar-benar dibenarkan, bagaimana saya bisa memastikan penulis PR akan menindaklanjutinya nanti di masa depan?" Dengan apa yang saya jelaskan, sepertinya agak bodoh. Jika saya memiliki pilihan antara pengiriman terlambat, dan pengiriman yang cukup baik, maka itu bukan keputusan Anda. Anda dapat bertanya kepada manajer produk Anda jika mau. Dan "pastikan penulis PR akan menindaklanjutinya"? Jika Anda memiliki tim, maka Anda harus memastikan bahwa ini masuk dalam sistem Anda, dan semoga tim Anda cukup terorganisir sehingga hal-hal yang dicatat tidak hilang, dan seseorang akan memperbaikinya pada akhirnya, ketika tidak ada item prioritas yang lebih tinggi. Ingat, ini adalah upaya tim.

Jika proyek Anda melacak item yang tertunda dalam kode sumber dengan TODOkomentar, maka Anda harus mengizinkannya.

Fakta bahwa keberadaan TODOkomentar dalam permintaan tarikan mengganggu Anda harus memberi tahu Anda bahwa melacak item yang tertunda dalam kode sumber adalah ide yang buruk. Hal-hal cenderung hilang atau diabaikan begitu saja. Sekarang, jika Anda berbicara tentang permintaan tarik ke "garpu kerja", maka situasinya berbeda. "Garpu kerja" hanyalah itu - sebuah karya yang sedang dalam proses. Tapi garpu seperti itu biasanya tidak memerlukan permintaan tarik. "Aturan Rumah" yang disarankan di sini adalah untuk permintaan tarik dari cabang utama .

House Rule # 1 - Semua yang berkomitmen untuk menguasai harus siap untuk pengujian, karena master dibangun setiap hari setelah check-in. Komit tersebut juga harus mencakup tes tambahan apa pun yang diperlukan.

Jika TODOkomentar ada di sana karena kode belum selesai, atau tes belum selesai, atau kodenya tidak siap untuk pengujian, maka kode itu termasuk dalam komit lokal, bukan permintaan tarik. Hubungi saya jika sudah siap.

House Rule # 2 - Semua informasi tentang masalah terbuka disimpan dalam pelacak masalah. Semua itu. Catatan, coretan, firasat, apa pun.

Jika TODOkomentar terkait dengan masalah terbuka, dan bukan perbaikan yang sebenarnya untuk masalah itu, maka informasi tersebut termasuk dalam pelacak masalah. Dengan begitu, sebelum masalah ditutup, semua informasi dapat ditinjau dan diverifikasi, jika perlu, untuk memastikan masalah tersebut benar-benar terselesaikan.

House Rule # 3 - Semua informasi mengenai tugas-tugas proyek yang tertunda termasuk dalam antrian prioritas (atau apa pun nama sistem Anda untuk itu).

Untuk klarifikasi, tugas proyek yang tertunda adalah sesuatu yang perlu dilakukan dalam proyek yang memiliki prioritas yang ditetapkan, apakah itu cacat yang ditemukan sebelum menghasilkan tiket masalah, atau penerapan persyaratan desain tertentu, atau salah satu dari komponen yang diperlukan persyaratan itu.

Jika ada TODOkomentar untuk mengatakan bahwa kode baru akan berdampak pada tugas yang tertunda, atau untuk menunjukkan sesuatu yang lain dalam basis kode yang perlu dilihat yang ditemukan ketika menerapkan kode baru, maka informasi tersebut termasuk dalam antrian prioritas, baik pada tugas yang ada atau sebagai yang baru.

House Rule # 4 - Saran termasuk dalam Kotak Ide (atau apa pun).

Jika TODOkomentar menyarankan perubahan dalam desain atau implementasi perangkat lunak, maka informasi itu termasuk dalam kotak ide proyek, atau "vNext", atau "Catatan Desain", atau apa pun yang Anda miliki untuk hal semacam itu.

House Rule # 5 - TODOkomentar tidak diizinkan dalam kode sumber. PERIODE.

Jika Anda tetap pada aturan ini, maka Anda tidak perlu khawatir ada orang yang menindaklanjuti apa pun.