Haruskah semua pengembangan, termasuk pekerjaan refactoring, disertai dengan masalah pelacakan?

Perdebatan: Haruskah semua pengembangan, termasuk pekerjaan refactoring, disertai dengan masalah penelusuran? (dalam kasus kami, Jira)

Pijakan yang sama: Tujuan utama kami adalah kualitas. Produk yang berfungsi, setiap rilis, lebih penting daripada yang lainnya. Basis kode kami sudah tua dan pengujian otomatis masih kurang; kami sedang mengerjakan ini tetapi ini adalah proyek jangka panjang, kami membutuhkan proses sementara.

Posisi 1: Pekerjaan refactoring harus dilacak di Jira. Jika tidak jelas terkait dengan perubahan yang Anda lakukan, maka Anda harus mengajukan masalah lain. Jika Anda tidak melakukannya, maka pekerjaan akan melewati tinjauan dan pengujian dan ada risiko terhadap tujuan utama kami. Argumen telah dibuat bahwa kepatuhan PCI (tujuan bisnis yang akan datang) membutuhkan tingkat pelacakan ini; Saya tidak dalam posisi untuk mengatakan itu benar atau salah dengan tingkat kepastian.

Posisi 2: Kualitas kode sangat penting. Semakin baik (ke titik; titik kita tidak dekat), semakin besar kemungkinan kita untuk terus merilis produk yang berfungsi. Apa pun yang menempatkan penghalang, sekecil apa pun, di jalan refactoring adalah risiko bagi tujuan utama kami. Seringkali, IDE melakukan pekerjaan untuk Anda, jadi sepertinya tidak salah.

Kasus-kasus berikut telah dibuat:

Apakah akan memuaskan kedua posisi jika pengembang menulis "Refactor" dan nomor revisi yang relevan pada kartu? Jujur, ini terasa seperti akan membuat semua orang sama-sama tidak bahagia. Itu masih menempatkan tingkat resistensi dalam melakukan refactoring, tetapi tidak menawarkan pelacakan yang memadai.

Bagaimana dengan memiliki semua masalah Jira yang mencakup pekerjaan refactoring untuk iterasi? Ya, ini menghapus lapisan resistensi pengembang, tapi saya khawatir itu juga menghilangkan manfaat pelacakan memiliki masalah Jira. Bagaimana QA mendapatkan ide yang jelas apa yang harus diuji? Ini tampaknya menjadi solusi politik, membuat semua orang tetap tenang dengan menambahkan proses yang ringan namun pada akhirnya tidak ada gunanya.

Tampak bagi saya bahwa, mengingat bahwa kedua sisi perdebatan pada akhirnya menginginkan hal yang sama, harus ada solusi yang membuat semua orang benar-benar bahagia. Kita tidak mungkin menjadi orang pertama yang mengajukan pertanyaan ini, jadi pengalaman apa yang dimiliki orang lain dalam situasi yang sama?

Mungkin saya kehilangan sesuatu di sini, tetapi bagaimana cara membuat tiket untuk pekerjaan yang Anda lakukan yang tidak masuk dalam lingkup tiket Anda yang lain sebagai 'lapisan resistensi'?

Apakah Anda baru-baru ini menerapkan sistem pelacakan tiket? Jika demikian, maka duduk dan buat aturan Anda untuk menggunakannya dan beri tahu tim bahwa mereka diharapkan untuk mengikuti aturan ini. Jika ini termasuk membuat tiket refactoring untuk pekerjaan ini, silakan saja. Anda tidak dapat membuat pengecualian sejak dini atau itu dapat menggagalkan seluruh proses yang sedang disiapkan oleh tim Anda.

Jika Anda telah menggunakan sistem pelacakan tiket untuk sementara waktu, maka saya benar-benar tidak mengerti mengapa ini akan menjadi 'lapisan resistensi'. Tim Anda seharusnya sudah terbiasa membuat Jira terbuka dan melihat tiket mereka dan harus nyaman membuat tiket.

Jika Anda ingin menyimpan semua upaya refactoring di satu tempat, buat tiket utama untuk ini, dan minta tim Anda membuat tugas di bawahnya untuk pekerjaan yang mereka lakukan. Kemudian dibutuhkan sekitar 5 detik untuk dev untuk membuat tugas baru untuk ini dan mereka dapat mencatat waktu mereka untuk tugas itu.

Manajer proyek, pimpinan tim, dan pengembang perlu tahu berapa banyak waktu yang diperlukan untuk upaya refactoing. Anda tidak ingin itu menjadi lubang waktu hitam. Memiliki tiket membuat pengembang bertanggung jawab atas pekerjaan mereka sambil menyediakan manajer dan memimpin tempat untuk melacak berapa jam pergi ke upaya.

Idealnya ya.

Setiap perubahan yang Anda lakukan pada basis kode harus memiliki alasan di baliknya. Ini bisa berupa permintaan pelanggan - item yang paling umum / kemungkinan besar, atau yang dibesarkan secara internal - seperti dalam contoh refactoring Anda.

Ini berarti bahwa serta melacak saat perubahan dilakukan, Anda dapat menautkan perubahan tersebut kembali ke sesuatu yang menjelaskan mengapa perubahan itu dilakukan. Mengapa ini tidak bisa hanya berupa komentar changeset? Ada beberapa alasan mengapa ini mungkin tidak cocok.

• Tidak selalu ada pemetaan 1: 1 antara item kerja dan perubahan - Anda mungkin perlu beberapa set edit untuk menyelesaikan item.
• Komentar changeset biasanya tidak terlihat oleh non-pengembang atau Anda mungkin perlu melampirkan dokumentasi lain ke item pekerjaan.

Refactoring kode, walaupun sangat diinginkan untuk meningkatkan kualitas, juga merupakan risiko yang melekat. Ini terutama benar ketika berhadapan dengan kode "dasar" di mana satu bug akan membuat seluruh sistem jatuh dan memecahkan satu "masalah" akan memiliki efek samping (mungkin tidak terduga) di seluruh aplikasi.

Terlepas dari jenis kode apa yang terlibat, ketika refactoring tidak terbatas pada kode untuk masalah tertentu (tiket), QA harus terlibat dan mengetahui bagian-bagian dari basis kode Anda yang terpengaruh. Mereka harus melakukan uji regresi penuh pada bagian-bagian itu untuk memastikan tidak ada yang terlewat. Dan mereka harus melakukannya bahkan, mungkin terutama, jika Anda memiliki set lengkap unit test di tempat yang membuat Anda merasa yakin melakukan refactoring. Tes unit banyak tes, tetapi mereka juga kehilangan banyak.

Jadi, jika kualitas kode penting, ya, harus ada sesedikit mungkin hambatan untuk meningkatkan kode. Tapi saya gagal melihat bagaimana membuat tiket untuk ini adalah penghalang. Ini hanya memastikan bahwa QA mendapat kesempatan untuk (im) membuktikan kualitas kode dan harus menjadi sesuatu yang diinginkan, bukan sesuatu yang dipandang sebagai penghalang.

Saya pikir jika Anda tidak dapat menggambarkan refactoring lebih khusus daripada "refactoring", Anda salah melakukannya. Refactoring harus memiliki tujuan dan ruang lingkup yang pasti. Melacak tugas-tugas refactoring secara terpisah di JIRA tidak hanya membuat audit, review dan pengujian lebih mudah, tetapi juga memaksa refactorers untuk memfokuskan pikiran mereka pada tujuan konkret ("menghapus ketergantungan melingkar antara modul X dan Y", misalnya) dan hanya akan mengarah pada refactoring yang lebih baik.

Di sisi lain, jika refactoring benar-benar sederhana, lokal dan hanya merupakan produk sampingan dari melaksanakan tugas yang berbeda, saya tidak akan repot melacaknya di bawah tiket terpisah dan hanya mendokumentasikannya di tiket taks asli, jika bisa berdampak pada pekerjaan orang lain.

Ya, idealnya setiap perubahan yang Anda buat dalam kode harus dikaitkan dengan item JIRA dan karenanya dapat dilacak. Seperti yang telah dicatat orang lain, Anda harus dapat mengidentifikasi mengapa perubahan tertentu dibuat, dan perubahan apa yang terkait dengannya.

Tidak apa-apa untuk memiliki Epics refactoring jangka panjang dalam proyek warisan, kita juga memilikinya. Namun, Anda harus berusaha memfokuskan hal ini pada beberapa area spesifik kode, dengan tujuan tertentu, jika tidak, sangat sulit untuk tetap terkendali. Misalnya "modul refactor Foo and Bar untuk menghilangkan dependensi siklik", "hierarki kelas refactor A untuk menghapus duplikasi dan membersihkan hierarki warisan".

Ketika mengerjakan kode warisan, memiliki sumber daya terbatas, kita harus memprioritaskan cara-cara yang mungkin untuk mengurangi utang teknis, untuk mencapai pengembalian investasi terbaik. Jadi menganalisis kemungkinan refactoring, kepentingannya, risiko, biaya dan manfaatnya harus dilakukan pula sebelum memulai pekerjaan. Juga, melacak kemajuan refactoring skala yang lebih besar dan mengetahui kapan itu selesai adalah penting. Dibandingkan dengan tugas-tugas yang diperlukan ini, IMHO upaya sebenarnya mengelola item JIRA sangat minim.

Argumen telah dibuat bahwa kepatuhan PCI (tujuan bisnis yang akan datang) membutuhkan tingkat pelacakan ini

Jika Anda maksudkan ini , saya bisa mengerti mengapa manajemen takut perubahan yang tidak terkendali dalam basis kode, namun pelacakan perubahan hanyalah bagian kecil dari solusi. Anda perlu pengujian sistem menyeluruh dan mungkin ulasan kode untuk memastikan bahwa tidak ada nomor kartu kredit yang bocor dari sistem melalui file log dll. Refactoring tidak seharusnya mengubah perilaku kode yang ada, dan Anda seharusnya memiliki unit test untuk membuktikan ini lagi pula (jangan mencoba bersandar pada keyakinan bahwa alat refactoring otomatis tidak dapat memecahkan kode - Anda HARUS memiliki unit test untuk menghindari kejutan yang tidak menyenangkan).

Di dunia yang ideal, jawaban Chris benar. Setiap kali Anda membuat perubahan pada kode atau artefak yang terkait dengan proyek perangkat lunak, harus ada log ini. Ini harus diserahkan, disetujui, ditugaskan kepada pihak yang tepat, perkiraan upaya, pekerjaan dilakukan, total waktu yang dicatat, dan deskripsi singkat tentang perubahan yang didokumentasikan.

Namun, ini tidak selalu layak. Misalnya, IDE saya dikonfigurasi untuk memformat ulang file kode berdasarkan pedoman kode organisasi. Jika saya membuka file dan melihat bahwa itu tidak cocok, itu sepele untuk diperbaiki - CTRL + SHIFT + F pada file memformat semuanya. Mungkin CTRL + SHIFT + O untuk memperbaiki impor. Saya melakukan ini tepat sebelum atau tepat setelah memperbaiki cacat yang saya ditugaskan.

Dalam hal ini, Anda selalu ingin mencatat fakta bahwa Anda melakukannya dan berapa lama, tetapi tidak membuat perubahan sekarang mungkin lebih buruk daripada melalui proses penetapan dan penerapan perubahan secara formal. Dalam beberapa kasus, lebih mudah untuk meminta maaf daripada meminta izin. Terserah Anda, sebagai insinyur, untuk membenarkan di mana tepatnya garis itu perlu ditarik.

Pada umumnya, refactoring harus dilakukan sebagai bagian normal dari alur kerja Anda. Dalam rangka untuk memperbaiki bug A , Anda perlu untuk menguji bahwa sedikit metode, dan sehingga Anda harus ekstrak sebagai metode B . Saat Anda melakukan itu, Anda melihat bidang C sangat buruk namanya, dan Anda menamainya kembali.

Untuk cara berpikir saya, ini biasa refactorings mendapatkan "dibebankan" asli bug A . Mereka diajukan dengan perbaikan, ditinjau dengan perbaikan, tiket dengan perbaikan. Mereka adalah bagian dari perbaikan.

Tetapi ada refactor yang lebih besar dan kurang fokus yang terjadi juga. Pengamatan umum bahwa kelas D terlalu besar. Akan lebih mudah untuk bekerja pada jika Anda dihilangkan duplikasi di E . Dan refactoring tersebut adalah yang paling berisiko yang akan Anda lakukan (terutama dalam basis kode tanpa tes). Dengan segala cara, buat tiket untuk mereka; letakkan setidaknya melalui proses peninjauan normal Anda.