ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਪ੍ਰਬੰਧਨ

ਲਾਭ:

• ਇੱਕ ਟੈਸਟ ਸੁਰੱਖਿਆ ਜਾਲ ਸਥਾਪਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਜੋ ਰੀਫੈਕਟਰਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ
• AI ਨੂੰ ਛੋਟੇ, ਇੱਕ-ਕਦਮ, ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਵਾਲੇ ਪਰਿਵਰਤਨਾਂ ਲਈ ਪੁੱਛਣ ਅਤੇ ਹਰੇਕ ਕਦਮ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ
• ਵਪਾਰਕ ਸੰਦਰਭ ਵਿੱਚ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦੀ ਪਛਾਣ ਕਰਨ ਅਤੇ ਤਰਜੀਹ ਦੇਣ ਦੀ ਸਮਰੱਥਾ

ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ ਕੋਡ ਦੇ ਬਾਹਰੀ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਉਸ ਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਰਹੀ ਹੈ: ਇਸਨੂੰ ਵਧੇਰੇ ਪੜ੍ਹਨਯੋਗ, ਸਰਲ, ਵਧੇਰੇ ਸਾਂਭਣਯੋਗ ਬਣਾਉਣਾ। ਦੂਜੇ ਪਾਸੇ, ਤਕਨੀਕੀ ਕਰਜ਼ਾ, ਇੱਕ ਤਤਕਾਲ ਹੱਲ ਦੀ ਖ਼ਾਤਰ ਕੀਤਾ ਗਿਆ ਇੱਕ ਡਿਜ਼ਾਇਨ ਸਮਝੌਤਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ "ਵਿਆਜ ਸਮੇਤ" ਵਾਪਸ ਅਦਾ ਕੀਤਾ ਗਿਆ ਹੈ — ਹਰ ਕੋਨਾ ਜੋ ਤੁਸੀਂ ਅੱਜ ਕੱਟਿਆ ਹੈ, ਕੱਲ੍ਹ ਨੂੰ ਇੱਕ ਮੰਦੀ ਜਾਂ ਬੱਗ ਵਜੋਂ ਵਾਪਸ ਆ ਜਾਵੇਗਾ। ਨਕਲੀ ਬੁੱਧੀ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਹਾਇਕ ਹੈ ਜੋ ਦੁਹਰਾਉਣ ਵਾਲੇ ਅਤੇ ਮਕੈਨੀਕਲ ਰੀਫੈਕਟਰਿੰਗ ਕਾਰਜਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ; ਪਰ ਰੀਫੈਕਟਰਿੰਗ ਦਾ ਇੱਕ ਸੁਨਹਿਰੀ ਨਿਯਮ ਹੈ, ਅਤੇ ਇਕੱਲਾ AI ਇਸਦੀ ਗਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦਾ: ਵਿਵਹਾਰ ਨੂੰ ਬਦਲਣਾ ਨਹੀਂ ਚਾਹੀਦਾ।

ਇਸ ਯੂਨਿਟ ਵਿੱਚ, ਅਸੀਂ ਸਿੱਖਦੇ ਹਾਂ ਕਿ AI ਨਾਲ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰਿੰਗ ਕਿਵੇਂ ਕਰਨੀ ਹੈ: ਛੋਟੇ ਅਤੇ ਉਲਟੇ ਜਾਣ ਵਾਲੇ ਕਦਮ, ਟੈਸਟਾਂ ਨਾਲ ਸੁਰੱਖਿਆ ਕਰਨਾ, ਕੋਡ ਦੀ ਬਦਬੂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਅਤੇ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਤਰਜੀਹ ਦੇਣਾ। ਨਾਜ਼ੁਕ ਬਿੰਦੂ ਇਹ ਹੈ: ਇਹ ਪਾਸ ਕਰਨ ਵਾਲੇ ਟੈਸਟ ਹਨ, ਨਾ ਕਿ ਏਆਈ ਦੇ ਸ਼ਬਦ, ਜੋ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਗਿਆ ਹੈ।

ਰੀਫੈਕਟਰਿੰਗ ਦਾ ਸੁਨਹਿਰੀ ਨਿਯਮ: ਵਿਵਹਾਰ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ

ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਖ਼ਤਰਨਾਕ ਬਣਾਉਣ ਵਾਲੀ ਚੀਜ਼ ਅਣਜਾਣੇ ਵਿੱਚ "ਮੈਂ ਸੁਧਾਰ ਰਿਹਾ ਹਾਂ" ਕਹਿਣ ਵੇਲੇ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲਣਾ ਹੈ। ਕਿਸੇ ਸ਼ਰਤ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਵੇਲੇ ਕਿਸੇ ਕਿਨਾਰੇ ਦੇ ਕੇਸ ਨੂੰ ਛੱਡਣਾ, ਲੂਪ ਨੂੰ ਬਦਲਦੇ ਸਮੇਂ ਕ੍ਰਮ ਨੂੰ ਤੋੜਨਾ, ਕਿਸੇ ਫੰਕਸ਼ਨ ਨੂੰ ਵੰਡਣ ਵੇਲੇ ਇੱਕ ਸਾਈਡ ਇਫੈਕਟ ਗੁਆਉਣਾ — ਇਹ ਸਭ "ਸਾਫ਼-ਸੁਥਰਾ" ਪਰ ਟੁੱਟਿਆ ਕੋਡ ਪੈਦਾ ਕਰਦੇ ਹਨ।

ਇਸ ਲਈ ਟੈਸਟਿੰਗ ਰੀਫੈਕਟਰਿੰਗ ਲਈ ਇੱਕ ਪੂਰਵ ਸ਼ਰਤ ਹੈ: ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹੇ ਟੈਸਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ। ਇਹ ਟੈਸਟ ਇੱਕ "ਸੁਰੱਖਿਆ ਜਾਲ" ਹਨ; ਜੇਕਰ ਤੁਸੀਂ ਰੀਫੈਕਟਰਿੰਗ ਦੌਰਾਨ ਗਲਤੀ ਨਾਲ ਕੁਝ ਤੋੜਦੇ ਹੋ, ਤਾਂ ਉਹ ਤੁਹਾਨੂੰ ਤੋੜ ਦੇਣਗੇ ਅਤੇ ਚੇਤਾਵਨੀ ਦੇਣਗੇ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਟੈਸਟ ਨਹੀਂ ਹਨ, ਤਾਂ ਉਹ ਟੈਸਟ ਲਿਖੋ ਜੋ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਯੂਨਿਟ 5 ਵਿੱਚ ਸਿੱਖਿਆ ਹੈ) — ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ AI ਇੱਕ ਛਾਲ ਮਾਰਦਾ ਹੈ।

ਸਾਵਧਾਨ: ਟੈਸਟਨੈੱਟ ਤੋਂ ਬਿਨਾਂ AI-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਰੀਫੈਕਟਰਿੰਗ ਬੱਗ ਦੇ ਸਭ ਤੋਂ ਵੱਧ ਧੋਖੇਬਾਜ਼ ਸਰੋਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। "ਮੈਂ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ" ਕਹਿਣਾ ਆਸਾਨ ਹੈ; ਸਬੂਤ ਇਹ ਹੈ ਕਿ ਉਹੀ ਟੈਸਟ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਾਸ ਹੁੰਦੇ ਹਨ।

ਕਦਮ ਦਰ ਕਦਮ: ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰਿੰਗ ਫਲੋ

1. ਸੁਰੱਖਿਆ ਜਾਲ ਸਥਾਪਤ ਕਰੋ। ਅਜਿਹੇ ਟੈਸਟ ਹੋਣ ਦਿਓ ਜੋ ਕੋਡ ਦੇ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਕਰੋਗੇ; ਜੇ ਨਹੀਂ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਲਿਖੋ (ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਜਾਂਦੇ ਹੋਏ ਦੇਖੋ)।
2. ਗੰਧ ਦਾ ਨਾਮ ਦੱਸੋ। ਤੁਸੀਂ ਕੀ ਸੁਧਾਰ ਰਹੇ ਹੋ ਅਤੇ ਕਿਉਂ? "ਇਹ ਫੰਕਸ਼ਨ 3 ਚੀਜ਼ਾਂ ਕਰਦਾ ਹੈ", "ਉਹੀ ਤਰਕ 4 ਥਾਵਾਂ 'ਤੇ ਦੁਹਰਾਉਂਦਾ ਹੈ", "ਨਾਮ ਗੁੰਮਰਾਹਕੁੰਨ ਹਨ"।
3. ਛੋਟੇ, ਇੱਕ-ਕਦਮ ਦੇ ਕਦਮਾਂ ਲਈ ਪੁੱਛੋ। AI ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਪਰਿਵਰਤਨ ਲਈ ਕਹੋ (ਜਿਵੇਂ ਕਿ "ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਅੱਧ ਵਿੱਚ ਵੰਡੋ"), ਪੂਰੀ ਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਨਹੀਂ।
4. ਟੈਸਟ ਚਲਾਓ. ਹਰ ਕਦਮ ਦੇ ਬਾਅਦ. ਜੇਕਰ ਇਹ ਹਰਾ ਹੈ, ਜਾਰੀ ਰੱਖੋ, ਜੇਕਰ ਇਹ ਲਾਲ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਵਾਪਸ ਲੈ ਜਾਓ।
5. ਡਿਫ ਪੜ੍ਹੋ। ਲਾਈਨ ਦਰ ਲਾਈਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤਬਦੀਲੀ ਅਸਲ ਵਿੱਚ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਵਾਲੀ ਹੈ; ਏਆਈ ਨੂੰ "ਸਿਰਫ਼ ਢਾਂਚਾ" ਕਹਿਣ ਵੇਲੇ ਕੋਈ ਤਰਕ ਫਿਸਲ ਸਕਦਾ ਹੈ।
6. ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਮਿਲਾਓ. ਵੱਡੇ ਵਨ-ਟਾਈਮ ਰੀਫੈਕਟਰਿੰਗ ਪੀਆਰਜ਼ ਜੋਖਮ ਭਰੇ ਅਤੇ ਅਣ-ਸਮੀਖਿਆਯੋਗ ਦੋਵੇਂ ਹੁੰਦੇ ਹਨ।

ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ

ਕੇਸ 1 — 220-ਲਾਈਨ ਫੰਕਸ਼ਨ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵੰਡਿਆ ਗਿਆ। ਇੱਕ ਟੀਮ ਵਿੱਚ 220-ਲਾਈਨ ਆਰਡਰ ਪ੍ਰੋਸੈਸਿੰਗ ਫੰਕਸ਼ਨ ਸੀ। ਪਹਿਲੇ 14 ਟੈਸਟ ਲਿਖੇ ਗਏ ਸਨ (ਏਆਈ ਦੀ ਮਦਦ ਨਾਲ) ਜੋ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਹਾਸਲ ਕਰਦੇ ਸਨ, ਉਹ ਸਾਰੇ ਪਾਸ ਹੋਏ। ਫਿਰ ਫੰਕਸ਼ਨ ਨੂੰ ਏਆਈ ਦੁਆਰਾ ਕਦਮ ਦਰ ਕਦਮ 5 ਛੋਟੇ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ; ਟੈਸਟ ਹਰ ਕਦਮ ਦੇ ਬਾਅਦ ਚਲਾਏ ਗਏ ਸਨ. ਇੱਕ ਪੜਾਅ ਵਿੱਚ ਦੋ ਟੈਸਟ ਟੁੱਟ ਗਏ ਸਨ - AI ਇੱਕ ਕਿਨਾਰੇ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਵਾਪਸੀ ਤੋਂ ਖੁੰਝ ਗਿਆ ਸੀ। ਟੈਸਟਾਂ ਨੇ ਇਸ ਨੂੰ ਤੁਰੰਤ ਫੜ ਲਿਆ ਅਤੇ ਇਸਨੂੰ ਠੀਕ ਕਰ ਦਿੱਤਾ। ਨੈੱਟਵਰਕ ਦੇ ਬਿਨਾਂ, ਤਰੁੱਟੀ ਉਤਪਾਦਨ ਦੇ ਸਾਰੇ ਤਰੀਕੇ ਨਾਲ ਜਾ ਸਕਦੀ ਸੀ।

ਕੇਸ 2 - ਬਿਨਾਂ ਟੈਸਟਨੈੱਟ ਦੇ ਆਫ਼ਤ। ਇੱਕ ਹੋਰ ਡਿਵੈਲਪਰ ਨੇ ਇੱਕ ਤਾਰੀਖ ਗਣਨਾ ਮੋਡੀਊਲ ਨੂੰ "ਸਾਫ਼" ਕੀਤਾ ਜਿਸਦਾ AI ਨਾਲ ਕੋਈ ਟੈਸਟ ਨਹੀਂ ਸੀ। ਕੋਡ ਬਿਹਤਰ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਸੀ, ਪਰ ਇਹ ਲੀਪ ਸਾਲ ਦੀ ਗਲਤ ਗਣਨਾ ਕਰ ਰਿਹਾ ਸੀ; ਇਹ ਬੱਗ ਦੋ ਹਫ਼ਤਿਆਂ ਬਾਅਦ ਗਾਹਕ ਦੀ ਸ਼ਿਕਾਇਤ ਨਾਲ ਸਾਹਮਣੇ ਆਇਆ। ਨੁਕਸਾਨ ਰਿਫੈਕਟਰਿੰਗ ਤੋਂ ਬਚੇ ਸਮੇਂ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਹੈ। ਸਬਕ: ਬਿਨਾਂ ਟੈਸਟ ਕੀਤੇ ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ ਜੂਆ ਹੈ।

ਕੇਸ 3 - ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦੀ ਤਰਜੀਹ। ਇੱਕ ਟੀਮ ਨੇ AI ਨੂੰ 30 ਜਾਂ ਇਸ ਤੋਂ ਵੱਧ "ਸੁਧਾਰਯੋਗ" ਪੁਆਇੰਟਾਂ ਦਾ ਬੈਕਲਾਗ ਦਿੱਤਾ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ "ਬਦਲਣ ਦੀ ਬਾਰੰਬਾਰਤਾ × ਜੋਖਮ × ਕੋਸ਼ਿਸ਼" ਧੁਰੇ 'ਤੇ ਸਕੋਰ ਕੀਤਾ। ਨਤੀਜਾ ਸਾਰਣੀ ਵਿੱਚ, ਇੱਕ ਬਦਸੂਰਤ ਮੋਡੀਊਲ ਜਿਸਨੂੰ ਬਹੁਤ ਘੱਟ ਛੂਹਿਆ ਗਿਆ ਸੀ ਅਸਲ ਵਿੱਚ ਇੱਕ ਘੱਟ ਤਰਜੀਹ ਸੀ, ਜਦੋਂ ਕਿ ਇੱਕ ਮੱਧਮ-ਜਟਿਲਤਾ ਮੋਡੀਊਲ ਜੋ ਅਕਸਰ ਬਦਲਦਾ ਹੈ ਇੱਕ ਉੱਚ ਤਰਜੀਹ ਸੀ। ਟੀਮ ਨੇ ਆਪਣੀ ਊਰਜਾ ਨੂੰ ਸਹੀ ਥਾਂ 'ਤੇ ਪਹੁੰਚਾਇਆ।

ਚਾਰ ਕਾਪੀ ਕਰਨ ਯੋਗ ਨਮੂਨੇ

ਕੋਡ ਗੰਧ ਖੋਜ ਅਤੇ ਤਰਜੀਹ:

ਇਸ ਕੋਡ ਵਿੱਚ ਰੀਫੈਕਟਰਿੰਗ ਉਮੀਦਵਾਰ "ਸੁਗੰਧ" ਦੀ ਸੂਚੀ ਬਣਾਓ: ਲੰਮਾ ਫੰਕਸ਼ਨ, ਦੁਹਰਾਓ (DRYViolation), ਗੁੰਮਰਾਹਕੁੰਨ ਨਾਮ, ਡੂੰਘੀ ਨੇਸਟਡ ਸਥਿਤੀ, ਲੁਕਿਆ ਹੋਇਆ ਮਾੜਾ ਪ੍ਰਭਾਵ, ਮੈਜਿਕ ਨੰਬਰ। ਹਰੇਕ ਲਈ: ਸਥਾਨ, ਸਮੱਸਿਆ ਕਿਉਂ, ਸੁਝਾਅ ਦਿੱਤਾ ਗਿਆ ਛੋਟਾ ਕਦਮ, ਅਨੁਮਾਨਿਤ ਜੋਖਮ (ਘੱਟ/ਮੱਧਮ/ਉੱਚ)। ਅਜੇ ਕੋਡ ਨਾ ਬਦਲੋ, ਬੱਸ ਯੋਜਨਾ ਬਣਾਓ।{{code}}

ਇੱਕ-ਕਦਮ, ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣ ਵਾਲਾ ਪਰਿਵਰਤਨ:

ਬਸ ਇਹ ਕਰੋ: {{ਇੱਕਲਾ ਰੂਪਾਂਤਰ, ਉਦਾਹਰਨ ਲਈ. ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ 3 ਛੋਟੇ ਨਾਮ ਵਾਲੇ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡੋ}}। ਦ੍ਰਿਸ਼ਮਾਨ ਵਿਵਹਾਰ, ਦਸਤਖਤ ਅਤੇ ਵਾਪਸੀ ਮੁੱਲ ਬਦਲੋ। 1 ਵਾਕ ਵਿੱਚ ਲਿਖੋ ਕਿ ਤੁਹਾਡੇ ਦੁਆਰਾ ਬਦਲੀ ਗਈ ਹਰ ਚੀਜ਼ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਿਉਂ ਰੱਖਦੀ ਹੈ।{{code}}

ਰਿਫੈਕਟਰ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਜਾਲ (ਚਰਿੱਤਰ ਜਾਂਚ):

ਟੈਸਟ ਲਿਖੋ ਜੋ ਇਸ ਫੰਕਸ਼ਨ ਦੇ ਮੌਜੂਦਾ ਵਿਹਾਰ ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ (ਸਹੀ ਜਾਂ ਨਹੀਂ); ਟੀਚਾ ਇਹ ਫੜਨਾ ਹੈ ਕਿ ਕੀ ਰਿਫੈਕਟਰਿੰਗ ਦੌਰਾਨ ਵਿਹਾਰ ਬਦਲਦਾ ਹੈ। ਆਮ + ਕਿਨਾਰੇ ਐਂਟਰੀਆਂ ਸ਼ਾਮਲ ਕਰੋ। ਫੰਕਸ਼ਨ ਦੇ ਮੌਜੂਦਾ ਆਉਟਪੁੱਟ ਦੇ ਆਧਾਰ 'ਤੇ ਉਮੀਦਾਂ ਲਿਖੋ।{{function}}

ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਰਿਕਾਰਡ (ਬੈਕਲਾਗ) ਪੀੜ੍ਹੀ:

ਗੰਧ ਦੀ ਹੇਠ ਲਿਖੀ ਸੂਚੀ ਨੂੰ ਤਰਜੀਹੀ ਸਾਰਣੀ ਵਿੱਚ ਪਾਓ: ਪਦਾਰਥ, ਪ੍ਰਭਾਵਿਤ ਖੇਤਰ, ਤਬਦੀਲੀ ਦੀ ਬਾਰੰਬਾਰਤਾ (ਮੇਰੀ ਜਾਣਕਾਰੀ: {{...}}), ਜੋਖਮ, ਅਨੁਮਾਨਿਤ ਕੋਸ਼ਿਸ਼, ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਤਰਜੀਹ। ਉੱਚ ਪ੍ਰਭਾਵ + ਘੱਟ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਸਿਖਰ 'ਤੇ ਰੱਖੋ। {{smell_list}}

ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ

ਕਮਜ਼ੋਰ: "ਇਸ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਬਿਹਤਰ ਬਣਾਓ।"

ਮਜਬੂਤ: "ਇਸ 90-ਲਾਈਨ ਫੰਕਸ਼ਨ ਨੂੰ 3 ਛੋਟੇ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਇੱਕ ਜਿੰਮੇਵਾਰੀ ਨਾਲ ਵੰਡੋ, ਇਸਦੇ ਬਾਹਰੀ ਵਿਵਹਾਰ ਅਤੇ ਦਸਤਖਤ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ। ਮੌਜੂਦਾ ਕ੍ਰਮ ਵਿੱਚ ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ (DB ਲਿਖਦਾ ਹੈ) ਨੂੰ ਰੱਖੋ। ਮੇਰੇ ਕੋਲ ਟੈਸਟ ਹਨ, ਵਿਵਹਾਰ ਇੱਕੋ ਜਿਹਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਅੰਤਰ ਦਿਓ ਅਤੇ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰੋ ਕਿ ਹਰੇਕ ਸਪਲਿਟ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਿਉਂ ਹੈ। [ਕੋਡ]"

ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੰਸਕਰਣ; ਇਸ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪਰਿਵਰਤਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇੱਕ ਵਿਵਹਾਰ ਅਤੇ ਦਸਤਖਤ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਾਇਜ਼ਤਾ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। "ਬਿਹਤਰ ਕਰੋ" ਵਰਗੀਆਂ ਅਸਪਸ਼ਟ ਬੇਨਤੀਆਂ ਬੇਕਾਬੂ ਅਤੇ ਜੋਖਮ ਭਰੀਆਂ ਤਬਦੀਲੀਆਂ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ।

ਰੀਫੈਕਟਰਿੰਗ ਕਿਸਮ

AI ਭਰੋਸੇਯੋਗਤਾ

ਪੂਰਵ ਸ਼ਰਤ

ਨਾਮ ਬਦਲੋ

ਉੱਚ

ਕੀ ਦਾਇਰਾ ਸਹੀ ਹੈ?

ਫੰਕਸ਼ਨ ਡਿਵੀਜ਼ਨ

ਮੱਧਮ-ਉੱਚਾ

ਟੈਸਟਨੈੱਟ ਲਾਜ਼ਮੀ ਹੈ

ਦੁਹਰਾਓ ਸਾਂਝਾ ਕਰਨਾ

ਮੱਧਮ

ਵਿਵਹਾਰ ਦਾ ਅੰਤਰ ਲੁਕਿਆ ਹੋ ਸਕਦਾ ਹੈ

ਐਲਗੋਰਿਦਮ/ਸੰਰਚਨਾ ਤਬਦੀਲੀ

ਘੱਟ

ਵਿਆਪਕ ਜਾਂਚ + ਮਨੁੱਖੀ ਪ੍ਰਮਾਣਿਕਤਾ

ਆਰਕੀਟੈਕਚਰਲ ਪੁਨਰਗਠਨ

ਘੱਟ

ਮਨੁੱਖੀ-ਅਗਵਾਈ, AI-ਸਮਰਥਿਤ

ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ, ਇਸਨੂੰ ਰੀਸੈਟ ਨਹੀਂ ਕਰਨਾ

ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਸਭ ਬੁਰਾ ਨਹੀਂ ਹੈ; ਕਈ ਵਾਰ ਸੁਚੇਤ ਤੌਰ 'ਤੇ ਉਧਾਰ ਲੈਣਾ (ਡਿਲਿਵਰੀ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ) ਸਹੀ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ। ਟੀਚਾ ਕਰਜ਼ੇ ਨੂੰ ਖਤਮ ਕਰਨਾ ਨਹੀਂ ਹੈ, ਪਰ ਇਸਨੂੰ ਦ੍ਰਿਸ਼ਮਾਨ ਅਤੇ ਪ੍ਰਬੰਧਨਯੋਗ ਬਣਾਉਣਾ ਹੈ। AI ਕਰਜ਼ੇ ਦਾ ਪਤਾ ਲਗਾਉਣ ਅਤੇ ਤਰਜੀਹ ਦੇਣ ਵਿੱਚ ਤੇਜ਼ ਹੈ, ਪਰ "ਕਿਹੜੇ ਕਰਜ਼ੇ ਦਾ ਭੁਗਤਾਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਸ ਨੂੰ ਛੱਡ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ" ਦਾ ਫੈਸਲਾ ਕਰਨ ਲਈ ਵਪਾਰਕ ਸੰਦਰਭ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਇਹ ਮੋਡੀਊਲ ਕਿੰਨੀ ਵਾਰ ਬਦਲਦਾ ਹੈ, ਕਿੰਨੇ ਲੋਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਜੋਖਮ ਕੀ ਹੈ? ਇਹ ਫੈਸਲਾ ਉਸ ਟੀਮ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਕੋਡ ਬੇਸ ਅਤੇ ਉਤਪਾਦ ਨੂੰ ਜਾਣਦੀ ਹੈ; AI ਸਿਰਫ਼ ਵਿਕਲਪਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ।

ਸੁਝਾਅ: ਆਪਣੇ ਰੀਫੈਕਟਰਿੰਗ PR ਨੂੰ PR ਤੋਂ ਵੱਖ ਰੱਖੋ ਜਿਸ ਵਿੱਚ ਵਿਵਹਾਰ ਵਿੱਚ ਤਬਦੀਲੀ ਸ਼ਾਮਲ ਹੈ। ਇਹ ਕਹਿਣ ਦੇ ਯੋਗ ਹੋਣਾ "ਇਹ PR ਕੇਵਲ ਇੱਕ ਰੀਫੈਕਟਰਿੰਗ ਹੈ, ਵਿਵਹਾਰ ਉਹੀ ਹੈ" ਜਾਂਚ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਜੇਕਰ ਕੋਈ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਕਾਰਨ ਨੂੰ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ

• ਬਿਨਾਂ ਟੈਸਟਨੈੱਟ ਦੇ ਰੀਫੈਕਟਰਿੰਗ। ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਸਾਬਤ ਕਰਨ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਬਚਿਆ ਹੈ ਕਿ ਵਿਵਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਗਿਆ ਹੈ.
• ਇਸਦਾ ਅਰਥ ਹੈ "ਪੂਰੀ ਫਾਈਲ ਸਾਫ਼ ਕਰੋ"। ਵੱਡੀਆਂ, ਬੇਕਾਬੂ ਤਬਦੀਲੀਆਂ ਗਲਤੀ ਨੂੰ ਲੁਕਾਉਂਦੀਆਂ ਹਨ ਅਤੇ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ।
• ਇਸ ਨੂੰ ਪੜ੍ਹੇ ਬਿਨਾਂ ਅੰਤਰ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ। ਜਦੋਂ ਏਆਈ ਨੇ "ਸਿਰਫ਼ ਬਣਤਰ" ਕਿਹਾ ਤਾਂ ਕੁਝ ਤਰਕ ਫਿਸਲ ਗਿਆ ਹੋ ਸਕਦਾ ਹੈ।
• ਵਿਹਾਰਕ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਉਲਝਣ ਵਾਲੀ ਰੀਫੈਕਟਰਿੰਗ। ਇੱਕੋ PR ਵਿੱਚ ਦੋਨਾਂ ਨੂੰ ਕਰਨ ਨਾਲ ਮੂਲ ਕਾਰਨ ਟਰੈਕਿੰਗ ਅਸੰਭਵ ਹੋ ਜਾਂਦੀ ਹੈ।
• ਹਰ ਗੰਧ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਬਦਸੂਰਤ ਕੋਡ ਜੋ ਘੱਟ ਹੀ ਬਦਲਦਾ ਹੈ ਅਕਸਰ ਘੱਟ ਤਰਜੀਹ ਹੁੰਦੀ ਹੈ; ਉਸ ਜਗ੍ਹਾ ਨੂੰ ਊਰਜਾ ਦਿਓ ਜੋ ਅਕਸਰ ਬਦਲਦਾ ਹੈ।

ਸੰਖੇਪ ਵਿੱਚ

ਰੀਫੈਕਟਰਿੰਗ ਦਾ ਇੱਕੋ ਇੱਕ ਨਿਯਮ ਇਹ ਹੈ ਕਿ ਵਿਵਹਾਰ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਸਬੂਤ ਟੈਸਟ ਹਨ। AI ਕੋਡ ਦੀ ਗੰਧ ਦਾ ਪਤਾ ਲਗਾਉਣ, ਇੱਕ-ਕਦਮ ਵਿੱਚ ਤਬਦੀਲੀਆਂ, ਅਤੇ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਵਿੱਚ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ; ਪਰ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਆ ਜਾਲ ਸਥਾਪਤ ਕਰਨਾ ਪਏਗਾ, ਟੈਸਟ ਚਲਾਉਣੇ ਪੈਣਗੇ ਅਤੇ ਹਰੇਕ ਕਦਮ ਦੇ ਬਾਅਦ ਅੰਤਰ ਨੂੰ ਪੜ੍ਹਨਾ ਹੋਵੇਗਾ। ਛੋਟੇ, ਉਲਟ ਕਦਮ ਚੁੱਕੋ; ਰਿਫੈਕਟਰਿੰਗ ਨੂੰ ਵਿਹਾਰ ਤਬਦੀਲੀ ਤੋਂ ਵੱਖ ਕਰਨਾ; ਅਤੇ ਕਾਰੋਬਾਰੀ ਸੰਦਰਭ ਜਾਣਦੀ ਟੀਮ ਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦਿਓ ਕਿ ਕਿਹੜਾ ਕਰਜ਼ਾ ਅਦਾ ਕਰਨਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ

ਆਪਣੇ ਕੋਡ ਅਧਾਰ ਤੋਂ ਇੱਕ ਫੰਕਸ਼ਨ ਚੁਣੋ ਜੋ ਤੁਹਾਨੂੰ ਲੰਬਾ ਜਾਂ ਗੁੰਝਲਦਾਰ ਲੱਗਦਾ ਹੈ। ਪਹਿਲੇ ਪ੍ਰਿੰਟ ਟੈਸਟ ਜੋ "ਸੁਰੱਖਿਆ ਨੈੱਟ" ਟੈਂਪਲੇਟ ਨਾਲ ਇਸਦੇ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਕੈਪਚਰ ਕਰਦੇ ਹਨ ਅਤੇ ਦੇਖਦੇ ਹਨ ਕਿ ਕੀ ਉਹ ਸਾਰੇ ਪਾਸ ਹੁੰਦੇ ਹਨ। ਫਿਰ ਫੰਕਸ਼ਨ ਨੂੰ "ਇੱਕ-ਕਦਮ, ਵਿਵਹਾਰ-ਰੱਖਿਅਤ ਪਰਿਵਰਤਨ" ਪੈਟਰਨ ਨਾਲ ਇੱਕ ਸਿੰਗਲ ਤਰੀਕੇ ਨਾਲ ਰੀਫੈਕਟਰ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਅੱਧੇ ਵਿੱਚ ਵੰਡਣਾ) ਅਤੇ ਟੈਸਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓ। ਜੇ ਕੋਈ ਟੈਸਟ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪਤਾ ਕਰੋ ਕਿ ਕਿਉਂ; ਜੇਕਰ ਇਹ ਬਿਲਕੁਲ ਵੀ ਨਹੀਂ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਕਿ ਵਿਵਹਾਰ ਨੂੰ ਅਸਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਗਿਆ ਹੈ, ਲਾਈਨ ਦੁਆਰਾ ਡਿਫ ਲਾਈਨ ਨੂੰ ਪੜ੍ਹੋ।

ਚੈੱਕਲਿਸਟ

• [ ] ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਰੀਫੈਕਟਰਿੰਗ ਵਿਹਾਰ ਨੂੰ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰਨ ਲਈ ਟੈਸਟ ਹਨ।
• [ ] ਮੈਂ ਇੱਕ ਸੁਰੱਖਿਆ ਜਾਲ ਸਥਾਪਤ ਕਰ ਰਿਹਾ ਹਾਂ ਜੋ ਰਿਫੈਕਟਰ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਵਿਵਹਾਰ ਨੂੰ ਫੜਦਾ ਹੈ।
• [ ] ਮੈਂ AI ਤੋਂ ਛੋਟੀਆਂ, ਇੱਕ-ਕਦਮ ਦੀਆਂ ਤਬਦੀਲੀਆਂ ਚਾਹੁੰਦਾ ਹਾਂ, ਨਾ ਕਿ ਵੱਡੇ-ਵੱਡੇ।
• ਹਰ ਕਦਮ ਦੇ ਬਾਅਦ ਮੈਂ ਟੈਸਟ ਚਲਾਉਂਦਾ ਹਾਂ ਅਤੇ ਅੰਤਰ ਪੜ੍ਹਦਾ ਹਾਂ।
• [ ] ਮੈਂ ਰਿਫੈਕਟਰਿੰਗ PR ਨੂੰ ਵਿਵਹਾਰ ਤਬਦੀਲੀ PR ਤੋਂ ਵੱਖ ਰੱਖਦਾ ਹਾਂ।
• [ ] ਮੈਂ ਵਪਾਰਕ ਸੰਦਰਭ ਦੇ ਨਾਲ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹਾਂ, ਅੰਨ੍ਹੇਵਾਹ ਜ਼ੀਰੋ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ।