ਤੁਸੀਂ ਇਹ ਕਿਵੇਂ ਫ਼ੈਸਲਾ ਕਰਦੇ ਹੋ ਕਿ ਕਿਸੇ ਸਿਸਟਮ ਨੂੰ refactor ਕਰਨਾ ਹੈ ਜਾਂ ਨਵੇਂ ਸਿਰਿਓਂ rewrite ਕਰਨਾ ਹੈ?

Question

Accepted Answer

Default **refactoring** ਵੱਲ ਹੋਵੋ। ਇੱਕ rewrite ਸਿਰਫ਼ ਉਦੋਂ ਜਾਇਜ਼ ਹੈ ਜਦੋਂ ਮੌਜੂਦਾ ਸਿਸਟਮ ਇੱਕ ਸਵੀਕਾਰਯੋਗ ਲਾਗਤ 'ਤੇ ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਹੋਰ ਵਿਕਸਤ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਅਤੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਕਰਦੇ ਹੋਏ ਕੀਮਤ ਪ੍ਰਦਾਨ ਕਰਦੇ ਰਹਿ ਸਕਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ "ਸਾਨੂੰ rewrite ਦੀ ਲੋੜ ਹੈ" ਪ੍ਰਵਿਰਤੀਆਂ ਅਸਲ ਵਿੱਚ ਇੱਕ ਅਣ-ਪ੍ਰਬੰਧਿਤ tech-debt ਸਮੱਸਿਆ ਹੁੰਦੀਆਂ ਹਨ ਜਿਸ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰ ਕੇ refactoring ਕਿਤੇ ਘੱਟ ਜੋਖ਼ਮ ਨਾਲ ਹੱਲ ਕਰ ਦਿੰਦੀ ਹੈ।

## ਮੈਂ ਇਸ ਬਾਰੇ ਕਿਵੇਂ ਤਰਕ ਕਰਦਾ ਹਾਂ

- **ਕੀ ਮੁੱਖ architecture ਅਜੇ ਵੀ ਵਿਹਾਰਕ ਹੈ?** ਜੇ data model, ਹੱਦਾਂ, ਅਤੇ runtime ਨਵੀਆਂ ਲੋੜਾਂ ਤੱਕ ਖਿੱਚੇ ਜਾ ਸਕਦੇ ਹਨ, ਤਾਂ refactor ਕਰੋ। ਜੇ ਬੁਨਿਆਦੀ ਧਾਰਨਾਵਾਂ ਗ਼ਲਤ ਹਨ (ਗ਼ਲਤ storage paradigm, scale ਕਰਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ, language/platform ਦਾ end-of-life), ਤਾਂ rewrite ਇੱਕ ਅਸਲ ਉਮੀਦਵਾਰ ਬਣ ਜਾਂਦਾ ਹੈ।
- **ਬਦਲਾਅ ਦੀ ਵਾਰੰਵਾਰਤਾ ਕੀ ਹੈ?** ਜੋ code ਕਦੇ-ਕਦਾਈ ਬਦਲਦਾ ਹੈ ਉਸ ਨੂੰ ਸੋਹਣਾ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ। ਮਿਹਨਤ ਉੱਥੇ ਕੇਂਦਰਿਤ ਕਰੋ ਜਿੱਥੇ ਟੀਮ ਰੋਜ਼ਾਨਾ ਕੰਮ ਕਰਦੀ ਹੈ।
- **ਕੀ ਅਸੀਂ ਮੌਜੂਦਾ ਵਿਹਾਰ ਨੂੰ ਸਮਝਦੇ ਹਾਂ?** ਇੱਕ rewrite edge-case ਗਿਆਨ ਦੇ ਸਾਲਾਂ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਜੇ ਕੋਈ tests ਅਤੇ ਕੋਈ spec ਨਹੀਂ ਹੈ, ਤਾਂ rewrite ਪੁਰਾਣੇ bugs ਨੂੰ ਮੁੜ-ਪੇਸ਼ ਕਰੇਗਾ।

## ਇੱਕ ਫ਼ੈਸਲਾ framework

| ਸੰਕੇਤ | refactor ਵੱਲ ਝੁਕੋ | rewrite ਵੱਲ ਝੁਕੋ |
| --- | --- | --- |
| Architecture ਲੋੜਾਂ ਨਾਲ ਫਿੱਟ ਹੈ | ਹਾਂ | ਨਹੀਂ |
| Test/spec coverage | ਘੱਟ ਜਾਂ ਉੱਚ | parity ਤਸਦੀਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਉੱਚ |
| ਇੱਕ-ਇੱਕ ਕਰ ਕੇ ship ਕਰ ਸਕਦੇ ਹਾਂ | ਹਾਂ | ਔਖਾ, big-bang |
| ਟੀਮ code ਨੂੰ ਸਮਝਦੀ ਹੈ | ਹਾਂ | ਨਹੀਂ, ਅਤੇ ਮੂਲ ਲੇਖਕ ਚਲੇ ਗਏ |

## Trade-offs

- **Refactor:** ਘੱਟ ਜੋਖ਼ਮ, ਲਗਾਤਾਰ delivery, ਪਰ ਇੱਕ ਸੱਚਮੁੱਚ ਸੜੀ ਹੋਈ ਬੁਨਿਆਦ 'ਤੇ ਹੌਲੀ।
- **Rewrite:** ਸਾਫ਼ ਸਲੇਟ, ਪਰ ਤੁਸੀਂ ਇੱਕ **feature-freeze ਟੈਕਸ** ਚੁਕਾਉਂਦੇ ਹੋ, **dual-maintenance ਲਾਗਤ** ਚੁੱਕਦੇ ਹੋ, ਅਤੇ ਕਲਾਸਿਕ second-system over-engineering ਜਾਲ ਦਾ ਜੋਖ਼ਮ ਲੈਂਦੇ ਹੋ।
- **strangler-fig** ਵਿਚਕਾਰਲੇ ਰਾਹ ਨੂੰ ਤਰਜੀਹ ਦਿਓ: ਪੁਰਾਣੇ ਦੇ ਨਾਲ-ਨਾਲ ਨਵਾਂ ਸਿਸਟਮ ਖੜ੍ਹਾ ਕਰੋ, traffic ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰ ਕੇ route ਕਰੋ, ਪੁਰਾਣੇ ਨੂੰ ਟੁਕੜੇ-ਟੁਕੜੇ ਕਰ ਕੇ ਮਿਟਾਓ। ਇਹ refactor-ਪੱਧਰ ਦੇ ਜੋਖ਼ਮ ਨਾਲ rewrite ਦੇ ਲਾਭ ਦਿੰਦਾ ਹੈ।

## ਗ਼ਲਤੀਆਂ

- ਕਾਰੋਬਾਰੀ ਲਾਗਤ ਦੀ ਬਜਾਏ **ਸੁਹਜ ਜਾਂ resume-driven** ਕਾਰਨਾਂ ਲਈ rewrite ਕਰਨਾ।
- ਲੁਕੇ ਵਿਹਾਰ ਨੂੰ ਘੱਟ ਅੰਦਾਜ਼ਣਾ; ਹਮੇਸ਼ਾ ਪਹਿਲਾਂ tests ਨਾਲ ਮੌਜੂਦਾ ਵਿਹਾਰ ਨੂੰ characterize ਕਰੋ।
- ਇੱਕ ਕਈ-ਤਿਮਾਹੀ big-bang rewrite ਜੋ ਕੁਝ ਵੀ ship ਨਹੀਂ ਕਰਦਾ — ਗਤੀ ਅਤੇ ਭਰੋਸਾ ਦੋਵੇਂ ਢਹਿ-ਢੇਰੀ ਹੋ ਜਾਂਦੇ ਹਨ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Refactor-ਬਨਾਮ-rewrite ਫ਼ੈਸਲਾ ਇੱਕ Tech Lead ਦੁਆਰਾ ਲਏ ਜਾਣ ਵਾਲੇ ਸਭ ਤੋਂ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਫ਼ੈਸਲਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਇਸ ਨੂੰ rewrite ਵੱਲ ਗ਼ਲਤ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਸਾਲ ਲਈ delivery freeze ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ ਅਸਫਲ ਹੋ ਸਕਦੇ ਹੋ; ਇਸ ਨੂੰ refactor ਵੱਲ ਗ਼ਲਤ ਕਰੋ ਅਤੇ ਤੁਸੀਂ ਹੌਲੀ-ਹੌਲੀ velocity ਗੁਆ ਬੈਠਦੇ ਹੋ। ਇਸ ਨੂੰ ਸੁਆਦ ਦੇ ਫ਼ੈਸਲੇ ਦੀ ਬਜਾਏ ਲਾਗਤ-ਅਤੇ-ਜੋਖ਼ਮ ਦੇ ਫ਼ੈਸਲੇ ਵਜੋਂ ਪੇਸ਼ ਕਰਨਾ ਹੀ ਸੀਨੀਅਰ ਨਿਰਣੇ ਨੂੰ ਤਰਜੀਹ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਸੰਕੇਤ	refactor ਵੱਲ ਝੁਕੋ	rewrite ਵੱਲ ਝੁਕੋ
Architecture ਲੋੜਾਂ ਨਾਲ ਫਿੱਟ ਹੈ	ਹਾਂ	ਨਹੀਂ
Test/spec coverage	ਘੱਟ ਜਾਂ ਉੱਚ	parity ਤਸਦੀਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਉੱਚ
ਇੱਕ-ਇੱਕ ਕਰ ਕੇ ship ਕਰ ਸਕਦੇ ਹਾਂ	ਹਾਂ	ਔਖਾ, big-bang
ਟੀਮ code ਨੂੰ ਸਮਝਦੀ ਹੈ	ਹਾਂ	ਨਹੀਂ, ਅਤੇ ਮੂਲ ਲੇਖਕ ਚਲੇ ਗਏ