Haruskah Anda memperbaiki kode yang ada yang tidak rusak dalam proyek yang berfokus pada fitur-fitur baru?


11

Diberikan proyek kecil yang bertujuan untuk menambah fungsionalitas baru ke aplikasi, perubahan yang diperkenalkan menyentuh beberapa kode yang ada, termasuk memperbarui ini di area tertentu. Selama implementasi, saya telah menemukan beberapa kode ini yang diperbarui memiliki kandidat untuk refactoring.

Apakah ini waktu yang tepat untuk refactor yang pada gilirannya akan memerlukan pengujian regresi untuk komponen-komponen yang terkena dampak (dengan demikian mungkin memperkenalkan ruang lingkup yang awalnya bukan bagian dari proyek)? Atau haruskah saya menunda, melengkapi fungsionalitas dan mungkin memiliki proyek terpisah untuk refactoring (walaupun saya agak ragu karena pengguna bisnis mungkin tidak sepenuhnya mensponsori proyek yang tidak menambahkan fungsionalitas apa pun, kecuali jika mereka menghargai pemeliharaan kode ...)?


2
Apakah Anda memiliki tes yang memungkinkan Anda untuk melakukan refactoring yang diinginkan?

2
Anda menjawabnya sendiri, klien tidak akan peduli dengan pemeliharaan kode kecuali jika kode itu sendiri dapat dikirimkan. Mereka peduli tentang uang dan waktu dan menganggap kualitas sebagai sesuatu yang diberikan. Kualitas, waktu, dan biaya berhubungan langsung dengan utang teknis, tetapi mereka juga relatif terhadap apa yang bersedia mereka terima. Jika Anda TIDAK memasukkan refactoring saat Anda berjalan maka perawatan kode akan menurun dan utang teknis akan meroket.
maple_shaft

Jawaban:


17

Benar.

Refactoring harus dilakukan pada proyek yang berfungsi dan "lewat". Ketika semua tes Anda (pada tingkat unit, sistem, dan penerimaan) lulus, Anda tahu bahwa produk Anda memenuhi persyaratan. Saat Anda refactor, Anda dapat terus mengonfirmasi bahwa semua tes terus berjalan. Jika tes apa pun mulai gagal, maka Anda melakukan sesuatu yang salah dan perlu memperbaikinya. Jika Anda gagal dalam tes, Anda harus memperbaikinya sebelum refactoring sehingga Anda selalu dapat memastikan refactoring Anda tidak mengubah fungsionalitas sistem.

Ini juga merupakan waktu yang tepat untuk refactoring, dengan anggapan Anda memiliki waktu dan sumber daya untuk melakukan refactoring dan masih memenuhi waktu dan anggaran. Refactoring sekarang akan membuatnya lebih mudah untuk memahami dan memelihara sistem Anda, sehingga saat Anda menambahkan lebih banyak fitur baru, itu menjadi lebih mudah. Anda harus berjuang melawan kode busuk dan entropi perangkat lunak .

Seperti yang ditunjukkan Joel Etherton dalam komentar, Anda perlu mengelola lingkup refactoring. Fokus pada refactoring bagian-bagian sistem yang akan segera Anda tambahkan fitur, melakukan refactoring yang akan membuatnya lebih mudah untuk bekerja dengan atau menambahkan fitur-fitur baru. Penggunaan analisis statis, alat metrik, dan ulasan kode dapat membantu Anda mengidentifikasi area yang paling kritis. Anda tidak ingin ketinggalan tenggat karena Anda sedang melakukan refactoring - Anda masih perlu terus menambah nilai kepada pelanggan.

Anda menyebutkan pelanggan tidak melihat nilai dalam refactoring. Biasanya, pelanggan tidak peduli dengan kualitas kode, tetapi dari produk. Refactoring akan memudahkan Anda untuk mempertahankan kualitas produk yang tinggi dan terus memberikan produk yang memenuhi kebutuhan pelanggan yang terus berubah. Cobalah untuk merundingkan waktu untuk refactoring ke dalam jadwal Anda (pelanggan menginginkan fitur X dalam Y hari, cobalah untuk melihat apakah Anda tidak bisa mendapatkan Y + Z hari atau fitur XN sehingga Anda dapat menghabiskan waktu pada desain, refactoring, dan implementasi), jika Anda bisa.


1
+1 terutama untuk paragraf tentang nilai refactoring untuk klien.
Marjan Venema

1
Dengan asumsi Anda memiliki serangkaian unit tes yang baik untuk memvalidasi refactoring tidak mengubah perilaku yang diamati. Diberi pilihan tes refactroring atau unit. Tambahkan tes unit terlebih dahulu.
Martin York

5
@ Thomas Owens: +1 Saya setuju, tetapi saya juga akan menambahkan catatan kehati-hatian pada refactoring. Sangat mudah bagi refactoring untuk memulai kaskade refactoring yang dapat menggembungkan pekerjaan aktual yang diperlukan dan menyebabkan tenggat waktu diperbesar.
Joel Etherton

@ Joel Itu poin bagus. Anda perlu menjaga agar refactoring terbatas dalam ruang lingkup untuk membuat tenggat waktu.
Thomas Owens

3

Pertimbangkan untuk menjawab pertanyaan di bawah ini, maka akan mudah bagi Anda untuk mengambil keputusan. Kebijaksanaan "jangan memperbaikinya jika tidak rusak" menggoda tetapi tidak selalu benar untuk pekerjaan profesional.

0-Apakah ada keluhan pelanggan tentang kode ini?

1-Apakah ini diperlukan untuk fungsionalitas aplikasi

2-Apakah kode saat ini berbahaya?

3-Apakah biaya perubahan sepadan?

4-Bisakah Anda membayar biayanya?

5-Apakah ini pemanfaatan keterampilan Anda yang terbaik untuk organisasi

6-Apakah perubahan Anda mengharuskan pengguna menginstal ulang perubahan baru - Bisakah Anda membenarkannya kepada pelanggan?

7-Bisakah Anda mentolerir risiko perbaikan buruk?

8-Apakah perubahan memengaruhi kode lain di luar proyek Anda?

9-Apakah ini produk yang berkembang atau produk yang stabil? Jika sedang berkembang, bisakah Anda memasukkan perubahan dengan rilis berikutnya?


Kamu sudah membaca pikiranku! Saya benar-benar memikirkan aturan terkenal itu "jangan memperbaikinya jika tidak rusak" untuk membenarkan menunda refactoring!
Carlos Jaime C. De Leon

3

Refactor segera, sering refactor.

Jika Anda mampu membelinya (waktu, uang, dll.) Anda harus melakukannya.

Saya mengatakan ini karena kadang-kadang Anda mungkin kehabisan waktu, atau seperti Anda mengatakan tidak mendapatkan uang untuk campur tangan pemeliharaan kode, atau Anda ingin menyelesaikan proyek Anda sesegera mungkin, dan lebih pada umumnya karena refactoring membutuhkan sumber daya. Namun terlepas dari itu selalu saat yang tepat untuk refactoring.

Anda menginginkan kode terbaru, dan jika Anda merasa kode Anda benar-benar membutuhkan beberapa perubahan, terutama ketika menambahkan fungsi baru, maka Anda harus mengubahnya.

Jangan lupa dengan sistem kontrol versi, Anda benar-benar dapat mengubah proyek Anda menjadi cabang baru, sehingga Anda tidak akan memengaruhi kode Anda saat ini sama sekali.


2

Jika refactoring diperlukan untuk mengimplementasikan fungsi baru maka itu harus dilakukan dan diperhitungkan sebagai bagian dari pengembangan baru.

Memiliki kode duplikat akan membebani Anda (baik Anda secara pribadi maupun perusahaan) dalam jangka panjang karena pengeditan dilakukan di satu tempat dan bukan di tempat lain.

Anda perlu memiliki serangkaian tes - baik tes unit otomatis atau tes regresi yang dapat Anda jalankan yang membuktikan bahwa Anda belum memperkenalkan masalah pada fungsionalitas yang ada.

Jika refactoring itu hanya "baik untuk dilakukan" - yaitu itu bukan dalam kode yang secara langsung dipengaruhi oleh fungsi baru maka saya akan membiarkannya sendiri. Anda memperkenalkan perubahan demi perubahan.


0

Sepertinya refactoring kode akan membuatnya lebih mudah untuk menambahkan fitur baru; itulah teorinya. Masukkan ini dalam lingkup fitur baru. Anda lebih cenderung mendapat dukungan dari pengguna bisnis dengan cara ini. Dalam hal ini, Anda harus dapat membuat argumen kompilasi dan membenarkan waktu untuk refactoring. Mudah-mudahan mereka akan memahami bahwa ini adalah bagian penting dari proses pengembangan dan akan memiliki lebih sedikit keberatan. Anda mungkin tidak selalu dapat menunjukkan manfaat langsung ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.