Kapan harus refactor

Saya telah membaca sebagian besar buku Refactoring Fowler dan telah merecode ulang banyak aplikasi di masa lalu saya besar dan kecil.

Salah satu hal sulit yang saya temukan untuk mengajar adalah "kapan" untuk refactor. Saya cenderung melakukan ini berdasarkan firasat yang telah melayani saya dengan sangat baik di masa lalu. Namun, ketika berdiskusi dengan orang-orang tentang apakah sepotong kode harus dibiarkan sendiri atau di refactored saat ini, sulit untuk bertahan dengan "pengecekan usus".

Saya merasa harus ada pendekatan yang lebih ketat untuk ini, tetapi saya tidak yakin apa itu.

Saya mengerti "kode-bau", red-green-refactor dan pemikiran lain, tetapi sering kali saya merasa bahwa waktu terbaik untuk refactor bukanlah pertama kali Anda menulis kode, tetapi kedua atau ketiga kalinya Anda menggunakan kode dan menyadari bahwa itu sebenarnya masalah dan sedang digunakan.

Refactor ketika biaya refactoring lebih rendah daripada biaya tidak refactoring.

Ukur "biaya" namun Anda bisa. Misalnya, apakah kode tersebut diterapkan dengan sangat buruk sehingga bug sepele menghabiskan berjam-jam atau berhari-hari untuk memperbaikinya? Akankah refactoring memungkinkan Anda untuk mendapatkan lebih banyak pelanggan, atau meningkatkan kapasitas, atau meningkatkan kinerja dan dengan demikian membuat pelanggan Anda yang ada lebih bahagia?

1. Apakah kompleksitas siklomatik dari fungsi di bawah 5?
2. Apakah Anda benar-benar memahami kompleksitas siklomatik tanpa mengikuti tautan itu?
3. Apakah Anda memiliki tes otomatis atau test case terdokumentasi untuk setiap jalur melalui fungsi?
4. Apakah semua test case yang ada lulus?
5. Bisakah Anda menjelaskan fungsinya dan semua kasing tepi kepada saya dalam waktu kurang dari 1 menit?
6. Jika tidak, bagaimana dengan 5 menit?
7. 10 menit?
8. Apakah ada kurang dari 100 baris kode dalam fungsi (termasuk komentar)?
9. Dapatkah Anda menemukan dua pengembang lain yang menyetujui kode ini bebas dari kesalahan hanya dengan inspeksi visual?
10. Apakah fungsi ini hanya digunakan di satu tempat?
11. Apakah fungsi tersebut memenuhi sasaran kinerja (Waktu / Memori / CPU)?

Mencetak gol

Tambahkan jawaban "tidak" di atas:

• 0-1 - Mengapa Anda berpikir tentang refactoring ini? Anda mungkin hanya ingin mengubah nama variabel karena Anda tidak menyukai konvensi penamaan pengembang sebelumnya
• 2-5 - Ini mungkin perlu sedikit penyesuaian, tapi saya tidak akan menahan rilis produksi untuk sesuatu dalam kisaran ini
• 6-8 - OK, kita mungkin perlu memperbaiki ini ... Kemungkinan kita akan terus meninjau kembali ini dan / atau kita tidak benar-benar tahu apa yang dilakukannya. Masih di pagar, tapi sangat mencurigakan
• 9+ - Ini adalah kandidat utama untuk refactoring. (Catatan, menulis test case adalah bentuk refactoring)

Ketika naluri Anda memberi tahu Anda bahwa Anda mungkin harus melakukan refactoring, kemungkinan naluri Anda memberi tahu Anda sedikit terlambat bahwa Anda telah menunda sesuatu yang penting terlalu lama.

Saya mengerti "kode-bau", red-green-refactor dan pemikiran lain, tetapi sering kali saya merasa bahwa waktu terbaik untuk refactor bukanlah pertama kali Anda menulis kode, tetapi kedua atau ketiga kalinya Anda menggunakan kode dan menyadari bahwa itu sebenarnya masalah dan sedang digunakan.

Ada dua level efektif untuk refactoring. Yang pertama adalah masalah yang jelas muncul ketika Anda pertama kali kode. Ini adalah sedikit optimasi yang membuat Anda sangat sedikit melakukan di muka. Hal-hal seperti menjaga metode dan kelas Anda kecil, dan mematuhi KERING dan SRP. Kemudian Anda memiliki tahap tambahan untuk menangani kekurangan utama dalam desain Anda, yang mungkin tidak segera terlihat sampai kode Anda memiliki beberapa mil di bawahnya. Ini adalah level kedua yang Anda bicarakan, namun untuk memastikan bahwa refactoring nanti tidak terlalu mahal, Anda harus sudah menulis kode Anda sedemikian rupa sehingga upaya yang Anda bayangkan nantinya menjadi lebih mudah dan lebih murah, yang berarti melakukan refactoring awal.

Seperti yang disebutkan Jeff dalam jawabannya, "waktu adalah uang" , terutama di perusahaan-perusahaan di mana beban kerjanya tinggi dan risikonya bahkan lebih tinggi. Waktu yang dihabiskan di depan untuk memastikan kode dalam keadaan sebaik mungkin dihemat kemudian, ketika mencari apa yang seharusnya menjadi refactoring mudah ternyata menjadi operasi besar.

Saat menulis perangkat lunak, setiap saat yang dihabiskan untuk memperbaiki kode Anda di muka adalah waktu yang dihemat nanti, ketika Anda benar-benar akan membutuhkannya. Semakin awal Anda melakukan refactor, perubahan Anda nantinya akan semakin jelas. Ini seperti membuat uang muka dalam dolar hari ini terhadap utang teknis di masa depan yang akan menjadi dolar yang digelembungkan besok.

Bagaimanapun, refactoring tidak boleh menjadi tugas yang Anda tunda sampai beberapa masa depan misterius ketika perangkat lunak sudah lengkap dan stabil, karena itu meningkatkan risiko Anda nanti ketika taruhannya jauh lebih tinggi dan produk jauh lebih sulit untuk diubah. Refactoring harus menjadi bagian dari kegiatan sehari-hari Anda, dan ini adalah inti dari filosofi Red-Green-Refactor yang Anda sebutkan.

Saya pikir pertanyaan Anda dapat dijawab secara berbeda oleh setiap pengembang dan bahkan manajemen yang bertanggung jawab atas pemrograman.

Preferensi pribadi saya adalah, setiap kali saya mempelajari sesuatu yang baru, atau meningkatkan praktik terbaik saya, saya refactor kode yang saya bisa - saya suka menjaga kode saya sesuai standar segera setelah saya belajar apa standar terbaik untuk digunakan untuk situasi itu. Saya diizinkan melakukan ini karena ini adalah perusahaan kecil yang menggunakan perangkat lunak yang sama untuk jangka waktu yang lama.

Dalam perusahaan pengembangan perangkat lunak yang lebih besar di mana waktu adalah uang, mungkin hanya mulai merancang dengan praktik yang lebih baik yang Anda pelajari dari titik ini ke depan, jangan khawatir tentang refactoring sampai verison 2 dari perangkat lunak tertentu?

Saya merasa mengajar kapan untuk refactor benar-benar tergantung pada perusahaan Anda saat ini.

"Kapan harus refactor?"

Jawaban singkat: setiap kali Anda menjumpai kode yang berbau tidak sedap atau dapat ditingkatkan ( Aturan Pramuka )

Secara praktis, ini terjadi:

• Jika Anda berlatih TDD, secara sistematis selama langkah Refactor dari siklus TDD, yaitu, setelah tes Anda hijau dan sebelum Anda mulai menulis tes baru.
• Sebagai hasil dari tinjauan kode
• Saat mengambil alih kode lawas
• Saat mengkonsumsi kode yang sepertinya dirancang dengan canggung
• dll.

Ketika saya pertama kali belajar tentang refactoring, mentor saya mengatakan kepada saya: "Lakukan dua kali, tahan hidungmu. Lakukan tiga kali. Refactor." (Terima kasih, Josh!) Untuk lebih spesifik, apa yang dia katakan adalah bahwa ketika Anda akan menulis blok kode yang sama untuk ketiga kalinya (atau bahkan pola kode yang serupa), itu adalah waktu untuk refactor. Saya telah mengikutinya selama 10 tahun terakhir, dan menganggapnya sebagai aturan yang cukup praktis.

Menggunakan Eclipse, atau IDE serupa yang memiliki dukungan refactoring yang kuat, mengurangi upaya untuk melakukan refactoring. Dukungan IDE membuatnya lebih mungkin Anda akan melakukan refactor segera setelah Anda menekan "ketiga kalinya" (atau melihat kebutuhan), daripada melihatnya sebagai upaya tambahan.

Juga - TDD juga sangat membantu di sini, karena Anda dapat terus menjalankan tes sebagai refactor, dan tahu bahwa Anda belum merusak apa pun.

Refactoring menurut definisi adalah suatu proses. Ini menyiratkan bahwa Anda tidak harus berusaha untuk menemukan waktu luang untuk melakukan tugas rafactoring, sebaliknya Anda harus terus refactoring setiap saat ketika Anda menemukan kode kode yang dapat ditulis lebih baik.

Secara pribadi saya suka menulis prototipe evolusi, mengatakannya lebih sederhana: kode yang hanya berfungsi, dan kemudian refactoring mereka sampai mereka akan memenuhi standar pengkodean yang diharapkan. Contoh bagus lainnya adalah menambahkan fungsionalitas tambahan dan refactoring kode yang ada untuk mengaktifkannya kembali.

Dalam 20 tahun pemrograman saya, di sini adalah satu-satunya aturan praktis yang benar-benar saya lihat berhasil, yang dapat dipatuhi orang, dan manajer memberikan waktu untuk itu. (Refactoring seperti diet: tentu saja, "kalori masuk / kalori keluar" adalah formula untuk menurunkan berat badan, tetapi itu tidak diterjemahkan ke dalam diet yang orang akan patuhi.) Jadi:

Refactor terus menerus, saat Anda bekerja. Gunakan Test Driven Development sehingga Anda memiliki beberapa siklus refactor merah-hijau sepanjang hari. Perbaiki hanya bagian-bagian kode yang telah Anda sentuh.

Setelah Anda lebih percaya diri, Anda dapat berbeda dari rejimen ini.

Saya pikir, itu tergantung pada tuntutan pemilik proyek dan orang yang menjawab untuk kualitas kode. Anda tidak bisa memutuskannya sendiri, ketika uang orang lain dipertanyakan.

Adapun alasan teknis, ada beberapa.

• Jika Anda memiliki bug dalam kode, itu berarti bahwa tempat ini disalahpahami dan SANGAT kemungkinan bahwa lebih banyak kesalahan dapat disembunyikan di sini dan tentunya akan ada masalah besar dengan upaya untuk mengembangkan bagian kode yang terhubung. Jadi, tempat ini harus diperiksa untuk kemungkinan refactoring.
• Alasan lain adalah ketika Anda menambah atau mengubah fitur dan kode lama sangat tidak nyaman untuk mengubah / menambah dan perubahan / penambahan nanti sangat mungkin. Tentu saja, Anda harus menyeimbangkan biaya.
• Mungkin alasan paling serius adalah ketika Anda mengubah kode dan itu tidak dapat ditebak.