Haruskah saya memperbaiki kode yang ditandai sebagai "jangan diubah"?

Saya berurusan dengan basis kode yang cukup besar dan saya diberikan beberapa bulan untuk memperbaiki kode yang ada. Proses refactor diperlukan karena kami akan segera perlu menambahkan banyak fitur baru ke produk kami dan untuk saat ini kami tidak lagi dapat menambahkan fitur apa pun tanpa merusak yang lain. Singkatnya: kode berantakan, besar, kereta, yang banyak dari kita lihat dalam karier mereka.

Selama refactoring, dari waktu ke waktu saya menjumpai kelas, metode atau baris kode yang memiliki komentar seperti

Waktu habis ditetapkan untuk memberi Modul A waktu untuk melakukan hal-hal. Jika tidak waktunya seperti ini, itu akan rusak.

atau

Jangan ubah ini. Percayalah, Anda akan merusak barang-barang.

atau

Saya tahu menggunakan setTimeout bukan praktik yang baik, tetapi dalam hal ini saya harus menggunakannya

Pertanyaan saya adalah: haruskah saya memperbaiki kode ketika saya menemukan peringatan seperti itu dari penulis (tidak, saya tidak bisa menghubungi penulis)?

Tampaknya Anda sedang melakukan refactoring "berjaga-jaga", tanpa tahu persis bagian mana dari basis kode secara detail akan diubah ketika pengembangan fitur baru akan berlangsung. Kalau tidak, Anda akan tahu jika ada kebutuhan nyata untuk memperbaiki modul rapuh, atau jika Anda dapat membiarkannya apa adanya.

Untuk mengatakan ini dengan lurus: Saya pikir ini adalah strategi refactoring yang gagal . Anda menginvestasikan waktu dan uang perusahaan Anda untuk sesuatu di mana tidak ada yang tahu apakah itu benar-benar akan memberikan manfaat, dan Anda berada di tepi memperburuk keadaan dengan memasukkan bug ke dalam kode kerja.

Ini strategi yang lebih baik: gunakan waktu Anda untuk

• tambahkan tes otomatis (mungkin bukan tes unit, tetapi tes integrasi) ke modul yang berisiko. Terutama modul-modul rapuh yang Anda sebutkan akan membutuhkan test suite lengkap sebelum Anda mengubah apa pun di sana.

• refactor hanya bit yang Anda butuhkan untuk membawa tes pada tempatnya. Cobalah untuk meminimalkan perubahan yang diperlukan. Satu-satunya pengecualian adalah ketika tes Anda mengungkapkan bug - kemudian segera memperbaikinya (dan refactor sejauh Anda perlu melakukannya dengan aman).

• ajar kolega Anda "prinsip pramuka" (AKA "refactoring oportunistik" ), jadi ketika tim mulai menambahkan fitur baru (atau untuk memperbaiki bug), mereka harus memperbaiki dan memperbaiki persis bagian-bagian dari basis kode yang perlu mereka ubah, tidak kurang, tidak lebih.

• dapatkan salinan buku Feather "Bekerja secara efektif dengan kode warisan" untuk tim.

Jadi ketika saatnya tiba ketika Anda tahu pasti Anda perlu mengubah dan memperbaiki modul rapuh (baik karena pengembangan fitur baru, atau karena tes yang Anda tambahkan pada langkah 1 mengungkapkan beberapa bug), maka Anda dan tim Anda siap untuk refactor modul, dan kurang lebih dengan aman mengabaikan komentar peringatan itu.

Sebagai balasan untuk beberapa komentar : bersikap adil, jika seseorang mencurigai modul dalam produk yang ada menjadi penyebab masalah secara teratur, terutama modul yang ditandai sebagai "jangan sentuh", saya setuju dengan semua kamu. Ini harus ditinjau ulang, didebug dan kemungkinan besar direaktor ulang dalam proses itu (dengan dukungan tes yang saya sebutkan, dan tidak harus dalam urutan itu). Bug adalah pembenaran yang kuat untuk perubahan, sering kali lebih kuat daripada fitur baru. Namun, ini adalah keputusan kasus per kasus. Kita harus memeriksa dengan sangat hati-hati jika benar-benar layak untuk mengubah sesuatu dalam modul yang ditandai sebagai "jangan sentuh".

Ya, Anda harus memperbaiki kode sebelum menambahkan fitur lainnya.

Masalah dengan komentar seperti ini adalah bahwa mereka bergantung pada keadaan lingkungan tertentu di mana basis kode berjalan. Batas waktu yang diprogram pada titik tertentu mungkin benar-benar diperlukan ketika diprogram.

Tetapi ada sejumlah hal yang dapat mengubah persamaan ini: perubahan perangkat keras, perubahan OS, perubahan yang tidak terkait dalam komponen sistem lain, perubahan volume data tipikal, sebut saja. Tidak ada jaminan bahwa pada hari ini masih diperlukan, atau itu masih cukup (integritas hal yang seharusnya dilindungi mungkin telah rusak untuk waktu yang lama - tanpa tes regresi yang tepat Anda mungkin tidak akan pernah memperhatikan). Inilah sebabnya mengapa pemrograman penundaan tetap untuk memungkinkan komponen lain untuk mengakhiri hampir selalu salah dan hanya berfungsi secara tidak sengaja.

Dalam kasus Anda, Anda tidak tahu keadaan aslinya, dan Anda juga tidak bisa bertanya kepada penulis aslinya. (Mungkin Anda juga tidak memiliki pengujian regresi / integrasi yang tepat, atau Anda bisa melanjutkan dan membiarkan tes Anda memberi tahu Anda apakah Anda memecahkan sesuatu.)

Ini mungkin terlihat seperti argumen untuk tidak mengubah apa pun karena kehati-hatian; tetapi Anda mengatakan bahwa bagaimanapun juga harus ada perubahan besar, sehingga bahaya mengganggu keseimbangan halus yang dulu dicapai di tempat ini sudah ada di sana. Jauh lebih baik untuk mengacaukan gerobak apel sekarang , ketika satu-satunya hal yang Anda lakukan adalah refactoring, dan pastikan bahwa jika ada yang rusak itu adalah refactoring yang menyebabkannya, daripada menunggu sampai Anda membuat perubahan tambahan secara bersamaan dan tidak pernah yakin.

Pertanyaan saya adalah: apakah saya harus memperbaiki kode ketika saya menemukan peringatan seperti itu dari penulis

Tidak, atau setidaknya belum. Anda menyiratkan bahwa tingkat pengujian otomatis sangat rendah. Anda perlu tes sebelum dapat melakukan refactor dengan percaya diri.

untuk saat ini kami tidak lagi dapat menambahkan fitur apa pun tanpa merusak sesuatu

Saat ini Anda perlu fokus pada peningkatan stabilitas, bukan refactoring. Anda mungkin melakukan refactoring sebagai bagian dari peningkatan stabilitas, tetapi ini adalah alat untuk mencapai tujuan Anda yang sebenarnya - basis kode yang stabil.

Sepertinya ini telah menjadi basis kode warisan, jadi Anda harus memperlakukannya sedikit berbeda.

Mulailah dengan menambahkan tes karakterisasi. Jangan khawatir tentang spek apa pun, cukup tambahkan tes yang menegaskan perilaku saat ini. Ini akan membantu mencegah pekerjaan baru dari melanggar fitur yang ada.

Setiap kali Anda memperbaiki bug, tambahkan test case yang membuktikan bahwa bug tersebut sudah diperbaiki. Ini mencegah regresi langsung.

Saat Anda menambahkan fitur baru, tambahkan setidaknya beberapa pengujian dasar bahwa fitur baru berfungsi sebagaimana dimaksud.

Mungkin mendapatkan salinan "Bekerja Efektif dengan Kode Legacy"?

Saya diberi waktu beberapa bulan untuk memperbaiki kode yang ada.

Mulailah dengan meningkatkan cakupan tes. Mulailah dengan area yang paling rusak. Mulailah dengan area yang paling banyak berubah. Kemudian setelah Anda mengidentifikasi desain yang buruk, gantilah satu per satu.

Anda hampir tidak pernah melakukan satu refactor besar, tetapi sebaliknya mengalir terus-menerus dari refactor kecil setiap minggu. Satu refactor besar memiliki risiko besar untuk memecahkan banyak hal, dan sulit untuk menguji dengan baik.

Ingat pagar GK Chesterton : jangan turun pagar yang menghalangi jalan sampai Anda mengerti mengapa itu dibangun.

Anda dapat menemukan pembuat kode dan komentar dalam pertanyaan, dan berkonsultasi dengan mereka untuk mendapatkan pemahaman. Anda dapat melihat pesan komit, utas email, atau dokumen jika ada. Kemudian Anda bisa memperbaiki fragmen yang ditandai, atau akan menuliskan pengetahuan Anda di komentar sehingga orang berikutnya yang mempertahankan kode ini dapat membuat keputusan yang lebih tepat.

Tujuan Anda adalah untuk mencapai pemahaman tentang apa yang dilakukan kode, dan mengapa kode itu ditandai dengan peringatan saat itu, dan apa yang akan terjadi jika peringatan itu diabaikan.

Sebelum itu, saya tidak akan menyentuh kode yang bertanda "jangan sentuh".

Kode dengan komentar seperti yang Anda tunjukkan akan menjadi yang teratas dalam daftar hal-hal yang akan direaksi jika, dan hanya jika saya punya alasan untuk melakukannya . Intinya, kode itu sangat busuk, Anda bahkan menciumnya melalui komentar. Tidak ada gunanya mencoba mengacak fungsi baru apa pun ke dalam kode ini, kode tersebut harus mati segera setelah perlu diubah.

Perhatikan juga bahwa komentar tidak banyak membantu: Mereka hanya memberi peringatan dan tanpa alasan. Ya, itu adalah tanda peringatan di sekitar tangki hiu. Tetapi jika Anda ingin melakukan apa pun di sekitarnya, ada sedikit poin untuk mencoba berenang bersama hiu. Imho, Anda harus menyingkirkan hiu itu terlebih dahulu.

Yang mengatakan, Anda benar-benar membutuhkan test case yang baik sebelum Anda berani bekerja pada kode tersebut. Setelah Anda memiliki kasus uji tersebut, pastikan untuk memahami setiap perubahan kecil yang Anda lakukan, untuk memastikan bahwa Anda benar-benar tidak mengubah perilaku. Jadikan prioritas utama Anda untuk menjaga semua keanehan perilaku kode hingga Anda dapat membuktikan bahwa mereka tidak berpengaruh. Ingat, Anda berurusan dengan hiu - Anda harus sangat berhati-hati.

Jadi, dalam kasus waktu habis: Biarkan sampai Anda mengerti persis apa kode menunggu, dan kemudian perbaiki alasan mengapa waktu habis diperkenalkan sebelum Anda melanjutkan untuk menghapusnya.

Juga, pastikan bahwa atasan Anda memahami upaya apa yang sedang Anda jalani, dan mengapa itu diperlukan. Dan jika mereka mengatakan tidak, jangan lakukan itu. Anda benar-benar membutuhkan dukungan mereka dalam hal ini.

Mungkin bukan ide yang baik untuk memperbaiki kode dengan peringatan seperti itu, jika semuanya berjalan dengan baik.

Tetapi jika Anda harus refactor ...

Pertama, tulis beberapa tes unit dan tes integrasi untuk menguji kondisi peringatan yang memperingatkan Anda. Cobalah untuk meniru kondisi seperti produksi sebanyak mungkin . Ini berarti mencerminkan basis data produksi ke server uji, menjalankan layanan lain yang sama pada mesin, dll ... apa pun yang dapat Anda lakukan. Kemudian cobalah refactoring Anda (pada cabang yang terisolasi, tentu saja). Kemudian jalankan pengujian Anda pada kode baru Anda untuk melihat apakah Anda bisa mendapatkan hasil yang sama dengan yang asli. Jika Anda bisa, maka mungkin OK untuk menerapkan refactoring Anda dalam produksi. Tapi bersiaplah untuk memutar kembali perubahan jika ada yang salah.

Saya katakan maju dan ubahlah. Percaya atau tidak, tidak setiap pembuat kode adalah jenius dan peringatan seperti ini berarti itu bisa menjadi tempat untuk perbaikan. Jika ternyata penulisnya benar, Anda dapat (megap-megap) DOKUMEN atau MENJELASKAN alasan peringatan itu.

Saya memperluas komentar saya menjadi sebuah jawaban karena saya pikir beberapa aspek dari masalah khusus diabaikan atau digunakan untuk menarik kesimpulan yang salah.

Pada titik ini, pertanyaan apakah refactor masih prematur (walaupun mungkin akan dijawab dengan bentuk spesifik 'ya').

Masalah utama di sini adalah bahwa (sebagaimana dicatat dalam beberapa jawaban) komentar yang Anda kutip sangat menunjukkan bahwa kode memiliki kondisi ras atau masalah konkurensi / sinkronisasi lainnya, seperti yang dibahas di sini . Ini adalah masalah yang sangat sulit, karena beberapa alasan. Pertama, seperti yang Anda temukan, perubahan yang tampaknya tidak terkait dapat memicu masalah (bug lain juga dapat memiliki efek ini, tetapi kesalahan concurrency hampir selalu terjadi.) Kedua, mereka sangat sulit untuk didiagnosis: bug sering memanifestasikan dirinya di tempat yang jauh dalam waktu atau kode dari penyebabnya, dan apa pun yang Anda lakukan untuk mendiagnosisnya dapat menyebabkannya hilang ( Heisenbugs). Ketiga, bug konkurensi sangat sulit ditemukan dalam pengujian. Sebagian, itu karena ledakan kombinatorial: itu cukup buruk untuk kode sekuensial, tetapi menambahkan interleaving yang mungkin dari eksekusi bersamaan meniupnya ke titik di mana masalah sekuensial menjadi tidak signifikan dibandingkan. Selain itu, bahkan uji kasus yang baik hanya dapat memicu masalah sesekali - Nancy Leveson menghitung bahwa salah satu bug mematikan di Therac 25terjadi di 1 dari sekitar 350 kali berjalan, tetapi jika Anda tidak tahu apa bug itu, atau bahkan ada bug, Anda tidak tahu berapa banyak pengulangan membuat tes yang efektif. Selain itu, hanya pengujian otomatis yang layak pada skala ini, dan ada kemungkinan bahwa penguji memaksakan batasan waktu halus sehingga tidak akan pernah benar-benar memicu bug (Heisenbugs lagi).

Ada beberapa alat untuk pengujian concurrency di beberapa lingkungan, seperti Helgrind untuk kode menggunakan pthreads POSIX, tetapi kami tidak tahu secara spesifik di sini. Pengujian harus dilengkapi dengan analisis statis (atau apakah itu sebaliknya?), Jika ada alat yang sesuai untuk lingkungan Anda.

Untuk menambah kesulitan, kompiler (dan bahkan prosesor, saat runtime) sering bebas mengatur ulang kode dengan cara yang kadang membuat alasan tentang keamanan utasnya sangat kontra-intuitif (mungkin kasus yang paling terkenal adalah pemeriksaan ulang). idiom kunci , meskipun beberapa lingkungan (Java, C ++ ...) telah dimodifikasi untuk memperbaikinya.)

Kode ini mungkin memiliki satu masalah sederhana yang menyebabkan semua gejala, tetapi kemungkinan besar Anda memiliki masalah sistemik yang dapat membuat rencana Anda untuk menghentikan fitur baru. Saya harap saya telah meyakinkan Anda bahwa Anda mungkin memiliki masalah serius di tangan Anda, mungkin bahkan ancaman eksistensial terhadap produk Anda, dan hal pertama yang harus dilakukan adalah mencari tahu apa yang terjadi. Jika ini mengungkapkan masalah konkurensi, saya sangat menyarankan Anda untuk memperbaikinya terlebih dahulu, bahkan sebelum Anda mengajukan pertanyaan apakah Anda harus melakukan refactoring yang lebih umum, dan sebelum Anda mencoba menambahkan lebih banyak fitur.

Saya berurusan dengan basis kode yang cukup besar dan saya diberikan beberapa bulan untuk memperbaiki kode yang ada. Proses refactor diperlukan karena kami akan segera menambahkan banyak fitur baru ke produk kami [...]

Selama refactoring, dari waktu ke waktu saya menjumpai kelas, metode, atau baris kode yang memiliki komentar seperti ["jangan sentuh ini!"]

Ya, Anda harus memperbaiki bagian-bagian itu terutama . Peringatan itu ditempatkan di sana oleh penulis sebelumnya yang berarti "jangan iseng mengutak-atik hal ini, itu sangat rumit dan ada banyak interaksi yang tidak terduga". Saat perusahaan Anda berencana untuk mengembangkan perangkat lunak lebih lanjut dan menambahkan banyak fitur, mereka secara khusus menugaskan Anda untuk membersihkan barang-barang ini. Jadi Anda tidak iseng - iseng merusaknya, Anda dengan sengaja ditugasi untuk membersihkannya.

Cari tahu apa yang dilakukan modul-modul rumit itu dan pecahkan menjadi masalah yang lebih kecil (apa yang seharusnya dilakukan oleh penulis asli). Untuk mendapatkan kode yang dapat dipelihara dari kekacauan, bagian-bagian yang baik perlu di-refactored dan bagian-bagian yang buruk perlu ditulis ulang .

Pertanyaan ini adalah variasi lain pada debat kapan / bagaimana merestorasi dan / atau membersihkan kode dengan tanda "bagaimana mewarisi kode". Kita semua memiliki pengalaman yang berbeda dan bekerja di organisasi yang berbeda dengan tim dan budaya yang berbeda, sehingga tidak ada jawaban benar atau salah kecuali "lakukan apa yang menurut Anda perlu Anda lakukan, dan lakukan dengan cara yang tidak membuat Anda dipecat" .

Saya tidak berpikir ada banyak organisasi yang akan berbaik hati untuk memiliki proses bisnis jatuh di sisinya karena aplikasi pendukung memerlukan pembersihan kode atau refactoring.

Dalam kasus khusus ini, komentar kode menaikkan tanda bahwa mengubah bagian kode ini tidak boleh dilakukan. Jadi, jika Anda melanjutkan, dan bisnis itu jatuh pada sisinya, Anda tidak hanya tidak memiliki apa pun untuk ditunjukkan untuk mendukung tindakan Anda, sebenarnya ada artefak yang bekerja bertentangan dengan keputusan Anda.

Jadi seperti yang selalu terjadi, Anda harus melanjutkan dengan hati-hati dan membuat perubahan hanya setelah Anda memahami setiap aspek dari apa yang akan Anda ubah, dan menemukan cara untuk menguji heck out dari itu memperhatikan sangat dekat dengan kapasitas dan kinerja dan waktu karena komentar dalam kode.

Tetapi meskipun demikian, manajemen Anda perlu memahami risiko yang melekat dalam apa yang Anda lakukan dan setuju bahwa apa yang Anda lakukan memiliki nilai bisnis yang melebihi risiko dan bahwa Anda telah melakukan apa yang dapat dilakukan untuk mengurangi risiko itu.

Sekarang, mari kita semua kembali ke TODO kita sendiri dan hal-hal yang kita tahu dapat ditingkatkan dalam kreasi kode kita sendiri jika saja ada lebih banyak waktu.

Ya, tentu saja. Ini adalah indikasi yang jelas bahwa orang yang menulis kode ini tidak puas dengan kode tersebut dan kemungkinan menusuknya sampai mereka berhasil bekerja. Mungkin saja mereka tidak mengerti apa masalah yang sebenarnya atau, lebih buruk lagi, memahami mereka dan terlalu malas untuk memperbaikinya.

Namun, itu peringatan bahwa banyak upaya akan diperlukan untuk memperbaikinya dan bahwa perbaikan tersebut akan memiliki risiko yang terkait dengan mereka.

Idealnya, Anda bisa mengetahui apa masalahnya dan memperbaikinya dengan benar. Sebagai contoh:

Waktu habis ditetapkan untuk memberi Modul A waktu untuk melakukan hal-hal. Jika tidak waktunya seperti ini, itu akan rusak.

Ini sangat menyarankan bahwa Modul A tidak menunjukkan dengan tepat kapan siap digunakan atau ketika telah selesai diproses. Mungkin orang yang menulis ini tidak mau repot memperbaiki Modul A atau tidak bisa karena suatu alasan. Ini tampak seperti bencana yang menunggu untuk terjadi karena itu menunjukkan ketergantungan waktu yang ditangani oleh keberuntungan daripada urutan yang tepat. Jika saya melihat ini, saya sangat ingin memperbaikinya.

Jangan ubah ini. Percayalah, Anda akan merusak barang-barang.

Ini tidak memberitahumu banyak. Itu akan tergantung pada apa yang dilakukan kode. Ini bisa berarti bahwa ia memiliki apa yang tampak sebagai optimasi yang jelas, karena satu dan lain alasan, akan benar-benar memecahkan kode. Sebagai contoh, sebuah loop mungkin terjadi untuk meninggalkan variabel pada nilai tertentu yang bergantung pada sepotong kode. Atau variabel mungkin diuji di utas lain dan mengubah urutan pembaruan variabel mungkin merusak kode lainnya.

Saya tahu menggunakan setTimeout bukan praktik yang baik, tetapi dalam hal ini saya harus menggunakannya.

Ini terlihat seperti yang mudah. Anda harus dapat melihat apa yang setTimeoutsedang dilakukan dan mungkin menemukan cara yang lebih baik untuk melakukannya.

Yang mengatakan, jika perbaikan semacam ini berada di luar ruang lingkup refactor Anda, ini adalah indikasi bahwa mencoba melakukan refactor di dalam kode ini dapat secara signifikan meningkatkan cakupan upaya Anda.

Paling tidak, perhatikan baik-baik kode yang terpengaruh dan lihat apakah Anda setidaknya dapat meningkatkan komentar hingga lebih jelas menjelaskan apa masalahnya. Itu mungkin menyelamatkan orang berikutnya dari menghadapi misteri yang sama yang Anda hadapi.

Penulis komentar kemungkinan besar tidak sepenuhnya memahami kode itu sendiri . Jika mereka benar-benar tahu apa yang mereka lakukan, mereka akan menulis komentar yang benar-benar bermanfaat (atau tidak memperkenalkan kondisi balap sejak awal). Sebuah komentar seperti " Percayalah padaku, kamu akan merusak barang-barang. " Bagiku menunjukkan penulis mencoba mengubah sesuatu yang menyebabkan kesalahan tak terduga yang tidak sepenuhnya mereka pahami.

Kode mungkin dikembangkan melalui menebak dan coba-coba tanpa pemahaman penuh tentang apa yang sebenarnya terjadi.

Ini berarti:

1. Beresiko untuk mengubah kode. Perlu waktu untuk memahami, jelas, dan mungkin tidak mengikuti prinsip-prinsip desain yang baik dan mungkin memiliki efek dan ketergantungan yang tidak jelas. Kemungkinan besar itu tidak cukup diuji, dan jika tidak ada yang sepenuhnya memahami apa yang dilakukan kode maka akan sulit untuk menulis tes untuk memastikan tidak ada kesalahan atau perubahan perilaku yang diperkenalkan. Kondisi balap (seperti komentar di atas) sangat sulit - ini adalah satu tempat di mana tes unit tidak akan menyelamatkan Anda.

2. Beresiko untuk tidak mengubah kode. Kode memiliki kemungkinan tinggi mengandung bug dan kondisi balap yang tidak jelas. Jika bug kritis ditemukan dalam kode, atau perubahan persyaratan bisnis prioritas tinggi memaksa Anda untuk mengubah kode ini dalam waktu singkat, Anda dalam masalah besar. Sekarang Anda memiliki semua masalah yang diuraikan dalam 1, tetapi di bawah tekanan waktu! Lebih jauh, "area gelap" dalam kode memiliki kecenderungan untuk menyebar dan menginfeksi bagian lain dari kode yang disentuhnya.

Komplikasi lebih lanjut: Tes unit tidak akan menyelamatkan Anda . Biasanya pendekatan yang disarankan untuk memperbaiki kode lama tersebut adalah dengan menambahkan unit atau tes integrasi terlebih dahulu, kemudian mengisolasi dan refactor. Tetapi kondisi balap tidak dapat ditangkap dengan pengujian otomatis. Satu-satunya solusi adalah duduk dan memikirkan kode sampai Anda memahaminya, dan kemudian menulis ulang untuk menghindari kondisi balap.

Ini berarti tugasnya jauh lebih menuntut daripada sekadar refactoring rutin. Anda harus menjadwalkannya sebagai tugas pengembangan nyata.

Anda mungkin dapat merangkum kode yang terpengaruh sebagai bagian dari refactoring reguler, jadi setidaknya kode berbahaya diisolasi.

Pertanyaan yang akan saya tanyakan adalah mengapa seseorang menulis, JANGAN EDIT di tempat pertama.

Saya telah bekerja pada banyak kode dan beberapa di antaranya jelek dan membutuhkan banyak waktu dan upaya untuk bekerja, dalam batasan yang diberikan pada saat itu.

Saya bertaruh dalam kasus ini, ini telah terjadi dan orang yang menulis komentar menemukan bahwa seseorang mengubahnya dan kemudian harus mengulangi seluruh latihan dan mengembalikannya ke jalan semula, untuk membuat benda itu bekerja. Setelah ini, karena frustrasi geser, mereka menulis ... JANGAN EDIT.

Dengan kata lain, saya tidak ingin harus memperbaikinya lagi karena saya memiliki hal-hal yang lebih baik untuk dilakukan dalam hidup saya.

Dengan mengatakan JANGAN EDIT, adalah cara untuk mengatakan bahwa kita tahu segala sesuatu yang akan kita ketahui sekarang dan oleh karena itu di masa depan kita tidak akan pernah belajar sesuatu yang baru.

Setidaknya harus ada komentar tentang alasan tidak mengedit. Seperti mengatakan "Jangan Sentuh" ​​atau "Jangan Masuk". Kenapa tidak menyentuh pagar? Kenapa tidak masuk? Bukankah lebih baik mengatakan, "Pagar Listrik, Jangan Menyentuh!" atau "Tambang Darat! Jangan Masuk!". Maka jelas mengapa, namun Anda masih bisa masuk, tetapi setidaknya tahu konsekuensinya sebelum Anda melakukannya.

Saya juga bertaruh sistem tidak memiliki tes di sekitar kode ajaib ini dan oleh karena itu tidak ada yang dapat mengkonfirmasi bahwa kode tersebut akan berfungsi dengan benar setelah perubahan apa pun. Menempatkan tes karakterisasi di sekitar kode masalah selalu merupakan langkah pertama. Lihat "Bekerja dengan Kode Warisan" oleh Michael Feathers untuk tips tentang cara memecahkan dependensi dan mendapatkan kode yang diuji, sebelum menangani mengubah kode.

Saya pikir pada akhirnya, disingkat melihat untuk membatasi refactoring dan membiarkan produk berevolusi secara alami dan organik.