Unaamuaje lini ufanye refactor dhidi ya kuandika upya (rewrite) mfumo kutoka mwanzo?

Question

Accepted Answer

Egemea **refactoring** kwa msingi. Rewrite huhalalishwa tu pale mfumo uliopo hauwezi tena kubadilika kukidhi mahitaji kwa gharama inayokubalika, na unaweza kuendelea kuwasilisha thamani unapoifanya. Silika nyingi za "tunahitaji rewrite" ni kweli tatizo la tech debt isiyodhibitiwa ambalo refactoring ya hatua kwa hatua hulitatua kwa hatari ndogo zaidi.

## Jinsi ninavyofikiria kuihusu

- **Je, usanifu wa msingi bado unafaa?** Ikiwa data model, mipaka, na runtime vinaweza kunyooka hadi mahitaji mapya, fanya refactor. Ikiwa dhana za msingi ni mbaya (paradigm ya storage isiyo sahihi, hakuna njia ya ku-scale, language/platform iliyofikia mwisho wa maisha), rewrite huwa mgombea halisi.
- **Mara kwa mara ya mabadiliko ni gani?** Msimbo unaobadilika mara chache hauhitaji kuwa mzuri. Zingatia juhudi pale timu inapofanya kazi kila siku.
- **Je, tunaelewa tabia ya sasa?** Rewrite hutupa miaka ya maarifa ya edge-case yaliyosimbwa. Ikiwa hakuna tests na hakuna spec, rewrite itarudisha bug za zamani.

## Mfumo wa uamuzi

| Ishara | Egemea refactor | Egemea rewrite |
| --- | --- | --- |
| Usanifu unakidhi mahitaji | Ndio | Hapana |
| Coverage ya test/spec | Ndogo au kubwa | Kubwa vya kutosha kuthibitisha usawa |
| Inaweza kuwasilishwa hatua kwa hatua | Ndio | Ngumu, big-bang |
| Timu inaelewa msimbo | Ndio | Hapana, na waandishi asili wameondoka |

## Mabadilishano

- **Refactor:** hatari ndogo, utoaji unaoendelea, lakini polepole kwenye msingi uliooza kweli.
- **Rewrite:** ubao safi, lakini unalipa **kodi ya kufungia vipengele (feature-freeze)**, unabeba **gharama ya matengenezo mawili (dual-maintenance)**, na hatari ya mtego wa kawaida wa kuzidisha usanifu wa mfumo wa pili.
- Pendelea njia ya kati ya **strangler-fig**: simamisha mfumo mpya kando ya wa zamani, elekeza trafiki hatua kwa hatua, futa wa zamani kipande kwa kipande. Hutoa faida za rewrite kwa hatari ya kiwango cha refactor.

## Makosa

- Kuandika upya kwa **urembo au sababu za resume-driven**, si gharama ya biashara.
- Kupuuza tabia iliyofichwa; daima tambua tabia ya sasa kwa tests kwanza.
- Rewrite ya big-bang ya robo nyingi za mwaka isiyowasilisha chochote — kasi na uaminifu vyote huanguka.

## Kwa nini ni muhimu

Uamuzi wa refactor-dhidi-ya-rewrite ni mojawapo ya maamuzi yenye nguvu kubwa zaidi ambayo Tech Lead hufanya. Ikose kuelekea rewrite na unaweza kufungia utoaji kwa mwaka na bado kushindwa; ikose kuelekea refactor na unavuja kasi taratibu. Kuitunga kama uamuzi wa gharama-na-hatari, si uamuzi wa ladha, ndio kinachotenganisha hukumu ya senior na upendeleo.

Ishara	Egemea refactor	Egemea rewrite
Usanifu unakidhi mahitaji	Ndio	Hapana
Coverage ya test/spec	Ndogo au kubwa	Kubwa vya kutosha kuthibitisha usawa
Inaweza kuwasilishwa hatua kwa hatua	Ndio	Ngumu, big-bang
Timu inaelewa msimbo	Ndio	Hapana, na waandishi asili wameondoka