ஒரு system-ஐ refactor செய்வதா அல்லது புதிதாக rewrite செய்வதா என்பதை எப்போது தீர்மானிக்கிறீர்கள்?

Question

Accepted Answer

**refactoring**-க்கு default ஆகுங்கள். தற்போதைய system ஏற்றுக்கொள்ளக்கூடிய செலவில் requirements-ஐ பூர்த்தி செய்ய இனி உருவாக முடியாதபோது மட்டுமே, மற்றும் அதைச் செய்யும்போது மதிப்பை தொடர்ந்து வழங்க முடிந்தால் மட்டுமே ஒரு rewrite நியாயப்படுத்தப்படுகிறது. பெரும்பாலான "எங்களுக்கு ஒரு rewrite தேவை" உள்ளுணர்வுகள் உண்மையில் ஒரு நிர்வகிக்கப்படாத tech-debt பிரச்சினையாகும், இதை incremental refactoring மிகவும் குறைந்த risk-உடன் தீர்க்கிறது.

## நான் அதைப் பற்றி எப்படி யோசிக்கிறேன்

- **core architecture இன்னும் viable ஆக இருக்கிறதா?** data model, boundaries, மற்றும் runtime புதிய requirements-க்கு நீள முடிந்தால், refactor செய்யுங்கள். அடிப்படை assumptions தவறாக இருந்தால் (தவறான storage paradigm, scale செய்ய வழியில்லை, language/platform end-of-life), ஒரு rewrite ஒரு உண்மையான வேட்பாளராக ஆகிறது.
- **change frequency என்ன?** அரிதாக மாறும் code அழகாக இருக்க வேண்டியதில்லை. team தினமும் வேலை செய்யும் இடத்தில் முயற்சியை குவியுங்கள்.
- **தற்போதைய behavior-ஐ புரிந்துகொள்கிறோமா?** ஒரு rewrite ஆண்டுகளாக encode செய்யப்பட்ட edge-case அறிவை வீசுகிறது. tests இல்லாமல், spec இல்லாமல், ஒரு rewrite பழைய bugs-ஐ மீண்டும் அறிமுகப்படுத்தும்.

## ஒரு முடிவு framework

| Signal | refactor சாய்வு | rewrite சாய்வு |
| --- | --- | --- |
| Architecture requirements-க்கு பொருந்துகிறது | ஆம் | இல்லை |
| Test/spec coverage | குறைவு அல்லது அதிகம் | parity சரிபார்க்க போதுமான அளவு அதிகம் |
| incrementally ship செய்ய முடியும் | ஆம் | கடினம், big-bang |
| team code-ஐ புரிந்துகொள்கிறது | ஆம் | இல்லை, மற்றும் original authors சென்றுவிட்டனர் |

## Trade-offs

- **Refactor:** குறைந்த risk, continuous delivery, ஆனால் உண்மையிலேயே அழுகிய அடித்தளத்தில் மெதுவானது.
- **Rewrite:** சுத்தமான slate, ஆனால் நீங்கள் ஒரு **feature-freeze tax** செலுத்துகிறீர்கள், **dual-maintenance cost** சுமக்கிறீர்கள், மற்றும் கிளாசிக் second-system over-engineering பொறி risk.
- **strangler-fig** நடுப் பாதையை விரும்புங்கள்: பழையதுடன் புதிய system-ஐ அமைத்து, traffic-ஐ incrementally route செய்து, பழையதை துண்டு துண்டாக நீக்கவும். இது refactor-level risk-உடன் rewrite நன்மைகளைக் கொடுக்கிறது.

## தவறுகள்

- வணிக செலவுக்காக அல்ல, **aesthetics அல்லது resume-driven** காரணங்களுக்காக rewrite செய்வது.
- மறைக்கப்பட்ட behavior-ஐ குறைத்து மதிப்பிடுவது; எப்போதும் முதலில் tests-உடன் தற்போதைய behavior-ஐ characterize செய்யுங்கள்.
- எதையும் ship செய்யாத ஒரு multi-quarter big-bang rewrite — வேகமும் நம்பிக்கையும் இரண்டும் சரிந்துவிடும்.

## இது ஏன் முக்கியம்

refactor-vs-rewrite முடிவு ஒரு Tech Lead எடுக்கும் மிக உயர்ந்த-leverage முடிவுகளில் ஒன்று. rewrite நோக்கி தவறாகச் செய்தால், ஒரு வருடம் delivery-ஐ முடக்கி இன்னும் தோல்வியடையலாம்; refactor நோக்கி தவறாகச் செய்தால், velocity-ஐ மெதுவாக இரத்தம் வடிக்கிறீர்கள். அதை ஒரு ரசனை முடிவாக அல்ல, செலவு-மற்றும்-risk முடிவாக வடிவமைப்பதுதான் senior judgment-ஐ விருப்பத்திலிருந்து பிரிக்கிறது.

Signal	refactor சாய்வு	rewrite சாய்வு
Architecture requirements-க்கு பொருந்துகிறது	ஆம்	இல்லை
Test/spec coverage	குறைவு அல்லது அதிகம்	parity சரிபார்க்க போதுமான அளவு அதிகம்
incrementally ship செய்ய முடியும்	ஆம்	கடினம், big-bang
team code-ஐ புரிந்துகொள்கிறது	ஆம்	இல்லை, மற்றும் original authors சென்றுவிட்டனர்