09 ਜੂਨ 2025·8 ਮਿੰਟ
ਕਿਵੇਂ ਐਪ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ ਸੁਧਾਰਿਆ ਜਾਵੇ ਬਿਨਾਂ ਸਾਰਾ ਕੋਡ ਦੁਬਾਰਾ ਲਿਖੇ
ਰਿਸਕੀ ਪੂਰੇ ਰੀਰਾਈਟ ਦੇ ਬਗੈਰ ਐਪ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ ਸੁਧਾਰਨ ਦੇ ਵੇਵਹਾਰਿਕ ਤਰੀਕੇ ਜਾਣੋ—ਰੀਫੈਕਟਰਿੰਗ, ਟੈਸਟਿੰਗ, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਬਦਲਣ ਦੇ ਪੈਟਰਨ।
ਰਿਸਕੀ ਪੂਰੇ ਰੀਰਾਈਟ ਦੇ ਬਗੈਰ ਐਪ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ ਸੁਧਾਰਨ ਦੇ ਵੇਵਹਾਰਿਕ ਤਰੀਕੇ ਜਾਣੋ—ਰੀਫੈਕਟਰਿੰਗ, ਟੈਸਟਿੰਗ, ਫੀਚਰ ਫਲੈਗ, ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਬਦਲਣ ਦੇ ਪੈਟਰਨ।
ਬਿਨਾਂ ਰੀਰਾਈਟ ਕੀਤੇ ਐਪ ਨੂੰ ਸੁਧਾਰਣਾ ਮਤਲਬ ਹੈ ਛੋਟੇ, ਲਗਾਤਾਰ ਬਦਲਾਵ ਕਰਨਾ ਜੋ ਸਮੇਂ ਨਾਲ ਮਿਲਕੇ ਵੱਡਾ ਫਰਕ ਬਣਾਉਂਦੇ ਹਨ—ਜਦੋਂ ਕਿ ਮੌਜੂਦਾ ਉਤਪਾਦ ਚੱਲਦਾ ਰਹਿੰਦਾ ਹੈ। “ਸਾਰਾ ਰੁਕ ਕੇ ਦੁਬਾਰਾ ਬਣਾਓ” ਦੀ ਥਾਂ, ਤੁਸੀਂ ਐਪ ਨੂੰ ਇੱਕ ਜੀਵਤ ਸਿਸਟਮ ਵਾਂਗ ਦੇਖਦੇ ਹੋ: ਤੁਸੀਂ ਦਰਦ ਵਾਲੀਆਂ ਥਾਵਾਂ ਠੀਕ ਕਰਦੇ ਹੋ, ਜਿਹੜੀਆਂ ਹਿੱਸੇ ਤੁਹਾਨੂੰ ਹੌਲੀ ਕਰਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਅਧੁਨਿਕ ਬਣਾਉਂਦੇ ਹੋ, ਅਤੇ ਹਰ ਰਿਲੀਜ਼ ਨਾਲ ਗੁਣਵੱਤਾ ਵਧਾਉਂਦੇ ਰਹਿੰਦੇ ਹੋ।
ਕ੍ਰਮਿਕ ਸੁਧਾਰ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
ਹਿਮਤ ਦੀ ਚੀਜ਼ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ (ਅਤੇ ਕਾਰੋਬਾਰ) ਰਾਹ ਵਿੱਚ ਹੀ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਸੁਧਾਰਾਂ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਵੱਡੇ ਡਿਲੀਵਰੀ ਵਿੱਚ।
ਪੂਰਾ ਰੀਰਾਈਟ ਆਕਰਸ਼ਕ ਲੱਗ ਸਕਦਾ ਹੈ—ਨਵੀਂ ਟੈਕ, ਘੱਟ ਪਾਬੰਦੀਆਂ—ਪਰ ਇਹ ਖਤਰਨਾਕ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ:
ਅਕਸਰ ਮੌਜੂਦਾ ਐਪ ਵਿੱਚ ਸਾਲਾਂ ਦੀ ਉਤਪਾਦ ਸਿੱਖਿਆ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਰੀਰਾਈਟ ਗਲਤੀ ਨਾਲ ਉਹ ਸਾਰਾ ਸਿੱਖਿਆ ਗੁਆ ਸਕਦਾ ਹੈ।
ਇਹ ਅਪ੍ਰੋਚ ਜਾਦੂ ਨਹੀਂ ਹੈ। ਤਰੱਕੀ ਅਸਲ ਹੈ, ਪਰ ਇਹ ਮਾਪੇ ਜਾ ਸਕਦੇ ਨਤੀਜੇ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: ਘੱਟ ਇੰਸੀਡੈਂਟ, ਤੇਜ਼ ਰਿਲੀਜ਼ ਚੱਕਰ, ਸੁਧਰੇ ਪ੍ਰਦਰਸ਼ਨ, ਜਾਂ ਬਦਲਾਵ ਲਿਆਂਉਣ ਦਾ ਘੱਟ ਸਮਾਂ।
ਕ੍ਰਮਿਕ ਸੁਧਾਰ ਲਈ product, design, engineering, ਅਤੇ ਹੋਰ ਸਟੇਕਹੋਲਡਰਾਂ ਵਿੱਚ ਸਹਿਮਤੀ ਚਾਹੀਦੀ ਹੈ। Product ਇਹ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਕਿ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, design ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਬਦਲਾਵ ਯੂਜ਼ਰਾਂ ਨੂੰ ਭੁਲਾ ਦੇਂਦਾ ਨਹੀਂ, engineering ਬਦਲਾਵਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਟਿਕਾਊ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਸਟੇਕਹੋਲਡਰ ਲਗਾਤਾਰ ਨਿਵੇਸ਼ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਨਾ ਕਿ ਸਾਰੇ ਦਾਅਵੇ ਇੱਕ ਡੇਡਲਾਈਨ 'ਤੇ।
ਕੋਡ ਰੀਫੈਕਟਰ ਕਰਨ ਜਾਂ ਨਵੇਂ ٹੂਲ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਦਰਦ ਪੂਰਾ ਕਰ ਰਿਹਾ ਹੈ। ਟੀਮਾਂ ਅਕਸਰ ਲੱਛਣਾਂ (ਜਿਵੇਂ “ਕੋਡ ਗੰਦਾ ਹੈ”) ਦਾ ਇਲਾਜ ਕਰਦੀਆਂ ਹਨ, ਜਦਕਿ ਅਸਲ ਮਸਲਾ ਰਿਵਿਊ ਵਿੱਚ ਬੋਤਲ-ਨੇਕ, ਅਸਪਸ਼ਟ ਮੰਗਾਂ, ਜਾਂ ਟੈਸਟ ਕਵਰੇਜ ਦੀ ਘਾਟ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਤੁਰੰਤ ਨਿਰਣੇ ਨੇ ਮਹੀਨਿਆਂ ਦੀਆਂ ਬੇਕਾਰ “ਸੁਧਾਰ” ਕੋਸ਼ਿਸ਼ਾਂ ਬਚਾ ਸਕਦੀਆਂ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਲੈਗਸੀ ਐਪ ਇੱਕ ਨਟਿਕਲੇ ਤਰੀਕੇ ਨਾਲ fail ਨਹੀਂ ਹੁੰਦੇ—ਉਹ friction ਰਾਹੀਂ fail ਹੁੰਦੇ ਹਨ। ਆਮ ਸ਼ਿਕਾਇਤਾਂ:
ਇੱਕ ਆਫ-ਵਿਕ ਦੀ ਬਦਲੀ ਨਾਲ ਨਹੀਂ, ਪਰ ਪੈਟਰਨ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਮਜਬੂਤ ਸੂਚਕ ਹਨ:
ਖੋਜ ਨੂੰ ਤਿੰਨ ਬਕਟਲਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਉਹੀ ਕੋਡ ਨਹੀਂ “ਠੀਕ” ਕਰ ਰਹੇ ਜਦੋਂ ਅਸਲ ਸਮੱਸਿਆ ਮੰਗਾਂ ਦੇ ਦੇਰ ਨਾਲ ਆਉਣ ਜਾਂ mid-sprint ਬਦਲਣ ਵਾਲੀਆਂ ਹਨ।
ਕੁਝ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਠੀਕ ਤਰ੍ਹਾਂ ਟਰੈਕ ਕਰ ਸਕਦੇ ਹੋ:
ਇਹ ਨੰਬਰ ਤੁਹਾਡਾ ਸਕੋਰਬੋਰਡ ਬਣ ਜਾਣਗੇ। ਜੇ ਰੀਫੈਕਟਰਿੰਗ hotfixes ਜਾਂ cycle time ਘਟਾਉਂਦਾ ਨਹੀਂ, ਤਾਂ ਇਹ ਅਜੇ ਮਦਦ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਟੈਕਨੀਕਲ ਡੈਬਟ ਉਹ “ਭਵਿੱਖ ਦੀ ਲਾਗਤ” ਹੈ ਜੋ ਤੁਸੀਂ ਅੱਜ ਤੁਰੰਤ ਹੱਲ ਚੁਣਕੇ ਲੈਂਦੇ ਹੋ। ਜਿਵੇਂ ਗੱਡੀ ਦੀ ਨਿਯਮਤ ਸੇਵਾ ਛੱਡ ਦੇਣ: ਅੱਜ ਸਮਾਂ ਬਚਦਾ ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਵਿਆਜ ਸਮੇਤ ਵੱਧ ਖਰਚ ਆਉਂਦਾ ਹੈ—ਹੁਣੇ ਬਦਲਾਵ ਕਰਨ ਵਿੱਚ ਮਦਦ ਨਹੀਂ, ਬੱਗ, ਅਤੇ ਤਣਾਉ ਭਰਿਆ ਰਿਲੀਜ਼ਜ਼ ਵਿੱਚ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਜ਼ ਮਕਸਦਪੂਰਕ ਤੌਰ 'ਤੇ ਡੈਬਟ ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ। ਇਹ ਤਦ ਬਣਦੀ ਹੈ ਜਦੋਂ:
ਸਮੇਂ ਦੇ ਨਾਲ, ਐਪ ਫ਼ਿਰ ਵੀ ਚੱਲਦੀ ਹੈ—ਪਰ ਕਿਸੇ ਵੀ ਬਦਲਾਵ ਨੂੰ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਹੋਰ ਕੀ ਤੋੜ ਜਾਵੇਗਾ।
ਹਰ ਡੈਬਟ ਤੁਰੰਤ ਧਿਆਨ-ਯੋਗ ਨਹੀਂ ਹੁੰਦੀ। ਮਾਧਿਅਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਉੱਤੇ ਧਿਆਨ ਦੇਓ ਜੋ:
ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਕੋਡ ਦਾ ਹਿੱਸਾ अक्सर ਛੁਹਿਆ ਜਾਂਦਾ ਅਤੇ ਅਕਸਰ ਫੇਲ ਹੁੰਦਾ, ਤਾਂ ਉਹ ਸਾਫ਼ ਕਰਨ ਲਈ ਵਧੀਆ ਉਮੀਦਵਾਰ ਹੈ।
ਤੁਹਾਨੂੰ ਵੱਖਰਾ ਸਿਸਟਮ ਜਾਂ ਲੰਬੇ ਦਸਤਾਵੇਜ਼ ਦੀ ਲੋੜ ਨਹੀਂ। ਮੌਜੂਦਾ ਬੈਕਲੌਗ ਵਰਤੋ ਅਤੇ ਇੱਕ ਟੈਗ ਜੋੜੋ ਜਿਵੇਂ tech-debt (ਚਾਹੋ ਤਾਂ tech-debt:performance, tech-debt:reliability)।
ਜਦੋਂ ਫੀਚਰ ਕੰਮ ਦੌਰਾਨ ਤੁਸੀਂ ਡੈਬਟ ਵੇਖਦੇ ਹੋ, ਇੱਕ ਛੋਟਾ, ਨਿੱਜੀ ਬੈਕਲੌਗ ਆਈਟਮ ਬਣਾਓ (ਕੀ ਬਦਲਣਾ ਹੈ, ਕਿਉਂ ਮਤਲਬੀ ਹੈ, ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਗੇ ਕਿ ਇਹ ਬਿਹਤਰ ਹੈ)। ਫਿਰ ਇਸਨੂੰ product ਕੰਮ ਦੇ ਨਾਲ ਸਮੇਟੋ—ਤਾਂ ਜੋ ਡੈਬਟ ਦਿੱਖ ਵਿੱਚ ਰਹੇ ਅਤੇ ਚੁਪਕੇ ਨਾਲ ਨਾ ਵਧੇ।
ਜਦੋਂ ਤੁਸੀਂ ਸਿਰਫ “ਐਪ ਨੂੰ ਸੁਧਾਰੋ” ਕਹਿ ਦੇਓ ਬਿਨਾਂ ਯੋਜਨਾ ਦੇ, ਤਾਂ ਹਰ ਬੇਨਤੀ ਇੱਕੋ ਜਿਹੀ ਤਰਜੀਹ ਲੱਗਦੀ ਹੈ ਅਤੇ ਕੰਮ ਵਿਖਰ ਜਾਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਲਿਖਤੀ ਯੋਜਨਾ ਸੁਧਾਰਾਂ ਨੂੰ ਸ਼ਡਿਊਲ, ਸਮਝਾਉਣ ਅਤੇ ਬਚਾਉਣ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ ਜਦੋਂ ਤਰਜੀਹਾਂ ਬਦਲਣ।
2–4 ਟੀਚੇ ਚੁਣੋ ਜੋ ਕਾਰੋਬਾਰ ਅਤੇ ਯੂਜ਼ਰਾਂ ਲਈ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ। ਠੋਸ ਅਤੇ ਗੱਲ-ਬਾਤ ਯੋਗ ਰੱਖੋ:
“ਮਾਡਰਨਾਈਜ਼” ਜਾਂ “ਕੋਡ ਸਾਫ਼” ਵਰਗੇ ਟੀਚੇ ਏਕੱਲੇ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਨਤੀਜੇ ਲਈ ਜੋੜੋ।
ਨਜ਼ਦੀਕੀ ਵਿੰਡੋ ਚੁਣੋ—ਆਮ ਤੌਰ 'ਤੇ 4–12 ਹਫਤੇ—ਅਤੇ ਚੰਦ ਮੈਟ੍ਰਿਕਸ ਨਾਲ “ਬਿਹਤਰ” ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ। ਉਦਾਹਰਨ:
ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਮਾਪ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਪ੍ਰਾਕਸੀ ਵਰਤੋ (support ticket ਵਾਲੀਓਮ, incident.resolve ਦਾ ਸਮਾਂ, ਯੂਜ਼ਰ ਛੱਡਣ ਦੀ ਦਰ)।
ਸੁਧਾਰਾਂ ਨੂੰ ਫੀਚਰਾਂ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਹਰ ਹਿੱਸਾ ਲਈ ਕਿੰਨੀ ਸਮਰੱਥਾ ਰੱਖੀ ਜਾਵੇ (ਉਦਾਹਰਨ: 70% ਫੀਚਰ / 30% ਸੁਧਾਰ ਜਾਂ alternating sprints)। ਯੋਜਨਾ ਵਿੱਚ ਇਸਨੂੰ ਲਿਖੋ ਤਾਂ ਜੋ ਸੁਧਾਰ ਦਾ ਕੰਮ ਡੇਡਲਾਈਨ ਆਉਣ 'ਤੇ ਗਾਇਬ ਨਾ ਹੋ ਜਾਵੇ।
ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰੋਗੇ, ਕੀ ਅਜੇ ਨਹੀਂ ਕਰੋਗੇ, ਅਤੇ ਕਿਉਂ। ਟਰੇਡ-ਆਫ਼ ਤੇ ਸਹਿਮਤੀ ਕਰੋ: ਇੱਕ ਥੋੜ੍ਹਾ ਹੋਇਆ ਫੀਚਰ ਰਿਲੀਜ਼ ਦੇਰੀ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਘੱਟ incidents, ਤੇਜ਼ support ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਡਿਲਿਵਰੀ ਮਿਲ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਹਰ ਕੋਈ ਯੋਜਨਾ 'ਤੇ ਸਹਿਮਤ ਹੋਵੇ, ਕ੍ਰਮਿਕ ਸੁਧਾਰ ਪਹਿਲਾਂ ਦੀ ਤਰ੍ਹਾਂ ਜ਼ਬਰਦਸਤੀ ਦੀ ਬਜਾਏ ਲਾਗੂ ਰਹਿੰਦਾ ਹੈ।
ਰੀਫੈਕਟਰਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਕੋਡ ਦਾ ਦੁਬਾਰਾ ਇੰਤਜ਼ਾਮ ਕਰਨਾ ਬਿਨਾਂ ਐਪ ਦੇ ਵਿਹੇਵਿਅਰ ਨੂੰ ਬਦਲੇ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਦਾ ਫਰਕ ਨਹੀਂ ਮਹਿਸੂਸ ਹੋਣਾ ਚਾਹੀਦਾ—ਉਹੀ ਸਕ੍ਰੀਨ, ਉਹੀ ਨਤੀਜੇ—ਪਰ ਅੰਦਰੂਨੀ ਹਿੱਸੇ ਸਮਝਣ ਯੋਗ ਅਤੇ ਬਦਲਣ ਯੋਗ ਹੋ ਜਾਣ।
ਉਹ ਬਦਲਾਅ ਭੁਾਰੇ ਜੋ ਵਿਹੇਵਿਅਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੁੰਦੀ ਹੈ:
ਇਹ ਕਦਮ ਭੁਲ੍ਹ-ਭੁੱਲੈ ਨਾਲ ਭਰਪੂਰ ਹਨ ਅਤੇ ਭਵਿੱਖ ਦੇ ਸੁਧਾਰ ਸਸਤੇ ਕਰ ਦਿੰਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾ ਜੋੜਨ।
Practical ਆਦਤ: boy scout rule—ਜੋ ਕੋਡ ਤੁਸੀਂ ਮਿਲਿਆ ਉਸਨੂੰ ਥੋੜ੍ਹਾ ਬਿਹਤਰ ਛੱਡੋ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਹਿੱਸੇ ਨੂੰ ਬਗ ਠੀਕ ਕਰਨ ਜਾਂ ਫੀਚਰ ਜੋੜਨ ਲਈ ਛੂਹਦੇ ਹੋ, ਤਾਂ ਕੁਝ ਵਧੇਰੇ ਮਿੰਟ ਲੈ ਕੇ ਉਸੇ ਖੇਤਰ ਨੂੰ ਸੁਥਰਾ ਕਰੋ—ਇੱਕ ਫੰਕਸ਼ਨ ਨਾਮ ਬਦਲੋ, ਇੱਕ ਹੈਲਪਰ ਨਿਕਾਲੋ, ਮਰੇ ਹੋਏ ਕੋਡ ਨੂੰ ਹਟਾਓ।
ਛੋਟੇ ਰੀਫੈਕਟਰਜ਼ ਸਮੀਖਿਆ ਲਈ ਆਸਾਨ, ਰੱਦ ਕਰਨ ਲਈ ਆਸਾਨ, ਅਤੇ ਵੱਡੇ “ਸਾਫ਼-ਕਰੋ” ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲੋਂ ਘੱਟ ਖਤਰਨਾਕ ਹੁੰਦੇ ਹਨ।
ਰੀਫੈਕਟਰਿੰਗ ਬਿਨਾਂ ਸਪਸ਼ਟ ਖਤਮ-ਪੰਛਾਣ ਦੇ ਡੁੱਬ ਸਕਦੀ ਹੈ। ਇਸਨੂੰ ਅਸਲੀ ਕੰਮ ਵਾਂਗ ਮੰਨੋ ਅਤੇ ਪੂਰਾ ਹੋਣ ਦੇ ਨਿਸ਼ਾਨ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ-ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਬਹੁਤ ਵੱਡਾ ਹੈ—ਇਸਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਦੱਸਣ ਦਾ ਤੌਰ-ਤਰੀਕਾ ਹੋਵੇ ਕਿ ਕੋਈ ਬਦਲਾ ਕੁਝ ਤੋੜਿਆ ਹੈ, ਤਾਂ ਜਿੰਨੀ ਵੀ ਛੋਟੀ ਰੀਫੈਕਟਰਿੰਗ ਹੋਵੇ ਉਹ ਆਸਾਨ ਹੁੰਦੀ ਹੈ। ਆਟੋਮੇਟেড ਟੈਸਟ ਵਰਤੋਂਦੜਤਾ ਦਿੰਦੇ ਹਨ। ਇਹ ਬੱਗਾਂ ਖਤਮ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਉਹ ਛੋਟੇ ਰੀਫੈਕਟਰਜ਼ ਦੇ ਖਤਰੇ ਨੂੰ ਨਟਕੀਮ ਘਟਾ ਦਿੰਦੇ ਹਨ।
ਹਰ ਸਕ੍ਰੀਨ ਦੀ ਪੂਰੀ ਕਵਰੇਜ ਪਹਿਲੇ ਦਿਨ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਉਹਨਾਂ ਫਲੋਜ਼ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦੇ fail ਹੋਣ ਨਾਲ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ:
ਇਹ ਟੈਸਟ ਰਾਹ ਦਿਖਾਉਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਦੇ ਹੋ, ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਗਠਿਤ ਕਰਦੇ ਹੋ, ਜਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗੇਗਾ ਕਿ ਆਵਸ਼ਯਕ ਕੰਮ ਅਜੇ ਵੀ ਛੁਟੇ ਹੋ ਰਹੇ ਹਨ।
ਇੱਕ ਸਿਹਤਮੰਦ ਟੈਸਟ ਸੂਟ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨਾਂ ਕਿਸਮਾਂ ਦਾ ਮਿਸ਼ਰਣ ਹੁੰਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ legacy ਕੋਡ ਨੂੰ ਛੁਹ ਰਹੇ ਹੋ ਜੋ “ਚੱਲਦਾ ਹੈ ਪਰ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿਉਂ,” ਤਾਂ ਪਹਿਲਾਂ characterization tests ਲਿਖੋ। ਇਹ ਟੈਸਟ ਵਰਤੋ ਤਾਂ ਕਿ ਕੋਡ ਦਾ ਮੌਜੂਦਾ ਵਿਹੇਵਿਅਰ ਲੌਕ ਹੋ ਜਾਵੇ। ਫਿਰ ਬਿਨਾਂ ਡਰ ਦੇ ਰੀਫੈਕਟਰ ਕਰੋ—ਕਿਸੇ ਵੀ ਅਕਸਮਾਤੀ ਬਦਲਾਅ ਦਾ ਪਤਾ ਤੁਰੰਤ ਲੱਗ ਜਾਵੇਗਾ।
ਟੈਸਟ ਸਿਰਫ਼ ਫਾਇਦਾ ਕਰਦੀਆਂ ਹਨ ਜੇ ਉਹ ਭਰੋਸੇਯੋਗ ਰਹਿਣ:
data-test IDs, ਨਾ ਕਿ ਨਾਜੁਕ CSS paths)ਇਸ ਸੁਰੱਖਿਆ ਜਾਲ ਨਾਲ, ਤੁਸੀਂ ਛੋਟੇ-ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਐਪ ਨੂੰ ਜ਼ਿਆਦਾ ਘਬਰਾਏ ਬਿਨਾਂ ਸੁਧਾਰ ਸਕੋਗੇ।
ਜਦੋਂ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਪੰਜ ਹੋਰ ਜਗ੍ਹਾਂ 'ਤੇ ਅਚਾਨਕ ਤੋੜਦਾ ਹੈ, ਤਾਂ ਮੁੱਦਾ ਆਮ ਤੌਰ 'ਤੇ tight coupling ਹੁੰਦਾ ਹੈ: ਐਪ ਦੇ ਹਿੱਸੇ ਇੱਕ-ਦੂਜੇ 'ਤੇ ਛੁਪੇ, ਨਾਜੁਕ ਤਰੀਕੇ ਨਾਲ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ। ਮੋਡੀਊਲਰ ਕਰਨ ਦਾ ਅਭਿਆਸ ਪ੍ਰੈਟਿਕਲ ਫਿਕਸ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਐਪ ਨੂੰ ਅਜਿਹੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣਾ ਜਿਥੇ ਅਕਸਰ ਬਦਲਾਵ ਸਥਾਨਕ ਰਹਿਣ ਅਤੇ ਹਿੱਸਿਆਂ ਦੇ ਵਿਚਕਾਰ ਸੰਪਰਕ explicit ਅਤੇ ਸੀਮਤ ਹੋਣ।
ਉਹ ਖੇਤਰ ਚੁਣੋ ਜੋ ਪਹਿਲਾਂ ਹੀ “ਉਤਪਾਦ-ਵਾਂਗ” ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ। ਆਮ ਸਰਹੱਦਾਂ ਵਿੱਚ billing, user profiles, notifications, ਅਤੇ analytics ਸ਼ਾਮਲ ਹਨ। ਇੱਕ ਵਧੀਆ ਸਰਹੱਦ ਅਕਸਰ ਇਹ ਗੁਣ ਰੱਖਦਾ ਹੈ:
ਜੇ ਟੀਮ ਇਸਦੀ ਮਾਲਕੀ ਬਾਰੇ ਝਗੜ ਰਹੀ ਹੈ, ਤਾਂ ਇਹ ਸੰਕੇਤ ਹੈ ਕਿ ਸਰਹੱਦ ਸਪਸ਼ਟ ਨਹੀਂ।
ਇੱਕ ਮੋਡੀਊਲ ਸਿਰਫ਼ ਨਵੇਂ ਫੋਲਡਰ ਵਿੱਚ ਹੋਣ ਨਾਲ “ਅਲੱਗ” ਨਹੀਂ ਹੋ ਜਾਂਦਾ। ਅਲੱਗੀਕਰਨ ਇੰਟਰਫੇਸ ਅਤੇ ਡੇਟਾ contracts ਨਾਲ ਬਣਦੀ ਹੈ।
ਉਦਾਹਰਨ ਵਜੋਂ, ਕਈ ਹਿੱਸੇ billing ਟੇਬਲਾਂ ਨੂੰ ਸਿੱਧਾ ਪੜ੍ਹਨ ਦੀ ਜਗ੍ਹਾ, ਇੱਕ ਛੋਟੀ billing API (ਇਹਨੂੰ ਅੰਦਰੂਨੀ service/class ਹੀ ਰੱਖੋ) ਬਣਾਉ। ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਕੀ ਪੁੱਛਿਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਵਾਪਸ ਮਿਲੇਗਾ। ਇਸ ਨਾਲ ਤੁਸੀਂ billing ਦੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਬਾਕੀ ਐਪ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ।
ਮੁੱਖ ਵਿਚਾਰ: ਨਿਰਭਰਤਾਵਾਂ ਇਕ-ਥੱਲੇ ਅਤੇ ਜਾਣ-ਬੁਝ ਕੇ ਬਣਾਉ। ਸਥਿਰ IDs ਅਤੇ ਹਰਿਆਣੇ ਲਘੂ ਓਬਜੈਕਟਾਂ ਨੂੰ ਪਾਸ ਕਰੋ ਜਿਸ ਨਾਲ ਅੰਦਰੂਨੀ ਡੇਟਾਬੇਸ ਸਟ੍ਰਕਚਰ ਸਾਂਝੇ ਕਰਨ ਦੀ ਲੋੜ ਘੱਟ ਹੋ ਜਾਵੇ।
ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਭ ਕੁਝ redesign ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਮੋਡੀਊਲ ਚੁਣੋ, ਉਸਦੇ ਮੌਜੂਦਾ ਵਿਹੇਵਿਅਰ ਨੂੰ ਇੱਕ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਰੈਪ ਕਰੋ, ਅਤੇ ਕੋਡ ਨੂੰ ਉਸ ਸਰਹੱਦ ਦੇ ਪਿੱਛੇ ਕਦਮ-ਬ-ਕਦਮ ਸਥਾਨਾਂਤਰਿਤ ਕਰੋ। ਹਰ ਨਿਕਾਸ ਛੋਟਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਸਕੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰ ਸਕੋ ਕਿ ਹੋਰ ਕੁਝ ਟੁੱਟਿਆ ਨਹੀਂ—ਅਤੇ ਸੁਧਾਰਾਂ ਸੰਪੂਰਨ ਕੋਡਬੇਸ 'ਤੇ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਉਂਦੇ।
ਪੂਰਾ ਰੀਰਾਈਟ ਤੁਹਾਨੂੰ ਇੱਕ ਵੱਡੀ ਲਾਂਚ 'ਤੇ ਸਾਰਾ ਦਾਅ ਲਗਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। strangler approach ਇਹ ਥੀਅਰੀ ਵਿੱਪਰਿਤ ਹੈ: ਤੁਸੀਂ ਮੌਜੂਦਾ ਐਪ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਵੇਂ ਖੰਡ ਬਣਾਉਂਦੇ ਹੋ, ਕੇਵਲ ਸੰਬੰਧਿਤ ਬੇਨਤੀਆਂ ਨੂੰ ਨਵੇਂ ਹਿੱਸਿਆਂ ਵੱਲ ਰਾਹ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਬਿਰਦੀਰੇ ਪੁਰਾਣੇ ਸਿਸਟਮ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਘਟਾ ਦਿੰਦੇ ਹੋ।
ਆਪਣੇ ਮੌਜੂਦਾ ਐਪ ਨੂੰ “ਪੁਰਾਣਾ ਕੋਰ” ਸਮਝੋ। ਤੁਸੀਂ ਇੱਕ ਨਵਾਂ ਏਜ (ਨਵੀਂ service, ਮਾਡਿਊਲ, ਜਾਂ UI ਸਲਾਈਸ) ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਜੋ ਇੱਕ ਛੋਟਾ ਕੰਮ end-to-end ਸੰਭਾਲ ਸਕਦਾ ਹੈ। ਫਿਰ ਕੁਝ ਟ੍ਰੈਫਿਕ ਨਵੇਂ ਰਸਤੇ 'ਤੇ ਭੇਜੋ ਜਦੋਂ ਕਿ ਬਾਕੀ ਹੀ ਪੁਰਾਣੇ ਰਸਤੇ ਨੂੰ ਵਰਤਦੇ ਹਨ।
ਛੋਟੇ-ਛੋਟੇ ਹਿੱਸੇ ਜੋ ਪਹਿਲਾਂ ਬਦਲੇ ਜਾਣ ਯੋਗ ਹਨ:
/users/{id}/profile ਨੂੰ ਨਵੀਂ ਸੇਵਾ ਵਿੱਚ ਲਾਗੂ ਕਰੋ, ਬਾਕੀ endpoints legacy API 'ਚ ਰਹਿਣਪੈਰਲੇਲ ਰੰਸ ਖਤਰੇ ਘਟਾਉਂਦੇ ਹਨ। ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਐਸੇ ਨਿਯਮਾਂ ਨਾਲ ਰਾਹ ਦਿਓ: “10% ਯੂਜ਼ਰ ਨਵੇਂ endpoint ਤੇ ਜਾਂਦੇ ਹਨ,” ਜਾਂ “ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਸਟਾਫ਼ ਨਵੀਂ ਸਕ੍ਰੀਨ ਵਰਤਦੇ ਹਨ।” ਫਾਲਬੈਕ ਰੱਖੋ: ਜੇ ਨਵਾਂ ਰਸਤਾ error ਕਰੇ ਜਾਂ timeout ਹੋਵੇ, ਤਾਂ legacy ਜਵਾਬ ਦੇ ਸਕੋ ਅਤੇ ਲੋਗ ਰਿਕਾਰਡ ਕਰੋ ਤਾਂ ਕਿ ਮਸਲਾ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕੇ।
ਰਿਟਾਇਰਮੈਂਟ ਇੱਕ ਯੋਜਿਤ ਮਾਇਲਸਟੋਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸੋਚਿਆ-ਨਹੀਂ:
ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਗਿਆ, strangler approach ਲਗਾਤਾਰ ਨਜ਼ਰਅੰਦਾਜ਼ ਯੋਗ ਸੁਧਾਰ ਦਿੰਦਾ ਹੈ—ਬਿਨਾਂ rewrite ਦੇ “ਸਭ-ਜਾ-ਕਿਏ/ਕੁਝ-ਨਹੀਂ” ਖਤਰੇ ਦੇ।
Feature flags ਐਪ ਵਿੱਚ ਸਧਾਰਨ switches ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਨਵੀਂ ਬਦਲਾਅ ਨੂੰ ਰੀਡਿਪਲੋਇ ਕੀਤੇ ਬਿਨਾਂ ਚਾਲੂ/ਬੰਦ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੇ ਹਨ। “ਸਭ ਲਈ ਸ਼ਿਪ ਕਰੋ ਅਤੇ ਆਸ ਰੱਖੋ” ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਪਹਿਲਾਂ disable ਕੀਤੇ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਸ਼ਿਪ ਕਰਦੇ ਹੋ, ਫਿਰ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਧੀਰੇ-ਧੀਰੇ enable ਕਰਦੇ ਹੋ।
ਫਲੈਗ ਨਾਲ, ਨਵੀਂ ਵਿਹੇਵਿਅਰ ਇੱਕ ਛੋਟੀ ਦਰਸ਼ਕ ਨੂੰ ਸੀਮਿਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਏ, ਤੁਸੀਂ ਫਲੈਗ ਬੰਦ ਕਰਕੇ ਤੁਰੰਤ rollback ਕਰ ਸਕਦੇ ਹੋ—ਅਕਸਰ release ਨੂੰ revert ਕਰਨ ਨਾਲ ਤੇਜ਼।
ਆਮ ਰੋਲਆਉਟ ਪੈਟਰਨ:
ਫੀਚਰ ਫਲੈਗ ਇੱਕ ਗੰਦੇ “ਕੰਟਰੋਲ ਪੈਨਲ” ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਜੇ ਆਪ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਭਾਲਦੇ ਨਹੀਂ। ਹਰ ਫਲੈਗ ਨੂੰ ਇਕ ਛੋਟੇ-ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ ਭਾਲੋ:
checkout_new_tax_calc)\n- ਮਾਲਕੀ: ਕਿਸੇ ਵਿਅਕਤੀ/ਟੀਮ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰ ਰੱਖੋ\n- ਅਵਧੀ: ਫਲੈਗ ਨੂੰ ਹਟਾਉਣ ਜਾਂ ਨਵੇਂ ਵਿਹੇਵਿਅਰ ਨੂੰ ਸਥਾਈ ਕਰਨ ਦੀ ਆਖਰੀ ਤਾਰੀਖ ਸੈੱਟ ਕਰੋ\n- ਦਸਤਾਵੇਜ਼: ਇਹ ਕੀ ਬਦਲਦਾ ਹੈ, ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੋਵੇਗਾ, ਅਤੇ ਕਿਵੇਂ disable ਕਰਨਾ ਹੈਫਲੈਗਾਂ ਖਤਰੇ ਵਾਲੇ ਬਦਲਾਵਾਂ ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਜ਼ਿਆਦਾ ਹੋਣ ਤੇ ਐਪ ਸਮਝਣਾ ਤੇ ਟੈਸਟ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੁੱਖ ਰਾਹਾਂ (login, payments) ਨੂੰ ਛੋਟਾ ਰੱਖੋ, ਅਤੇ ਪੁਰਾਣੇ ਫਲੈਗਾਂ ਨੂੰ ਤੁਰੰਤ ਹਟਾਉ।
ਜੇ ਸੁਧਾਰ ਕਰਨਾ ਖਤਰਨਾਕ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਬਦਲਾਅ ਸ਼ਿਪ ਕਰਨਾ ਧੀਮਾ, ਹੱਥ-ਹੱਥ ਅਤੇ ਗੈਰ-ਇਕਸਾਰ ਹੈ। CI/CD (Continuous Integration / Continuous Delivery) ਡਿਲਿਵਰੀ ਨੂੰ ਰੁਟੀਨ ਬਣਾਉਂਦਾ ਹੈ: ਹਰ ਬਦਲਾਅ ਨੂੰ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਹਲ ਕੀਤਾ ਜਾਂਦਾ, ਨਾਲ ਹੀ ਚੈੱਕ ਹੁੰਦੇ ਹਨ ਜੋ ਮੁੱਦਿਆਂ ਨੂੰ ਜਲਦ ਫੜ ਲੈਂਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਾ pipeline ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਮਹਿੰਗਾ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ:
ਹਰ ਵਾਰੀ pipeline ਹੀ default ਰਾਹ ਹੋਵੇ, ਤਾਂ tribal knowledge ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ।
ਵੱਡੀਆਂ ਰਿਲੀਜ਼ ਡਿਬੱਗਿੰਗ ਨੂੰ detective ਕੰਮ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਬਹੁਤ ਸਾਰੇ ਬਦਲਾਅ ਇੱਕੱਠੇ ਲੈਂਡ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਇਹ unclear ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਬਦਲਾਅ ਬਗ ਜਾਂ ਧੀਮਾਪਨ ਲਿਆ। ਛੋਟੇ ਰਿਲੀਜ਼ ਕਾਰਨ-ਅਤੇ-ਅਸਰ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ।
ਉਹ ਕੋਆਰਡੀਨੇਸ਼ਨ ਓਵਰਹੈਡ ਨੂੰ ਵੀ ਘਟਾਉਂਦੇ ਹਨ। ਇੱਕ ਵੱਡੇ release day ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਤਿਆਰ ਹੋਣ 'ਤੇ ਸੁਧਾਰ ਸ਼ਿਪ ਕਰ ਸਕਦੀਆਂ ਹਨ—ਜੋ ਕਿ ਕ੍ਰਮਿਕ ਸੁਧਾਰ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਆਟੋਮੇਟ ਕਰੋ ਉਹ ਸੌਖੇ ਜੇਤੂ:
ਏਹ ਚੈੱਕ ਤੇਜ਼ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਉਹ ਹੌਲੇ ਜਾਂ flaky ਹੋਣ ਤਾਂ ਲੋਕ ਉਨ੍ਹਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰ ਦੇਣਗੇ।
ਰੇਪੋ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਚੈਕਲਿਸਟ (/docs/releasing ਵਰਗਾ) ਦਸਤਾਵੇਜ਼ ਕਰੋ: ਕੀ ਗਰੀਨ ਹੋਣਾ ਚਾਹੀਦਾ, ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ, ਅਤੇ deploy بعد verify ਕਰਨ ਲਈ ਕੀ ਕਰਨਾ ਹੈ।
ਇੱਕ rollback ਯੋਜਨਾ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇਹ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਅਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਕਿਵੇਂ revert ਕਰੀਏ? (ਪਿਛਲਾ ਵਰਜ਼ਨ, config switch, ਜਾਂ database-safe rollback steps)। ਜਦੋਂ ਹਰ ਕੋਈ escape hatch ਜਾਣਦਾ ਹੈ, ਤਾਂ ਸੁਧਾਰਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਨਾ ਹਰਿਆਣਾ ਬਣ ਜਾਂਦਾ ਹੈ।
Tooling note: ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਨਵੇਂ UI slices ਜਾਂ services ਨਾਲ ਅਧੁਨਿਕੀਕਰਨ 'ਤੇ ਐਕਸਪੇਰੀਮੈਂਟ ਕਰ ਰਹੀ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਵਰਗਾ Koder.ai ਤੁਹਾਨੂੰ chat ਰਾਹੀਂ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਦੁਹਰਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। snapshots/rollback ਅਤੇ planning mode ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਵ ਸ਼ਿਪ ਕਰਨ ਵੇਲੇ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹਨ।
ਜੇ ਤੁਸੀਂ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਆਪਣੀ ਐਪ ਕਿਵੇਂ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ ਨਹੀਂ ਦੇਖ ਸਕਦੇ, ਤਾਂ ਹਰ “ਸੁਧਾਰ” ਉਸ ਦਾ ਇੱਕ ਹਿੱਸਾ ਅਣਜਾਣ ਹੁੰਦਾ ਹੈ। ਪ੍ਰੋਡਕਸ਼ਨ ਮੋਨੀਟਰਿੰਗ ਤੁਹਾਨੂੰ ਸਬੂਤ ਦਿੰਦਾ ਹੈ: ਕੀ ਸਸਤਾ ਹੈ, ਕੀ ਟੁੱਟ ਰਿਹਾ ਹੈ, ਕੌਣ ਪ੍ਰਭਾਵਿਤ ਹੈ, ਅਤੇ ਕਿਸੇ ਬਦਲਾਅ ਨਾਲ ਕੀ ਫ਼ਰਕ ਪਿਆ।
Observability ਨੂੰ ਤਿੰਨ ਕਾਰੇਕ ਸ਼ੈਲੀਆਂ ਵਜੋਂ ਸੋਚੋ:
ਉਹ ਸਿਗਨਲ ਚੁਣੋ ਜੋ ਗਾਹਕ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ:
ਇੱਕ alert ਨੂੰ ਇਹ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਕੌਣ ਇਸਦਾ ਮਾਲਕ ਹੈ, ਕੀ ਟੁੱਟਿਆ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ। ਇਕੱਲੀ spike 'ਤੇ ਆਧਾਰਿਤ noisy alerts ਤੋਂ ਬਚੋ; thresholds ਨੂੰ ਕੁਝ ਸਮੇਂ ਦੀ ਵਿੰਡੋ 'ਤੇ ਮਨਜ਼ੂਰ ਕਰੋ (ਉਦਾਹਰਨ: “error rate >2% ਲਈ 10 ਮਿੰਟ”) ਅਤੇ ਸੰਬੰਧਿਤ dashboard ਜਾਂ runbook (/blog/runbooks) ਦੇ ਲਿੰਕ ਸ਼ਾਮਲ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਮੁਦਿਆਂ ਨੂੰ releases ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਅਤੇ fixes ਨੂੰ ਮਾਪਯੋਗ ਨਤੀਜਿਆਂ (ਘੱਟ crashes, ਤੇਜ਼ checkout, ਘੱਟ payment failures) ਦੇ ਆਧਾਰ 'ਤੇ ਤਰਜੀਹ ਦੇ ਸਕਦੇ ਹੋ—ਨ ਕਿ ਸਿਰਫ ਅਨੁਭਵ ਤੇ।
ਲੇਗਸੀ ਐਪ ਨੂੰ ਅਧੁਨਿਕ ਬਣਾਉਣਾ ਇੱਕ ਇਕ-ਵਾਰੀ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ—ਇਹ ਇੱਕ ਆਦਤ ਹੈ। momentum ਗੁੰਮ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਅਧੁਨਿਕੀਕਰਨ ਨੂੰ “ਔਰਜ” ਸਮਝ ਕੇ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ, ਜਿਸਦੀ ਕੋਈ ਮਾਲਕੀ ਨਾ ਹੋਵੇ, ਨਾ ਕੋਈ ਮੈਟਰਿਕ ਹੋਵੇ, ਅਤੇ ਹਰ ਤੁਰੰਤ ਮੰਗ ਨਾਲ ਤਾਲ-ਮਿਲਾਪ ਹੋ ਜਾਵੇ।
ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਕਿਸਨੇ ਕੀ ਮਾਲਕੀ ਹੈ। ਮਾਲਕੀ ਮੋਡੀਊਲ (billing, search) ਦੇ ਅਨੁਸਾਰ ਹੋ ਸਕਦੀ ਹੈ, ਜਾਂ cross-cutting ਖੇਤਰ (performance, security) ਦੇ ਅਨੁਸਾਰ, ਜਾਂ ਉਹ ਸੇਵਾਵਾਂ ਜੇ ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਵੰਡ ਚੁੱਕੇ ਹੋ।
ਮਾਲਕੀ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਕੇਵਲ ਤੁਸੀਂ ਹੀ ਇਸਨੂੰ ਛੂਹ ਸਕਦੇ ਹੋ।” ਇਸਦਾ ਅਰਥ ਇਹ ਹੈ ਕਿ ਇੱਕ ਵਿਅਕਤੀ (ਜਾਂ ਛੋਟੀ ਟੀਮ) ਜਿੰਮੇਵਾਰ ਹੋਵੇਗਾ:
Standards ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਦੋਂ ਉਹ ਛੋਟੀ, ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ, ਅਤੇ ਹਰ ਵਾਰੀ code review ਅਤੇ CI ਵਿੱਚ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣ। ਪ੍ਰਯੋਗਤਮ:
ਇੱਕ ਛੋਟੀ “Engineering Playbook” ਪੇਜ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਤਾਂ ਕਿ ਨਵੇਂ ਸਾਥੀ ਉਸ ਨੂੰ ਫਾਲੋ ਕਰ ਸਕਣ।
ਜੇ ਸੁਧਾਰ ਕੰਮ ਹਮੇਸ਼ਾਂ "ਜਦੋਂ ਸਮਾਂ ਮਿਲੇ" ਬਣੇ ਰਹਿੰਦਾ, ਤਾਂ ਇਹ ਕਦੇ ਨਹੀਂ ਹੋਵੇਗਾ। ਇੱਕ ਛੋਟਾ, ਦੁਹਰਾਉਣਯੋਗ ਬਜਟ ਰੱਖੋ—ਮਹੀਨਾਵਾਰ cleanup ਦਿਨ ਜਾਂ ਤਿਮਾਹੀ ਲਕੜੀਆਂ ਜੋ ਇੱਕ ਜਾਂ ਦੋ ਮਾਪਯੋਗ ਨਤੀਜਿਆਂ (ਘੱਟ incidents, ਤੇਜ਼ deploys, ਘੱਟ error rate) ਨਾਲ ਜੁੜੀਆਂ ਹੋਣ।
ਆਮ ਨਾਕਾਮੀ ਦੇ ਢੰਗ ਅੰਦਾਜੇ ਲਾਏ ਜਾ ਸਕਦੇ ਹਨ: ਸਭ ਕੁਝ ਇਕੱਠੇ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼, ਮੈਟ੍ਰਿਕਸ ਬਿਨਾਂ ਤਬਦੀਲੀਆਂ ਕਰਨਾ, ਅਤੇ ਪੁਰਾਣੇ ਰਸਤੇ ਕਦੇ ਨ ਹੀ ਹਟਾਉਣਾ। ਛੋਟਾ ਯੋਜਨਾ ਬਣਾਓ, ਪ੍ਰਭਾਵ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਜੋ ਤੁਸੀਂ ਬਦਲਿਆ ਹੈ ਉਸਨੂੰ ਹਟਾਓ—ਨਾਹ ਤਾਂ complexity ਵਧਦੀ ਹੀ ਰਹੇਗੀ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ “ਬਿਹਤਰ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਹ ਕਿਵੇਂ ਮਾਪੋਗੇ (ਉਦਾਹਰਨ: ਘੱਟ hotfixes, ਤੇਜ਼ cycle time, ਘੱਟ error rate)। ਫਿਰ ਸੁਧਾਰ ਕੰਮ ਲਈ ਖਾਸ ਸਮਰੱਥਾ ਰੱਖੋ (ਜਿਵੇਂ 20–30%) ਅਤੇ ਇਸਨੂੰ ਫੀਚਰਾਂ ਦੇ ਨਾਲ ਛੋਟੇ-ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਰਿਲੀਜ਼ ਕਰੋ।
ਕਿਉਂਕਿ ਰੀਰਾਈਟ ਅਕਸਰ ਬਨਸਪੇ ਨਾਲੋਂ ਲੰਮਾ ਲੈਂਦਾ ਹੈ, ਪੁਰਾਣੀਆਂ ਬੱਗਾਂ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ “ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ” (ਐਜ ਕੇਸ, ਇੰਟੀਗਰੇਸ਼ਨ, ਐਡਮਿਨ ਟੂਲ) ਗੁਆਊਂਦਾ ਹੈ। ਕ੍ਰਮਿਕ ਸੁਧਾਰ ਮੁੱਲ ਜਾਰੀ ਰੱਖਦਾ ਹੈ, ਖਤਰੇ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਪੈਦਾਵਾਰੀ ਸਿੱਖਣ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ।
ਆਮ ਰੂਪ ਵਿੱਚ ਪੈਟਰਨ ਵੇਖੋ: ਅਕਸਰ hotfixes, ਲੰਬਾ onboarding, “ਛੂਹਣ ਨਹੀਂ” ਵਾਲੇ ਮੋਡੀਊਲ, ਹੌਲੀ ਰਿਲੀਜ਼, ਅਤੇ ਉੱਚ support ਲੋਡ। ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਤਿੰਨ ਸਲੋਟਾਂ ਵਿੱਚ ਵੰਡੋ: process, code/architecture, ਅਤੇ product/requirements — ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰੋ ਜੋ ਅਸਲ ਵਿੱਚ ਦਰਦ ਦੇ ਰਹੀ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ ਲੱਛਣ।
ਕੁਝ ਛੋਟੇ ਬੇਸਲਾਈਨ ਮੈਟ੍ਰਿਕਸ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਹਫ਼ਤਾਵਾਰੀ ਤੌਰ 'ਤੇ ਵੇਖ ਸਕਦੇ ਹੋ:
ਈਹ ਤੁਹਾਡਾ ਸਕੋਰਬੋਰਡ ਬਣ ਜਾਵੇਗਾ; ਜੇ ਰੀਫੈਕਟਰਿੰਗ ਨੇ ਇਹ ਨੰਬਰ ਘਟਾਏ ਨਹੀਂ, ਤਾਂ ਇਹ ਵੀ ਨਹੀਂ ਕਰ ਰਿਹਾ।
ਟੈਕਨੀਕਲ ਡੈਬਟ ਨੂੰ ਇੱਕ ਬੈਕਲੌਗ ਆਈਟਮ ਸਮਝੋ ਜਿਸਦਾ ਸਪੱਸ਼ਟ ਨਤੀਜਾ ਹੋਵੇ। ਉਸ ਡੈਬਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ:
ਆਈਟਮਾਂ ਨੂੰ ਹਲਕਾ ਟੈਗ ਦਿਓ (ਜਿਵੇਂ tech-debt:reliability) ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ product ਕੰਮ ਦੇ ਨਾਲ ਸ਼ਡਿਊਲ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਦਿੱਖ ਵਿੱਚ ਰਹਿਣ।
ਰੀਫੈਕਟਰ ਛੋਟੇ ਅਤੇ ਵਰਤੋਂ-ਸੁਰੱਖਿਅਤ ਮੋੜਾਂ ਵਿੱਚ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਨੂੰ 1–2 ਵਾਕਾਂ ਵਿੱਚ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਇਸਨੂੰ ਚੋਟੀ-ਚੋਟੀ ਕਦਮਾਂ ਵਿੱਚ ਵੰਡੋ।
ਅਦਾਰਤ ਟੈਸਟਾਂ ਨਾਲ ਸੁਰੱਖਿਆ ਜਾਲ ਬਣਾਓ:
data-test ਸਿਲੈਕਟਰ ਵਰਤੋਂ ਅਤੇ end-to-end ਟੈਸਟਾਂ ਨੂੰ ਕੇਵਲ ਪ੍ਰਮੁੱਖ ਜਰਨੀਆਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋਇਨ੍ਹਾਂ ਨਾਲ ਛੋਟੇ ਰੀਫੈਕਟਰਜ਼ ਵੀ ਮਹਿੰਗੀਆਂ ਘਟਨਾਵਾਂ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦੀਆਂ।
“Product-ਜਿਹੇ” ਖੇਤਰਾਂ ਦੀ ਪਛਾਣ ਕਰੋ (billing, profiles, notifications) ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਬਣਾਓ ਤਾਂ ਜੋ ਨਿਰਭਰਤਾਵਾਂ ਸਪਸ਼ਟ ਹੋ ਜਾਣ। ਜਿਸ ਥਾਂ ਤੇ ਬਹੁਤ ਸਾਰੇ ਹਿੱਸੇ ਸਾਧਾਰਨ internals ਨੂੰ ਪੜ੍ਹਦੇ/ਲਿਖਦੇ ਹਨ, ਉਸ ਦੀ ਥਾਂ ਇੱਕ ਛੋਟੀ API/service ਲੇਅਰ ਰੱਖੋ ਜੋ ਬਾਕੀ ਐਪ ਤੋਂ ਵੱਖਰੀ ਤਰ੍ਹਾਂ ਬਦਲੀ ਜਾ ਸਕਦੀ ਹੈ।
ਕ੍ਰਮਿਕ ਬਦਲਾਵ ਵਰਗੇ ਮਾਡਲ ਵਰਤੋਂ (strangler approach): ਇੱਕ ਨਵਾਂ ਹਿੱਸਾ ਬਣਾਓ (ਇੱਕ ਸਕ੍ਰੀਨ, ਇੱਕ ਐਂڈਪਾਇੰਟ, ਇੱਕ ਪਿਛੋਕੜ ਕੰਮ), ਟ੍ਰੈਫਿਕ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਨਵੀਂ ਪਾਥ ਨੂੰ ਦਿਓ, ਅਤੇ fallback ਰੱਖੋ ਜੋ ਲੈਗਸੀ ਰਸਤਾ ਦੇਵੇ ਜੇ ਨਵਾਂ ਫੇਲ ਕਰੇ۔ ਟ੍ਰੈਫਿਕ ਨਿਹਾਰ ਕੇ ਵਧਾਓ (10% → 50% → 100%), ਫਿਰ legacy ਹਿੱਸੇ ਨੂੰ freeze ਅਤੇ ਹਟਾਓ।
Feature flags ਕੋਡ ਨੂੰ ਬਿਨਾਂ redeploy ਕੀਤੇ on/off ਕਰਨ ਦੇ ਯੰਤਰ ਹਨ। ਇਹ ਤੁਹਾਨੂੰ ਨਵੀਂ ਬਿਹੈਵਿਅਰ ਨੂੰ ਪਹਿਲਾਂ ਚੋਟੀ ਦੇ ਦਰਸ਼ਕਾਂ ਲਈ ਰੋਲਆਉਟ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਗਲਤੀ ਹੋਣ 'ਤੇ ਫਲੈਗ ਬੰਦ ਕਰਕੇ ਤੁਰੰਤ rollback ਦੇ ਸਕਦੇ ਹਨ।
ਫਲੈਗਾਂ ਦੀ ਸਾਫ਼-ਸੁਥਰੀ ਸੰਭਾਲ ਲਈ:
checkout_new_tax_calc)ਪਰ ਫਲੈਗਾਂ ਦੀ ਬੇਹੱਦ ਵਰਤੋਂ ਤੋਂ ਬਚੋ—ਜ਼ਿਆਦਾ ਫਲੈਗਾਂ ਸੰਕਲਪ ਨੂੰ ਪੀਚੀਦਾ ਕਰ ਦੇਂਦੇ ਹਨ।