Sebagian besar kode saya memiliki cacat desain utama. Selesaikan atau perbaiki sekarang? [Tutup]

Saya seorang siswa sekolah menengah yang mengerjakan proyek C # dengan seorang teman saya dengan tingkat keterampilan yang sama dengan saya. Sejauh ini, kami telah menulis sekitar 3.000 baris kode dan 250 baris kode uji dalam rentang 100 komit. Karena sekolah, saya menunda proyek selama beberapa bulan dan baru-baru ini saya bisa mengambilnya kembali.

Pada saat saya mengambilnya kembali, saya mengerti bahwa kode yang saya tulis tidak dirancang dengan baik, seperti dimasukkannya utas yang berlebihan dalam penyaji, buruknya pencegahan kondisi lomba dalam interaksi antara CPU yang ditiru, GPU, dan kartrid permainan , serta kode yang hanya mubazir dan membingungkan.

Masalahnya adalah bahwa saya belum menyelesaikan bahkan fungsi utama dari program saya, jadi saya tidak dapat benar-benar menolak, dan saya merasa berkecil hati untuk terus menyadari bahwa desain kode saya cacat. Pada saat yang sama, saya tidak ingin meninggalkan proyek; sejumlah besar kemajuan telah dibuat dan pekerjaan tidak boleh sia-sia.

Saya merasa seolah-olah saya memiliki beberapa pilihan: untuk hanya menyelesaikan fungsionalitas dengan bekerja di sekitar desain yang buruk dan kemudian refactoring setelah semuanya bekerja, menghentikan semuanya dan bekerja untuk mengurai semuanya sebelum sisa fungsi dapat diselesaikan, memulai proyek seluruh sehingga segar di pikiran saya lagi, atau benar-benar meninggalkan proyek karena ukurannya yang berlebihan (pada dasarnya "kembali ke papan gambar").

Berdasarkan pengalaman orang lain dalam proyek-proyek semacam itu, apa jalan untuk mengembalikan diri ke jalur yang benar? Dari jawaban di situs ini, konsensus umum adalah bahwa menulis ulang pada umumnya tidak perlu tetapi merupakan opsi yang tersedia jika kode tidak dapat dipertahankan tanpa biaya berlebihan. Saya benar-benar ingin mengejar proyek ini, tetapi sebagaimana adanya, kode saya tidak dirancang dengan cukup baik untuk saya lanjutkan, dan perasaan sedih membuat saya tidak bisa melanjutkan.

Jika saya berada di posisi Anda, saya mungkin akan mencobanya dengan cara ini:

• pertama, selesaikan proyek saat ini - setidaknya sebagian - sesegera mungkin, tetapi dalam kondisi kerja . Mungkin Anda perlu mengurangi tujuan awal Anda, pikirkan fungsionalitas minimum yang benar-benar perlu Anda lihat di "versi 1.0".

• kemudian, dan hanya kemudian berpikir tentang menulis ulang dari awal (sebut ini "versi 2.0"). Mungkin Anda dapat menggunakan kembali beberapa kode dari V1.0. Mungkin setelah tidur lagi tentang situasi Anda sampai pada keputusan Anda bisa refactor V1.0 dan menyimpan sebagian besar. Tetapi jangan membuat keputusan ini sebelum Anda tidak memiliki "bukti konsep V1.0".

Program kerja "1.0" adalah sesuatu yang dapat Anda tunjukkan kepada orang lain, bahkan ketika kode itu buruk (yang tidak akan dipedulikan oleh orang lain, kecuali diri Anda sendiri). Jika di tengah membuat V2.0 Anda menyadari Anda kehabisan waktu, Anda masih memiliki V1.0 sebagai sebagian sukses, yang akan jauh lebih baik untuk moral Anda. Namun, jika Anda tidak menyelesaikan V1.0 terlebih dahulu, ada kemungkinan besar Anda tidak akan pernah menyelesaikan V2.0 karena ketika Anda setengah jalan, akan ada titik di mana Anda tidak puas dengan desain lagi, lalu? Apakah Anda akan meninggalkan V2.0 lagi dan bekerja di V3.0? Ada risiko tinggi berlari ke lingkaran yang tidak pernah berakhir ini, tidak pernah berakhir.

Lebih baik mengambil ini sebagai kesempatan untuk belajar bagaimana mencapai tujuan menengah, daripada kesempatan untuk belajar bagaimana meninggalkan proyek dalam keadaan yang belum selesai.

Proyek IT yang sudah jadi, bahkan yang salah, jauh lebih baik daripada yang belum selesai.

Yang belum selesai bisa banyak mengajari Anda, tetapi tidak sebanyak yang sudah selesai.

Anda mungkin tidak melihatnya sekarang, tetapi Anda mendapatkan sejumlah besar nilai yang bekerja bahkan dengan kode yang salah.

Pilihan saya berlaku untuk penyelesaian dan kemudian, mungkin, refactoring - jika perlu. Ketika Anda mulai bekerja dengan lebih banyak proyek, Anda akan melihat bahwa sering kali bagian yang "dimaksudkan untuk di-refactored" tetap tidak tersentuh selama bertahun-tahun, sementara bagian lainnya diperpanjang.

Dari sudut pandang ketenagakerjaan, dalam banyak kasus, Anda akan mendapatkan lebih banyak pujian untuk proyek yang sudah selesai.

Saya akan dengan senang hati memulai proyek ini.

Anda seorang siswa, dan Anda masih belajar. Ini menempatkan Anda pada posisi yang sangat berbeda dari pertanyaan yang Anda tautkan.

• Anda tidak memiliki tanggung jawab profesional untuk kode Anda; jika Anda menghapus seluruh proyek sekarang dan berjalan pergi, Anda tidak akan menderita akibat. Ini adalah keuntungan besar bagi pengembang. Dalam pertanyaan yang Anda tautkan, para pengembang itu mencoba memelihara perangkat lunak yang dibayar orang, dan bahkan bug kecil pun dapat menyebabkan masalah besar dengan pelanggan, yang membuatnya berbahaya untuk menulis dari awal. Anda tidak memiliki masalah itu.

• Sebagai proyek pribadi, ini adalah kesempatan sempurna untuk mencoba hal-hal baru dan belajar dari kesalahan Anda. Sangat menyenangkan mengetahui bahwa kode lama Anda bermasalah, karena itu berarti Anda telah belajar bagaimana melakukan yang lebih baik. Pengalaman melalui trial-and-error dapat sangat berharga bagi pemrogram pemula.

• Proyek Anda relatif kecil, dan pada dasarnya Anda tidak memiliki tes. Mungkin sesingkat beberapa malam untuk menulis 3000 baris dari awal, terutama karena Anda sudah memiliki ide tentang apa yang harus dilakukan lebih baik di waktu berikutnya.

• Bekerja di basis kode yang rusak akan jauh lebih menguras moral Anda daripada menulis ulang.

Selain itu, ini mungkin kesempatan besar untuk mencoba menulis program yang lebih modular dengan unit test. Melakukan hal itu akan membuatnya lebih mudah untuk memahami kode jika Anda kembali ke sana setelah istirahat lama, dan membantu mencegah kesalahan yang mungkin tidak sengaja Anda perkenalkan karena pelupa.

Akhirnya, di sini ada satu pendapat tentang kebijaksanaan terkadang mengambil langkah mundur untuk mengambil langkah maju yang lebih besar.

Anda mungkin masih berada di bagian "belajar cepat" dari perkembangan Anda. Ada peluang bagus bahwa beberapa bulan dari sekarang, Anda akan menemukan bahwa desain baru dan mengagumkan Anda rusak parah dengan cara yang bahkan tidak Anda sadari ketika Anda mulai.

Selesaikan semuanya - ini adalah satu-satunya hal terpenting yang perlu Anda pelajari. Percayalah, saya kenal banyak orang (bukan hanya programmer) yang terjebak dalam lingkaran "terus memulai dari awal karena saya telah belajar banyak sebelum saya memulai proyek ini". Masalahnya adalah itu tidak pernah berakhir - sampai Anda berhenti belajar hal-hal baru, yang bukan tempat yang menyenangkan :)

Ini juga penting untuk bisa menyelesaikan apa pun. Memulai dari awal itu menyenangkan, keren, menyenangkan ... tetapi jika Anda hanya belajar itu, Anda tidak akan pernah bisa menyelesaikan apa pun. Sekali lagi, itu bukan kemampuan yang sangat berguna, dan itu sebenarnya tidak terasa sebagus membuat sesuatu yang bermanfaat (atau menyenangkan). Hidup ini singkat, waktu terbatas, dan Anda tidak bisa terus berlatih tanpa hasil nyata - Anda akan menjadi sangat marah karenanya. Jika Anda merasa tidak dapat mulai bekerja karena Anda tidak dapat memutuskan pendekatan mana yang harus diambil, Anda sudah berada di zona bahaya.

Akan selalu ada impuls untuk memulai kembali. Bahkan dalam lingkungan belajar, kemungkinan besar itu adalah ide yang buruk. Itu tidak berarti Anda perlu membawa setiap prototipe ke aplikasi yang siap produksi, jauh dari itu. Tetapi Anda harus setidaknya sampai pada fase prototipe yang berfungsi - kemungkinan besar itu akan membantu moral Anda, dan itu adalah sifat yang sangat berguna bagi pengembang dalam bentuk apa pun. Selesaikan semuanya . Dan bagian yang menyenangkan adalah, Anda akan segera melihat bahwa ada sejuta lagi hal menyenangkan atau berguna yang dapat Anda lakukan dengan prototipe Anda daripada "menulis ulang dari awal" - dan dalam banyak kasus, bahkan melakukan refactoring. Segala sesuatu yang Anda lakukan memiliki biaya - setidaknya, Anda bisa saja melakukan sesuatu yang lain sementara itu.

Saya mengikuti ideologi "Jadikan Bekerja, Jadikan Benar, Jadikan Cepat" dalam pengembangan perangkat lunak.

1. Buat itu Bekerja : Tulis fungsionalitas inti, sehingga proyek dapat digunakan. Lakukan apa yang harus Anda lakukan untuk membuat semuanya berfungsi, bahkan jika itu berarti kode jelek.
2. Lakukan dengan Benar : Perbaiki bug dan perbaiki kode sehingga lebih mudah untuk membaca, memahami, dan memelihara.
3. Jadikan Cepat : Optimalkan program, yang bertujuan untuk keseimbangan yang baik antara kecepatan, penggunaan sumber daya, dan pemeliharaan.

Saat ini, Anda belum menyelesaikan langkah 1. Buat itu berfungsi dulu, dan kemudian Anda bisa khawatir tentang betapa jeleknya kode Anda. Sebenarnya menciptakan produk yang berfungsi adalah salah satu hal tersulit yang harus dilakukan pengembang baru, karena mereka begitu sibuk mencoba membuat kode mereka sempurna pertama kali, dan mereka terjebak dalam Optimasi Neraka dan tidak pernah benar-benar menyelesaikan penyelesaian. mengimplementasikan semua fitur. Anda harus belajar bagaimana mengesampingkan semua kekhawatiran tentang refactoring dan optimisasi sehingga Anda bisa fokus membuat perangkat lunak berfungsi. Setelah Anda mendapatkan lebih banyak pengalaman, secara alami Anda akan melakukan lebih banyak hal dengan benar pertama kali, jadi lebih sedikit refactoring diperlukan.

Perlu diingat: optimasi prematur adalah akar dari semua kejahatan (lihat pertanyaan Programmer.SE yang sangat baik ini untuk diskusi yang baik). Jika Anda menghabiskan terlalu banyak waktu untuk memikirkan bagaimana membuat kode Anda lebih baik, Anda terjebak dalam kelumpuhan analisis . Ini membunuh proyek. Lebih baik menyelesaikan proyek sebelum Anda mulai mencoba mengoptimalkannya.

Mengutip pembicara motivasi yang hebat: lakukan saja .

Seperti biasa, ada xkcd yang relevan:

Tulis ulang. Kode yang tidak berfungsi memiliki nilai yang kecil, dan tiga ribu baris tidak banyak kode. Tidak akan memakan waktu hampir sepanjang untuk menulis kode yang Anda miliki saat ini, dan itu akan jauh lebih baik. Saya sering membuang lima ratus atau seribu baris kode yang buruk, dan sering menulis ulang sepanjang seperlima.

Sebagian besar gagasan tentang "jangan menulis ulang" berhubungan dengan sistem besar yang melakukan hal-hal penting dan mengalami perubahan konstan untuk memenuhi persyaratan yang berkembang. Penulisan ulang sistem kompleks yang digunakan jarang berhasil.

Situasi Anda adalah kebalikannya. Anda memiliki aplikasi kecil tanpa pengguna dan satu-satunya persyaratan adalah yang Anda pilih untuk diterapkan. Jadi, silakan tulis ulang.

Memulai kembali dari awal biasanya merupakan langkah buruk dalam proyek kehidupan nyata, terutama karena proyek kehidupan nyata menumpuk perbaikan bug yang tidak disadari oleh pengembang baru (mis., Lihat Hal yang Seharusnya Tidak Pernah Dilakukan , dari Joel di blog Perangkat Lunak .)

Namun demikian, proyek sekolah tidak mewarisi sejarah seperti itu dan biasanya mulai dengan pengkodean dan desain pada saat yang sama dengan pengetahuan parsial tentang komputasi dan kurangnya pengalaman. Saya akan menganggap versi pertama Anda sebagai prototipe, yang digunakan sebagai bukti konsep yang telah gagal, dan saya akan dengan senang hati membuangnya (lihat Apa perbedaan antara prototipe throwaway dan evolusioner? Untuk diskusi tentang prototipe throwaway vs evolusioner.)

Desain yang tepat telah matang di kepala Anda dan tidak perlu banyak waktu untuk menuliskannya dalam kode.

Dengan penuh hormat saya akan tidak setuju dengan saran bahwa menulis ulang adalah ide yang buruk.

Dalam bidang siklus hidup perangkat lunak, secara umum diterima bahwa waktu dan upaya yang diperlukan untuk memperbaiki kesalahan meningkat dengan urutan besarnya setiap lapisan dalam siklus hidup. Artinya, jika diperlukan 1 jam untuk memperbaiki kesalahan pada tingkat persyaratan, itu akan membutuhkan 10 jam dalam desain, 100 jam dalam pengujian kode, dan 1000 jam sebagai perbaikan bug. Angka-angka itu mungkin terdengar keterlaluan, tetapi mereka diterima di industri sebagai kira-kira benar. Jelas, kurang dalam proyek yang lebih kecil, tetapi ide umumnya tetap ada. Jika proyek Anda memiliki cacat desain dasar, maka lebih tepat menyebutnya pengalaman belajar dan kembali, tinjau persyaratan awal dan desain ulang Anda.

Saya juga akan mendorong mempertimbangkan model Pengembangan Didorong menggunakan tes unit terstruktur. Mereka menyakitkan dan awalnya tampak seperti buang-buang waktu, tetapi kemampuan mereka untuk mengungkap kesalahan, terutama ketika mengintegrasikan dengan kode orang lain tidak dapat dinyatakan secara berlebihan.

Anda kehilangan saya pada kalimat ini:

Masalahnya adalah bahwa saya belum menyelesaikan bahkan fungsi utama dari program saya, jadi saya tidak dapat benar-benar menolak, dan saya merasa berkecil hati untuk terus menyadari bahwa desain kode saya cacat.

Saya percaya pada prinsip (dinyatakan dalam Systemantics ) itu

• Suatu sistem kompleks yang bekerja selalu ditemukan telah berevolusi dari sistem sederhana yang berfungsi.
• Sistem kompleks yang dirancang dari awal tidak pernah berfungsi dan tidak dapat ditambal untuk membuatnya berfungsi. Anda harus memulai dari awal, dimulai dengan sistem sederhana yang berfungsi.

Jadi, penulisan sistem yang rumit meliputi

• Menulis sistem yang sederhana
• Memastikan itu berhasil

... yaitu langkah-langkah berikut:

1. Tulis sedikit kode
2. Uji untuk memastikan itu berhasil
3. Tulis sedikit lebih banyak kode
4. Tes lagi
5. Dll

Perhatikan bahwa langkah 3 mungkin melibatkan:

3. Tulis sedikit lebih banyak kode
   1. Perbaiki kode yang ada untuk mempersiapkannya untuk penambahan baru
   2. Uji refactoring untuk memastikannya masih berfungsi
   3. Tambahkan fungsi baru

Juga, Langkah 2 "Uji untuk memastikannya berhasil" mungkin melibatkan penulisan ulang jika tidak.

Jika saya membangun di basis kode busuk saya akan enggan untuk menambah fungsionalitas lebih lanjut. Jadi saya cenderung untuk menjadwalkan sesuatu seperti "menyederhanakan implementasi threading yang ada" sebagai bagian dari pekerjaan yang akan dilaksanakan. Dengan asumsi bahwa Anda telah menguji saat Anda berjalan, Anda harus dapat memperlakukan ini sebagai latihan refactoring. Kriteria keberhasilan / keluar untuk fase kerja ini adalah:

• Kode sumber lebih sederhana
• Dan tidak ada bug baru yang diperkenalkan
• (Dan beberapa bug lama dihilangkan)

Secara kebetulan, "mengujinya untuk memastikan ia bekerja" tidak berarti "unit test" - ketika struktur tim sederhana, Anda dapat menguji sistem (sederhana) menggunakan tes sistem (sederhana) (bukan tes unit) .

Salah satu masalah yang Anda hadapi ketika mengalami masalah seperti ini, adalah Anda secara emosional melekat pada kode yang telah Anda tulis sejauh ini dalam beberapa cara.

Seorang kolega memberi tahu saya dia sedang menulis sebuah program saat di universitas sementara dia mendapat pelajaran dari seorang profesor terkenal (saya percaya itu adalah Dijkstra). Dia meminta profesor untuk melihat kode yang telah dia kerjakan selama lebih dari sebulan. Profesor bertanya kepadanya apakah dia telah membuat cadangan, dia menjawab tidak. Profesor itu kemudian menghapus semua kode dan menyuruhnya untuk menulisnya lagi.

Dia marah, tetapi 3 hari kemudian dia menyelesaikan program, dengan kode yang lebih bersih dan lebih sedikit bug dan lebih sedikit baris kode.

Cobalah untuk membuat perkiraan yang jujur ​​tentang opsi apa yang terbaik dalam waktu yang tersedia untuk proyek tersebut.

3 pilihannya adalah

• Hapus itu (sepenuhnya, tanpa melihat ke belakang)
• Terus bekerja dalam desain lama
• Kode refactor saat Anda pergi.

Saya telah menjadi programmer profesional selama lebih dari 10 tahun, dan dalam pekerjaan saya, saya berkesimpulan bahwa opsi terakhir adalah yang paling sering dipilih, tetapi tidak selalu merupakan pilihan terbaik.

Sepertinya keahlian Anda telah tumbuh secara substansial dalam periode waktu itu. Mungkin mengerjakan proyek itu berkontribusi padanya. Mendesainnya kembali sebagai pengalaman belajar yang disengaja akan membuahkan hasil.

Ingat, ini bukan sesuatu yang perlu Anda berikan sebagai program kerja untuk pelanggan. Itu ditulis khusus untuk latihan. Jadi, kecuali Anda ingin berlatih memiliki masalah pengiriman dan cacat pengiriman, saya pikir Anda saat ini berada dalam fase perkembangan di mana bekerja "otot desain" Anda akan terbukti bermanfaat.

Saat melakukannya, fokuslah pada proses desain dan perencanaan, dan renungkan hal-hal yang ada dan renungkan apa yang Anda pahami dengan lebih baik.

Refactor. Refactor. Refactor! REFACTOR !!!!

Jujur, tidak peduli seberapa berpengalaman Anda ini adalah masalah umum. Anda menulis kode, Anda belajar sesuatu, dan Anda ingin menggunakan pengetahuan baru pada kode lama. Anda ingin mengukur kode lama terhadap pengetahuan baru.

Itu tidak akan berhasil. Jika Anda melakukannya, aplikasi / game Anda tidak akan pernah selesai. Sebagai gantinya, cobalah untuk mengalokasikan waktu Anda pada proyek sehingga beberapa "tugas" Anda adalah untuk memperbaiki kode yang buruk. Katakanlah, misalnya, Anda memiliki metode mengerikan menyelamatkan permainan. Tetap bekerja pada gim itu sendiri, tetapi temukan waktu untuk memperbaiki (mengganti) metode mengerikan itu. Usahakan agar refactor tetap kecil, dan itu seharusnya tidak menjadi masalah.

Ketika Anda sampai ke bagian utama dari aplikasi yang membutuhkan refactor maka Anda melakukannya dengan salah, serius. Hancurkan refactoring itu ke bagian yang lebih kecil. Cobalah untuk menghabiskan tujuh jam menulis kode, dan satu jam refactoring.

Ketika Anda selesai dengan proyek dan Anda menekan pembekuan fitur, maka Anda dapat menghabiskan beberapa waktu refactoring besar-besaran. Untuk saat ini, selesaikan game, tetapi masih coba refactor beberapa. Itu yang terbaik yang bisa Anda lakukan.

Akan selalu ada sesuatu untuk diperbaiki.

Saya akan mengatakan itu sedikit tergantung pada jenis kode apa yang Anda miliki sekarang dan di mana tepatnya masalahnya. Yaitu, jika fondasi Anda bagus (desain kelas yang tepat di sebagian besar bagian, pemisahan / kohesi yang baik, dll., Hanya beberapa pilihan buruk seperti utas yang Anda sebutkan), maka dengan segala cara dapatkan tulang kosong keluar dan kemudian refactor seperti tidak ada hari esok.

Di sisi lain, jika itu benar-benar hanya sekelompok file teks yang ditampar jelek yang entah bagaimana melewati kompiler, tanpa struktur yang dapat dilihat, dll. (Dengan kata lain, prototipe pembelajaran-on-the-job-proof-of-concept), maka saya lebih suka menghapusnya dan memulai lagi.

Pada versi Anda berikutnya, lakukan pendekatan gesit: tentukan sendiri jadwal waktu berulang, seperti 2 minggu atau apa pun yang sesuai dengan jadwal Anda. Di awal setiap potongan (sebut saja sprint), tetapkan sendiri tujuan yang dapat dicapai dalam 2 minggu. Silakan dan lakukan itu, cobalah yang terkuat untuk membuatnya bekerja. Tetapkan tujuan Anda sehingga setelah setiap 2 minggu Anda memiliki sesuatu yang dapat ditunjukkan kepada teman, bukan hanya pekerjaan internal abstrak. Google "scrum" dan "smart goal". Ini semua sangat mudah dilakukan, jika Anda sendirian, hanya selembar kertas dengan beberapa poin yang cepat dicatat.

Jika Anda bisa melakukannya, maka memulai dari awal itu baik. Jika Anda tahu jauh di dalam hati bahwa setelah memulai dari awal Anda kemungkinan akan berakhir di tempat Anda berada sekarang, bagaimanapun, tetaplah dengan kode Anda dan membuatnya bekerja.

Anda harus menempatkan diri pada posisi pengusaha.

Bagi sebagian besar perekrut, Anda akan menjadi yang paling berharga jika Anda melakukannya: - Selesaikan dengan tes 100% pada kode baru yang Anda tulis. - Tambahkan tes untuk kode lama (dirancang buruk). - Refactor untuk mencapai apa yang Anda inginkan sebagai desain.

Lakukan semua itu dengan proses versi, cabang, dan tag yang baik.

Menulis ulang sering kali merupakan ide yang seksi, tetapi sering kali merupakan gagasan yang dimiliki pendatang baru yang agak berbahaya dalam kehidupan nyata. Menunjukkan bahwa Anda lebih bersedia untuk meningkatkan kualitas pekerjaan yang sudah Anda lakukan daripada mulai dari awal adalah pertanda baik bahwa Anda adalah orang yang serius.

Anda jelas dapat menulis ulang, tetapi buatlah proyek lain.

Hanya dengan menambahkan beberapa pengalaman masa lalu saya ke dalam campuran. Saya telah mengerjakan proyek sampingan selama lebih dari satu tahun sekarang, setiap kali saya mendapat waktu luang beberapa menit. Proyek ini berubah dari testbed sederhana ke kelas statis menjadi desain garis tipis berorientasi objek seperti sekarang.

Sepanjang semua perubahan ini saya telah menjaga fungsi kode yang sama, tidak termasuk perbaikan bug dan manfaat kinerja (harus secepat mungkin). Basis kode yang sama meskipun refactored tetap sama dan karenanya saya telah memperbaikinya secara besar-besaran tanpa harus menulis ulang kode dari awal dan membuang waktu.

Ini berarti bahwa saya telah dapat meningkatkan kode pada tingkat yang lebih cepat daripada yang saya mampu sebelumnya. Itu juga berarti ketika saya akan pergi, lebih mudah untuk mengatakan apa yang perlu dihapus, yaitu kelas yang tidak perlu, dan apa yang bisa tetap lebih mudah daripada menulis ulang dengan ide lama yang masih ada dalam pikiran saya.

Karena itu saran saya adalah untuk memperbaiki kode Anda dan pindah dari sana membuat perbaikan yang diperlukan. Meskipun ingat jika Anda memutuskan untuk menulis ulang dari awal, Anda harus mengambil ide-ide bagus dari proyek lama dan melihat mereka dengan cermat untuk melihat di mana mereka cacat. Yaitu jangan hanya menyalin kode lama ke proyek baru.

Jawabannya tergantung pada sesuatu yang saya suka menyebutnya "plafon kompleksitas". Saat Anda menambahkan semakin banyak ke basis kode, ada kecenderungan untuk menjadi lebih dan lebih kompleks dan semakin tidak terorganisir. Pada titik tertentu, Anda akan mencapai "plafon kompleksitas", di mana kemajuan kemajuan menjadi sangat sulit. Daripada mencoba untuk terus bergerak dengan kekerasan, lebih baik untuk membuat cadangan, mengatur ulang / menulis ulang, dan kemudian terus bergerak maju.

Jadi apakah basis kode Anda sangat buruk sehingga Anda mendekati plafon kompleksitas? Jika Anda merasa itu, luangkan waktu untuk membersihkan dan menyederhanakan sebelum melanjutkan. Jika cara termudah untuk membersihkan adalah menulis ulang beberapa bagian, itu tidak masalah.

Bukan? Kedua?

Lanjutkan dan seterusnya, luangkan waktu untuk merevisi desain yang ada dan beberapa waktu menambahkan fungsionalitas baru.

Jika Anda memiliki interaksi yang bersemangat, itu mungkin tempat yang baik untuk memulai ("thread berlebihan di renderer" terdengar seperti inefisiensi, daripada sesuatu yang akan menyebabkan masalah ketepatan). Lihat apakah Anda dapat menemukan cara umum untuk melepaskan diri dari ras (dan mungkin kebuntuan), atau setidaknya beberapa cara spesifik untuk melakukannya.

Saya tidak tahu sejauh mana hal-hal seperti kebuntuan dan detektor ras tersedia untuk C #, tetapi jika ada, mereka mungkin berguna dalam mengidentifikasi masalah apa yang ada dan memverifikasi bahwa perbaikan Anda berfungsi.

Saya menemukan bahwa, secara umum, saya lebih termotivasi untuk memperbaiki masalah dengan kode yang melakukan sesuatu yang bermanfaat, daripada membuangnya dan memulai, sekali lagi, dari awal. Ada kasus-kasus di mana pengembangan bidang yang hangus (analogi dengan ladang hijau dan ladang coklat ...) lebih memuaskan, tetapi itu biasanya untuk hal-hal di mana pendekatan yang ada begitu jauh dari tempat seharusnya tidak lagi salah.

Jika kode Anda modular maka Anda harus dapat menyelesaikan sisa kode di sekitar komponen yang ditulis dengan buruk kemudian menulis ulang komponen yang ditulis dengan buruk tanpa mempengaruhi sisa kode.

Dalam hal ini, terserah Anda ketika Anda menulis ulang komponen yang ditulis dengan buruk. Jika komponen-komponen yang ditulis dengan buruk ditulis dengan sangat buruk sehingga kode yang sudah selesai tidak akan berfungsi sebagaimana mestinya, maka Anda harus menuliskannya kembali sebelum Anda dapat menyelesaikan sisa kode.

Pertanyaan pertama yang harus Anda tanyakan pada diri sendiri adalah "seberapa buruk cacatnya?"

Apa yang sebenarnya kamu lakukan salah?

Jika ada sesuatu yang sangat buruk sehingga Anda akan membuang banyak waktu untuk bekerja dengan masalah ini, memaparkan data sensitif (kata sandi / kartu kredit), atau menyebabkan kerentanan buruk, maka mungkin Anda harus mengeditnya, tetapi sebagian besar waktu Anda dapat ambil apa yang Anda miliki, selesaikan, dan perbaiki masalah nanti.

Pemrogram suka meningkatkan aplikasi mereka, ingin mereka menjadi "yang terbaik yang bisa," tapi itu bukan pendekatan yang benar.

JIKA Anda merilis aplikasi Anda sesegera mungkin, bahkan jika itu tidak 100%, bug dan semua, maka Anda mendapatkan UMPAN BALIK dari orang lain, sambil memiliki waktu untuk memperbaiki bug dan hal-hal lain untuk versi 1.1. Orang lain akan dapat membantu Anda membuat aplikasi jauh lebih baik, dan Anda mungkin membuang waktu untuk melakukan sesuatu yang orang mungkin tidak suka.

Jadi dalam kasus Anda, keluarkan di sana, dapatkan umpan balik, dan kemudian Anda dapat menyusun versi 2.0 dengan semua perubahan, dan memperbaiki kekurangan yang Anda miliki.

Hal lain yang perlu diingat adalah kita terus membaik. Ada pepatah yang mengatakan bahwa jika Anda dapat melihat kode Anda dari setahun yang lalu, dan melihat bahwa itu buruk, itu berarti Anda masih membaik, dan itu hal yang hebat.

Itu tergantung pada seberapa kacau kode Anda.

• Jika Anda membuat kesalahan n00b nyata yang membuat kode Anda terlalu rumit atau bertele-tele, maka saya akan merekomendasikan untuk menulis ulang bagian-bagian itu.

• Jika Anda berpikir Anda memiliki bug serius yang harus Anda perbaiki, maka tulis beberapa tes unit yang dapat memeriksa apakah Anda telah memperbaiki bug (... karena Anda belum dapat meluncurkan program). Lebih baik untuk memperbaiki bug lebih awal, dan itu pasti lebih baik untuk memperbaiki bug saat Anda masih ingat apa yang kode lakukan.

• Jika Anda tidak menyukai metode apa yang dipanggil, atau kelas mana mereka berasal, atau hal-hal kecil seperti itu, maka gunakan saja IDE. (Ingat, ini C #, bukan javascript, python, perl, php, dll.) Ketika Anda mengerjakan kode yang menggunakan komponen yang terpengaruh, dan Anda memiliki gambaran yang jelas di kepala Anda tentang apa yang harus dilakukan komponen itu, kemudian refactor jika IDE Anda membuatnya tidak menyakitkan.

Kalau tidak, buat itu berfungsi dan asah keterampilan Anda pada proyek berikutnya.

Seperti yang disarankan orang lain, karena ini adalah proyek pribadi, bukan (belum) proyek profesional, saya serius akan mempertimbangkan penulisan ulang.

Namun, Anda dapat memanfaatkan metode ilmiah di sini, dengan melakukan percobaan. Pertama, bayangkan hipotesis. Punyaku adalah, "mungkin sudah waktunya untuk menulis ulang." Untuk menghemat waktu, mengurangi biaya kegagalan, dan agak membatasi bias apriori, sebelum Anda melakukan pemrograman lagi, tentukan lama waktu ("kotak waktu"). Saya akan menyarankan mungkin 4 jam dinding. Juga memutuskan metodologi untuk mengevaluasi hipotesis. Karena taruhannya rendah, saya sarankan sebagai metodologi, tanyakan pada diri sendiri: "Apakah saya senang saya melakukan ini?" Sekarang mulailah eksperimen. Setelah kotak waktu yang Anda pilih, apa evaluasi hipotesis? misalnya Dari contoh saya, apakah Anda senang Anda mulai menulis ulang sekarang karena Anda telah menghabiskan 4 jam melakukannya? Maka itu mungkin pilihan yang tepat.

Anda dapat meminta semua saran di dunia, tetapi tidak ada yang seperti menguji hipotesis secara empiris.

Beberapa alasan untuk mempertimbangkan pemilihan penulisan ulang sebagai eksperimen Anda:

• Dalam pengalaman saya, biasanya lebih menyenangkan. Alasan utama penulisan ulang seringkali tidak dipilih dalam situasi profesional adalah bahwa kesenangan jauh dari kriteria tunggal. Tetapi Anda masih relatif baru dalam pengkodean, jadi kesenangan mungkin adalah kriteria yang cukup penting, dan juga merupakan indikator faktor-faktor lain yang mungkin tidak berwujud bagi Anda pada tahap awal ini (kesenangan menunjukkan Anda akan belajar lebih banyak, dll.).
• Pengalaman Anda dan mungkin perasaan nurani yang mengganggu tampaknya memberi tahu Anda bahwa menulis ulang patut dipertimbangkan. Dengarkan suara itu, jika ada. Bahkan jika Anda tidak mengikuti saran itu, setidaknya dengarkan. Di masa depan akan ada lebih banyak suara eksternal, dan Anda perlu berlatih mendengarkan akal sehat Anda sendiri.
• Saya curiga dengan penulisan ulang, Anda lebih cenderung memodulasi kode Anda lebih banyak. Saat Anda membuat modul, Anda memiliki komponen yang dapat digunakan kembali dan andal yang dapat Anda manfaatkan untuk proyek lain. Anda bahkan mungkin menemukan bahwa pada akhirnya, apa yang tampak seperti modul belaka dari proyek utama Anda ternyata merupakan bagian kode yang paling menarik dan berharga yang Anda tulis.

Menyelesaikan sesuatu adalah ide yang bagus, tetapi tidak dalam ruang hampa. Jika Anda memulai penulisan ulang, maka Anda dapat memilih untuk menyelesaikan sesuatu dengan menyelesaikan sub-modul tertentu. Anda dapat menetapkan itu sebagai tujuan pertama, setelah percobaan di atas. Finishing tidak harus berarti menyelesaikan proyek utama awal Anda dulu. Setelah Anda menyelesaikan modul, selesaikan modul lain, dll., Hingga Anda selesai menulis ulang seluruh ruang lingkup proyek asli Anda, jika Anda mau.