Refactor atau Berkonsentrasi pada Aplikasi yang Menyelesaikan

Apakah Anda akan memperbaiki aplikasi saat Anda pergi atau fokus menyelesaikan aplikasi terlebih dahulu? Refactoring berarti kemajuan aplikasi aplikasi akan melambat.

Menyelesaikan aplikasi akan berarti Anda mendapatkan aplikasi yang sangat sulit nantinya?

Aplikasi ini adalah proyek pribadi. Saya tidak benar-benar tahu bagaimana menjawab "Apa yang mendorong fungsionalitas dan desain", tapi saya kira itu untuk mengatasi ketidakefisienan dalam perangkat lunak saat ini di luar sana. Saya suka perangkat lunak yang mudah digunakan juga. Jadi saya menghapus beberapa fitur dan menambahkan beberapa yang saya rasa akan membantu.

Buat itu bekerja. Kemudian membuatnya cepat. Akhirnya, buatlah itu indah.

Jika Anda memiliki pemisahan yang baik antara kode Anda (presentasi, bisnis, dan lapisan data) menggunakan antarmuka, dan itu bukan desain monolitik, maka refactoring seharusnya tidak terlalu sulit.

Jika Anda mengalami banyak kesulitan refactoring, itu mungkin bau kode - Saya sarankan Anda melihat Prinsip Padat

Saya pikir intinya adalah menjaga antarmuka tetap bersih . Anda selalu dapat refactor atau bahkan menulis ulang modul / kelas / implementasi apa pun di kemudian hari, selama lapisan komunikasi di antara mereka adalah waras. Luangkan waktu untuk mencari tahu apa yang mudah diubah di kemudian hari, dan apa yang tidak. Buat yang terakhir benar.

Ini konsisten dengan semangat TDD. Untuk menulis tes yang bagus, Anda membutuhkan antarmuka yang bagus untuk mengujinya. Betapa berantakan itu di belakang layar saat ini tidak begitu penting, karena Anda dapat memperbaikinya nanti.

Saya selalu refactor saat saya pergi, terutama menggunakan TDD.

1. Tulis tesnya

2. Lewati tes

3. Refactor

Ini akan membantu Anda memiliki lebih sedikit bug dan kode yang lebih baik untuk produk jadi. Ini juga akan membuat Anda memiliki lebih sedikit kode untuk dipertahankan ketika Anda selesai.

Refactor lebih awal dan sering! Waktu yang Anda "hemat" untuk tidak melakukannya dihabiskan berkali-kali untuk mencoba meretas fitur berikutnya dan mencari bug dalam kode yang terlalu rumit atau kacau.

Refactoring seperti mengambil kamar Anda.

Jika Anda menjaga hal-hal tetap rapi, Anda memiliki overhead linear, sebanding dengan jumlah pekerjaan produktif yang Anda lakukan pada kode, O (n) dalam istilah algoritolog. Dengan asumsi Anda menghabiskan 10% dari waktu refactoring Anda (atau menjaga kamar Anda rapi), bahwa 10% diberikan, dan itu akan tetap konstan seiring waktu.

Namun, jika Anda melemparkan pakaian kotor Anda ke sudut, dan terus melakukannya, jumlah waktu yang Anda habiskan untuk mengambil kamar Anda tumbuh seiring kekacauan menjadi lebih kompleks. Dengan asumsi bahwa setiap bagian dari cucian kotor berkontribusi secara eksponensial terhadap waktu pembersihan yang diperlukan, Anda sekarang berada dalam situasi O (e ⁿ ).

Siapa pun yang pernah menggali konsep kompleksitas algoritmik akan mengamati bahwa ada titik impas di suatu tempat, yaitu, ada jumlah optimal cucian kotor yang menumpuk; seberapa banyak itu tergantung pada faktor konstan yang dibuang dalam notasi O-besar. Faktor lain adalah nilai pekerjaan Anda dari waktu ke waktu: jika pekerjaan Anda bernilai banyak sekarang, tetapi murah minggu depan (yaitu, ada tenggat waktu hari Jumat ini untuk proyek ini dan tiga lagi, tetapi setelah itu, Anda akan kebanyakan menganggur ), persamaan mungkin berubah untuk tidak refactoring.

Dan kemudian ada kerumitan massa kritis. Pada titik tertentu, kekacauan ('kekacauan kritis', jika Anda mau) menjadi sangat buruk sehingga tampaknya lebih mudah membakar seluruh ruangan dan membeli pakaian baru. Pada kenyataannya biasanya tidak, tetapi tampaknya seperti itu, dan efek psikologis akan membuatnya sepuluh kali lebih sulit untuk mengatasi hal itu.

Dan jelas, jika Anda masuk ke proyek yang sudah menjadi kekacauan berlipat ganda raksasa, Anda memiliki pilihan terbatas.

TL; DR: Jika ragu, refactor. Anda harus memiliki bukti yang sangat baik sebelum memutuskan untuk tidak melakukannya.

Jika Anda memiliki kesempatan untuk menambahkan fitur atau menghancurkan bug untuk mendapatkan penjualan / kepuasan pelanggan di tempat yang menurut Anda seharusnya, lakukanlah. Setelah ada lebih sedikit tuntutan baru, Anda dapat menyeimbangkan dengan refactoring. Pada titik tertentu Anda harus memastikan Anda menulis kode yang diinginkan orang. Semua hal sama, saya lebih suka membuang 100 jam kode daripada 1000. Yang akan Anda lakukan jika tidak ada yang menginginkannya.

Sangat tergantung di mana Anda berada!

Hal-hal lain untuk dipikirkan:

Seberapa yakin Anda, Anda benar-benar mendapatkan desain fungsionalnya? Bisakah Anda mendesain ulang lagi setelah mendapat umpan balik dari pengguna?

Saya lebih suka melepaskan daripada menulis ulang. Optimalkan setelah Anda yakin telah memakukan desain fungsional.

Selama Anda yakin dapat memenuhi tenggat waktu, Anda yakin dapat memperbaiki semua yang Anda inginkan. Namun, bahkan jika ada sedikit ketidakpastian lebih baik untuk tetap dengan pengembangan dan mungkin refactor hanya dalam langkah bertahap sederhana.

Jika desain buruk yang ingin Anda refactor benar-benar menyakiti Anda, Anda lebih baik memperbaikinya sekarang daripada membuat lebih banyak kode yang bergantung padanya. Refactoring nanti akan lebih sulit dan lebih mahal; kemungkinan Anda tidak akan bisa melakukannya lagi.

Di sisi lain, jika satu-satunya masalah Anda adalah keburukan, Anda mungkin ingin menyelesaikan perangkat lunak Anda terlebih dahulu, karena hampir tidak ada yang mengalahkan menyelesaikan sesuatu .

Refactoring akan sangat penting saat Anda berupaya menyelesaikan aplikasi Anda.

+ VES

1. Clear Flow: Refactoring akan memberikan kejelasan kode karena kadang-kadang jika kode sedikit tidak terstruktur, memahami aliran kode setelah periode waktu akan menjadi sulit dan kode refactoring bisa menjadi tugas berat dan bug bisa diperkenalkan.

2. Meningkatkan kinerja: Refactoring yang tepat dari aplikasi pasti akan membantu meningkatkan kinerja aplikasi.

3. Pemeliharaan: Terakhir tetapi tidak sedikit, akan lebih mudah untuk mempertahankan dalam jangka panjang.

-VE

1. Konsumsi Waktu: Akan jauh lebih memakan waktu di setiap tahap kemajuan Anda. Sehingga bisa terjadi keterlambatan penyelesaian.

Intinya

Bergantung pada jenis proyek, Anda dapat memprioritaskan pada kualitas kode atau penyelesaian mana saja yang menuntut situasi saat ini.

Berdasarkan dari pengalaman pribadi saya, saya biasanya pergi untuk menyelesaikan aplikasi terlebih dahulu dengan syarat ada batas waktu yang harus dicapai. Setelah selesai, Anda dapat melakukan refactor.

Selesaikan dan perbaiki itu. Tetapi jika tidak ada tenggat waktu untuk terburu-buru atau kerangka waktu, saya sarankan refactoring itu akan baik.