15 ਸਤੰ 2025·8 ਮਿੰਟ
ਕਿਉਂ AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡਬੇਸ ਮੁੜਲਿਖਣਾ ਆਸਾਨ ਹੋ ਸਕਦਾ ਹੈ
AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਅਕਸਰ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪੈਟਰਨ ਫੋਲੋ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਰੀਰਾਈਟ ਅਤੇ ਬਦਲਾਅ ਹੁਣੇ-ਹੁਣੇ ਤੇਜ਼ ਅਤੇ ਆਸਾਨ ਹੋ ਸਕਦੇ ਹਨ। ਜਾਣੋ ਕਿਉਂ ਅਤੇ ਕਿਵੇਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ।
AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਅਕਸਰ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪੈਟਰਨ ਫੋਲੋ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਰੀਰਾਈਟ ਅਤੇ ਬਦਲਾਅ ਹੁਣੇ-ਹੁਣੇ ਤੇਜ਼ ਅਤੇ ਆਸਾਨ ਹੋ ਸਕਦੇ ਹਨ। ਜਾਣੋ ਕਿਉਂ ਅਤੇ ਕਿਵੇਂ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ।
“ਸੌਖਾ ਬਦਲਣਾ” ਅਕਸਰ ਪੂਰੇ ਐਪ ਨੂੰ ਮਿਟਾ ਕੇ ਨਵਾਂ ਬਣਾਉਣ ਨਹੀਂ ਹੁੰਦਾ। ਅਸਲ ਟੀਮਾਂ ਵਿੱਚ ਰੀਪਲੇਸਮੈਂਟ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ ਤੇ ਹੁੰਦਾ ਹੈ, ਅਤੇ “ਰੀਰਾਈਟ” ਦਾ ਅਰਥ ਇਸ ਗੱਲ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਬਦਲ ਰਹੇ ਹੋ।
ਇੱਕ ਰੀਪਲੇਸਮੈਂਟ ਹੋ ਸਕਦਾ ਹੈ:
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਕੋਡਬੇਸ “ਰੀਰਾਈਟ ਕਰਨ ਲਈ ਆਸਾਨ” ਹੈ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਲੈਂਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸਲਾਈਸ ਨੂੰ ਬਿਨਾਂ ਬਾਕੀ ਸਭ ਕੁਝ ਖ਼ਰਾਬ ਕੀਤੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ, ਕਾਰੋਬਾਰ ਚਲਦਾ ਰਹੇਗਾ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸੁਸਤ ਤਰੀਕੇ ਨਾਲ ਹੋਵੇਗੀ।
ਇਹ ਦਲੀਲ “AI ਕੋਡ ਵਧੀਆ ਹੈ” ਨਹੀਂ ਹੈ। ਇਹ ਆਮ ਰੁਝਾਨਾਂ ਬਾਰੇ ਹੈ।
ਰੀਰਾਈਟ ਦੌਰਾਨ ਇਹ ਫਰਕ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ: ਜੇ ਕੋਡ ਵਿਸ਼ਵ-ਪੱਧਰੀ ਤੌਰ 'ਤੇ ਸਮਝ ਆਉਣ ਵਾਲੀਆਂ ਰਵਾਇਤਾਂ ਨੂੰ ਫੋਲੋ ਕਰਦਾ ਹੈ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉਸਨੂੰ ਕਿਸੇ ਹੋਰ ਸਧਾਰਨ ਇੰਪਲੀਮੇੰਟੇਸ਼ਨ ਨਾਲ ਘੱਟ ਗਤੀਵਿਧੀ ਅਤੇ ਘੱਟ ਹੈਰਾਨੀਆਂ ਨਾਲ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।
AI-ਜਨਰੇਟ ਕੋਡ ਇਕਸਾਰ ਨਾ ਹੋ ਸਕਦਾ, ਦੁਹਰਾਅ ਵਾਲਾ ਹੋ ਸਕਦਾ ਜਾਂ ਥੋੜਾ ਘੱਟ-ਟੈਸਟ ਕੀਤਾ ਹੋ ਸਕਦਾ ਹੈ। “ਸੌਖਾ ਬਦਲਣਾ” ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕਿ ਇਹ ਸਾਫ਼ ਹੈ—ਇਹ ਦਾਅਵਾ ਹੈ ਕਿ ਇਹ ਅਕਸਰ ਘੱਟ “ਖਾਸ” ਹੁੰਦਾ ਹੈ। ਜੇ ਇਕ ਉਪ-ਸਿਸਟਮ ਆਮ ਸਮੱਗਰੀ ਤੋਂ ਬਣਿਆ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬਦਲਨਾ ਇੱਕ ਸਟੈਂਡਰਡ ਪਾਰਟ ਨੂੰ ਬਦਲਣ ਵਰਗਾ ਹੋ ਸਕਦਾ ਹੈ, ਨ ਕਿ ਕਿਸੇ ਕਸਟਮ ਮਸ਼ੀਨ ਦੀ ਰਿਵਰਸ ਇੰਜੀਨੀਅਰਿੰਗ ਬਣਨ ਜਿਹਾ।
ਮੁੱਖ ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਮਿਆਰੀ ਬਣਤਰ ਸਵਿੱਚਿੰਗ ਲਾਗਤ ਘਟਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਕੋਡ ਪਹਚਾਣਯੋਗ ਪੈਟਰਨਾਂ ਅਤੇ ਸਪੱਸ਼ਟ ਸੀਮਾਂ ਨਾਲ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਤਦ ਤੁਸੀਂ ਹਿੱਸਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਜਨਰੇਟ, ਰਿਫੈਕਟਰ ਜਾਂ ਮੁੜਲਿਖ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਛੁਪੇ ਨਿਰਭਰਤਾ ਨੂੰ ਤੋੜਨ ਦਾ ਡਰ ਕੀਤੇ। ਹੇਠਾਂ ਖੰਡ, ਮਾਲਕੀਅਤ, ਟੈਸਟਿੰਗ ਅਤੇ ਰੋਜ਼ਾਨਾ ਇੰਜਨੀਅਰਿੰਗ ਗਤੀ ਵਿੱਚ ਇਹ ਕਿਵੇਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਦਿਖਾਇਆ ਗਿਆ ਹੈ।
AI-ਜਨਰੇਟ ਕੋਡ ਦਾ ਇੱਕ ਵਿਹਾਰਕ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਇਹ ਅਕਸਰ ਆਮ, ਪਹਚਾਣਯੋਗ ਪੈਟਰਨਾਂ 'ਤੇ ਡਿਫੌਲਟ ਕਰਦਾ ਹੈ: ਜਾਣੂ ਫੋਲਡਰ ਲੇਆਉਟ, ਅਨੁਮਾਨਕ ਨੇਮਿੰਗ, ਮੁੱਖ ਫ੍ਰੇਮਵਰ্ক ਕਨਵੈਂਸ਼ਨਾਂ, ਅਤੇ ਰੂਟਿੰਗ, ਵੈਲਿਡੇਸ਼ਨ, ਐਰਰ ਹੈਂਡਲਿੰਗ ਅਤੇ ਡੇਟਾ ਐਕਸੇਸ ਦੇ “ਟੈਕਸਟਬੁੱਕ” ਤਰੀਕੇ। ਭਾਵੇਂ ਕੋਡ ਪੂਰਨ ਨਹੀਂ ਹੋਵੇ, ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਟਿਊਟੋਰਿਯਲਾਂ ਅਤੇ ਸਟਾਰਟਰ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹਨਯੋਗ ਹੁੰਦਾ ਹੈ।
ਰੀਰਾਈਟ ਮਹਿੰਗੇ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਰੋਂੜੇ ਸਮਝਣ ਲਈ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਕਾਰਜ-ਪ੍ਰਣਾਲੀ ਨੂੰ ਸਮਝਣਾ ਪੈਂਦਾ ਹੈ। ਜੇ ਕੋਡ ਜਾਣੇ-ਪਛਾਣੇ ਨਿਯਮਾਂ ਨੂੰ ਫੋਲੋ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ “ਡਿਕੋਡਿੰਗ” ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ। ਨਵੇਂ ਇੰਜਨੀਅਰ ਜੋਖਮ ਕਮਾਈਆਂ ਭਾਵਨਾਵਾਂ ਨਾਲ ਜੋੜ ਕੇ ਜੋ ਮਾਡਲ ਉਹਨਾਂ ਨੇ ਸਿੱਖਿਆ ਹੈ: ਕਿੱਥੇ ਕਾਨਫਿਗ ਰਹਿੰਦਾ ਹੈ, ਕਿਵੇਂ ਰਿਕਵੇਸਟ ਫਲੋ ਕਰਦਾ ਹੈ, ਨਿਰਭਰਤਾਵਾਂ ਕਿਵੇਂ ਵਾਇਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਅਤੇ ਟੈਸਟ ਕਿੱਥੇ ਹੋਣ ਚਾਹੀਦੇ ਹਨ।
ਇਸ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ:
ਦੂਜੇ ਪਾਸੇ, ਬਹੁਤ ਹੀ ਹੱਥ-ਬਣਾਇਆ ਕੋਡਬੇਸ ਅਕਸਰ ਡੂੰਘੀ ਨਿੱਜੀ ਸ਼ੈਲੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: ਵਿਲੱਖਣ ਅਬਸਟ੍ਰੈਕਸ਼ਨ, ਕਸਟਮ ਮਿਨੀ-ਫ੍ਰੇਮਵਰਕ, ਚਤੁਰ “ਗਲੂ” ਕੋਡ ਜਾਂ ਡੋਮੇਨ-ਖ਼ਾਸ ਪੈਟਰਨ ਜੋ ਸਿਰਫ਼ ਇਤਿਹਾਸਕ ਸੰਦਰਭ ਨਾਲ ਹੀ ਸਮਝ ਆਉਂਦੇ ਹਨ। ਇਹ ਚੋਣਾਂ ਸੁੰਦਰ ਹੋ ਸਕਦੀਆਂ ਹਨ—ਪਰ ਉਹ ਮੁੜ ਲਿਖਣ ਦੀ ਲਾਗਤ ਵਧਾ ਦਿੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਰੀਰਾਈਟ ਨੂੰ ਪਹਿਲਾਂ ਲੇਖਕ ਦੀ ਸੋਚ ਨੂੰ ਫਿਰ ਤੋਂ ਸਿੱਖਣਾ ਪੈਂਦਾ ਹੈ।
ਇਹ ਕੋਈ ਜਾਦੂ ਨਹੀਂ ਜੋ صرف AI ਲਈ ਖਾਸ ਹੋਵੇ। ਟੀਮਾਂ (ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ) ਟੈਂਪਲੇਟ, ਲਿੰਟਰ, ਫਾਰਮੇਟਰ ਅਤੇ ਸਕੈਫੋਲਡਿੰਗ ਟੂਲ ਵਰਤ ਕੇ ਸਟਰੱਕਚਰ ਅਤੇ ਸਟਾਈਲ ਲਾਗੂ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਫਰਕ ਇਹ ਹੈ ਕਿ AI ਅਕਸਰ “ਜਨਰਿਕ ਡਿਫੌਲਟ” ਤਿਆਰ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਮਨੁੱਖ-ਲਿਖੇ ਸਿਸਟਮ ਸਮੇਂ ਨਾਲ bespoke ਰੂਹ ਵੱਲ ਜਾ ਸਕਦੇ ਹਨ ਜੇ ਤੱਕ ਸੰਦਰਭਕ ਨਿਯਮ ਬਰਕਰਾਰ ਨਾ ਰੱਖੇ ਜਾਣ।
ਬਹੁਤ ਸਾਰਾ ਰੀਰਾਈਟ ਦਰਦ “ਮੁੱਖ” ਬਿਜ਼ਨੱਸ ਲੋਜਿਕ ਕਰਕੇ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ bespoke glue ਦੇ ਕਾਰਨ ਹੁੰਦਾ ਹੈ—ਕਸਟਮ ਹੇਲਪਰ, ਘਰੇਲੂ ਮਾਈਕ੍ਰੋ-ਫ੍ਰੇਮਵਰਕ, ਮੈਟਾਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਚਾਲਾਂ, ਅਤੇ ਇਕ-ਵਾਰ ਦੀਆਂ ਰੀਤਾਂ ਜੋ ਚੁਪਚਾਪ ਹਰ ਚੀਜ਼ ਨੂੰ ਜੁੜਦੀਆਂ ਹਨ।
ਗਲੂ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ, ਫਿਰ ਵੀ ਤੁਾਡਾ ਪ੍ਰੋਡਕਟ ਉਸਦੇ ਬਿਨਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਉਦਾਹਰਣਾਂ: ਇਕ ਕਸਟਮ ਡਿਪੈਂਡੈਂਸੀ ਇੰਜੈਕਸ਼ਨ ਕੰਟੇਨਰ, DIY ਰੂਟਿੰਗ ਲੇਅਰ, ਇੱਕ ਜਾਦੂਈ ਬੇਸ ਕਲਾਸ ਜੋ ਮੋਡਲਾਂ ਨੂੰ ਆਟੋ-ਰਜਿਸਟਰ ਕਰਦੀ ਹੈ, ਜਾਂ ਐਸੇ ਹੇਲਪਰ ਜੋ ਸੁਵਿਧਾ ਲਈ ਗਲੋਬਲ ਸਟੇਟ ਨੂੰ ਮਿਉਟੇਟ ਕਰਦੇ ਹਨ। ਇਹ ਆਮ ਤੌਰ ਤੇ ਇੱਕ ਸਮਾਂ-ਬਚਤ ਸ਼ੁਰੂਆਤ ਹੁੰਦੀ ਹੈ ਜੋ ਅੰਤ ਵਿੱਚ ਹਰ ਬਦਲਾਅ ਲਈ ਲਾਜ਼ਮੀ ਗਿਆਨ ਬਣ ਜਾਂਦੀ ਹੈ।
ਸਮੱਸਿਆ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਗਲੂ ਮੌਜੂਦ ਹੈ—ਪਰ ਇਹ ਅਦਿੱਖਾ coupling ਬਣ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਗਲੂ ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਵਿਲੱਖਣ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ:
ਰੀਰਾਈਟ ਦੌਰਾਨ ਇਹ ਗਲੂ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਦੁਹਰਾਉਣਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਨਿਯਮ ਆਮ ਤੌਰ 'ਤੇ ਲਿਖੇ ਨਹੀਂ ਜਾਂਦੇ। ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਤੋੜ ਕੇ ਹੀ ਖੋਜਦੇ ਹੋ।
AI ਆਉਟਪੁੱਟ ਅਕਸਰ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਆਮ ਪੈਟਰਨ ਅਤੇ ਸਪੱਸ਼ਟ ਵਾਇਰਿੰਗ ਵਲ ਝੁਕਦਾ ਹੈ। ਇਹ ਸ਼ਾਇਦ ਇਕ ਮਾਈਕ੍ਰੋ-ਫ੍ਰੇਮਵਰਕ ਨਹੀਂ ਬਣਾਂਦਾ ਜਦੋਂ ਇੱਕ ਸਿੱਧੀ ਮੋਡੀਊਲ ਜਾਂ ਸਰਵਿਸ ਆਬਜੈਕਟ ਕਾਫ਼ੀ ਹੋਵੇਗਾ। ਇਹ ਰਿਹਾਇਤ ਇੱਕ ਫੀਚਰ ਹੋ ਸਕਦੀ ਹੈ: ਘੱਟ ਜਾਦੂਈ ਹੂਕ ਦਾ ਮਤਲਬ ਘੱਟ ਛੁਪੇ ਨਿਰਭਰਤਾ, ਅਤੇ ਇਸ ਨਾਲ ਇੱਕ ਉਪ-ਸਿਸਟਮ ਨੂੰ ਅੱਗੇ ਖਿੱਚ ਕੇ ਬਦਲਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ “ਸਧਾਰਨ” ਕੋਡ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਹੋਰ ਲੰਬਾ ਹੋਵੇ—ਜ਼ਿਆਦਾ ਪੈਰਾਮੀਟਰ, ਸਿੱਧੀ ਪਲੰਬਿੰਗ, ਘੱਟ ਛੋਟ-ਕੱਟ। ਪਰ ਲੰਬਾਈ ਆਮ ਤੌਰ 'ਤੇ ਰਹੱਸ ਨਾਲੋਂ ਸਸਤੀ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਮੁੜਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਉਹ ਕੋਡ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਮਝਣਾ ਆਸਾਨ ਹੋਵੇ, ਮਿਟਾਉਣਾ ਆਸਾਨ ਹੋਵੇ, ਅਤੇ ਗਲਤ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇ।
“ਪੇਸ਼ਗੋਈਯੋਗ ਢਾਂਚਾ” ਸੁੰਦਰਤਾ ਦੀ ਗੱਲ ਨਹੀਂ, ਸਗੋਂ ਇੱਕਸਾਰਤਾ ਦੀ ਗੱਲ ਹੈ: ਇੱਕੋ ਜਿਹੇ ਫੋਲਡਰ, ਨੇਮਿੰਗ ਨਿਯਮ, ਅਤੇ ਰਿਕਵੇਸਟ ਫਲੋ ਹਰ ਜਗ੍ਹਾ ਦਿਖਾਈ ਦੇ ਰਹੇ ਹਨ। AI-ਜਨਰੇਟ ਪ੍ਰੋਜੈਕਟ ਅਕਸਰ parichit defaults ਵੱਲ ਝੁਕਦੇ ਹਨ—controllers/, services/, repositories/, models/—ਸਾਥ ਹੀ ਦੁਹਰਾਏ ਗਏ CRUD ਐਂਡਪਾਇੰਟ ਅਤੇ ਸਮਾਨ ਵੈਲਿਡੇਸ਼ਨ ਪੈਟਰਨ।
ਉਹ ਇਕਸਾਰਤਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਰੀਰਾਈਟ ਨੂੰ ਇੱਕ ਚੀਜ਼ ਤੋਂ ਕੂਦਣ ਵਾਲੀ ਚੀਜ਼ ਦੀ ਥਾਂ ਸੀੜ੍ਹੀ ਬਣਾਉਂਦੀ ਹੈ।
ਤੁਸੀਂ ਹਰ ਫੀਚਰ 'ਤੇ ਪੈਟਰਨ ਦਿਖਦੇ ਹੋ:
UserService, UserRepository, UserController)ਜਦੋਂ ਹਰ ਫੀਚਰ ਇਕੋ ਹੀ ਢੰਗ ਨਾਲ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਹਿੱਸਾ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਵਾਰੀ ਸਿਸਟਮ ਨੂੰ ਦੁਬਾਰਾ ਸਿੱਖਣ ਤੋਂ।
ਇੰਕ੍ਰਿਮੈਂਟਲ ਰੀਰਾਈਟ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ boundary ਨੂੰ ਅਲੱਗ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉਸ ਦੇ ਪਿੱਛੇ ਦੁਬਾਰਾ ਬਣਾਉ। ਪੇਸ਼ਗੋਈਯੋਗ ਢਾਂਚੇ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਉਹ ਸੀਮਾਵਾਂ ਬਣਾਉਂਦੇ ਹਨ: ਹਰ ਲੇਅਰ ਦਾ ਕੰਮ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਕਾਲ ਇੱਕ ਛੋਟੀ interface ਸੈਟ ਰਾਹੀਂ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਕਾਰਜਕਾਰੀ ਤਰੀਕਾ “strangler” ਅੰਦਾਜ਼ ਹੈ: ਪਰਚਾਰਕ API ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਅੰਦਰੂਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਧੀਰੇ-ਧੀਰੇ ਬਦਲੋ।
ਮਾਨ ਲਓ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ controller → service → repository ਦਾ ਫਲੋ ਹੈ:
OrdersController → OrdersService → OrdersRepositoryਤੁਸੀਂ ਸਿੱਧੇ SQL ਤੋਂ ORM ਵੱਲ ਜਾਂ ਇੱਕ ਡੇਟਾਬੇਸ ਤੋਂ ਦੂਜੇ ਨੂੰ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਇੱਕ ਪੇਸ਼ਗੋਈਯੋਗ ਕੋਡਬੇਸ ਵਿੱਚ ਇਹ ਤਬਦੀਲੀ ਸੀਮਿਤ ਰਹਿ ਸਕਦੀ ਹੈ:
OrdersRepositoryV2 ਬਣਾਓ (ਨਵਾਂ ਇੰਪਲਿਮੇਂਟੇਸ਼ਨ)getOrder(id), listOrders(filters))Controller ਅਤੇ service ਕੋਡ ਜ਼ਿਆਦਾਤਰ ਅਣਛੁਏ ਰਹਿੰਦੇ ਹਨ।
ਬਹੁਤ ਹੱਥ-ਬਣਾਏ ਗਏ ਸਿਸਟਮ ਸ਼ਾਨਦਾਰ ਹੋ ਸਕਦੇ ਹਨ—ਪਰ ਉਹ ਅਕਸਰ ਵਿਲੱਖਣ ਵਿਚਾਰਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਐਂਕੋਡ ਕਰਦੇ ਹਨ: ਕਸਟਮ ਅਬਸਟ੍ਰੈਕਸ਼ਨ, ਮੈਟਾਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਜਾਂ ਬੇਸ ਕਲਾਸਾਂ ਵਿੱਚ ਛੁਪਾ ਕ੍ਰਾਸ-ਕਟਿੰਗ ਵਿਹਾਰ। ਇਹ ਹਰ ਬਦਲਾਅ ਲਈ ਡੂੰਘਾ ਇਤਿਹਾਸਕ ਸੰਦਰਭ ਮੰਗ ਸਕਦੇ ਹਨ। ਪੇਸ਼ਗੋਈਯੋਗ ਢਾਂਚੇ ਨਾਲ, “ਮੈਂ ਇਹ ਇਥੇ ਕਿੱਥੇ ਬਦਲਾਂ?” ਦਾ ਸਵਾਲ ਆਮ ਤੌਰ 'ਤੇ ਸਿੱਧਾ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਹਫਤੇ-ਦਰ-ਹਫਤੇ ਛੋਟੇ ਰੀਰਾਈਟ ਸੰਭਵ ਹਨ।
ਅਕਸਰ ਰੀਰਾਈਟ ਵਿੱਚ ਇੱਕ ਚੁਪਚਾਪ ਰੋਕ ਨਾਂ ਕਿ ਤਕਨੀਕੀ—ਪਰ ਸੋਸ਼ਲ ਹੁੰਦੀ ਹੈ। ਟੀਮਾਂ अक्सर ਮਾਲਕੀਅਤ ਦਾ ਜੋਖਮ ਲੈਂਦੀਆਂ ਹਨ, ਜਿਥੇ ਸਿਰਫ਼ ਇੱਕ ਵਿਅਕਤੀ ਜਾਣਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਉਸ ਵਿਅਕਤੀ ਨੇ ਵੱਡੇ ਹਿੱਸਿਆਂ ਨੂੰ ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕੋਡ ਇੱਕ ਨਿੱਜੀ ਕਲਾ ਜਿਹਾ ਮਹਿਸੂਸ ਹੋ ਜਾਂਦਾ ਹੈ: “ਮੇਰਾ ਡਿਜ਼ਾਇਨ,” “ਮੇਰਾ ਚਤੁਰ ਹੱਲ,” “ਮੇਰਾ ਵਰਕਅਰਾਉਂਡ ਜਿਸ ਨੇ ਰਿਲੀਜ਼ ਬਚਾਈ।” ਉਹ ਲੱਗਾਅ ਮਿਟਾਉਣਾ ਜਜ਼ਬੀ ਰੂਪ ਵਿੱਚ ਮਹਿੰਗਾ ਬਣਾਉਂਦਾ ਹੈ, ਚਾਹੇ ਆਰਥਿਕ ਰੂਪ ਵਿੱਚ ਰੀਰਾਈਟ ਸਹੀ ਹੋਵੇ।
AI-ਜਨਰੇਟ ਕੋਡ ਇਹ ਪ੍ਰਭਾਵ ਘਟਾ ਸਕਦਾ ਹੈ। ਕਿਉਂਕਿ ਸ਼ੁਰੂਆਤੀ ਡਰਾਫਟ ਇੱਕ ਟੂਲ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਹੋ ਸਕਦਾ ਹੈ (ਅਤੇ ਆਮ ਰੂਪ ਵਿੱਚ ਪਰਿਚਤ ਪੈਟਰਨ ਫੋਲੋ ਕਰਦਾ ਹੈ), ਕੋਡ ਨਿਰਮਾਤਾ ਦੀ ਦਸਤਖਤ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਅਤੇ ਇਸਨੂੰ ਬਦਲਣਾ ਔਖਾ ਨਹੀਂ ਲੱਗਦਾ। ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਐਸਾ ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਆਰਾਮਦਾਇਕ ਹੁੰਦੇ ਹਨ: “ਚਲੋ ਇਸ ਮੋਡੀਊਲ ਨੂੰ ਬਦਲ ਦਈਏ,” ਜਦੋਂ ਇਹ ਕਿਸੇ ਦੀ ਕ੍ਰਾਫਟਸਮੈਨਸ਼ਿਪ ਨੂੰ ਮਿਟਾਉਣ ਵਰਗਾ ਨਹੀਂ ਮਹਿਸੂਸ ਹੁੰਦਾ।
ਜਦੋਂ ਲੇਖਕ-ਲੱਗਾਅ ਘੱਟ ਹੁੰਦਾ ਹੈ, ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ:
ਰੀਰਾਈਟ ਫੈਸਲੇ ਫਿਰ ਵੀ ਲਾਗਤ ਅਤੇ ਨਤੀਜਿਆਂ ਦੁਆਰਾ ਚਲਾਏ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ: ਡਿਲਿਵਰੀ ਸਮਾਂ, ਜੋਖਮ, ਰੱਖ-ਰਖਾਅਯੋਗਤਾ ਅਤੇ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ। “ਇਹ ਮਿਟਾਉਣ ਲਈ ਆਸਾਨ ਹੈ” ਇਕ ਮਦਦਗਾਰ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ—ਪਰ ਇਹ ਆਪਣੀ ਸਟ੍ਰੈਟਜੀ ਨਹੀਂ ਹੋ ਸਕਦੀ।
AI-ਜਨਰੇਟ ਕੋਡ ਦਾ ਇੱਕ ਘੱਟ-ਮੁੱਲਾਂਕਣਿਆ ਲਾਭ ਇਹ ਹੈ ਕਿ ਜਨਰੇਸ਼ਨ ਦੇ ਇੰਪੁੱਟ ਜੀਵੰਤ ਵਿਸ਼ੇਸ਼ਣ ਵਾਂਗ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਪ੍ਰੰਪਟ, ਟੈਂਪਲੇਟ ਅਤੇ ਜਨਰੇਟਰ ਕੰਫਿਗਰੇਸ਼ਨ ਮਨਸ਼ਾ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹਨ: ਫੀਚਰ ਕੀ ਕਰੇ, ਕਿਹੜੀਆਂ ਪਾਬੰਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਹਨ (ਸੁਰੱਖਿਆ, ਪ੍ਰਦਰਸ਼ਨ, ਸਟਾਈਲ), ਅਤੇ “ਕੋਨਕਲੀਟ” ਕੀ ਹੈ।
ਜਦੋਂ ਟੀਮਾਂ ਦੋਹਰਾਏ ਜਾਣ ਵਾਲੇ ਪ੍ਰੰਪਟ (ਜਾਂ ਪ੍ਰੰਪਟ ਲਾਇਬ੍ਰੇਰੀ) ਅਤੇ ਸਥਿਰ ਟੈਂਪਲੇਟ ਵਰਤਦੀਆਂ ਹਨ, ਉਹ ਫੈਸਲਿਆਂ ਦੀ ਇੱਕ ਆਡੀਟ ਟ੍ਰੇਲ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਹੋਰਥਾਂ ਅਨੁਮਾਨਿਤ ਹੁੰਦੀਆਂ। ਇੱਕ ਚੰਗਾ ਪ੍ਰੰਪਟ ਉਹ ਗੱਲਾਂ ਦਰਸਾ ਸਕਦਾ ਹੈ ਜੋ ਭਵਿੱਖ ਦੇ ਮਾਇੰਟੇਨਰ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨ ਕਰਨਾ ਪੈਂਦਾ:
ਇਹ ਕਈ ਹੱਥ-ਲਿਖੇ ਕੋਡਬੇਸਾਂ ਤੋਂ ਵੱਖਰਾ ਹੈ ਜਿੱਥੇ ਮੁੱਖ ਡਿਜ਼ਾਇਨ ਚੋਣਾਂ commit messages, tribal knowledge ਅਤੇ ਛੋਟੀਆਂ, ਆਨਲਿਖਿਤ ਰੀਤਾਂ ਵਿੱਚ ਫਿੱਲ ਹੁੰਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਜਨਰੇਸ਼ਨ ਟਰੇਸ (ਪ੍ਰੰਪਟ + ਮਾਡਲ/ਵਰਜਨ + ਇਨਪੁੱਟ + ਪੋਸਟ-ਪ੍ਰੋਸੈਸਿੰਗ ਕਦਮ) ਰੱਖਦੇ ਹੋ ਤਾਂ ਇੱਕ ਰੀਰਾਈਟ ਖ਼ਾਲੀ ਪੰਨੇ ਤੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੀ। ਤੁਸੀਂ ਉਹੀ ਚੈੱਕਲਿਸਟ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹੀ ਵਿਹਾਰ ਇੱਕ ਸਾਫ਼ ਢਾਂਚੇ ਵਿੱਚ ਰੀ-ਕ੍ਰੀਏਟ ਕੀਤਾ ਜਾਵੇ, ਫਿਰ ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਅਮਲ ਵਿੱਚ, ਇਹ ਰੀਰਾਈਟ ਨੂੰ ਇਹ ਬਣਾਉਂਦਾ ਹੈ: “ਨਵੀਂ ਕਨਵੈਂਸ਼ਨ ਹੇਠ ਫੀਚਰ X ਨੂੰ ਦੁਬਾਰਾ ਜਨਰੇਟ ਕਰੋ, ਫਿਰ ਪੈਰਿਟੀ ਵੈਰੀਫਾਈ ਕਰੋ,” ਬਜਾਏ “ਫੀਚਰ X ਦਾ ਵਿਹਾਰ ਉੱਧੇ ਤੋਂ ਰਿਵਰਸ-ਇੰਜੀਨੀਅਰ ਕਰੋ।”
ਇਹ ਸਿਰਫ਼ ਕੰਮ ਕਰੇਗਾ ਜੇ ਪ੍ਰੰਪਟ ਅਤੇ ਕੰਫਿਗਸ ਨੂੰ ਉਸੇ ਅਨੁਸ਼ਾਸ਼ਨ ਨਾਲ ਸੰਭਾਲਿਆ ਜਾਵੇ ਜਿਵੇਂ ਸਰੋਤ ਕੋਡ:
ਬਿਨਾਂ ਇਸ ਦੇ, ਪ੍ਰੰਪਟ ਇਕ ਹੋਰ ਅਣਲਿਖਿਆ ਨਿਰਭਰਤਾ ਬਣ ਸਕਦੇ ਹਨ। ਨਾਲ ਇਹ ਹੋਵੇ ਤਾਂ ਉਹ ਉਹ ਦਸਤਾਵੇਜ਼ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਬਹੁਤ ਸਾਰੇ ਹੱਥ-ਲਿਖੇ ਸਿਸਟਮ ਕਦੇ ਨਹੀਂ ਰੱਖਦੇ।
“ਸੌਖਾ ਬਦਲਣਾ” ਅਸਲ ਵਿੱਚ ਇਸ ਗੱਲ ਬਾਰੇ ਨਹੀਂ ਕਿ ਕੋਡ ਕਿਸ ਨੇ ਲਿਖਿਆ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਭਰੋਸੇ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਟੈਸਟ ਤੁਹਾਨੂੰ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਦੱਸਦੇ ਹਨ ਕਿ ਵਿਹਾਰ ਇੱਕੋ ਜਿਹਾ ਰਹਿਆ, ਤਦ ਰੀਰਾਈਟ ਇੱਕ ਰੋਜ਼ਮਰਾ ਇੰਜਨੀਅਰਿੰਗ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
AI-ਜਨਰੇਟ ਕੋਡ ਇੱਥੇ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਮਨਵੀਛੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਪ੍ਰੰਪਟ ਵਿੱਚ ਬੋਇਲਰਪਲੇਟ ਟੈਸਟ ਮੰਗਦੀਆਂ ਹਨ (ਬੇਸਿਕ ਯੂਨਿਟ ਟੈਸਟ, ਹੈਪੀ-ਪਾਥ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਟੈਸਟ, ਸਧਾਰਨ ਮੌਕ)। ਇਹ ਟੈਸਟ ਪੂਰਨ ਨਹੀਂ ਹੋ ਸਕਦੇ, ਪਰ ਉਹ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਸੇਫਟੀ ਨੈੱਟ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਬਹੁਤ ਸਾਰੇ ਹੱਥ-ਲਿਖੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਲਾਪਤਾ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਰੀਪਲੇਸਬਿਲਟੀ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਟੈਸਟਿੰਗ ਦੀ ਉਰਜਾ ਉਹ ਸੀਮਾਂ 'ਤੇ ਜ਼ਿਆਦਾ ਲਗਾਓ ਜਿੱਥੇ ਹਿੱਸੇ ਮਿਲਦੇ ਹਨ:
ਕਾਂਟਰੈਕਟ ਟੈਸਟ ਇਹ ਲਾਕ ਕਰਦੇ ਹਨ ਕਿ ਜੇ ਇੰਟਰਨਲ ਬਦਲਦੇ ਹਨ ਤਾਂ ਕੀ ਬਾਕੀ ਚੀਜ਼ਾਂ ਸਹੀ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਮੋਡੀਊਲ ਨੂੰ ਮੁੜਲਿਖ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਵਿਹਾਰ ਤੇ ਮੁੜ ਚਰਚਾ ਕੀਤੇ।
ਕਵਰੇਜ ਨੰਬਰ ਇਹ ਜਾਣਨ ਲਈ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਖਤਰਾ ਕਿੱਥੇ ਹੈ, ਪਰ 100% ਪਿਛਾ ਕਰਨ ਨਾਲ ਅਕਸਰ ਨਾਜੁਕ ਟੈਸਟ ਬਣਦੇ ਹਨ ਜੋ ਰਿਫੈਕਟਰ ਨੂੰ ਰੋਕਦੇ ਹਨ। ਇਸਦੀ ਥਾਂ:
ਮਜ਼ਬੂਤ ਟੈਸਟਾਂ ਨਾਲ, ਰੀਰਾਈਟ ਹੀਰੋਇਕ ਪ੍ਰੋਜੈਕਟ ਨਹੀਂ ਰਹਿਦੇ—ਬਲਕਿ ਸੈਫ, ਵਾਪਸ ਯੋਗ ਕਦਮਾਂ ਦੀ ਲੜੀ ਬਣ ਜਾਂਦੀ ਹੈ।
AI-ਜਨਰੇਟ ਕੋਡ ਅਕਸਰ ਇੱਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਅਕਸਰ ਦੁਹਰਾਏ ਹੋਏ ਲਾਜਿਕ (ਉਹੇ ਹੇਲਪਰ ਨੂੰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਜਗ੍ਹਾਂ 'ਤੇ ਮੁੜ-ਲਿਖਿਆ), “ਲਗਭਗ ਇੱਕੋ” ਸ਼ਾਖਾਂ ਜੋ ਏਡਜ-ਕੇਸ ਨੂੰ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਸੰਭਾਲਦੀਆਂ ਹਨ, ਜਾਂ ਐਸੇ ਫੰਕਸ਼ਨ ਜੋ ਮਾਡਲ ਵੱਲੋਂ ਲਗਾਤਾਰ ਸਹੀ-ਠੀਕਾਂ ਜੋੜਦੇ ਹੋਏ ਵੱਡੇ ਹੋ ਜਾਂਦੇ ਹਨ ਦੇਖੋਗੇ। ਇਹ ਸਭ ਚੰਗਾ ਨਹੀਂ—ਪਰ ਇੱਕ ਫਾਇਦਾ ਇਹ ਹੈ: ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਦਿੱਖਦੀਆਂ ਹਨ।
ਹੱਥ-ਲਿਖਿਆ ਸਿਸਟਮ ਚਤੁਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨਾਂ, ਮਾਈਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨਾਂ ਜਾਂ ਤੰਗ ਕਪਲਿੰਗ ਦੇ ਪਿੱਛੇ ਕਠੋਰਤਾ ਛੁਪਾ ਸਕਦੇ ਹਨ। ਉਹ ਬੱਗ ਦਰਦਨਾਕ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਹੀ ਲੱਗਦੇ ਹਨ ਅਤੇ ਸਧਾਰਨ ਸਮੀਖਿਆ ਪਾਰ ਕਰ ਲੈਂਦੇ ਹਨ।
AI ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿਆਦਾ ਸਪੱਸ਼ਟ ਅਸਮਰੂਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ: ਇੱਕ ਪੈਰਾਮੀਟਰ ਇਕ ਪਾਥ ਵਿੱਚ ਅਣਡਾਢ ਗਿਆ, ਇੱਕ ਫਾਇਲ ਵਿੱਚ ਵੈਲਿਡੇਸ਼ਨ ਚੈੱਕ ਹੈ ਪਰ ਦੂਜੇ ਵਿੱਚ ਨਹੀਂ, ਜਾਂ ਐਰਰ ਹੈਂਡਲਿੰਗ ਹਰ ਕੁਝ ਜਗ੍ਹਾ ਵੱਖਰੀ ਹੈ। ਇਹ ਗ਼ਲਤੀਆਂ ਸਮੀਖਿਆ ਅਤੇ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ ਦੌਰਾਨ ਆਸਾਨੀ ਨਾਲ ਉੱਭਰਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਅਕਸਰ ਡੂੰਘੇ ਇਰਾਦਿਆਂ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਦੁਹਰਾਅ ਇੱਕ ਨਿਸ਼ਾਨ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਉਹੀ ਕਦਮ-ਕ੍ਰਮ ਕਈ ਐਂਡਪਾਇੰਟਾਂ ਜਾਂ ਸਰਵਿਸز 'ਚ ਮੁੜ-ਅਪਨੀ ਹੋ ਰਹੀ ਦੇਖਦੇ ਹੋ—parse input → normalize → validate → map → return—ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਕੁਦਰਤੀ ਸੀਮਾ ਲਈ ਸੂਚਿਤ ਹੋ।
AI ਅਕਸਰ ਇੱਕ ਨਵੇਂ ਰਿਕਵੇਸਟ ਦਾ ਹੱਲ ਪਿਛਲੇ ਹੱਲ ਨੂੰ ਥੋੜ੍ਹਾ ਬਦਲ ਕੇ ਮੁੜ ਪ੍ਰਿੰਟ ਕਰ ਕੇ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਨੇੜੇ-ਨਕਲਾਂ ਦੇ ਕਲੱਸਟਰ ਬਣਦੇ ਹਨ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਤਰੀਕਾ ਹੈ ਕਿ ਕੋਈ ਵੀ ਦੁਹਰਾਇਆ ਹੋਇਆ ਖੰਡ ਨਿਕਾਲ ਕੇ ਨਿਰਧਾਰਤ ਟੈਸਟਾਂ ਵਾਲੇ ਇੱਕ ਮੋਡੀਊਲ ਨੂੰ ਦਿੱਤਾ ਜਾਵੇ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ:
ਜੇ ਤੁਸੀਂ ਦੁਹਰਾਏ ਵਿਹਾਰ ਨੂੰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ, ਤਾਂ ਉਹ ਸੰਭਵਤ: ਇੱਕ ਮੋਡੀਊਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਦੁਹਰਾਏ ਖੰਡਾਂ ਨੂੰ ਇੱਕ ਸੰਨੀਰਤ ਮੌਡੀਊਲ (ਯੂਟੀਲਿਟੀ, ਸਾਂਝੀ ਸਰਵਿਸ, ਲਾਇਬ੍ਰੇਰੀ) ਵਿਚ ਰੱਖੋ, ਉਹਨਾਂ ਏਡਜ-ਕੇਸਾਂ ਲਈ ਟੈਸਟ ਲਿਖੋ ਜੋ ਉਮੀਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਨਕਲਾਂ ਨੂੰ ਮਿਟਾ ਦਿਓ। ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਨਾਜੁਕ ਨਕਲਾਂ ਨੂੰ ਇੱਕ ਸੁਧਰਿਆ ਕੇਂਦਰ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ—ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਮੁੜ ਰੀਰਾਈਟ ਲਈ ਇਕ ਹੀ ਜਗ੍ਹਾ ਹੋਵੇਗੀ।
AI-ਜਨਰੇਟ ਕੋਡ ਅਕਸਰ ਉਸ ਵੇਲੇ ਚਮਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਸਾਫਾਈ ਲਈ ਕਹਿੰਦੇ ਹੋ। ਸਹੀ ਪ੍ਰੰਪਟ ਅਤੇ ਲਿੰਟ ਨਿਯਮਾਂ ਨਾਲ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਪਰੀਚਿਤ ਕੰਟਰੋਲ ਫਲੋ, ਰਵਾਇਤੀ ਨਾਂਵਾਂ ਅਤੇ “ਬੋਰੀਂ” ਮੋਡੀਊਲ ਚੁਣੇਗਾ ਬਜਾਏ ਨਵਾਂਪਣ ਦੇ। ਇਹ ਲੰਮੇ ਸਮੇਂ ਵਿੱਚ ਉਹ ਕੁਝ ਪ੍ਰਤਸ਼ਤ ਤੇਜ਼ੀ ਜੋ ਹੱਥ-ਟਿਊਨ ਕੀਤੇ ਗਏ ਸੁਝਾਵ ਤੋਂ ਮਿਲਦੀ ਹੈ, ਉਸ ਤੋਂ ਵੱਡੀ ਜਿੱਤ ਹੋ ਸਕਦੀ ਹੈ।
ਜਦੋਂ ਨਵੇਂ ਲੋਕ ਸਿਸਟਮ ਦਾ ਸਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਲੈਂਦੇ ਹਨ, ਤਾਂ ਰੀਰਾਈਟ ਸਫਲ ਹੁੰਦੀ ਹੈ। ਪੜ੍ਹਨਯੋਗ, ਇਕਸਾਰ ਕੋਡ ਬੁਨਿਆਦੀ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ: “ਇੱਥੇ ਰਿਕਵੇਸਟ ਕਿੱਥੋਂ ਦਾਖਲ ਹੁੰਦੀ ਹੈ?” ਅਤੇ “ਇੱਥੇ ਡੇਟਾ ਦਾ ਆਕਾਰ ਕੀ ਹੈ?” ਜੇ ਹਰ ਸਰਵਿਸ ਸਮਾਨ ਪੈਟਰਨ ਫਾਲੋ ਕਰਦੀ ਹੈ (ਲੇਆਉਟ, ਐਰਰ ਹੈਂਡਲਿੰਗ, ਲੌਗਿੰਗ, ਕਨਫਿਗਰੇਸ਼ਨ), ਤਾਂ ਇੱਕ ਨਵੀਂ ਟੀਮ ਇੱਕ ਗੱਲ-ਦਰ-ਗੱਲ ਰੀਰਾਈਟ ਕਰ ਸਕਦੀ ਹੈ ਬਿਨਾਂ ਹਰ ਇਕ ਸਥਾਨਕ ਰੀਤ ਨੂੰ ਮੁੜ ਸਿੱਖਣ ਤੋਂ।
ਇਕਸਾਰਤਾ ਡਰ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਕੋਡ ਪੇਸ਼ਗੋਈਯੋਗ ਹੁੰਦਾ ਹੈ, ਇੰਜਨੀਅਰ ਹਿੱਸਿਆਂ ਨੂੰ ਮਿਟਾਉਣ ਅਤੇ ਦੁਬਾਰਾ ਬਣਾਉਣ ਵਿੱਚ ਭਰੋਸਾ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਸਤਹ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਹੈ ਅਤੇ “ਬਲਾਸਟ ਰੇਇਡੀਅਸ” ਛੋਟਾ ਲੱਗਦਾ ਹੈ।
ਬਹੁਤ optimize ਕੀਤਾ, ਹੱਥ-ਲਿਖਿਆ ਕੋਡ ਮੁੜਲਿਖਣਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰਦਰਸ਼ਨ ਤਕਨੀਕ ਅਕਸਰ ਹਰ ਜਗ੍ਹਾ ਲੀਕ ਹੁੰਦੀਆਂ ਹਨ: ਕਸਟਮ ਕੈਸ਼ਿੰਗ ਲੇਅਰ, ਮਾਈਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ, ਘਰੇਲੂ concurrency ਪੈਟਰਨ, ਜਾਂ ਖਾਸ ਡੇਟਾ ਸਟ੍ਰਕਚਰ ਨਾਲ ਤਗੜਾ coupling। ਇਹ ਚੋਣਾਂ ਮਾਰਕੂਕੀ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਅਕਸਰ ਉਹ ਛੁਪੇ ਹੋਏ ਪਾਬੰਧ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਤੋੜਨ 'ਤੇ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।
ਪੜ੍ਹਨਯੋਗਤਾ ਇੱਕ ਆਜ਼ਾਦੀ ਨਹੀਂ ਹੈ ਕਿ ਤੁਸੀਂ ਸਲੋ ਹੋ ਸਕੋ। ਮਕਸਦ ਹੈ ਤਕਨੀਕੀ ਸ਼ਾਹੀਤਾ ਨਾਲ ਪ੍ਰਮਾਣ ਲੈਣਾ। ਰੀਰਾਈਟ ਤੋਂ ਪਹਿਲਾਂ ਬੇਲਾਈਨ ਮੈਟ੍ਰਿਕਸ (ਲੈਟੈਂਸੀ ਪਰਸੈਂਟਾਈਲ, CPU, ਮੈਮਰੀ, ਲਾਗਤ) ਲਵੋ। ਕਿਸੇ ਹਿੱਸੇ ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਫੇਰ ਮਾਪੋ। ਜੇ ਪ੍ਰਦਰਸ਼ਨ ਘਟਦਾ ਹੈ, ਤਾਂ ਖਾਸ ਹੌਟ ਪਾਥ ਨੂੰ optimize ਕਰੋ—ਬਿਨਾਂ ਪੂਰੇ ਕੋਡਬੇਸ ਨੂੰ ਪਜ਼ਲ ਬਣਾਏ।
ਜਦੋਂ ਇੱਕ AI-ਸਹਾਇਤ ਕੋਡਬੇਸ “ਗਲਤ” ਮਹਿਸੂਸ ਹੋਂਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਸਵੈਚਾਲਿਤ ਤੌਰ 'ਤੇ ਪੂਰਾ ਰੀਰਾਈਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਸਭ ਤੋਂ ਵਧੀਆ ਰੀਸੈੱਟ ਇਹ ਉੱਪਰ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਕਿੰਨਾ ਗਲਤ ਹੈ ਬਨਾਮ ਕੇਵਲ ਗੰਦਾ।
Regenerate ਦਾ ਮਤਲਬ ਹੈ ਕਿਸੇ ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਸਪੈੱਕ ਜਾਂ ਪ੍ਰੰਪਟ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣਾ—ਅਕਸਰ ਇੱਕ ਟੈਂਪਲੇਟ ਜਾਂ ਪਤਾ ਲਗੇ ਪੈਟਰਨ ਤੋਂ। ਇਹ “ਸੱਫਾ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਬਣਾਓ” ਹੈ, ਨ ਕਿ “ਸਭ ਕੁਝ ਮਿਟਾ ਦਿਓ।”
Refactor ਵਿਹਾਰ ਨੂੰ ਇੱਕੋ ਰੱਖਦਾ ਹੈ ਪਰ ਅੰਦਰੂਨੀ ਸਮਰਚਨਾ ਬਦਲਦਾ ਹੈ: ਨਾਮ ਬਦਲਣਾ, ਮੋਡੀਊਲਾਂ ਨੂੰ ਵੰਡਣਾ, ਸਥਿਤੀਆਂ ਸਧਾਰਣਾ, duplication ਹਟਾਉਣਾ, ਟੈਸਟ ਬਿਹਤਰ ਕਰਨਾ।
Rewrite ਇੱਕ ਹਿੱਸਾ ਜਾਂ ਸਿਸਟਮ ਨੂੰ ਨਵੇਂ ਇੰਪਲੇਮੇਂਟੇਸ਼ਨ ਨਾਲ ਬਦਲਣਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਜਦੋਂ ਮੌਜੂਦਾ ਡਿਜ਼ਾਇਨ ਨੂੰ ਸਿਹਤਮੰਦ ਬਣਾਉਣ ਲਈ ਵਿਹਾਰ, ਸੀਮਾਵਾਂ ਜਾਂ ਡੇਟਾ ਫਲੋ ਬਦਲਣਾ ਲੋੜੀਂਦਾ ਹੋਵੇ।
ਜਦੋਂ ਕੋਡ ਜ਼ਿਆਦਾਤਰ ਬੋਇਲਰਪਲੇਟ ਹੋ ਅਤੇ ਮੁੱਲ ਇੰਟਰਫੇਸ ਵਿੱਚ ਹੋਵੇ (ਬਜਾਏ ਚਤੁਰ ਇੰਟਰਨਲਾਂ ਦੇ), ਤਦ ਰੀਜਨਰੇਸ਼ਨ ਚਮਕਦਾ ਹੈ:
ਜੇ ਸਪੈੱਕ ਸਪੱਸ਼ਟ ਹੈ ਅਤੇ ਮੋਡੀਊਲ ਸੀਮਾ ਸਾਫ਼ ਹੈ, ਤਾਂ ਜਨਰੇਟ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਅਣਟੈਂਗਲ ਕਰਨ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਚੇਤਾਵਨੀ ਜਦੋਂ ਕੋਡ ਵਿੱਚ ਪੱਕਾ ਡੋਮੇਨ ਗਿਆਨ ਜਾਂ ਨਾਜੁਕ ਸਹੀ-ਠੀਕਤਾਵਾਂ ਨੇ:
ਇਨ੍ਹਾਂ ਖੇਤਰਾਂ ਵਿੱਚ “ਨੇੜੇ-ਕਾਫੀ” ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਮਹਿੰਗਾ ਸਾਬਤ ਹੋ ਸਕਦਾ ਹੈ—ਰੀਜਨਰੇਸ਼ਨ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਪਰ ਕੇਵਲ ਜੇ ਤੁਸੀਂ ਮਜ਼ਬੂਤ ਟੈਸਟ ਅਤੇ ਸਮੀਖਿਆ ਨਾਲ ਸਮਰਥਿਤ ਹੋ।
ਜਨਰੇਟ ਕੀਤੇ ਕੋਡ ਨੂੰ ਇੱਕ ਨਵੇਂ ਡਿਪੈਂਡੈਂਸੀ ਵਾਂਗ ਹੀ ਟ੍ਰੀਟ ਕਰੋ: ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਲਾਜ਼ਮੀ ਕਰੋ, ਪੂਰਾ ਟੈਸਟ ਸੂਟ ਚਲਾਓ, ਅਤੇ ਪਹਿਲਾਂ ਦੇਖੇ ਗਏ ਫੇਲਾਂ ਲਈ ਨਿਸ਼ਾਨ-ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ। ਛੋਟੇ ਸਲਾਈਸਾਂ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰੋ—ਇੱਕ ਐਂਡਪਾਇੰਟ, ਇੱਕ ਸਕ੍ਰੀਨ, ਇੱਕ ਐਡਾਪਟਰ—ਫੀਚਰ-ਫਲੈਗ ਜਾਂ ਗਰੇਡੁਅਲ ਰਿਲੀਜ਼ ਦੇ ਪਿੱਛੇ ਜੇ ਸੰਭਵ ਹੋਵੇ।
ਉਪਯੋਗੀ ਡਿਫਾਲਟ ਇਹ ਹੈ: ਸ਼ੈੱਲ ਨੂੰ ਰੀਜਨਰੇਟ ਕਰੋ, ਸੀਮਾਂ ਨੂੰ ਰਿਫੈਕਟਰ ਕਰੋ, ਜਿੱਥੇ ਅਨੁਮਾਨ بار-ਬਾਰ ਟੁਟਦੇ ਹਨ ਉਥੇ ਹੀ ਰੀਰਾਈਟ ਕਰੋ।
“ਆਸਾਨੀ ਨਾਲ ਬਦਲਣਯੋਗ” ਉਹੀ ਲਾਭ ਬਣਾ ਰਹੀ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਰੀਪਲੇਸਮੈਂਟ ਨੂੰ ਇੱਕ ਇੰਜਿਨੀਅਰਡ ਗਤੀਵਿਧੀ ਵਾਂਗ ਨਹੀਂ ਸਾਂਭਦੀਆਂ। AI-ਲਿਖੇ ਮੋਡੀਊਲ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲੇ ਜਾ ਸਕਦੇ ਹਨ—ਪਰ ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ 'ਤੇ ਜ਼ਿਆਦਾ ਭਰੋਸਾ ਕਰ ਲੈਂਦੇ ਹੋ ਬਿਨਾਂ ਜਾਂਚ ਦੇ, ਤਾਂ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਫੇਲ ਵੀ ਹੋ ਸਕਦੇ ਹਨ।
AI-ਜਨਰੇਟ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰਾ ਦਿਖਦਾ ਹੈ ਭਾਵੇਂ ਉਹ ਨਾ ਹੋਵੇ। ਇਹ ਝੂਠੀ ਭਰੋਸੇਯੋਗਤਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਹੈਪੀ-ਪਾਥ ਡੈਮੋ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ।
ਦੂਜਾ ਖਤਰਾ ਗੁੰਮ-ਮੁੱਦੇ ਹੈ: ਅਜਿਹੇ ਇਨਪੁੱਟ, ਟਾਈਮਆਉਟ, concurrency ਖੱਟੇ-ਭੱਟੇ, ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ ਜੋ ਪ੍ਰੰਪਟ ਜਾਂ ਨਮੂਨਾ ਡੇਟਾ ਵਿੱਚ ਕਵਰ ਨਹੀਂ ਕੀਤੇ ਗਏ।
ਅਖੀਰ ਵਿੱਚ, ਲਾਇਸੰਸਿੰਗ/IP ਅਣਪੱਕਤਾ ਹੈ। ਭਾਵੇਂ ਕਿ ਖਤਰਾ ਕਈ ਸੈਟਅਪਾਂ ਵਿੱਚ ਘੱਟ ਹੋ ਸਕਦਾ ਹੈ, ਟੀਮਾਂ ਨੂੰ ਇਹ ਨੀਤੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕਿਹੜੇ ਸਰੋਤ ਅਤੇ ਟੂਲ ਮਨਜ਼ੂਰ ਹਨ ਅਤੇ provenance ਕਿਵੇਂ ਟਰੈਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਬਦਲਾਅ ਨੂੰ ਉਹੀ ਗੇਟਾਂ ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਜੋ ਕਿਸੇ ਹੋਰ ਬਦਲਾਅ ਲਈ ਹੁੰਦੀਆਂ ਹਨ:
ਕਿਸੇ ਭਾਗ ਨੂੰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਸਦੀ ਸੀਮਾ ਅਤੇ ਇਨਵੈਰੀਅਂਟ ਲਿਖੋ: ਇਹ ਕੀ ਇਨਪੁੱਟ ਲੈਂਦਾ ਹੈ, ਇਹ ਕੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ, ਇਹ ਕੀ ਕਦੇ ਨਹੀਂ ਕਰੇਗਾ (ਉਦਾਹਰਣ: “ਗਾਹਕ ਦਾ ਡੇਟਾ ਕਦੇ ਹਟਾਓ ਨਾ”), ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ/ਲੈਟੈਂਸੀ ਉਮੀਦਾਂ। ਇਹ “ਕਾਂਟਰੈਕਟ” ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸਦੇ ਖਿਲਾਫ਼ ਤੁਸੀਂ ਟੈਸਟ ਕਰਦੇ ਹੋ—ਭਾਵੇਂ ਕੋਡ ਕਿਸ ਨੇ ਵੀ ਲਿਖਿਆ ਹੋਵੇ।
AI-ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਅਕਸਰ ਰੀਰਾਈਟ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਪਰਿਚਿਤ ਪੈਟਰਨ ਫੋਲੋ ਕਰਦਾ ਹੈ, ਗਹਿਰੀ “ਕ੍ਰਾਫਟ” ਨਿੱਜੀਕਰਨ ਤੋਂ ਬਚਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਲੋੜ ਬਦਲਦੀ ਹੈ ਤਾਂ ਦੁਬਾਰਾ ਜਨਰੇਟ ਕਰਨਾ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ। ਉਹ ਪੇਸ਼ਗੋਈਤਾ ਸਮਾਜਿਕ ਅਤੇ ਤਕਨੀਕੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਕਿ ਹਿੱਸਿਆਂ ਨੂੰ ਮਿਟਾ ਕੇ ਬਦਲਣਾ ਇੱਕ ਆਮ, ਘੱਟ-ਘਰਣ ਫ਼ੈਸਲਾ ਬਣ ਜਾਵੇ—ਕਾਂਟਰੈਕਟ ਅਤੇ ਟੈਸਟਾਂ ਨਾਲ ਸਹਿਯੋਗੀ।
ਮਕਸਦ “ਕੋਡ ਫੈਕਣ” ਨਹੀਂ, ਪਰ ਇਹ ਹੈ ਕਿ ਕੋਡ ਬਦਲਣ ਇਕ ਆਮ, ਨਿਰੀਜਕ ਚੋਣ ਹੋਵੇ—ਕਾਂਟਰੈਕਟ ਅਤੇ ਟੈਸਟਾਂ ਦੁਆਰਾ ਸਮਰਥਿਤ।
ਟੌਨ ਸਟੈਂਡਰਡ ਕੰਵੇਂਸ਼ਨਾਂ ਨੂੰ ਲਾਕ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਦੁਬਾਰਾ ਜਨਰੇਟ ਕੀਤਾ ਜਾਂ ਮੁੜਲਿਖਿਆ ਕੋਡ ਇੱਕੋ ਢੰਗ ਵਿੱਚ ਫਿੱਟ ਹੋਵੇ:
ਜੇ ਤੁਸੀਂ ਇੱਕ vibe-coding ਵਰਕਫਲੋ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਯੂਜ਼ਰ-ਮਿੱਤਰ ਟੂਲ ਖੋਜੋ ਜੋ ਇਹ ਪ੍ਰਚਲਨਾਂ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ: “ਪਲੈਨਿੰਗ ਮੋਡ” ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਰਿਪੋ ਨਾਲ ਰੱਖਣਾ, ਜਨਰੇਸ਼ਨ ਟਰੇਸ ਕੈਪਚਰ ਕਰਨਾ, ਅਤੇ ਸੇਫ ਰੋਲਬੈਕ ਸਮਰਥਿਤ ਕਰਨਾ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਚੈਟ-ਚਲਿਤ ਜਨਰੇਸ਼ਨ ਨਾਲ snapshots ਅਤੇ rollback ਸਹੀ ਬਣਾ ਕੇ "replaceable by design" ਧਾਰਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ—ਇੱਕ ਸਲਾਈਸ ਨੂੰ ਰੀਜਨਰੇਟ ਕਰੋ, ਕਾਂਟਰੈਕਟ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਜੇ ਪੈਰਿਟੀ ਟੈਸਟ ਫੇਲ ਹੋਣ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਜਾਓ।
ਇੱਕ ਅਜਿਹਾ ਮੋਡੀਊਲ ਚੁਣੋ ਜੋ ਮਹੱਤਵਪੂਰਨ ਪਰ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਅਲੱਗ ਹੋਵੇ—ਰਿਪੋਰਟ ਜਨਰੇਸ਼ਨ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਭੇਜਣਾ, ਜਾਂ ਇੱਕ CRUD ਖੇਤਰ। ਇਸਦੀ ਪਬਲਿਕ ਇੰਟਰਫੇਸ ਤੈਅ ਕਰੋ, ਕਾਂਟਰੈਕਟ ਟੈਸਟ ਜੋੜੋ, ਫਿਰ ਆਪਣੇ ਆਪ ਨੂੰ ਆਜ਼ਾਦ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇੰਟਰਨਲ ਨੂੰ ਰੀਜਨਰੇਟ/ਰਿਫੈਕਟਰ/ਰੀਰਾਈਟ ਕਰ ਸਕੋ ਜਦ ਤੱਕ ਇਹ ‘ਬੋਰੀਂ’ ਨਾ ਹੋ ਜਾਏ। ਸਾਇਕਲ ਸਮਾਂ, дефेक्ट ਦਰ ਅਤੇ ਸਮੀਖਿਆ ਮਹਨਤ ਨੂੰ ਮਾਪੋ; ਨਤੀਜਿਆਂ ਦੇ ਆਧਾਰ ਤੇ ਟੀਮ-ਵਿਆਪੀ ਨੀਤੀਆਂ ਬਣਾਓ।
ਇਸਨੂੰ ਓਪਰੇਸ਼ਨਲ ਬਣਾਉਣ ਲਈ, ਆਪਣੇ ਅੰਦਰੂਨੀ ਪਲੇਅਬੁੱਕ ਵਿੱਚ ਇੱਕ ਚੈੱਕਲਿਸਟ ਰੱਖੋ ਅਤੇ “ਕਾਂਟਰੈਕਟ + ਕਨਵੇਂਸ਼ਨ + ਟਰੇਸ” ਤਿਕੋਣੀ ਨੂੰ ਨਵੇਂ ਕੰਮਾਂ ਲਈ ਲਾਜ਼ਮੀ ਬਣਾਉ। ਜੇ ਤੁਸੀਂ ਟੂਲ ਸਹਾਇਤਾ ਜਾਂਚ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਵੀ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਖਾਸੀਅਤਾਂ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹੋ ਪਹਿਲਾਂ ਕਿ /pricing ਵੇਖੋ।
“ਬਦਲਨਾ” ਆਮ ਤੌਰ ’ਤੇ ਸਿਸਟਮ ਦੇ ਇੱਕ ਟੁਕੜੇ ਨੂੰ ਬਦਲ ਕੇ ਬਾਕੀ ਹਿੱਸੇ ਨੂੰ ਚਲਦੇ ਰਹਿਣ ਦੀ ਆਗਿਆ ਦੇਣ ਨੂੰ ਕਹਿੰਦਾ ਹੈ। ਆਮ ਨਿਸ਼ਾਨੇ:
ਪੂਰਾ ਐਪ ਹਟਾ ਕੇ ਮੁੜ ਲਿਖਣਾ ਅਕਸਰ ਨਹੀਂ ਹੁੰਦਾ; ਜ਼ਿਆਦਾਤਰ ਕਾਮਯਾਬ ਰੀਰਾਈਟ ਖੰਡ-ਖੰਡ ਹੁੰਦੇ ਹਨ।
ਦਾਅਵਾ ਗੁਣਵੱਤਾ ਬਾਰੇ ਨਹੀਂ, ਬਲਕਿ ਸਧਾਰਨ ਰੁਝਾਨਾਂ ਬਾਰੇ ਹੈ। AI-ਜਨਰੇਟ ਕੋਡ ਅਕਸਰ:
ਇਹ "ਘੱਟ ਵਿਸ਼ੇਸ਼" ਰੂਪ ਅਕਸਰ ਸਮਝਣ ਵਿੱਚ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਸ ਲਈ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਾ ਵੀ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।
ਮਿਆਰੀ ਪੈਟਰਨ ਰੀਰਾਈਟ ਦੌਰਾਨ “ਡਿਕੋਡਿੰਗ” ਦਾ ਖਰਚ ਘਟਾਉਂਦੇ ਹਨ। ਜੇ ਇੰਜਨੀਅਰ ਤੁਰੰਤ ਸਮਝ ਸਕਦੇ ਹਨ:
…ਤਾਂ ਉਹ ਨਵੇਂ ਇੰਪਲੇਮੇਂਟੇਸ਼ਨ ਵਿੱਚ ਵਿਹਾਰ ਦੁਹਰਾਅ ਕਰਨ ਵਿੱਚ ਤੇਜ਼ ਹੁੰਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਦੇਖਭਾਲ ਦੇ।
ਕਸਟਮ ਗਲੂ (ਘਰੇਲੂ DI ਕੰਟੇਨਰ, ਜਾਦੂਈ ਬੇਸ ਕਲਾਸ, ਗਲੋਬਲ ਸਟੇਟ ਵਗੈਰਾ) coupling ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕੋਡ ਵਿੱਚ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ। ਰੀਪਲੇਸਮੈਂਟ ਦੌਰਾਨ ਤੁਸੀਂ:
ਵੱਧ ਸਪੱਸ਼ਟ, ਪਰੰਪਰਾਗਤ ਵਾਇਰਿੰਗ ਇਨ੍ਹਾਂ ਅਚਾਨਕਾਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
ਇੱਕ ਤਰਤੀਬਬੱਧ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਆਪ ਆਊਟਪੁੱਟ ਦੇ ਇੰਟਰਨਲ ਨੂੰ ਬਦਲੋ ਪਰ ਪਬਲਿਕ ਇੰਟਰਫੇਸ ਸਥਿਰ ਰੱਖੋ:
ਇਹ “strangler” ਅੰਦਾਜ਼ ਹੈ: ਕਲਿਫ ਨਹੀਂ, ਸੀੜ੍ਹੀ।
ਜਦੋਂ ਕੋਡ ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਨਿੱਜੀ ਨਮਾਇਸ਼ ਵਾਂਗ ਲੱਗਦਾ ਹੈ ਤਾਂ ਟੀਮਾਂ ਰੀਰਾਈਟ ਕਰਨ ਵਿੱਚ ਹिचਕिचਾਉਂਦੀਆਂ ਹਨ। AI-ਜਨਰੇਟ ਕੋਡ ਆਮ ਤੌਰ ਤੇ ਇੱਕ ਟੂਲ ਦੁਆਰਾ ਬਣਿਆ ਹੋਇਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਪਰੰਪਰਾਗਤ ਰੂਪ ਫਾਲੋ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਲੋਕ ਆਮ ਤੌਰ ਤੇ ਆਸਾਨੀ ਨਾਲ ਕਹਿ ਸਕਦੇ ਹਨ: “ਚਲੋ ਇਸ ਮੋਡੀਊਲ ਨੂੰ ਬਦਲ ਦਈਏ।”
ਇਸ ਨਾਲ ਟੀਮ ਵੱਧ ਖੁੱਲ ਕੇ ਮੌਜੂਦਾ ਕੋਡ ਨੂੰ ਚੁਣੌਤੀ ਦੇ ਸਕਦੀ ਹੈ, ਅਨਵਧੇਸ਼ਤਾਂ ਘਟਦੀਆਂ ਹਨ ਅਤੇ ਗਿਆਨ ਤੇਜ਼ੀ ਨਾਲ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰੰਪਟ, ਟੈਂਪਲੇਟ ਅਤੇ ਜਨਰੇਸ਼ਨ ਕੰਫਿਗ ਫਾਇਲਾਂ ਨੂੰ ਰਿਪੋ ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਤਾਂ ਉਹ ਇਕ ہਲਕੀ-ਫੁਲਕੀ ਵਿਸ਼ੇਸ਼ ਦਸਤਾਵੇਜ਼ ਵਾਂਗ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ:
ਇਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕਰੋ ਜਿਵੇਂ ਕਿ ਕੋਡ ਦੀ ਵਰਜ਼ਨਿੰਗ ਹੁੰਦੀ ਹੈ ਅਤੇ ਦਰਸਾਓ ਕਿ ਕਿਹੜੀ ਪ੍ਰੰਪਟ/ਕੰਫਿਗ ਕਿਸ ਮੋਡੀਊਲ ਨੂੰ ਜਨਰੇਟ ਕਰਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਪ੍ਰੰਪਟ ਵੀ ਇਕ ਹੋਰ ਅਣਡਾਕੂ ਡੈਪੈਂਡੇਸੀ ਬਣ ਸਕਦੇ ਹਨ।
ਉਹ ਸਥਾਨ ਜਿੱਥੇ ਬਦਲਾਅ ਹੁੰਦੇ ਹਨ ਉਨ੍ਹਾਂ ਦੇ ਸੀਮਾਂ 'ਤੇ ਟੈਸਟ ਤੇ ਧਿਆਨ ਦੇਵੋ:
ਜਦੋਂ ਇਹ ਕਾਂਟਰੈਕਟ ਟੈਸਟ ਪਾਸ ਹੋਂਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇੰਟਰਨਲ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਬਹੁਤ ਡਰ ਦੇ।
AI-ਜਨਰੇਟ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਦਿੱਖ ਵਿੱਚ ਖੁਲਾਸਾ ਕਰਦਾ ਹੈ:
ਇਹ ਦੁਸਰਿਆਂ ਦੇ ਛੁਪੇ ਹੋਏ ਚੁਕਾਂ ਨਾਲੋਂ ਆਸਾਨੀ ਨਾਲ ਪਛਾਣ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਦੁਹਰਾਏ ਗਏ ਹਿੱਸਿਆਂ ਨੂੰ ਇੱਕ ਟੈਸਟ ਕੀਤੇ ਹੋਏ ਮੋਡੀਊਲ ਵਿੱਚ ਜੋੜੋ ਅਤੇ ਫੇਰ ਨਕਲਾਂ ਨੂੰ ਹਟਾ ਦਿਓ।
ਰੀਡੇਬਿਲਿਟੀ ਅਤੇ ਸੰਗਤੀਵਾਦ (consistency) ਅਕਸਰ ਹੱਥ-ਟੋਂ-ਸੁਧਾਰੇ ਪ੍ਰਦਰਸ਼ਨ-ਹੈਕਸ ਤੋਂ ਵੱਧ ਲਾਭਦਾਇਕ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਕੋਡ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਇੱਕਸਾਰ ਹੁੰਦਾ ਹੈ, ਨਵੇਂ ਲੋਕ ਸਿਸਟਮ ਦਾ ਸਹੀ ਮਾਨਸਿਕ ਮਾਡਲ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਲੈਂਦੇ ਹਨ ਅਤੇ ਇੱਕ-ਇਕ ਸਲਾਈਸ ਬਦਲ ਸਕਦੇ ਹਨ।
ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ—ਨਾਪੋ ਅਤੇ ਆਧਾਰ ਤੇ ਹੀ ਠੀਕ ਕਰੋ। ਅਗੇਤਰ ਰੀਰਾਈਟ ਤੋਂ ਪਹਿਲਾਂ ਮੈਟਰਿਕਸ ਲੈ ਲਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੁੜ ਮਾਪੋ।
ਤਿੰਨ ਵਿਕਲਪ ਹਨ:
Regenerate ਵਧੀਆ ਹੈ ਜਦੋਂ ਕੋਡ ਬਹੁਤ ਬੋਇਲਰਪਲੇਟ ਹੋਵੇ। ਧਿਆਨ ਨਾਲ, ਰੀਜਨਰੇਸ਼ਨ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਵਿੱਚ ਖਤਰਨਾਕ ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਡੋਮੇਨ-ਖ਼ਾਸ ਗਿਆਨ ਜਾਂ ਜਟਿਲ concurrency/ਕੰਪਲਾਇੰਸ ਲੋਜ਼ ਹੈ—ਇਨ੍ਹਾਂ ਲਈ ਬਲੜੇ ਟੈਸਟ ਅਤੇ ਮਨੁੱਖੀ ਸਮੀਖਿਆ ਜ਼ਰੂਰੀ ਹੈ।