Bagaimana anda menentukan bila perlu refactor berbanding rewrite sesuatu sistem dari awal?

Question

Accepted Answer

Lalai kepada **refactoring**. Satu rewrite hanya wajar apabila sistem sedia ada tidak lagi boleh berkembang untuk memenuhi keperluan pada kos yang boleh diterima, dan anda boleh terus menyampaikan nilai semasa melakukannya. Kebanyakan naluri "kita perlukan rewrite" sebenarnya ialah masalah tech debt yang tidak diurus yang refactoring berperingkat selesaikan dengan jauh kurang risiko.

## Bagaimana saya menaakulnya

- **Adakah seni bina teras masih berdaya maju?** Jika model data, sempadan, dan runtime boleh diregangkan untuk memenuhi keperluan baharu, refactor. Jika andaian asas adalah salah (paradigma storan yang salah, tiada cara untuk menskala, tamat hayat bahasa/platform), rewrite menjadi calon sebenar.
- **Apakah kekerapan perubahan?** Kod yang jarang berubah tidak perlu cantik. Tumpukan usaha di mana pasukan bekerja setiap hari.
- **Adakah kita memahami tingkah laku semasa?** Satu rewrite membuang bertahun-tahun pengetahuan kes-tepi yang dikodkan. Jika tiada ujian dan tiada spec, satu rewrite akan memperkenalkan semula pepijat lama.

## Satu rangka kerja keputusan

| Isyarat | Cenderung refactor | Cenderung rewrite |
| --- | --- | --- |
| Seni bina muat dengan keperluan | Ya | Tidak |
| Liputan ujian/spec | Rendah atau tinggi | Cukup tinggi untuk mengesahkan pariti |
| Boleh dihantar secara berperingkat | Ya | Sukar, big-bang |
| Pasukan memahami kod | Ya | Tidak, dan penulis asal sudah tiada |

## Trade-off

- **Refactor:** risiko lebih rendah, penyampaian berterusan, tetapi lambat pada asas yang benar-benar reput.
- **Rewrite:** helaian bersih, tetapi anda membayar **cukai pembekuan ciri**, menanggung **kos penyelenggaraan berganda**, dan berisiko perangkap klasik kejuruteraan-berlebihan sistem-kedua.
- Lebih utamakan laluan tengah **strangler-fig**: dirikan sistem baharu di sebelah yang lama, halakan trafik secara berperingkat, padam yang lama sekeping demi sekeping. Ia memberi manfaat rewrite dengan risiko tahap refactor.

## Perangkap

- Menulis semula atas alasan **estetika atau didorong resume**, bukan kos perniagaan.
- Memandang rendah tingkah laku tersembunyi; sentiasa cirikan tingkah laku semasa dengan ujian dahulu.
- Satu rewrite big-bang berbilang suku tahun yang tidak menghantar apa-apa — momentum dan kepercayaan kedua-duanya runtuh.

## Mengapa ia penting

Keputusan refactor-berbanding-rewrite adalah salah satu keputusan dengan leverage tertinggi yang dibuat seorang Tech Lead. Salahkan ia ke arah rewrite dan anda boleh membekukan penyampaian selama setahun dan tetap gagal; salahkan ia ke arah refactor dan anda menghakis velociti perlahan-lahan. Membingkaikannya sebagai keputusan kos-dan-risiko, bukan keputusan citarasa, adalah apa yang membezakan pertimbangan senior daripada pilihan peribadi.

Isyarat	Cenderung refactor	Cenderung rewrite
Seni bina muat dengan keperluan	Ya	Tidak
Liputan ujian/spec	Rendah atau tinggi	Cukup tinggi untuk mengesahkan pariti
Boleh dihantar secara berperingkat	Ya	Sukar, big-bang
Pasukan memahami kod	Ya	Tidak, dan penulis asal sudah tiada