24 ਅਕਤੂ 2025·8 ਮਿੰਟ
AI ਕਿਵੇਂ ਕੋਡ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ, ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਸਾਦਗੀ ਦਾ ਸੰਤੁਲਨ ਕਰਦਾ ਹੈ
ਜਾਣੋ ਕਿ AI-ਜਨਰੇਟ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਕਿਵੇਂ ਤੇਜ਼, ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਸਧਾਰਨ ਰਹਿ ਸਕਦੀ ਹੈ—ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਾਂਪਟ, ਸਮੀਖਿਆ ਚੈਕ ਅਤੇ ਰੱਖਿਆਯੋਗ ਕੋਡ ਲਈ ਪੈਟਰਨ।
ਜਾਣੋ ਕਿ AI-ਜਨਰੇਟ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਕਿਵੇਂ ਤੇਜ਼, ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਸਧਾਰਨ ਰਹਿ ਸਕਦੀ ਹੈ—ਅਤੇ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਾਂਪਟ, ਸਮੀਖਿਆ ਚੈਕ ਅਤੇ ਰੱਖਿਆਯੋਗ ਕੋਡ ਲਈ ਪੈਟਰਨ।
ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ "ਸੰਤੁਲਿਤ" ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਜਾਣਨਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਕਿਸਮ ਦੇ ਕੋਡ ਦੀ ਗੱਲ ਕਰ ਰਹੇ ਹੋ।
ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਉਹ ਕੋਡ ਹੈ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੇ ਨਿਯਮਾਂ ਅਤੇ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਵਰਣਨ ਕਰਦਾ ਹੈ: ਯੋਗਤਾ ਚੈੱਕ, ਕੀਮਤ ਫੈਸਲੇ, ਆਰਡਰ ਸਟੇਟ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ, ਅਧਿਕਾਰ ਅਤੇ "ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ" ਵਾਲੇ ਨਿਯਮ। ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਕਾਰੋਬਾਰੀ ਵਿਹਾਰ ਨਾਲ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ ਅਤੇ ਅਕਸਰ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ।
ਇੰਫਰਾਸਟਰੱਕਚਰ ਕੋਡ ਪਲੰਬਿੰਗ ਹੈ: ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ, HTTP ਸਰਵਰ, ਮੈਸੇਜ ਕਿਊਜ਼, ਡਿਪਲੌਇਮੈਂਟ ਕਨਫਿਗ, ਲੌਗਿੰਗ ਪਾਈਪਲਾਈਨ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ। ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹੋ ਜਗ੍ਹਾ ਨਹੀਂ ਹੁੰਦੀ ਜਿੱਥੇ ਤੁਸੀਂ ਐਪ ਦੇ ਕੋਰ ਨਿਯਮ ਕੋਡ ਕਰਦੇ ਹੋ।
ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਡ ਕੰਮ ਨੂੰ ਵਾਜਬ ਸਮਾਂ ਅਤੇ ਸਰੋਤਾਂ (CPU, ਮੈਮੋਰੀ, ਨੈੱਟਵਰਕ ਕਾਲ, ਡੇਟਾਬੇਸ ਕ੍ਵੈਰੀ) ਵਿੱਚ ਕਰਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਵਧੇਰੇ I/O (ਬਹੁਤ ਸਾਰੀਆਂ ਕਵੈਰੀਆਂ, ਦੁਹਰਾਈ ਗਈ API ਕਾਲਾਂ) ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਨਾਂ ਕਿ ਸست ਲੂਪਾਂ ਤੋਂ।
ਪੜ੍ਹਨਯੋਗਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਕ ਟੀਮਮੇਟ ਇਹ ਸਹੀ ਢੰਗ ਨਾਲ ਸਮਝ ਸਕੇ ਕਿ ਕੋਡ ਕੀ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਉਂ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਬਦਲਣਾ ਹੈ—ਬਿਨਾਂ ਘੰਟਿਆਂ ਦਿਮਾਗ ਵਿੱਚ ਡੀਬੱਗ ਕਰਨ ਦੇ।
ਸਾਦਗੀ ਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਹਿਲਦੇ-ਡੁੱਲਦੇ ਹਿੱਸੇ: ਘੱਟ abstractions, ਘੱਟ ਖਾਸ ਕੇਸ ਅਤੇ ਘੱਟ ਲੁੱਕੇ ਪ੍ਰਭਾਵ। ਸਧਾਰਣ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਟੈਸਟ ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤਬਦੀਲੀਆਂ ਕਰਨ ਤੇ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਟੀਚਾ ਵਧਾਉਣ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਹੋਰ ਟੀਚਿਆਂ 'ਤੇ ਦਬਾਅ ਪੈਂਦਾ ਹੈ।
ਕੈਸ਼ਿੰਗ ਚੀਜ਼ਾਂ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੀ ਹੈ ਪਰ invalidation ਨਿਯਮ ਲਿਆਉਣਦੀ ਹੈ। ਭਾਰੀ abstraction duplication ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ ਪਰ ਫਲੋ ਨੂੰ ਸਮਝਣਾ ਔਖਾ ਕਰ ਸਕਦਾ ਹੈ। ਮਾਈਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਰਨਟਾਈਮ ਘਟਾ ਸਕਦੀਆਂ ਹਨ ਪਰ ਇਰਾਦਾ ਅਪੂਰਣ ਰਹਿ ਸਕਦਾ ਹੈ।
AI ਵੀ "ਜਰੂਰੀ ਤੋਂ ਜ਼ਿਆਦਾ ਹੱਲ" ਦੇ ਸਕਦਾ ਹੈ: ਇਹ ਜਨਰਲਾਈਜ਼ਡ ਪੈਟਰਨ (factories, strategy objects, ਵਿਸਤ੍ਰਿਤ helpers) ਸੁਝਾ ਸਕਦਾ ਹੈ ਜਦਕਿ ਸਿੱਧਾ ਫੰਕਸ਼ਨ ਸਪਸ਼ਟ ਹੋਵੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ "ਚੰਗਾ ਕਾਫ਼ੀ" ਇਹ ਹੁੰਦਾ ਹੈ:
ਸੰਤੁਲਨ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਕੋਡ ਡਿਪਲੌਇ ਕਰਨਾ ਹੁੰਦਾ ਹੈ ਜੋ ਰੱਖਣਾ ਆਸਾਨ ਹੋਵੇ, ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਜਟਿਲਤਾ ਲਿਆਉਣਾ ਜਦੋਂ ਮਾਪ (ਜਾਂ ਅਸਲ ਘਟਨਾ) ਇਸ ਦੀ ਲੋੜ ਦਿਖਾਏ।
AI ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਨਹੀਂ "ਫੈਸਲਾ" ਕਰਦਾ; ਇਹ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ ਅਤੇ ਦਿੱਖੇ ਹੋਏ ਪੈਟਰਨ ਦੇ ਆਧਾਰ 'ਤੇ ਅਗਲੇ ਸਭ ਤੋਂ ਸੰਭਾਵਿਤ ਟੋਕਨ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਡ ਦਾ ਆਕਾਰ ਬਹੁਤ ਹੱਦ ਤੱਕ ਤੁਹਾਡੇ ਮੰਗਣ 'ਤੇ ਅਤੇ ਤੁਸੀਂ ਜੋ ਉਦਾਹਰਣ ਦਿੱਤੇ ਹਨ ਉਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ "ਸਭ ਤੋਂ ਤੇਜ਼ ਹੱਲ" ਮੰਗੋਂਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਅਕਸਰ ਵਧੇਰੇ caching, early exits ਅਤੇ ਡੇਟਾ ਸੰਰਚਨਾਵਾਂ ਮਿਲਣਗੀਆਂ ਜੋ ਗਤੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ—ਭਾਵੇਂ ਇਸ ਦਾ ਲਾਭ ਘੱਟ ਹੋਵੇ। ਜੇ ਤੁਸੀਂ "ਸਾਫ਼ ਅਤੇ ਪੜ੍ਹਨਯੋਗ" ਮੰਗੋਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਵਧੇਰੇ ਵੇਰਵੇ ਵਾਲੇ ਨਾਮ, ਛੋਟੇ ਫੰਕਸ਼ਨ ਅਤੇ ਸਪਸ਼ਟ ਕੰਟਰੋਲ ਫਲੋ ਮਿਲੇਗਾ।
ਕਿਸੇ ਉਦਾਹਰਣ ਜਾਂ ਮੌਜੂਦਾ ਕੋਡ ਸਟਾਈਲ ਨੂੰ ਦਿਖਾਉਣਾ ਸ਼ਬਦਾਂ ਤੋਂ ਵੀ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੁੰਦਾ ਹੈ। ਮਾਡਲ ਇਹ ਨਕਲ ਕਰੇਗਾ:
ਕਿਉਂਕਿ AI ਪੈਟਰਨ ਨੂੰ ਜੋੜ ਕੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ "ਚਤੁਰ" ਹੱਲ ਵੱਲ ਵੱਦ ਸਕਦਾ ਹੈ ਜੋ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦੇ ਹਨ ਪਰ ਰੱਖਿਆ ਵਿੱਚ ਮੁਸ਼ਕਲ ਹਨ:
AI ਵੱਖ-ਵੱਖ ਅਸਲੀ ਕੋਡ ਦੇ ਮਿਸ਼ਰਣ ਤੋਂ ਸਿੱਖਦਾ ਹੈ: ਸਾਫ਼ ਲਾਇਬ੍ਰੇਰੀਜ਼, ਜਲਦੀ ਲਿਖਿਆ ਗਿਆ ਐਪ ਕੋਡ, ਇੰਟਰਵਿਊ ਸੁਟਲੇਸ਼ਨ ਅਤੇ ਫਰੇਮਵਰਕ ਉਦਾਹਰਣ। ਇਸ ਵੱਖ-ਵੱਖਤਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਤੁਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ inconsistent ਸਟ੍ਰਕਚਰ ਦੇਖ ਸਕਦੇ ਹੋ—ਕਈ ਵਾਰੀ idiomatic, ਕਈ ਵਾਰੀ ਜ਼ਿਆਦਾ abstract, ਕਈ ਵਾਰੀ ਜ਼ਰੂਰੀ ਤੋਂ verbose।
ਮਾਡਲ ਵਿਕਲਪ ਸجھਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਡੇ ਬਾਂਧਣ (ਟੀਮ ਦੀ ਕੁਸ਼ਲਤਾ, ਕੋਡਬੇਸ ਰਿਵਾਜ, ਪ੍ਰੋਡਕਸ਼ਨ ਟ੍ਰੈਫਿਕ, ਡੇਡਲਾਈਨ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਰੱਖਿਆ ਲਾਗਤ) ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਜਾਣਦਾ। AI ਦੇ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਡਰਾਫਟ ਵਜੋਂ ਲਓ। ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ ਕਿ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਟਰੇਡ-ਆਫ਼ ਚਾਹੀਦਾ ਹੈ—ਅਤੇ ਇਰਾਦਾ ਸਪਸ਼ਟ ਹੋਣ ਤੱਕ ਸਰਲ ਕਰੋ।
ਰੋਜ਼ਾਨਾ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਇੱਕ ਤਿਕੋਣ ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ: ਕਾਰਗੁਜ਼ਾਰੀ, ਪੜ੍ਹਨਯੋਗਤਾ, ਅਤੇ ਸਾਦਗੀ। AI-ਜਨਰੇਟ ਕੋਡ ਅਕਸਰ "ਠੀਕ" ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤਿੰਨੋ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ—ਪਰ ਅਸਲ ਪ੍ਰੋਜੈਕਟ ਤੁਹਾਨੂੰ ਹਰ ਹਿੱਸੇ ਲਈ ਇੱਕ ਮੁੱਖ ਕੋਣ ਚੁਣਨ ਦੀ ਲੋੜ ਪਾ ਸਕਦੇ ਹਨ।
ਇੱਕ ਕਲਾਸਿਕ ਉਦਾਹਰਣ ਕੈਸ਼ਿੰਗ ਵਿਰੁੱਧ ਸਪਸ਼ਟਤਾ ਹੈ। ਕੈਸ਼ ਜੋੜਨ ਨਾਲ ਧੀਰੇ ਰਿਕਵੈਸਟ ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਪ੍ਰਸ਼ਨ ਉਠਦੇ ਹਨ: cache ਕਦੋਂ expire ਹੋਵੇਗਾ? ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ? ਜੇ cache ਨਿਯਮ ਸਪਸ਼ਟ ਨਹੀਂ ਹਨ, ਭਵਿੱਖ ਦੇ ਪਾਠਕ ਇਸਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਗੇ ਜਾਂ "ਠੀਕ" ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ।
ਇੱਕ ਹੋਰ ਤਣਾਅ ਹੈ abstractions ਵਿਰੁੱਧ ਡਾਇਰੈਕਟ ਕੋਡ। AI ਕਦੇ-ਕਦੇ helpers ਨਿਕਾਲ ਸਕਦਾ ਹੈ, generic utilities ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਲੇਅਰਾਂ ("service", "repository", "factory") ਜੋੜ ਕੇ ਸੁਧਾਰ ਲਿਆਉਂਦਾ ਹੈ। ਕਈ ਵਾਰੀ ਇਹ ਪੜ੍ਹਨਯੋਗਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦਾ ਹੈ। ਕਈ ਵਾਰੀ ਇਹ ਅਸਲ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਨੂੰ ਇੰਡੀਰੇਕਸ਼ਨ ਦੇ ਪਿੱਛੇ ਛੁਪਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਧਾਰਣ ਬਦਲਾਅ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੇ ਹਨ।
ਛੋਟੇ-ਛੋਟੇ ਬਦਲਾਅ—array pre-allocation, ਚਤੁਰ ਇਕ-ਲਾਈਨਰ, ਟੈਂਪ ਵੈਰੀਏਬਲ ਤੋਂ ਬਚਨਾ—ਮਿਲੀਸੈਕਿੰਡ ਘਟਾ ਸਕਦੇ ਹਨ ਪਰ ਮਨੁੱਖੀ ਧਿਆਨ ਲਈ ਮਿੰਟਾਂ ਖਰਚ ਕਰਦੇ ਹਨ। ਜੇ ਕੋਡ non-critical path 'ਤੇ ਹੈ ਤਾਂ ਇਹ ਮਾਈਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਨੁਕਸਾਨਦਾਇਕ ਹੁੰਦੇ ਹਨ। ਸਾਫ਼ ਨਾਮਕਰਨ ਅਤੇ ਸਿੱਧਾ ਕੰਟਰੋਲ ਫਲੋ ਜਿੱਤਦਾ ਹੈ।
ਦੂਜੇ ਪਾਸੇ, ਸਭ ਤੋਂ ਸਧਾਰਣ ਤਰੀਕਾ ਲੋਡ 'ਤੇ ਟੁੱਟ ਸਕਦਾ ਹੈ: ਲੂਪ ਵਿੱਚ ਕੁਐਰੀ ਕਰਨਾ, ਇੱਕੋ ਜੇਹੀ ਚੀਜ਼ ਨੂੰ ਮੁੜ-ਮੁੜ ਕਲਕੂਲੇਟ ਕਰਨਾ, ਜਾਂ ਜ਼ਰੂਰਤ ਤੋਂ ਵੱਧ ਡੇਟਾ ਫੈਚ ਕਰਨਾ। ਜੋ ਕੋਡ 100 ਯੂਜ਼ਰਾਂ ਵਾਸਤੇ ਵਧੀਆ ਲੱਗ ਰਿਹਾ ਸੀ, 100,000 ਲਈ ਮਹਿੰਗਾ ਹੋ ਸਕਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪੜ੍ਹਨਯੋਗ ਵਰਜਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸਹੀ ਹੋ। ਫਿਰ ਹੀ optimize ਕਰੋ—ਕੇਵਲ ਉਦੋਂ ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਸਬੂਤ ਹੋਵੇ (ਲੌਗ, ਪ੍ਰੋਫਾਈਲ, ਅਸਲ ਲੈਟੈਂਸੀ ਮੈਟਰਿਕ) ਕਿ ਕੋਡ ਬੋਤਲਨੇਕ ਹੈ। ਇਹ AI ਨਤੀਜੇ ਨੂੰ ਸਮਝਣਯੋਗ ਰੱਖਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਜਿੱਥੇ ਲੋੜ ਹੈ ਉੱਥੇ ਕਾਰਗੁਜ਼ਾਰੀ ਕਮਾਉਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ।
AI ਆਮ ਤੌਰ 'ਤੇ ਬਿਲਕੁਲ ਉਹੀ ਕਰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਗਦੇ ਹੋ—ਅਤੇ ਜੇ ਤੁਹਾਡਾ ਪ੍ਰਾਂਪਟ vague ਹੈ ("ਇਸਨੂੰ ਤੇਜ਼ ਬਣਾਓ"), ਤਾਂ ਇਹ ਜਟਿਲਤਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਨਹੀਂ ਚਾਹੀਦੀ, ਜਾਂ ਗਲਤ ਚੀਜ਼ ਐਪਟਿਮਾਈਜ਼ ਕਰਦਾ ਹੈ। ਨਤੀਜੇ ਨੂੰ ਸਹੀ ਦਿਸ਼ਾ ਵਿੱਚ ਲੈ ਜਾਣ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਦੱਸੋ ਕਿ "ਚੰਗਾ ਕੀ ਲੱਗਦਾ ਹੈ" ਅਤੇ "ਤੁਸੀਂ ਕੀ ਨਹੀਂ ਚਾਹੁੰਦੇ"।
3–6 ਠੋਸ acceptance criteria ਲਿਖੋ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਚੈੱਕ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਫਿਰ non-goals ਸ਼ਾਮِل ਕਰੋ ਤਾਂ ਜੋ "ਸਹਾਇਕ" ਦਿਸ਼ਾ-ਭਟਕਾਓ ਰੁੱਕ ਸਕੇ।
ਉਦਾਹਰਣ:
ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸਾਦਗੀ ਸੰਦਰਭ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਬੰਧਨ ਦਿਓ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ:
ਹ ਅਨੁਮਾਨ ਵੀ ਜ਼ਿਆਦਾ ਭੰਗ ਨਹੀਂ—ਕਿਸੇ ਵੀ ਅੰਕ ਦਾ ਹੋਣਾ ਬਿਹਤਰ ਹੈ।
ਖੁੱਲ੍ਹੇ ਢੰਗ ਨਾਲ ਦੋ ਵਰਜਨ ਅਣਗੇ:
Write application logic for X.
Acceptance criteria: ...
Non-goals: ...
Constraints: latency ..., data size ..., concurrency ..., memory ...
Deliver:
1) Simple version (most readable)
2) Optimized version (explain the trade-offs)
Also: explain time/space complexity in plain English and note any edge cases.
ਮਾਡਲ ਨੂੰ ਇਹ ਮੰਗੋ ਕਿ ਉਹ ਮੁੱਖ ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਦਾ ਵਜਹੁ ਦਿਓ ("ਇਹ ਡੇਟਾ ਸਰਚਨਾ ਕਿਉਂ", "ਇਹ branching ਕ੍ਰਮ ਕਿਉਂ") ਅਤੇ complexity ਦਾ ਅੰਦਾਜ਼ਾ ਬਿਨਾਂ ਬੇਲਗਾਮ ਟੈਕਨਿਕਲ ਸ਼ਬਦਾਵਲੀ ਦੇ ਦੇਵੇ। ਇਸ ਨਾਲ ਸਮੀਖਿਆ, ਟੈਸਟ ਅਤੇ ਟੀਮ ਨਿਰਣਯ ਕਰਨ ਲਈ ਸੁਲਭ ਹੋ ਜਾਵੇਗਾ।
ਪੜ੍ਹਨਯੋਗ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਸੰਭਵਤ: ਕਿਸੇ ਚਮਕਦਾਰ ਸਿੰਟੈਕਸ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਅਗਲੇ ਵਿਅਕਤੀ (ਅਕਸਰ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ) ਨੂੰ ਇੱਕ ਪਾਸ ਵਿੱਚ ਸਮਝ ਆ ਜਾਵੇ ਇਹ ਬਾਰੇ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ AI ਨੂੰ ਲੌਜਿਕ ਬਣਾਉਣ ਲਈ ਵਰਤਦਿਆਂ, ਕੁਝ ਪੈਟਰਨ ਹਨ ਜੋ ਨਿਰੰਤਰ ਵਧੀਆ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ।
AI ਅਕਸਰ validation, transformation, persistence ਅਤੇ logging ਨੂੰ ਇਕੱਠਾ ਕਰ ਦੇਂਦਾ ਹੈ। ਇਸਨੂੰ ਛੋਟੇ ਯੂਨਿਟਾਂ ਵੱਲ ਧੱਕੋ: ਇੱਕ ਫੰਕਸ਼ਨ input validate ਕਰਨ ਲਈ, ਇੱਕ result ਕੈਲਕੂਲੇਟ ਕਰਨ ਲਈ, ਇੱਕ store ਕਰਨ ਲਈ।
ਇੱਕ ਰੂਲ-ਆਫ-ਥੰਬ: ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਫੰਕਸ਼ਨ ਦਾ ਕੰਮ ਇਕ ਛੋਟੀ ਸੈਂਟెనਸ ਵਿੱਚ ਵੇਰਵਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਬਿਨਾਂ "ਅਤੇ" ਵਰਤੇ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕਰ ਰਿਹਾ ਹੈ।
ਪੜ੍ਹਨਯੋਗ ਲੌਜਿਕ ਗੁਰੂਰੇ ਸ਼ਾਰਤੀ branching ਨੂੰ ਚਮਕਦਾਰ ਕੰਪ੍ਰੈਸ਼ਨ 'ਤੇ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ। ਜੇ ਕੋਈ ਸ਼ਰਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ if ਬਲੌਕ ਦੇ ਰੂਪ ਵਿੱਚ ਲਿਖੋ ਬਜਾਏ nested ternary ਜਾਂ boolean ਚੇਨ ਦੇ।
ਜਦੋਂ ਤੁਸੀਂ AI ਨਤੀਜੇ ਵਿੱਚ ਦੇਖਦੇ ਹੋ "ਇੱਕ ਐਕਸਪ੍ਰੈਸ਼ਨ ਵਿੱਚ ਸਭ ਕੁਝ ਕਰੋ", ਤਾਂ ਮਾਡਲ ਨੂੰ "early returns" ਅਤੇ "guard clauses" ਲਈ ਕਹੋ। ਇਹ ਅਕਸਰ ਨੇਸਟਿੰਗ ਘਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਖੁਸ਼ਹਾਲ ਰਸਤਾ (happy path) ਆਸਾਨੀ ਨਾਲ ਵੇਖਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਮਾਇਣ ਭਰੇ ਨਾਮ generic helper ਪੈਟਰਨਾਂ ਤੋਂ ਬੇਹਤਰ ਹੁੰਦੇ ਹਨ। processData() ਜਾਂ handleThing() ਦੀ ਥਾਂ ਉਹਨਾਂ ਨਾਂਵਾਂ ਨੂੰ ਪਸੰਦ ਕਰੋ ਜੋ ਇਰਾਦਾ ਦਰਸਾਉਂਦੇ ਹਨ:
calculateInvoiceTotal()isPaymentMethodSupported()buildCustomerSummary()ਇਸੇ ਤਰ੍ਹਾਂ over-generic utilities (ਜਿਵੇਂ mapAndFilterAndSort()) ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ: ਉਹ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਨੂੰ ਛੁਪਾ ਸਕਦੇ ਹਨ ਅਤੇ ਡੀਬੱਗਿੰਗ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੇ ਹਨ।
AI verbose ਟਿੱਪਣੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਕੋਡ ਨੂੰ ਦੁਹਰਾ ਦਿੰਦੀਆਂ ਹਨ। ਟਿੱਪਣੀਆਂ ਸਿਰਫ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਨੀਅਤ ਸਪਸ਼ਟ ਨਹੀਂ ਹੁੰਦੀ: ਕਿਉਂ ਕੋਈ ਨਿਯਮ ਹੈ, ਕਿਸ edge case ਤੋਂ ਤੁਸੀਂ ਬਚਾ ਰਹੇ ਹੋ, ਜਾਂ ਕਿਹੜਾ ਅਨਮਾਨ ਸਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਕੋਡ ਸਮਝਣ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਟਿੱਪਣੀਆਂ ਲੱਗਦੀਆਂ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਸੰਕੇਤ ਵਜੋਂ ਲਓ ਕਿ ਸਟ੍ਰਕਚਰ ਸਧਾਰਨ ਕਰੋ ਜਾਂ ਨਾਮ ਇੰਪ੍ਰੂਵ ਕਰੋ—ਟਿੱਪਣੀਆਂ ਵਧਾਉਣਾ ਨਾ।
ਸਾਦਗੀ ਆਮ ਤੌਰ 'ਤੇ "ਘੱਟ ਕੋਡ" ਲਿਖਣ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਉਹ ਕੋਡ ਲਿਖਣਾ ਹੈ ਜੋ ਇਕ ਟੀਮਮੇਟ ਭਰੋਸੇ ਨਾਲ ਅਗਲੇ ਹਫ਼ਤੇ ਬਦਲ ਸਕੇ। AI ਇੱਥੇ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸਧਾਰਨ ਵਿਕਲਪਾਂ ਵੱਲ ਧੱਕੋ।
AI ਅਕਸਰ ਚਤੁਰ ਸਟਰੱਕਚਰਾਂ (maps-of-maps, custom classes, nested generics) ਵੱਲ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ "ਸੁਧਰਾ" ਲੱਗਦਾ ਹੈ। ਵਾਪਸ ਖਿੱਚੋ। ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਲਈ ਆਮ ਅਰੇ/ਲਿਸਟ ਅਤੇ ਸਧਾਰਨ objects ਸਮਝਣ ਵਿੱਚ ਬਹਿਤਰ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਥੋੜ੍ਹਾ ਸਮੱਗਰੀ ਹੈ, ਤਾਂ ਫਿਲਟਰ/ਫਾਈਂਡ ਨਾਲ ਇੱਕ ਸਧਾਰਨ ਲਿਸਟ ਇੱਕ ਇੰਡੈਕਸ ਬਣਾਉਣ ਤੋਂ ਕਈ ਵਾਰੀ ਪੱਛੇ ਰਹੇਗੀ। ਕਿਵੇਂ ਤਾਂ map/dictionary ਉਸ ਵੇਲੇ ਹੀ ਲਿਆਓ ਜਦ ਲੁੱਕਅੱਪ ਵਾਸਤੇ ਦੁਹਰਾਈ ਸਚਮੁਚ ਕੇਂਦਰੀ ਹੋਵੇ।
Abstractions ਸੁੰਦਰ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਜ਼ਿਆਦਾ abstraction ਅਸਲ ਵਿਹਾਰ ਨੂੰ ਲੁਕਾ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ AI ਲਈ ਕੋਡ ਮੰਗ ਰਹੇ ਹੋ, ਤਰਜੀਹ ਦਿਓ "ਇੱਕ ਪੱਧਰ ਦੀ ਇੰਡਾਇਰੈਕਸ਼ਨ" ਸਾਲਿਊਸ਼ਨਾਂ ਨੂੰ: ਇਕ ਛੋਟਾ ਫੰਕਸ਼ਨ, ਸਪਸ਼ਟ ਮਾਡਿਊਲ, ਅਤੇ ਡਾਇਰੈਕਟ ਕਾਲਾਂ।
ਇੱਕ ਮਦਦਗਾਰ ਨਿਯਮ: ਇੱਕ ਸਿੰਗਲ ਯੂਜ਼ ਕੇਸ ਨੂੰ hald ਕਰਨ ਲਈ generic interface, factory ਅਤੇ plugin ਸਿਸਟਮ ਨਾ ਬਣਾਓ। ਦੂਜੇ ਜਾਂ ਤੀਜੇ ਵੈਰੀਅਸ਼ਨ ਦੇਖਣ ਤੋਂ ਬਾਅਦ ਹੀ ਰੀਫੈਕਟਰ ਕਰੋ।
ਇੰਹੈਰੀਟੈਂਸ ਟ੍ਰੀਜ਼ ਦਾ ਸਵਾਲ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੇ ਹਨ: "ਇਹ ਵਿਹਾਰ ਵਾਸਤੇ ਜ਼ਿੰਮੇਵਾਰ ਕਿੱਥੇ ਹੈ?". ਕੰਪੋਜ਼ੀਸ਼ਨ dependencies ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖਦਾ ਹੈ। class A extends B extends C ਦੀ ਥਾਂ ਛੋਟੇ ਕੰਪੋਨੈਂਟ ਜੋ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਜੋੜੇ ਜਾ ਸਕਦੇ ਹਨ, ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
AI ਪ੍ਰਾਂਪਟਾਂ ਵਿੱਚ ਤੁਸੀਂ ਕਹਿ ਸਕਦੇ ਹੋ: "ਇੰਹੈਰੀਟੈਂਸ ਤੋਂ ਬਚੋ ਜਦ ਤਕ ਇਕ स्थਿਰ shared contract ਨਹੀ ਹੈ; ਸਹਾਇਕ/ਸੇਵਾ ਨੂੰ parameter ਵਜੋਂ ਪਾਸ ਕਰੋ।"
AI ਉਹ ਪੈਟਰਨ ਸੁਝਾ ਸਕਦਾ ਹੈ ਜੋ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਠੀਕ ਹਨ ਪਰ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਲਈ ਸਾਂਸਕ੍ਰਿਤਿਕ ਤੌਰ 'ਤੇ ਅਣਜਾਣ ਹੋ ਸਕਦੇ ਹਨ। ਜਾਣ-ਪਛਾਣ ਇਕ ਫੀਚਰ ਹੈ। ਹੱਲਾਂ ਨੂੰ ਆਪਣੇ stack ਅਤੇ ਰਿਵਾਜਾਂ (ਨਾਮਕਰਨ, ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਏਰਰ ਹੈਂਡਲਿੰਗ) ਨਾਲ ਮੇਲ ਖਾਂਉਣ ਲਿਖੋ ਤਾਂ ਕਿ ਨਤੀਜਾ ਸਮੀਖਿਆ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਬੈਠ ਜਾਵੇ।
ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਕੰਮ ਉਸ ਵੇਲੇ ਘਟ ਜਾਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਗਲਤ ਚੀਜ਼ optimize ਕਰੋ। ਸਭ ਤੋਂ "ਤੇਜ਼" ਕੋਡ ਅਕਸਰ ਸਿਰਫ਼ ਠੀਕ algorithm ਨੂੰ ਅਸਲੀ ਸਮੱਸਿਆ 'ਤੇ ਲਾਗੂ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਲੂਪਾਂ ਜਾਂ ਚਤੁਰ ਇਕ-ਲਾਈਨਰ ਨੂੰ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇਕ ਸਮਝਦਾਰ ਰਵੱਈਆ ਵਰਤ ਰਹੇ ਹੋ: hash map ਵਜੋਂ ਦੁਹਰਾਏ ਲੀਨੇਅਰ ਖੋਜਾਂ, membership checks ਲਈ set, ਇਕ ਗੁਜ਼ਾਰ ਬਜਾਏ ਕਈ ਸਕੈਨ। ਜਦੋਂ AI ਦੀ ਮਦਦ ਮੰਗੀ ਜਾਵੇ, constraints (ਇਨਪੁੱਟ ਆਕਾਰ, ਕੀ ਡੇਟਾ sorted ਹੈ, "ਤੇਜ਼ ਕਾਫੀ" ਕਿਆ ਹੈ) ਸਪਸ਼ਟ ਕਰੋ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ complexity ਗਲਤ ਹੈ (ਉਦਾਹਰਣ ਵਜੋਂ O(n²) ਵੱਡੀ ਲਿਸਟਾਂ 'ਤੇ), ਤਾਂ ਕੋਈ ਵੀ ਮਾਈਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੁਹਾਨੂੰ ਬਚਾ ਨਹੀਂ ਸਕਦੀ।
ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ। ਬੁਨਿਆਦੀ ਪ੍ਰੋਫਾਈਲਿੰਗ, ਹਲਕੇ-ਫੁਲਕੇ ਬੈਂਚਮਾਰਕ ਅਤੇ—ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ—ਅਸਲੀ ਡੇਟਾ ਵਾਲੀ ਵੌਲਿਊਮ ਵਰਤੋ। AI-ਜਨਰੇਟ ਕੋਡ ਦਿਖਣ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਮਹਿੰਗਾ ਕੰਮ (ਦੁਹਰਾਈ ਗਈ parsing ਜਾਂ ਵਾਧੂ ਕਵੈਰੀਆਂ) ਛੁਪਾ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕੀ ਮਾਪਿਆ ਅਤੇ ਕਿਉਂ ਇਹ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ, ਇਹ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਇੱਕ ਛੋਟੀ ਟਿੱਪਣੀ ਜਿਵੇਂ "50k ਆਈਟਮ ਲਈ optimize ਕੀਤਾ ਗਿਆ; ਪਿਛਲੇ ਵਰਜਨ ਨੇ ~2s 'ਤੇ ਟਾਇਮਆਊਟ ਕੀਤਾ" ਅਗਲੇ ਵਿਅਕਤੀ ਲਈ ਸਹਾਇਕ ਹੋਵੇਗੀ।
ਬਹੁਤ ਸਾਰਾ ਕੋਡ ਬੋਰਿੰਗ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ। ਕਾਰਗੁਜ਼ਾਰੀ ਮਹੱਤਵਪੂਰਨ ਥਾਂਵਾਂ ਤੇ ਧਿਆਨ ਰੱਖੋ: ਜ਼ਰਦੀ ਲੂਪ, ਸੀਰਿਆਂਲਾਇਜ਼ੇਸ਼ਨ, ਡੇਟਾਬੇਸ ਕਾਲ, ਨੈੱਟਵਰਕ ਸੀਮਾ। ਹੋਰ ਥਾਂਵਾਂ ਤੇ ਸਾਫ਼ਤਾ ਕੋਲ ਜਾਓ, ਭਾਵੇਂ ਇਹ ਕੁਝ ਮਿਲੀਸੈਕਿੰਡ ਸਲੋ ਹੋਵੇ।
ਇਹ ਤਕਨੀਕਾਂ ਵੱਡੇ ਲਾਭ ਦੇ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਮਨ-ਭਾਰ ਦਾ ਕੰਮ ਵੀ ਜੋੜਦੀਆਂ ਹਨ।
ਜੇ AI ਇਹਨਾਂ ਤਕਨੀਕਾਂ ਦੀ ਸਿਫਾਰਸ਼ ਕਰੇ, ਤਾਂ ਇਸ ਨੂੰ "ਕਿਉਂ", trade-offs ਅਤੇ ਕਦੋਂ ਅਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਹਟਾਈ ਜਾ ਸਕਦੀ ਹੈ ਇਹ ਵੀ ਦੱਸਣ ਲਈ ਕਹੋ।
AI ਤੇਜ਼ੀ ਨਾਲ "ਤੱਤੋਂ" ਲੌਜਿਕ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਸੁਕੜੇ ਬੱਗ ਜਾਂ ਸਮਝ ਦੀ ਕਮੀ ਮਹਿਸੂਸ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਟੈਸਟ ਉਹ ਬਫਰ ਹਨ ਜੋ ਇੱਕ ਮਦਦਗਾਰ ਡਰਾਫਟ ਅਤੇ ਭਰੋਸੇਯੋਗ ਕੋਡ ਦੇ ਵਿਚਕਾਰ ਖੜੇ ਹੁੰਦੇ ਹਨ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕਾਰਗੁਜ਼ਾਰੀ ਲਈ ਬਦਲਾਅ ਜਾਂ ਸਰਲਤਾ ਲਈ ਰੀਫੈਕਟਰ ਕਰੋਗੇ।
ਜਦੋਂ ਤੁਸੀਂ implementation ਮੰਗਦੇ ਹੋ, ਤਦੋਂ tests ਵੀ ਮੰਗੋ। ਇਸ ਨਾਲ assumptions ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਮਾਡਲ ਨੂੰ ਵਿਵਹਾਰ ਸਾਬਤ ਕਰਨ ਲਈ ਹੱਲ ਲਿਖਣੇ ਪੈਂਦੇ ਹਨ।
ਵਰਕੇ ਸੋਚ:
AI ਆਮ ਤੌਰ 'ਤੇ "happy path" ਪਹਿਲਾਂ ਲਿਖਦਾ ਹੈ। ਆਪਣੀ ਟੈਸਟ ਯੋਜਨਾ ਵਿੱਚ edge cases ਸਪਸ਼ਟ ਕਰੋ ਤਾਂ ਜੋ ਭਵਿੱਖ 'ਚ ਕੋਈ ਯਾਦਾਂ 'ਤੇ ਨਿਰਭਰ ਨਾ ਹੋਵੇ। ਆਮ case ਹਨ:
null / undefinedਕਾਰੋਬਾਰੀ ਲੌਜਿਕ ਵਿੱਚ ਅਕਸਰ ਬਹੁਤ ਸਾਰੀਆਂ ਛੋਟੀ-ਛੋਟੀ ਵੈਰੀਏਸ਼ਨ ਹੁੰਦੀਆਂ ਹਨ ("ਜੇ ਯੂਜ਼ਰ X ਹੈ ਅਤੇ ਆਰਡਰ Y ਹੈ, ਤਾਂ Z ਕਰੋ"). Table-driven tests ਇਸ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖਦੀਆਂ ਹਨ।
ਜੇ ਨਿਯਮਾਂ ਵਿੱਚ ਕੁਝ ਅਨਿਵਾਰੀਆਂ ਹਨ ("ਟੋਟਲ ਨੈਗੇਟਿਵ ਨਹੀਂ ਹੋ ਸਕਦਾ", "ਡਿਸਕਾਊਂਟ ਕਦੇ ਵੀ subtotal ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋਵੇ"), ਤਾਂ property-based tests ਹੋਰ ਕੇਸ ਐਕਸਪਲੋਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਇਕ ਵਾਰ ਤੁਸੀਂ ਚੰਗੀ coverage ਹਾਸਲ ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਨਿਰਭੈ ਹੋ ਕੇ:
ਪਾਸ ਹੋ ਰਹੇ ਟੈਸਟਾਂ ਨੂੰ ਆਪਣਾ contract ਮੰਨੋ: ਜੇ ਤੁਸੀਂ ਪੜ੍ਹਨਯੋਗਤਾ ਜਾਂ ਗਤੀ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੇ ਹੋ ਅਤੇ ਟੈਸਟਾਂ ਹਾਲੇ ਵੀ ਪਾਸ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਸਹੀ ਰਿਹਾ।
AI "ਸਮਝਦਾਰ" ਕੋਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਸਾਫ਼ ਲੱਗਦਾ ਹੈ। ਚੰਗੀ ਸਮੀਖਿਆ ਇਹ ਦੇਖਦੀ ਹੈ ਕਿ ਇਹ ਤੁਹਾਡੇ ਐਪ ਲਈ ਸਹੀ ਲਾਜ਼ਮੀ ਤਰ੍ਹਾਂ ਹੈ—ਨਾ ਕਿ ਸਿਰਫ ਇਹ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਲਿਖ ਸਕਦੇ ਸੀ।
ਸਮੀਖਿਆ ਦੇ ਪਹਿਲੇ ਪਾਸ ਵਜੋਂ ਇਹ ਤੇਜ਼ ਜाँच ਵਰਤੋ ਜੋ ਅਗਲੇ ਵਿਵਾਦ ਤੋਂ ਪਹਿਲਾਂ ਕੀਤੀ ਜਾ ਸਕੇ:
isEligibleForDiscount vs flag)?AI ਅਕਸਰ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਛੁਪਾ ਕੇ ਦਰਸਾਂਦਾ ਹੈ:
ਸੰਭਾਵਨਾ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ; ensure output ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ formatting ਅਤੇ conventions (lint rules, file structure, error types) ਦੇ ਨਾਲ ਮੇਲ ਖਾਂਉਂਦਾ ਹੈ। ਜੇ ਨਹੀਂ, ਤੁਰੰਤ ਠੀਕ ਕਰੋ—ਸਟਾਈਲ inconsistent ਹੋਣ ਨਾਲ ਭਵਿੱਖ ਦੀ ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਸਮੀਖਿਆ ਮੁਸ਼ਕਲ ਹੁੰਦੀ ਹੈ।
AI-ਜਨਰੇਟ ਲੌਜਿਕ ਰੱਖੋ ਜੇ ਇਹ ਸਿੱਧਾ, ਟੈਸਟਯੋਗ ਅਤੇ ਟੀਮ conventions ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ।
ਬਦਲੋ ਜਦ ਤੁਸੀਂ ਵੇਖੋ:
ਜੇ ਤੁਸੀਂ ਇਹ ਸਮੀਖਿਆ ਰੋਜ਼ਾਨਾ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਉਹਨਾਂ ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਪਛਾਣਨਾ ਸਿਖ ਲਵੋਗੇ ਜੋ reviewable ਕੋਡ ਦੇਂਦੇ ਹਨ—ਫਿਰ ਅਗਲੀ ਬਾਰ ਪ੍ਰਾਂਪਟ ਨੂੰ ਪਹਿਲਾਂ ਤਿਉਂਾਰ ਕਰੋ।
ਜਦੋਂ AI ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇਹ ਅਕਸਰ "ਹੈਪੀ ਪਾਥ" ਸਪਸ਼ਟਤਾ ਲਈ optimize ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਉਹ ਖੇਤਰ ਰਹਿ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਰਹਿੰਦੀ ਹੈ: edge cases, failure modes ਅਤੇ ਆਸਾਨ defaults ਜੋ ਸੁਵਿਧਾਜਨਕ ਪਰ ਅਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦੇ ਹਨ।
ਪ੍ਰਾਂਪਟਾਂ ਨੂੰ ਪਬਲਿਕ ਰੀਪੋ ਵਿੱਚ ਕੋਡ ਟਿੱਪਣੀ ਵਾਂਗ ਸਾਂਭੋ। ਕਦੇ ਵੀ API keys, production tokens, ਗਾਹਕ ਡੇਟਾ ਜਾਂ ਅੰਦਰੂਨੀ URLs ਪੇਸਟ ਨਾ ਕਰੋ। ਨਤੀਜੇ ਨੂੰ ਵੀ ਚੈੱਕ ਕਰੋ: AI ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਪੂਰੀ requests, headers ਜਾਂ exception objects ਲੌਗ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰੇ ਜੋ ਸਾਇਡ-ਚੀਜ਼ਾਂ ਵਿੱਚ secrets ਹੋ ਸਕਦੇ ਹਨ।
ਸਧਾਰਨ ਨਿਯਮ: identifiers ਲੌਗ ਕਰੋ, payloads ਨਹੀਂ। ਜੇ debug ਲਈ payload ਲੌਗ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਤਾਂ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ redact ਕਰੋ ਅਤੇ ਇਸਨੂੰ environment flag ਦੇ ਪਿੱਛੇ ਰੱਖੋ।
AI-ਲਿਖਿਆ ਕੋਡ ਕਦੇ-ਕਦੇ ਇਨਪੁੱਟ ਨੂੰ ਸਹੀ ਮੰਨ ਲੈਂਦਾ ਹੈ। ਬਾਰਡਰਾਂ (HTTP handlers, message consumers, CLI) 'ਤੇ validation explicit ਰੱਖੋ। ਅਣਉਮੀਦ ਇਨਪੁੱਟ ਨੂੰ consistent errors ਵਿੱਚ ਬਦਲੋ (ਉਦਾਹਰਣ ਲਈ 400 vs 500), ਅਤੇ retries ਨੂੰ ਸੇਫ ਬਣਾਉਣ ਲਈ idempotent operations ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਭਰੋਸੇਯੋਗਤਾ ਸਮੇਂ ਦਾ ਵੀ ਮਾਮਲਾ ਹੈ: timeouts ਸ਼ਾਮਿਲ ਕਰੋ, nulls ਹੈਂਡਲ ਕਰੋ, ਅਤੇ vague strings ਦੀ ਥਾਂ structured errors ਵਾਪਸ ਕਰੋ।
ਜਨਰੇਟ ਕੀਤਾ ਗਿਆ ਕੋਡ ਸੁਵਿਧਾ ਲਈ shortcuts ਸ਼ਾਮਿਲ ਕਰ ਸਕਦਾ ਹੈ:
least-privilege configurations ਮੰਗੋ ਅਤੇ authorization checks ਨੂੰ ਉਹਨਾਂ ਡੇਟਾ ਐਕਸੈਸ ਦੇ ਨੇੜੇ ਰੱਖੋ ਜਿਨ੍ਹਾਂ ਦੀ ਰਕਸ਼ਾ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪ੍ਰਾਂਪਟ ਪੈਟਰਨ: "ਆਪਣੀਆਂ ਸੁਰੱਖਿਆ assumptions, threat model, ਅਤੇ dependencies fail ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਇਹ ਸਮਝਾਓ।" ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ AI ਇਹਨਾਂ ਗੱਲਾਂ ਨੂੰ ਉਲਲੇਖ ਕਰੇ: "ਇਸ endpoint ਲਈ authenticated users ਲਾਜ਼ਮੀ ਹਨ", "ਟੋਕਨ rotate ਕੀਤੇ ਜਾਂਦੇ ਹਨ", "DB timeouts 'ਤੇ 503 ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ" ਆਦਿ।
ਜੇ ਇਹ assumptions ਹਕੀਕਤ ਨਾਲ ਮਿਲਦੀਆਂ ਨਹੀਂ, ਤਾਂ ਕੋਡ ਗਲਤ ਹੈ—ਭਾਵੇਂ ਇਹ ਤੇਜ਼ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਲੱਗੇ।
AI ਤੇਜ਼ੀ ਨਾਲ ਪੜ੍ਹਨਯੋਗ ਲੌਜਿਕ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਰੱਖਿਆਯੋਗਤਾ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਮਹੀਨਿਆਂ ਵਿੱਚ ਕਮਾਉਂਦੇ ਹੋ: ਬਦਲਦੀਆਂ ਜ਼ਰੂਰਤਾਂ, ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ ਅਤੇ ਅਣਸਮਝੇ ਤੌਰ 'ਤੇ ਵਧਦੀ ਟ੍ਰੈਫਿਕ। ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ ਆਪ ਨੂੰ ਹਮੇਸ਼ਾ "ਪੂਰਾ ਬੇਦਕਲ" ਕਰਨਾ ਹੈ—ਲਕੜੀ ਇਹ ਹੈ ਕਿ ਕੋਡ ਸਮਝਦਾਰ ਰਹੇ ਜਦ ਤੱਕ ਇਹ ਅਸਲ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਰੀਫੈਕਟਰ ਉਸ ਵੇਲੇ ਵਾਜਬ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਮਾਪਯੋਗ ਲਾਗਤ ਦੱਸ ਸਕੋ:
ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ ਹੋ ਰਿਹਾ, ਤਾਂ ਸਿਰਫ਼ "ਸਫਾਈ" ਲਈ ਸੁਧਾਰ ਤੋਂ ਬਚੋ। ਕੁਝ duplicates abstractions ਲਿਆਉਣ ਤੋਂ ਸਸਤੇ ਹੋ ਸਕਦੇ ਹਨ।
AI-ਲਿਖਿਆ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਤਰਕਸੰਗਤ ਲੱਗਦਾ ਹੈ, ਪਰ ਭਵਿੱਖ ਦੇ ਤੁਹਾਨੂੰ context ਦੀ ਲੋੜ ਪਏਗੀ। ਮੁੱਖ ਫੈਸਲਿਆਂ ਦੀਆਂ ਛੋਟੀਆਂ ਨੋਟਸ ਜੋੜੋ:
ਇਹ ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖੋ (docstring, README, ਛੋਟੀ /docs ਨੋਟ) ਅਤੇ ਜੇ ਹੋ ਸਕੇ ਟਿਕਟਾਂ ਨੂੰ ਲਿੰਕ ਕਰੋ।
ਕੁਝ ਮੁੱਖ ਰਾਹਾਂ ਲਈ ਇਕ ਛੋਟਾ ਡਾਇਗ੍ਰਾਮ ਗਲਤਫਹਿਮੀਆਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਅਚਾਨਕ ਰੀਰਾਈਟਸ ਘਟਾਉਂਦਾ ਹੈ:
Request → Validation → Rules/Policy → Storage → Response
↘ Audit/Events ↗
ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਮੈਨੇਜ ਕਰਨ ਯੋਗ ਹਨ ਅਤੇ ਸਮੀਖਿਆਕਾਰਾਂ ਨੂੰ ਵਿਖਾਉਂਦੇ ਹਨ ਕਿ ਨਵਾਂ ਲੌਜਿਕ ਕਿੱਥੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਆਪਰੇਸ਼ਨਲ ਉਮੀਦਾਂ, ਸਕੇਲ ਥ੍ਰੈਸ਼ਹੋਲਡ, ਅਤੇ ਅੱਗਲਾ ਕਦਮ ਕੀਹ ਹੋਵੇਗਾ ਇਹ ਲਿਖੋ। ਉਦਾਹਰਣ: "ਇੱਕ ਇੰਸਟੈਂਸ 'ਤੇ ~50 requests/sec ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ; bottleneck rule evaluation ਹੈ; ਅਗਲਾ ਕਦਮ caching ਹੋਵੇਗਾ।"
ਇਸ ਨਾਲ ਰੀਫੈਕਟਰਿੰਗ ਵਰਤੋਂ ਦੇ ਅਨੁਸਾਰ ਯੋਜਿਤ ਹੁੰਦੀ ਹੈ ਨਾ ਕਿ ਅਨੁਮਾਨੀ। ਇਹ premature optimization ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਸਾਦਗੀ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ।
ਚੰਗਾ ਵਰਕਫਲੋ AI ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਪਹਿਲਾ ਡਰਾਫਟ ਮੰਨਦਾ ਹੈ, ਨਾਂ ਕਿ ਇੱਕ ਤਿਆਰ ਫੀਚਰ। ਲਕੜੀ ਇਹ ਹੈ: ਸਹੀ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਕੁਝ ਜਲਦੀ ਪ੍ਰਦਾਨ ਕਰੋ, ਫਿਰ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ ਠੀਕ ਕਰੋ।
ਇਹ ਓਸ ਸਮੇਂ ਜਿੱਥੇ ਟੂਲ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai (chat-to-app with planning mode, source export, and snapshots/rollback), ਤਾਂ ਇਹੀ ਸਿਧਾਂਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਦਾ ਸਧਾਰਨ, ਪੜ੍ਹਨਯੋਗ ਪਹਿਲਾ ਵਰਜਨ ਪ੍ਰਾਪਤ ਕਰੋ, ਫਿਰ ਛੋਟੇ, ਸਮੀਖਿਆਯੋਗ ਬਦਲਾਅ ਕਰੋ। ਪਲੇਟਫਾਰਮ ਡਰਾਫਟਿੰਗ ਅਤੇ ਸਕੈਫੋਲਡਿੰਗ ਗਤੀ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਟੀਮ ਹਮੇਸ਼ਾਂ ਟਰੇਡ-ਆਫ਼ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਰੱਖਦੀ ਹੈ।
ਕੁਝ ਡਿਫੌਲਟ ਲਿਖੋ ਤਾਂ ਜੋ ਹਰ AI-ਪੈਦਾ ਕੀਤੀ ਬਦਲੀ ਇੱਕੋ ਉਮੀਦਾਂ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ:
invoiceTotal), single-letter variables ਨਾ ਵਰਤੋ ਸਿਵਾਏ ਛੋਟੇ ਲੂਪਾਂ ਦੇ।Feature ਅਤੇ constraints ਵੇਰਵਾ ਕਰੋ (inputs, outputs, invariants, error cases).
AI ਤੋਂ ਸਧਾਰਨ implementation ਅਤੇ tests ਮੰਗੋ।
ਸਮੀਖਿਆ ਸਪਸ਼ਟਤਾ ਲਈ ਕਰੋ, ਚਤੁਰਾਈ ਲਈ ਨਹੀਂ। ਜੇ ਤੁਸੀਂ ਇਕ-ਦੋ ਵਾਕਾਂ ਵਿੱਚ flow ਨਹੀਂ ਸਪਸ਼ਟ ਕਰ ਸਕਦੇ ਤਾਂ ਇਹ ਸ਼ਾਇਦ ਬਹੁਤ ਜਟਿਲ ਹੈ।
ਕੇਵਲ ਸਮੂਹਾਤਮਕ ਹਿੱਸਿਆਂ ਦੀ ਮਾਪ ਲਓ। ਛੋਟਾ benchmark ਜਾਂ suspected bottleneck 'ਤੇ ਹਲਕਾ timing ਚਲਾਓ।
ਵੀਸ਼ੇਸ਼ ਪ੍ਰਾਂਪਟਾਂ ਨਾਲ refine ਕਰੋ। "ਇਸਨੂੰ ਤੇਜ਼ ਕਰੋ" ਦੀ ਥਾਂ ਕਹੋ "ਇਸ ਲੂਪ ਵਿੱਚ allocations ਘਟਾਓ ਜਦੋਂ ਕਿ ਫੰਕਸ਼ਨ ਸਟ੍ਰਕਚਰ ਬਦਲਿਆ ਨਹੀਂ ਜਾਣਾ।"
You are generating application logic for our codebase.
Feature:
- Goal:
- Inputs:
- Outputs:
- Business rules / invariants:
- Error cases:
- Expected scale (typical and worst-case):
Constraints:
- Keep functions small and readable; avoid deep nesting.
- Naming: use domain terms; no abbreviations.
- Performance: prioritize clarity; optimize only if you can justify with a measurable reason.
- Tests: include unit tests for happy path + edge cases.
Deliverables:
1) Implementation code
2) Tests
3) Brief explanation of trade-offs and any performance notes
ਜੇ ਤੁਸੀਂ ਇਹ ਲੂਪ—generate, review, measure, refine—ਬਣਾਈ ਰੱਖੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਐਸਾ ਕੋਡ ਪ੍ਰਾਪਤ ਕਰੋਂਗੇ ਜੋ ਅਜੇ ਵੀ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀਆਂ ਉਮੀਦਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਤੋਂ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਸਹੀ ਵਰਜਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਹੀ ਅਪਟਿਮਾਈਜ਼ ਕਰੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਸਬੂਤ ਹੋਵੇ (ਲੌਗ, ਪ੍ਰੋਫਾਈਲਿੰਗ, ਲੈਟੈਂਸੀ ਮੈਟਰਿਕਸ) ਕਿ ਇਹ ਬੋਤਲਨੇਕ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡੇ ਫਾਇਦੇ ਆਮ ਤੌਰ 'ਤੇ I/O ਘਟਾਉਣ ਨਾਲ ਮਿਲਦੇ ਹਨ (ਘੱਟ DB/API ਰਾਊਂਡ ਟ੍ਰਿਪ) ਨਾ ਕਿ ਲੂਪਾਂ ਦੀ ਮਾਈਕ੍ਰੋ-ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਨਾਲ।
ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਕਾਰੋਬਾਰੀ ਨਿਯਮਾਂ ਅਤੇ ਵਰਕਫਲੋਜ਼ (ਉਪਯੋਗਤਾ ਯੋਗਤਾ, ਕੀਮਤ ਨਿਰਣਾ, ਸਟੇਟ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ) ਨੂੰ ਕੋਡ ਕਰਦੀ ਹੈ ਅਤੇ ਅਕਸਰ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ। ਇੰਫਰਾਸਟਰੱਕਚਰ ਕੋਡ ਪਲੰਬਿੰਗ ਹੈ (DB ਕਨੈਕਸ਼ਨ, ਸਰਵਰ, ਕਿਊਜ਼, ਲੌਗਿੰਗ). ਟਰੇਡ-ਆਫ਼ ਵੱਖ-ਵੱਖ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਲੌਜਿਕ ਬਦਲਾਅ ਅਤੇ ਸਪਸ਼ਟਤਾ ਲਈ ਅਨੁਕੂਲ ਹੁੰਦੀ ਹੈ, ਜਦਕਿ ਇੰਫਰਾਸਟਰੱਕਚਰ ਨੂੰ ਜ਼ਿਆਦਾ ਸਥਿਰ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਕਿਉਂਕਿ ਇੱਕ ਉਦਯੋਗ ਵਿੱਚ ਇਕ هدف ਹੋਰਾਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ:
ਸੰਤੁਲਨ ਦਾ ਮਤਲਬ ਹੈ ਇਸ ਗੱਲ ਨੂੰ ਚੁਣਨਾ ਕਿ ਕਿਸ ਮੋਢੇ ਲਈ ਕਿਹੜੀ ਲਕੜੀ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਮਾਡਲ ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟ ਅਤੇ ਉਦਾਹਰਣਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਭਾਵਿਤ ਕੋਡ ਪੈਟਰਨਾਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰਦਾ ਹੈ—ਇਹ ਇੱਕ ਇੰਜੀਨੀਅਰ ਵਾਂਗ ਸੋਚ ਕੇ ਫੈਸਲਾ ਨਹੀਂ ਲੈਂਦਾ। ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ালী ਸਿਗਨਲ ਹਨ:
ਜੇ ਤੁਸੀਂ vague ਰਹੋਗੇ, ਤਾਂ ਇਹ ਬਿਨਾਂ ਲੋੜ ਦੇ ਜਟਿਲ ਪੈਟਰਨ ਬਣਾਉਣ ਲੱਗੇਗਾ।
ਧਿਆਨ ਰੱਖੋ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਪੜ੍ਹਨ ਦੇ ਯੋਗ ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਵਾਰੀ ਪੜ੍ਹ ਕੇ ਸਮਝਾ ਨਾ ਸਕਦੇ, ਤਾਂ ਮਾਡਲ ਨੂੰ ਸਰਲ ਕਰਨ ਲਈ ਕਹੋ।
ਪ੍ਰਮਾਣਤ acceptance criteria, non-goals ਅਤੇ constraints ਦਿਓ। ਉਦਾਹਰਣ:
ਇਸ ਨਾਲ ਮਾਡਲ ਨੂੰ ਉਹ ਕੰਪਲੇਕਸਿਟੀ ਬਣਾਉਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਨਹੀਂ।
ਦੋ ਵਰਜਨ ਮੰਗੋ:
ਇਸ ਦੇ ਨਾਲ plain-English complexity explanation ਅਤੇ edge cases ਦੀ ਲਿਸਟ ਵੀ ਮੰਗੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆ ਤੇਜ਼ੀ ਨਾਲ ਹੋ ਸਕੇ।
ਹੇਠਾਂ ਉਹ ਪੈਟਰਨ ਹਨ ਜੋ ਇਨਪੁਟ ਨੌਕਰੀ ਨੂੰ ਸਮਝਣਯੋਗ ਬਣਾਊਂਦੇ ਹਨ:
isEligibleForDiscount)ਜੇ ਇੱਕ ਹੈਲਪਰ ਨਾਮ ਬਹੁਤ ਸਰਲ-ਸਧਾਰਨ ਲੱਗੇ, ਤਾਂ ਇਹ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਛੁਪਾ ਰਿਹਾ ਹੋ ਸਕਦਾ ਹੈ।
ਵੱਡੇ ਨਫ਼ੇ ਵਰਨਾਂ ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਸਮਝਾਉਣਯੋਗ ਰਹਿਣ:
ਜੇ ਤੁਸੀਂ caching/batching/indexing ਜੋੜ ਰਹੇ ਹੋ ਤਾਂ invalidation, batch size ਅਤੇ failure behavior ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਸਮਝ ਆ ਜਾਵੇ ਕਿ ਕਿਉਂ ਇਹ ਕੀਤਾ ਗਇਆ।
ਟੈਸਟਾਂ ਨੂੰ ਹਮੇਸ਼ਾਂ implementation ਦੇ ਨਾਲ ਮੰਗੋ:
ਚੰਗੇ ਟੈਸਟਾਂ ਨਾਲ ਤੁਸੀਂ ਰੀਫੈਕਟਰਿੰਗ ਜਾਂ ਹਾਟ ਪਾਥ ਦਾ ਅਪਟਿਮਾਈਜ਼ੇਸ਼ਨ ਨਿਰਭਯਤਾ ਨਾਲ ਕਰ ਸਕਦੇ ਹੋ।