30 ਅਕਤੂ 2025·8 ਮਿੰਟ
ਕਿਵੇਂ AI-ਨਿਰਮਿਤ ਕੋਡ ਸ਼ੁਰੂਆਤੀ ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਘਟਾਉਂਦਾ ਹੈ
ਦੇਖੋ ਕਿਵੇਂ AI-ਨਿਰਮਿਤ ਕੋਡ ਮੁੱਖ ਲਾਜਿਕ ਨੂੰ ਵੱਖ ਕਰਕੇ, ਪ੍ਰਯੋਗ ਤੇਜ਼ ਕਰਕੇ, ਅਤੇ ਬਾਅਦ ਦੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਕੇ ਸ਼ੁਰੂਆਤੀ ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਘਟਾ ਸਕਦਾ ਹੈ।
ਦੇਖੋ ਕਿਵੇਂ AI-ਨਿਰਮਿਤ ਕੋਡ ਮੁੱਖ ਲਾਜਿਕ ਨੂੰ ਵੱਖ ਕਰਕੇ, ਪ੍ਰਯੋਗ ਤੇਜ਼ ਕਰਕੇ, ਅਤੇ ਬਾਅਦ ਦੀਆਂ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾਕੇ ਸ਼ੁਰੂਆਤੀ ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਘਟਾ ਸਕਦਾ ਹੈ।
ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਉਸ ਵੇਲੇ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਉਤਪਾਦ ਕਿਸੇ ਖਾਸ ਫਰੇਮਵਰਕ (ਜਾਂ ਵੈਂਡਰ ਪлатਫ਼ਾਰਮ) ਨਾਲ ਇੰਨਾ ਜ਼ਿਆਦਾ ਜੁੜ ਜਾਂਦਾ ਹੈ ਕਿ ਬਾਅਦ ਵਿੱਚ ਉਸਨੂੰ ਬਦਲਣਾ ਕੰਪਨੀ ਨੂੰ ਮੁੜ ਲਿਖਣ ਵਰਗਾ ਲੱਗਣ ਲਗਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ “ਅਸੀਂ React ਵਰਤ ਰਹੇ ਹਾਂ” ਜਾਂ “ਅਸੀਂ Django ਚੁਣਿਆ” ਨਾਲ ਸਿਮਟ ਕੇ ਨਹੀਂ ਰਹਿੰਦਾ। ਜਦੋਂ ਫਰੇਮਵਰਕ ਦੀਆਂ ਪਰੰਪਰਾਵਾਂ ਹਰ ਜਗ੍ਹਾ ਵਿਆਪ ਜਾਂਦੀਆਂ ਹਨ—ਕਾਰੋਬਾਰੀ ਨਿਯਮ, ਡੇਟਾ ਐਕਸੈਸ, ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ, authentication, ਇੱਥੋਂ ਤੱਕ ਕਿ ਫਾਇਲਾਂ ਦੇ ਨਾਂ—ਤਦ ਤਾਂ ਫਰੇਮਵਰਕ ਹੀ ਐਪ ਬਣ ਜਾਂਦਾ ਹੈ।
ਲੌਕ-ਇਨ ਵਾਲੀ ਕੋਡਬੇਸ ਅਕਸਰ ਐਸੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ ਜਿੱਥੇ ਕਾਰੋਬਾਰੀ ਫੈਸਲੇ ਫਰੇਮਵਰਕ-ਖਾਸ ਕਲਾਸਾਂ, ਡੈਕੋਰੇਟਰਾਂ, ਕੰਟਰੋਲਰਾਂ, ORM, ਅਤੇ middleware ਦੇ ਅੰਦਰ ਗੂੰਝਦੇ ਹਨ। ਨਤੀਜਾ: ਛੋਟੇ ਬਦਲਾਅ (ਜਿਵੇਂ ਕਿਸੇ ਹੋਰ ਵੈੱਬ ਫਰੇਮਵਰਕ 'ਤੇ ਜਾਣਾ, ਡੇਟਾਬੇਸ ਲੇਅਰ ਬਦਲਣਾ, ਜਾਂ ਸਰਵਿਸ ਵੰਡਣਾ) ਵੀ ਵੱਡੇ, ਖਤਰਨਾਕ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦੇ ਹਨ।
ਅਕਸਰ ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ “ਕੁਝ ਵੀ ਕਰਨ ਦੀ ਥਾਂ ਫਰੇਮਵਰਕ ਦੀਆਂ ਦਿਸ਼ਾਵਾਂ ਫੋਲੋ ਕਰੋ” ਹੁੰਦਾ ਹੈ। ਇਹ ਗਲਤ ਨਹੀਂ—ਫਰੇਮਵਰਕ ਤੇਜ਼ੀ ਲਈ ਹੁੰਦੇ ਹਨ। ਮੁੱਦਾ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਫਰੇਮਵਰਕ ਪੈਟਰਨ ਤੁਹਾਡੇ ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ ਬਣ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵਿਸਥਾਰ ਰਹਿ ਜਾਂਦਾ।
ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ ਦਬਾਅ ਹੇਠਾਂ ਬਣਦੇ ਹਨ: ਤੁਸੀਂ ਆਈਡੀਆ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਦੀ ਦੌੜ ਵਿਚ ਹੋ, ਲੋੜਾਂ ਹਫ਼ਤੇ-ਬ-ਹਫ਼ਤੇ ਬਦਲ ਰਹੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਟੀਮ ਹਰ ਚੀਜ਼ ਨੂੰ ਸੰਭਾਲ ਰਹੀ ਹੁੰਦੀ ਹੈ—onboarding ਤੋਂ ਲੈ ਕੇ billing ਤੱਕ। ਇਸ ਮਾਹੌਲ ਵਿੱਚ, copy-paste ਕਰਨ, ਡਿਫੌਲਟ ਸਵੀਕਾਰ ਕਰਨ, ਅਤੇ scaffolding ਨੂੰ structure ਨਿਰਧਾਰਤ ਕਰਨ ਦੇ ਫੈਸਲੇ ਲੈਣਾ ਆਮ ਹੈ।
ਉਹ ਛੋਟੇ shortcuts ਤੇਜ਼ੀ ਨਾਲ ਜੁਟਦੇ ਹਨ। ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ “MVP-plus” ਤੱਕ ਪਹੁੰਚਦੇ ਹੋ, ਤੁਸੀਂ ਪਾ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ ਮੁੱਖ ਲੋੜ (multi-tenant ਡੇਟਾ, audit trails, offline mode, ਨਵਾਂ ਇੰਟਿਗ੍ਰੇਸ਼ਨ) ਮੁਢਲੇ ਫਰੇਮਵਰਕ ਚੋਣਾਂ ਨਾਲ ਬਿਨਾਂ ਜ਼ਬਰਦਸਤੀ ਫਿਟ ਨਹੀਂ ਬੈਠਦੀ।
ਇਹ ਕਦੇ ਵੀ ਫਰੇਮਵਰਕ ਤੋਂ ਸਦਾ-ਹੀ ਦੂਰ ਰਹਿਣ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਵਿਕਲਪਾਂ ਨੂੰ ਕਾਫੀ ਦੇਰ ਲਈ ਖੁੱਲ੍ਹੇ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਿੱਖ ਸਕੋ ਕਿ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਫਰੇਮਵਰਕ ਬਦਲਣ ਯੋਗ ਹਿੱਸੇ ਹੋਣ ਚਾਹੀਦੇ ਹਨ—ਨਾ ਕਿ ਓਥੇ ਜਿੱਥੇ ਤੁਹਾਡੇ ਕੋਰ ਨਿਯਮ ਰਹਿੰਦੇ ਹਨ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਤੁਹਾਡੇ ਲਈ clean seams—interfaces, adapters, validation, ਅਤੇ tests—ਤਿਆਰ ਕਰਕੇ ਲੌਕ-ਇਨ ਘਟਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਚਲਣ ਲਈ ਹਰ ਇਕ ਫਰੇਮਵਰਕ ਨਿਰਣਾ ਬਹੁਤ ਜ਼ਰੂਰੀ ਨਾ ਬਣਾਉਣਾ ਪਏ।
ਪਰ AI ਤੁਹਾਡੇ ਲਈ ਆਰਕੀਟੈਕਚਰ ਚੁਣ ਨਹੀਂ ਸਕਦਾ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਹਦਬੰਦੀ ਦੇ “ਫੀਚਰ ਬਣਾ ਕੇ ਦਿਖਾਓ” ਕਹੋਗੇ, ਤਾਂ ਇਹ ਅਕਸਰ ਫਰੇਮਵਰਕ ਦੇ ਡਿਫੌਲਟ ਪੈਟਰਨ ਦੀ ਨਕਲ ਕਰੇਗਾ। ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਦਿਸ਼ਾ ਦੇਣੀ ਪਏਗੀ: ਕਾਰੋਬਾਰੀ ਲੋਜਿਕ ਨੂੰ ਅਲੱਗ ਰੱਖੋ, ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਆਇਸੋਲੇਟ ਕਰੋ, ਅਤੇ ਬਦਲਾਅ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ—ਫਿਰ ਭੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੇ ਸਮੇਂ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ AI ਡਿਵੈਲਪਮੈਂਟ ਵਾਤਾਵਰਣ (ਸਿਰਫ਼ ਇਨ-ਏਡੀਟਰ ਮਦਦਗਾਰ ਨਹੀਂ) ਦਾ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਹ ਫੀਚਰ ਖੋਜੋ ਜੋ ਇਹ ਹਦਬੰਦੀਆਂ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਵਿੱਚ ਇੱਕ planning mode ਹੈ ਜੋ ਤੁਸੀਂ ਉਪਭੋਗ ਕਰਕੇ ਪਹਿਲਾਂ ਹੀ ਸੀਮਾਵਾਂ ਸਪੱਸ਼ਟ ਕਰ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ “core ਵਿੱਚ ਕੋਈ framework imports ਨਹੀਂ ਹਨ”), ਅਤੇ ਇਹ source code export ਦਾ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ—ਤਾਂ ਜੋ ਤੁਸੀਂ portability ਰੱਖ ਸਕੋ ਅਤੇ tooling ਚੋਣਾਂ ਨੇ ਤੁਹਾਨੂੰ ਫਸਾਇਆ ਨਾ।
ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਸ਼ੁਰੂ ਤੋਂ ਕੋਈ ਜਾਣ-ਬੂਝ ਕੇ ਫੈਸਲਾ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਅਕਸਰ ਦਰਜਨਾਂ ਛੋਟੇ “ਅੱਜ-ਭੇਜੋ” فیصلਿਆਂ ਤੋਂ ਵਧਦਾ ਹੈ ਜੋ ਉਸ ਸਮੇਂ ਨਿਰਦੋਸ਼ ਲੱਗਦੇ ਹਨ, ਪਰ ਆਹਿਸਤਾਂ-ਆਹਿਸਤਾਂ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਧਾਰਣਾਂ ਵੱਜੋਂ ਜੜ੍ਹ ਜਾਂਦੇ ਹਨ।
ਕੁਝ ਪੈਟਰਨ ਮੁੜ-ਮੁੜ ਦੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ:
AI-ਨਿਰਮਿਤ ਕੋਡ ਇਸ ਦੁਰਘਟਨਾ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦਾ ਹੈ: ਜੇ ਤੁਸੀਂ "ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਡ" ਮੰਗਦੇ ਹੋ, ਇਹ ਅਕਸਰ ਸਭ ਤੋਂ idiomatic, ਫਰੇਮਵਰਕ-ਨੇਟਿਵ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੇਵੇਗਾ—ਜੋ ਤੇਜ਼ੀ ਲਈ ਵਧੀਆ ਹੈ, ਪਰ ਇਹ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਜਲਦੀ ਕਠੋਰ ਕਰ ਸਕਦਾ ਹੈ।
ਲੌਕ-ਇਨ ਅਕਸਰ ਕੁਝ high-gravity ਇਲਾਕਿਆਂ ਵਿੱਚ ਬਣਦਾ ਹੈ:
ਲੌਕ-ਇਨ ਸਦਾ ਹੀ ਮਾੜਾ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਫਰੇਮਵਰਕ ਚੁਣਨਾ ਅਤੇ ਉਸ 'ਤੇ ਝੁਕਣਾ ਤਬੋਂ ਸਮਝਦਾਰ ਫੈਸਲਾ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਰਫ਼ਤਾਰ ਮਹੱਤਵਪੂਰਨ ਹੋਵੇ। ਅਸਲ ਸਮੱਸਿਆ ਅਕਸਮਾਤਿਕ ਲੌਕ-ਇਨ ਹੈ—ਜਦੋਂ ਤੁਸੀਂ ਮਨ ਨਹੀਂ ਕੀਤਾ ਹੁੰਦਾ, ਪਰ ਤੁਹਾਡਾ ਕੋਡ ਸਾਫ seams ਨਹੀਂ ਰੱਖਦਾ ਜਿੱਥੇ ਕੋਈ ਹੋਰ ਫਰੇਮਵਰਕ ਜਾਂ ਮੋਡੀਊਲ ਬਾਅਦ ਵਿੱਚ ਜੁੜ ਸਕੇ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਟੂਲ ਹਨ ਜੋ ChatGPT ਜਾਂ ਇਨ-ਏਡੀਟਰ ਮਦਦਗਾਰ ਵਰਗੇ models ਨੂੰ ਪ੍ਰਾਂਪਟ ਦੇ ਕੇ ਕੋਡ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਇੱਕ function, ਇੱਕ ਫਾਇਲ ਸਕੈਫੋਲਡ, ਟੈਸਟ, ਰਿਫੈਕਟਰ ਸੁਝਾਅ, ਜਾਂ ਛੋਟਾ ਫੀਚਰ। ਇਹ ਤੇਜ਼ pattern-matching ਹੈ ਜੋ ਤੁਸੀਂ ਦਿੱਤਾ ਹੋਇਆ context ਵਰਤਦਾ ਹੈ—ਲਾਭਕਾਰੀ, ਪਰ ਜਾਦੂਈ ਨਹੀਂ।
ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰੋਟੋਟਾਇਪ ਤੋਂ MVP ਵੱਲ ਜਾ ਰਹੇ ਹੋ, AI ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਉਹਨਾਂ ਕੰਮਾਂ ਲਈ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੇ:
ਇਸ ਤਰ੍ਹਾਂ ਵਰਤਿਆ ਜਾਣ ਤੇ, AI ਲੌਕ-ਇਨ ਦਬਾਅ ਨੂੰ ਘਟਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਸੀਮਾਵਾਂ (ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਬਨਾਮ ਫਰੇਮਵਰਕ glue) 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦਾ ਹੈ।
AI ਨਿਰਭਰਤਾਪੂਰਵਕ ਨਹੀਂ:
ਇੱਕ ਆਮ ਫੇਲ ਮੋਡ ਹੈ “ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ” ਕੋਡ ਜੋ ਸੁਵਿਧਾ ਵਾਲੇ ਫਰੇਮਵਰਕ ਫੀਚਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਆਹਿਸਤਾ-ਆਹਿਸਤਾ ਭਵਿੱਖ ਦੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਨੂੰ ਇੱਕ ਜੂਨੀਅਰ ਸਹਿਕਾਰੀ ਦੀ ਪਹਿਲੀ ਕੌਪ ਦੀ ਤਰ੍ਹਾਂ ਸਮਝੋ: ਮਦਦਗਾਰ, ਪਰ ਇਸਦਾ ਰਿਵਿਊ ਲਾਜ਼ਮੀ ਹੈ। ਵਿਕਲਪ ਮੰਗੋ, framework-agnostic ਵਰਜਨਾਂ ਦੀ ਮੰਗ ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਤਕਨੀਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੋਰ ਲਾਜਿਕ ਪੋਰਟੇਬਲ ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਲਚਕੀਲੇ ਰਹਿਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੇ ਫਰੇਮਵਰਕ (Next.js, Rails, Django, Flutter ਆਦਿ) ਨੂੰ ਇੱਕ ਡਿਲਿਵਰੀ ਲੇਅਰ ਸਮਝੋ—ਉਹ ਹਿੱਸਾ ਜੋ HTTP درخواستਾਂ, ਸਕ੍ਰੀਨਾਂ, routing, auth wiring, ਅਤੇ ਡੇਟਾਬੇਸ ਪਲੰਬਿੰਗ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ।
ਤੁਹਾਡੀ ਕੋਰ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਬਦਲਣ 'ਤੇ ਵੀ saccha ਰਹੇ: ਮੁੱਲ ਨਿਯਮ, invoice calculations, eligibility checks, state transitions, ਅਤੇ ਨੀਤੀਆਂ (ਜਿਵੇਂ “sirf admins ਹੀ invoices void ਕਰ ਸਕਦੇ ਹਨ”)। ਉਸ ਲਾਜਿਕ ਨੂੰ ਨਹੀਂ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਕਿ ਇਹ ਇੱਕ ਵੈੱਬ ਕੰਟਰੋਲਰ, ਮੋਬਾਈਲ ਬਟਨ, ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬ ਦੁਆਰਾ trigger ਹੋ ਰਹੀ ਹੈ।
ਇੱਕ ਵਰਤੀਜੋਗ ਨਿਯਮ ਜੋ ਗਹਿਰੇ coupling ਨੂੰ ਰੋਕਦਾ ਹੈ:
ਫਰੇਮਵਰਕ ਕੋਡ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਉਲਟ ਨਹੀਂ।
ਇਸ ਲਈ ਕੰਟਰੋਲਰ ਮੈਥਡ ਨੂੰ ਨਿੱਘਾ ਰੱਖੋ: ਇਨਪੁੱਟ ਪਾਰਸ ਕਰੋ → ਇੱਕ use-case ਮੋਡੀਊਲ ਨੂੰ ਕਾਲ ਕਰੋ → ਜਵਾਬ ਵਾਪਸ ਕਰੋ।
ਆਪਣੇ AI ਸਹਾਇਕ ਨੂੰ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ plain ਮੋਡੀਊਲਾਂ ਵਜੋਂ ਬਣਾਉਣ ਲਈ ਕਹੋ ਜੋ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਦੇ ਨਾਂ 'ਤੇ ਹੋਣ:
CreateInvoiceCancelSubscriptionCalculateShippingQuoteਇਹ ਮੋਡੀਊਲ plain data (DTOs) ਲੈਣ ਅਤੇ ਨਤੀਜੇ ਜਾਂ domain errors ਵਾਪਸ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ—ਕੋਈ framework request objects, ORM models, ਜਾਂ UI widgets ਦਾ ਹਵਾਲਾ ਨਹੀਂ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਖਾਸ ਤੌਰ 'ਤੇ ਫਾਇਦਾ مند ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਹੈਪੀ-ਵੇਅਰ endpoint ਤੋਂ ਲਾਜਿਕ ਨੂੰ ਸਾਫ਼ functions/services ਵਿੱਚ ਨਿਕਾਲਦੀ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਗੰਦਲ endpoint ਪੇਸਟ ਕਰਕੇ ਬੋਲ ਸਕਦੇ ਹੋ: “Refactor into a pure CreateInvoice service with input validation and clear return types; keep the controller thin.”
ਜੇ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਫਰੇਮਵਰਕ ਪੈਕੇਜਾਂ ਨੂੰ import ਕਰਦੇ ਹਨ (routing, controllers, React hooks, mobile UI), ਤਾਂ ਤੁਸੀਂ ਲੇਅਰ ਮਿਲਾ ਰਹੇ ਹੋ। ਇਸਨੂੰ ਉਲਟੋ: imports ਫਰੇਮਵਰਕ ਵੱਲੋਂ core ਤੱਕ ਵਹਿਣ—ਅਤੇ ਤੁਹਾਡਾ ਕੋਰ ਲਾਜਿਕ ਬਾਅਦ ਵਿੱਚ ਡਿਲਿਵਰੀ ਲੇਅਰ ਬਦਲਣਵਾਲੀ ਰਹੇਗੀ।
ਅਡੈਪਟਰ ਛੋਟੇ “ਅਨੁਵਾਦਕ” ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਐਪ ਅਤੇ ਕਿਸੇ ਖਾਸ ਟੂਲ ਜਾਂ ਫਰੇਮਵਰਕ ਵਿਚਕਾਰ ਬੇਠਦੇ ਹਨ। ਤੁਹਾਡਾ ਕੋਰ ਇੱਕ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਦੇਖਦੇ ਇੰਟਰਫੇਸ (ਇੱਕ ਸਧਾਰਣ_contract_ ਜਿਵੇਂ EmailSender ਜਾਂ PaymentsStore) ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਅਡੈਪਟਰ ਇਹ ਨਿਰੰਤਰ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸ ਤਰ੍ਹਾਂ ਇੱਕ ਫਰੇਮਵਰਕ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ।
ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਵਿਕਲਪ ਖੁੱਲੇ ਰਹਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਟੂਲ-swapping ਇੱਕ ਕੇਂਦਰਤ ਬਦਲਾਅ ਬਣ ਜਾਂਦਾ: ਅਡੈਪਟਰ ਬਦਲੋ, ਨਾ ਕਿ ਪੂਰਾ ਉਤਪਾਦ।
ਕੁਝ ਇਲਾਕੇ ਜਿੱਥੇ ਲੌਕ-ਇਨ ਅਕਸਰ ਪਹਿਲਾਂ ਵਾਪਰਦਾ ਹੈ:
HttpClient / ApiClient ਦੇ ਪਿੱਛੇ ਢੱਕੋ।ਜਦੋਂ ਇਹ ਕਾਲਾਂ ਸਾਰੇ ਕੋਡਬੇਸ ਵਿੱਚ ਛਿੜਕੀ ਹੋਈਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ “ਹਰ ਚੀਜ਼ ਨੂੰ ਛੇੜੋ” ਬਣ ਜਾਂਦੀ ਹੈ। ਅਡੈਪਟर्स ਨਾਲ, ਇਹ “ਇੱਕ ਮੋਡੀਊਲ ਬਦਲੋ” ਬਣ ਜਾਂਦਾ ਹੈ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਇੱਥੇ ਦੁਹਰਾਅ ਵਾਲੀ scaffolding ਬਣਾਉਣ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਹੈ: ਇੱਕ ਇੰਟਰਫੇਸ + ਇਕ concrete implementation।
ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰਾਂਪਟ ਵਿੱਚ ਮੰਗੋ:
Queue) ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਲੋੜੀਏ ਨੂੰ ਮੈਥਡਸ (publish(), subscribe())SqsQueueAdapter) ਜੋ ਚੁਣੀ ਗਈ ਲਾਇਬ੍ਰੇਰੀ ਵਰਤਦਾ ਹੈInMemoryQueue)ਤੁਸੀਂ ਫਿਰ ਵੀ ਡਿਜ਼ਾਈਨ ਦੀ ਸਮੀਖਿਆ ਕਰੋਗੇ, ਪਰ AI boilerplate 'ਤੇ ਘੰਟੇ ਬਚਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਅਡੈਪਟਰ ਨਿਰਸ ਹੁੰਦਾ ਹੈ: ਘੱਟ-ਸਭਿਆਚਾਰਤ ਲਾਜਿਕ, ਸਾਫ਼ errors, ਅਤੇ ਕੋਈ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਨਹੀਂ। ਜੇ ਅਡੈਪਟਰ ਬਹੁਤ ਸਿਆਣਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਨਿਰਭਰਤਾ ਨੂੰ ਨਵੇਂ ਸਥਾਨ 'ਤੇ ਲਿਜਾ ਰਹੇ ਹੋ। ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਨੂੰ ਆਪਣੇ ਕੋਰ ਵਿੱਚ ਰੱਖੋ; adapters ਨੂੰ replaceable ਪਲੰਬਿੰਗ ਰਹਿਣ ਦਿਉ।
ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਅਕਸਰ ਇੱਕ ਸਰਲ shortcut ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ UI ਬਣਾਉਂਦੇ ਹੋ, ਇਸਨੂੰ ਜੋ ਡੇਟਾ ਸਹੂਲਤ ਸੁਵਿਧਾ ਦਿੰਦੀ ਹੈ ਉਹੀ ਵੇਖ ਕੇ ਸਿੱਧਾ ਡੇਟਾਬੇਸ ਜਾਂ API ਨਾਲ ਵਾਇਰ ਕਰ ਦਿੰਦੇ ਹੋ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਹਰ ਸਕ੍ਰੀਨ ਇੱਕੋ ਹੀ ਫਰੇਮਵਰਕ-ਖਾਸ ਡੇਟਾ ਮਾਡਲ ਮੰਨ ਲੈਂਦਾ ਹੈ।
“contract first” ਪਹੁੰਚ ਉਸ ਆਰਡਰ ਨੂੰ ਉਲਟ ਦਿੰਦੀ ਹੈ। ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਫਰੇਮਵਰਕ ਨਾਲ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ, ਉਹ contracts (request/response shapes, events, ਅਤੇ ਕੋਰ ਡੇਟਾ structures) ਪਰਿਭਾਸ਼ਤ ਕਰੋ। ਸੋਚੋ: “CreateInvoice ਕੀ ਲੱਗਦਾ ਹੈ?” ਅਤੇ “Invoice ਕੀ ਗਾਰੰਟੀ ਕਰਦਾ ਹੈ?” ਨਾ ਕਿ “ਮੇਰਾ ਫਰੇਮਵਰਕ ਇਸ ਨੂੰ ਕਿਵੇਂ ਸੀਰੀਅਲਾਈਜ਼ ਕਰਦਾ ਹੈ?”
ਇੱਕ ਪੋਰਟੇਬਲ ਸਕੀਮਾ ਫਾਰਮੈਟ ਵਰਤੋ (OpenAPI, JSON Schema, ਜਾਂ GraphQL schema)। ਇਹ ਤੁਹਾਡੇ ਉਤਪਾਦ ਲਈ ਇੱਕ ਸਟੇਬਲ ਗ੍ਰੈਵੀਟੀ ਪੋਇੰਟ ਬਣ ਜਾਂਦਾ ਹੈ—ਭਾਵੇਂ UI Next.js ਤੋਂ Rails 'ਤੇ ਜਾਂ API REST ਤੋਂ ਕੁਝ ਹੋਰ 'ਤੇ ਬਦਲੇ।
ਜਦੋਂ ਸਕੀਮਾ ਮੌਜੂਦ ਹੋ, AI-ਨਿਰਮਿਤ ਕੋਡ ਖਾਸ ਕਰਕੇ ਲਾਭਕਾਰੀ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਨੇਕਾਂ stacks ਵਿੱਚ consistent artifacts ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ:
ਇਸ ਨਾਲ framework coupling ਘਟਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ internal types ਅਤੇ validated inputs 'ਤੇ ਨਿਰਭਰ ਕਰ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ framework request objects 'ਤੇ।
contracts ਨੂੰ ਇੱਕ ਫੀਚਰ ਵਾਂਗ treat ਕਰੋ: ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜਨ ਕਰੋ। ਇਵਨ ਹਲਕੀ ਵਰਜਨਿੰਗ (ਉਦਾਹਰਨ: /v1 ਬਨਾਮ /v2, ਜਾਂ invoice.schema.v1.json) ਤੁਹਾਨੂੰ ਖੇਤਰ ਬਦਲਣ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ ਦੋਨੋਂ ਵਰਜਨਾਂ ਦਾ ਸਮਰਥਨ ਦੌਰਾਨੀ ਰੂਪ ਵਿੱਚ ਕਰ ਸਕਦੇ ਹੋ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਹੌਲੀ-ਹੌਲੀ ਮਾਈਗ੍ਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦ ਫਰੇਮਵਰਕ ਬਦਲੇ ਤਾਂ ਵੀ ਵਿਕਲਪ ਖੁਲੇ ਰੱਖ ਸਕਦੇ ਹੋ।
ਟੈਸਟਸ ਸ਼ੁਰੂਵਾਤੀ ਹੀ ਸਭ ਤੋਂ ਵਧੀਆ anti-lock-in ਔਜ਼ਾਰ ਹਨ—ਕਿਉਂਕਿ ਵਧੀਆ ਟੈਸਟਸ ਬਿਹੇਵਿਯਰ ਨੂੰ ਵੇਰਵਾ ਦਿੰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ। ਜੇ ਤੁਹਾਡੀ ਟੈਸਟ ਸੁੱਟੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਹਿੰਦੀ ਹੈ “ਇਨ੍ਹਾਂ ਇਨਪੁੱਟਾਂ ਤੇ ਅਸੀਂ ਇਹ ਨਤੀਜੇ ਦੇਣੇ ਆਂ”, ਤਾਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਫਰੇਮਵਰਕ swap ਕਰਨ ਜਾਂ ਰੀਫੈਕਟਰ ਕਰਨ ਵਿੱਚ ਘੱਟ ਡਰਵਾਂਗੇ। ਕੋਡ ਬਦਲ ਸਕਦਾ ਹੈ; ਵਿਵਹਾਰ ਨਹੀਂ।
ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਅਕਸਰ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਫਰੇਮਵਰਕ ਰੀਤਾਂ ਨਾਲ ਗੁੰਝ ਜਾਂਦੇ ਹਨ। ਚੰਗੀਆਂ ਯੂਨਿਟ ਟੈਸਟਸ ਉਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ ਵਿੱਚ ਲਿਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੋਰਟੇਬਲ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਜਦ ਤੁਸੀਂ ਮਾਈਗ੍ਰੇਟ ਕਰੋ ਜਾਂ ਰੀਫੈਕਟਰ ਕਰੋ, ਤੁਹਾਡੇ ਟੈਸਟਸ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਉਤਪਾਦ ਨੂੰ ਨਹੀਂ ਤੋੜਿਆ।
AI ਖਾਸ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਲਈ ਮਦਦਗਾਰ ਹੈ:
ਇੱਕ ਪ੍ਰਾਯੋਗਿਕ ਵਰਕਫਲੋ: ਇੱਕ function ਅਤੇ ਨਿਯਮ ਦਾ ਸੰਖੇਪ ਵੇਰਵਾ ਪੇਸਟ ਕਰੋ, ਫਿਰ AI ਨੂੰ boundary ਅਤੇ “weird” inputs ਸਮੇਤ test cases ਸੁਝਾਉਣ ਲਈ ਕਹੋ। ਤੁਸੀਂ ਹਜੇ ਵੀ ਕੇਸ ਦਾ ਰਿਵਿਊ ਕਰੋਗੇ, ਪਰ AI ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਜ਼ਿਆਦਾ ਕਵਰੇਜ ਦੇਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਲਚੀਲੇ ਰਹਿਣ ਲਈ, ਘਣੇ ਯੂਨਿਟ ਟੈਸਟ, ਕੁਝ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਟੈਸਟ, ਅਤੇ ਥੋੜੇ end-to-end ਟੈਸਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਯੂਨਿਟ ਟੈਸਟ ਤੇਜ਼, ਸਸਤੇ, ਅਤੇ ਕਿਸੇ ਇੱਕ ਫਰੇਮਵਰਕ ਨਾਲ ਘੱਟ ਜੁੜੇ ਹੋਏ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡੇ ਟੈਸਟਸ ਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ ਫਰੇਮਵਰਕ ਬੂਟ ਦੀ ਲੋੜ ਹੈ, custom decorators, ਜਾਂ ਭਾਰੀ mocking utilities ਜੋ ਸਿਰਫ ਇੱਕ ecosystem 'ਚ ਮੌਜੂਦ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਚੁਪਚਾਪ ਆਪਣੇ ਆਪ ਨੂੰ ਫਰੇਮਵਰਕ ਵਿੱਚ ਲੌਕ ਕਰ ਰਹੇ ਹੋ। ਸਾਫ ਸਾਦਾ assertions ਨੂੰ ਪਸੰਦ ਕਰੋ ਜੋ pure functions ਅਤੇ domain services 'ਤੇ ਚੱਲਣ।
ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦਾਂ ਨੂੰ ਐਕਸਪੇਰਿਮੈਂਟ ਵਾਂਗ ਵਰਤੋ: ਛੋਟੀ ਚੀਜ਼ ਬਣਾਓ, ਮਾਪੋ, ਫਿਰ ਮਿਲਦਾ ਨਤੀਜਾ ਦੇ ਅਧਾਰ 'ਤੇ ਦਿਸ਼ਾ ਬਦਲੋ। ਰਿਸਕ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾ ਪ੍ਰੋਟੋਟਾਇਪ ਅਚਾਨਕ “ਉਤਪਾਦ” ਬਣ ਕੇ ਰਹਿ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਦੋਂ ਤੱਕ ਕੀਤੇ ਫਰੇਮਵਰਕ ਚੋਣ ਮਹਿੰਗੇ ਰੀਵਰਟ ਹੋ ਜਾਂਦੇ ਹਨ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਵੈਰੀਏਸ਼ਨਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਅਜ਼ਮਾਉਣ ਲਈ идеਅਲ ਹੈ: React ਵਿੱਚ ਸਧਾਰਣ onboarding flow ਬਰਾਮਬਾਰ server-rendered ਵਰਜਨ, ਦੋ ਵੱਖ-ਵੱਖ payment providers, ਜਾਂ ਇੱਕ feature ਲਈ ਵੱਖ-ਵੱਖ ਡੇਟਾ ਮਾਡਲ। ਕਿਉਂਕਿ AI ਕਈ ਵਾਰੀ ਮੁਲਾਕਾਤਕ ਸਕੈਫੋਲਡਿੰਗ ਮਿੰਟਾਂ ਵਿੱਚ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਸੀਂ ਪਹਿਲੇ stack 'ਤੇ ਕੰਪਨੀ ਨਹੀਂ ਬੇਟ ਕਰਦੇ।
ਕੀਮਤੀ ਗੱਲ ਇਰਾਦਾ ਹੈ: ਪ੍ਰੋਟੋਟਾਇਪ ਨੂੰ ਅਸਥਾਇੀ ਲੇਬਲ ਕਰੋ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਉਹ ਕਿੱਦਾ sawal ਦਾ ਉੱਤਰ ਦੇਵੇਗਾ (ਉਦਾਹਰਨ: “ਕੀ ਯੂਜ਼ਰ ਤੀਜੇ ਕਦਮ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ?” ਜਾਂ “ਕੀ ਇਹ ਵਰਕਫਲੋ ਸਮਝਣਯੋਗ ਹੈ?”)। ਜਦ ਤੁਸੀਂ ਉੱਤਰ ਪ੍ਰਾਪਤ ਕਰ ਲਵੋ, ਤਾਂ ਪ੍ਰੋਟੋਟਾਇਪ ਨੇ ਆਪਣਾ ਕੰਮ ਕੀਤਾ।
ਛੋਟੀ ਸਮਾਂ-ਵਿੰਡੋ ਰੱਖੋ—ਅਕਸਰ 1–3 ਦਿਨ—ਪ੍ਰੋਟੋਟਾਇਪ ਬਣਾਉਣ ਅਤੇ ਟੈਸਟ ਕਰਨ ਲਈ। ਸਮਾਂ ਖਤਮ ਹੋਣ 'ਤੇ ਇੱਕ ਚੋਣ ਕਰੋ:
ਇਸ ਨਾਲ “prototype glue” (quick fixes, copy-pasted snippets, framework-specific shortcuts) ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ coupling ਬਣਨ ਤੋਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਜਨਰੇਟ ਅਤੇ ਸੋਧ ਰਹੇ ਹੋ, ਇੱਕ ਹਲਕੀ decision log ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਕੀ ਮਾਪਿਆ, ਅਤੇ ਕਿਉਂ ਇਸ ਦਿਸ਼ਾ ਨੂੰ ਚੁਣਿਆ ਜਾਂਦਾ/ਰੱਦ ਕੀਤਾ ਗਿਆ। ਬੰਧਨਾਂ ਨੂੰ ਵੀ ਕੈਪਚਰ ਕਰੋ ("ਮੌਜੂਦਾ ਹੋਸਟਿੰਗ 'ਤੇ ਚੱਲਣਾ ਲਾਜ਼ਮੀ", "SOC2 ਦੀ ਲੋੜ ਆਏਗੀ"). /docs ਜਾਂ project README ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਪੰਨਾ ਕਾਫੀ ਹੈ—ਅਤੇ ਇਹ ਭਵਿੱਖੀ ਬਦਲਾਅਾਂ ਨੂੰ ਯੋਜਤ ਬਣਾਉਂਦਾ ਹੈ, ਨਾਂ ਕਿ ਦਰਦਨਾਕ ਰੀਰਾਈਟਸ।
ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ ਹਫ਼ਤੇ-ਦਰ-ਹਫ਼ਤਾ ਬਦਲਦੇ ਹਨ: ਨਾਂ, ਡੇਟਾ ਆਕਾਰ, ਇੱਥੋਂ ਤੱਕ ਕਿ “ਉਪਭੋਗਤਾ” ਦਾ ਅਰਥ ਵੀ। ਜੇ ਤੁਸੀਂ ਰੀਫੈਕਟਰ ਕਰਨ ਲਈ ਇੰਤਜ਼ਾਰ ਕਰੋਗੇ ਤੱਕ ਵੱਧ, ਤੁਹਾਡੇ ਫਰੇਮਵਰਕ ਚੋਣਾਂ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਵਿੱਚ ਜੜ੍ਹ ਕੇ ਰਹਿ ਜਾਣਗੀਆਂ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਤੁਹਾਨੂੰ ਜਲਦੀ ਰੀਫੈਕਟਰ ਕਰਨ ਵਿਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦੁਹਰਾਵੀ, ਘਟ-ਖਤਰੇ ਵਾਲੇ ਸੋਧੇ ਚੀਜ਼ਾਂ (ਨਾਮ ਬਦਲਣਾ, helpers ਨਿਕਾਲਣਾ, ਫਾਈਲਾਂ ਦੁਬਾਰਾ ਵਿਵਸਥਿਤ ਕਰਨਾ, boundaries ਦਰਿਆਫ਼ਤ ਕਰਨਾ) ਵਿੱਚ ਚੰਗਾ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਵਰਤਣ ਨਾਲ coupling ਰਚਨਾਤਮਕ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਘਟ ਸਕਦੀ ਹੈ।
ਸ਼ੁਰੂ ਕਰੋ ਉਹਨਾਂ ਸੋਧਾਂ ਨਾਲ ਜੋ ਤੁਹਾਡੇ ਕੋਰ ਵਿਵਹਾਰ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਅਸਾਨੀ ਨਾਲ ਨਿਕੱਲਣਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ:
BillingService, InventoryService) ਜੋ controllers, ORM models, ਜਾਂ framework request objects ਨੂੰ import ਨਾ ਕਰਨ।NotFound, ValidationError) ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਬਾਊਂਡਰੀ 'ਤੇ translate ਕਰੋ।ਰਿਵਰਸੀਬਲ increments ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰੋ:
ਇਹ “ਇੱਕ ਬਦਲਾਅ + green tests” ਰਿਥਮ AI ਨੂੰ ਮਦਦਗਾਰ ਬਣਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਇਸਦੇ ਭਟਕਣ ਦੇ।
ਸਾਰੀ ਰਿਪੋ 'ਤੇ "modernize the architecture" ਵਰਗੀਆਂ ਬੇਨੀਆਂ ਬੇਨਤੀਆਂ ਨਾ ਕਰੋ। ਵੱਡੇ, ਜਨਰੇਟ ਕੀਤੇ ਰੀਫੈਕਟਰ ਆਮ ਤੌਰ 'ਤੇ ਸਟਾਈਲ ਬਦਲਣਾਂ ਅਤੇ ਵਿਵਹਾਰ ਬਦਲਣਾਂ ਨੂੰ ਮਿਲਾ ਦੇਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਬੱਗ ਖੋਜਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ diff ਵੱਡਾ ਹੈ ਅਤੇ ਰਿਵਿਊ ਕਰਨ ਯੋਗ ਨਹੀਂ, ਤਾਂ ਇਸ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣਾ ਨਿਰਾਸ਼ਾਵਾਦ ਨਹੀਂ—ਇਹ ਬੀਮਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਉਤਪਾਦ ਤੇਜ਼ੀ ਨਾਲ ਦਿਸ਼ਾ ਬਦਲਦੇ ਹਨ: ਤੁਸੀਂ ਫਰੇਮਵਰਕ ਬਦਲ ਸਕਦੇ ਹੋ, ਮੋਨੋਲਿਥ ਨੂੰ ਵੰਡ ਸਕਦੇ ਹੋ, ਜਾਂ authentication ਨੂੰ ਇੱਕ ਕੋਈ compliance-ਯੋਗ ਹੱਲ 'ਤੇ ਸਟੇਪ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ ਬਾਹਰ ਨਿਕਲਣ ਦੀ ਯੋਜਨਾ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰੋਗੇ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਕੋਡ ਵਿੱਚ ਵੀ ਸਾਫ਼ ਸੀਮਾਵਾਂ ਰਹਿਣਗੀਆਂ—ਭਾਵੇਂ ਤੁਸੀਂ ਰੁਕੇ ਰਹੋ।
ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਕਸਰ ਅਸਫਲ ਜਾਂ ਮਹਿੰਗੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਸਭ ਤੋਂ ਗੁੰਝਲਦਾਰ ਹਿੱਸੇ ਹਰ ਜਗ੍ਹਾ ਫੈਲ ਹੋਏ ਹੁੰਦੇ ਹਨ:
ਇਹ ਇਲਾਕੇ sticky ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਕਈ ਫਾਇਲਾਂ ਨੂੰ ਛੂਹਦੇ ਹਨ, ਅਤੇ ਥੋੜੀਆਂ ਅਸਮਰਥਤਾਵਾਂ ਹੀ ਵੱਧ ਕੇ ਮਿਲਦੀਆਂ ਹਨ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਇਥੇ ਸਹਾਇਕ ਹੋ ਸਕਦਾ ਹੈ—"ਮਾਈਗ੍ਰੇਟ ਕਰੋ" ਕਰਨ ਲਈ ਨਹੀਂ, ਪਰ ਢਾਂਚਾ ਬਣਾਉਣ ਲਈ:
ਮੁੱਖ ਗੱਲ: ਕੋਡ ਦੀ ਬਜਾਏ ਕਦਮ ਅਤੇ invariants ਮੰਗੋ।
ਸਾਰਾ ਕੁਝ ਰੀਰਾਈਟ ਕਰਨ ਦੀ ਥਾਂ, ਨਵਾਂ ਮੋਡੀਊਲ ਪੁਰਾਣੇ ਦੇ ਨਾਲ ਨਾਲ ਚਲਾਓ:
ਇਹ ਤਰੀਕਾ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸਾਫ਼ ਸੀਮਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਨਮੂਨੇ ਅਤੇ ਉਦਾਹਰਨਾਂ ਲਈ, ਵੇਖੋ /blog/strangler-pattern ਅਤੇ /blog/framework-agnostic-architecture.
ਜੇ ਤੁਸੀਂ ਕਦੇ ਮਾਈਗ੍ਰੇਟ ਵੀ ਨਾ ਕਰੋ, ਤਾਂ ਇਸਤੋਂ ਫਾਇਦਾ ਇਹ ਹੈ: ਘੱਟ ਛੁਪੇ ਨਿਰਭਰਤਾ, ਸਾਫ਼ contracts, ਅਤੇ ਘੱਟ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ tech debt।
AI ਬਹੁਤ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦਾ ਹੈ—ਅਤੇ ਇਹ ਫਰੇਮਵਰਕ ਦੀਆਂ ਧਾਰਣਾਂ ਹਰ ਜਗ੍ਹਾ ਫੈਲਾ ਸਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਸੀਮਾਵਾਂ ਨਾ ਲਗਾਵੋ। ਲਕੜੀ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ "ਘੱਟ ਭਰੋਸਾ ਕਰੋ", ਪਰ ਇਹ ਕਿ ਰਿਵਿਊ ਕਰਨਾ ਆਸਾਨ ਅਤੇ ਗਲਤੀ ਨਾਲ coupling ਘੱਟ ਕਰਨਾ ਔਖਾ ਬਣਾਓ।
ਹਰ PR ਵਿੱਚ (ਖਾਸ ਕਰਕੇ AI-ਸਹਾਇਤਾ ਵਾਲੀਆਂ) ਇੱਕ ਛੋਟਾ, ਦੋਹਰਾਉਣਯੋਗ ਚੈਕਲਿਸਟ ਵਰਤੋ:
Request, DbContext, ActiveRecord, Widget ਆਦਿ ਨਹੀਂ)। Core ਕੋਡ ਤੁਹਾਡੇ ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ ਗੱਲ ਕਰੇ: Order, Invoice, UserId।ਅਧਿਕਾਰਿਤ ਰੱਖਣ ਲਈ standards ਸਾਦੇ ਰੱਖੋ:
core/, adapters/, app/ ਵਰਗੀਆਂ ਫੋਲਡਰ ਹੱਦਾਂ define ਕਰੋ ਅਤੇ ਨਿਯਮ ਰੱਖੋ: “core ਵਿੱਚ zero framework imports।”*Service (ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ), *Repository (interface), *Adapter (framework glue).AI ਤੋਂ ਕੋਡ ਮੰਗਣ ਵੇਲੇ ਸ਼ਾਮਲ ਕਰੋ:
/core with no framework imports”),ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ "plan then build" ਵਰਗੇ AI ਪਲੇਟਫਾਰਮ ਸਹਾਇਕ ਹੋ ਸਕਦੇ ਹਨ। Koder.ai ਵਿੱਚ, ਉਦਾਹਰਨ ਵਜੋਂ, ਤੁਸੀਂ planning mode ਵਿੱਚ ਇਹ ਹਦਬੰਦੀਆਂ ਵੇਰਵਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਕੋਡ generate ਕਰਵਾ سکتے ਹੋ, snapshots ਅਤੇ rollback ਵਰਤ ਕੇ ਵੱਡੇ diffs ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੀਵਿਊ ਕਰਨ ਲਈ।
ਦਿਨ ਇੱਕ ਤੋਂ formatters/linters ਅਤੇ ਇੱਕ ਸਧਾਰਨ CI check (ਇੱਕ "lint + test" pipeline) ਸੈਟ ਕਰੋ। coupling ਨੂੰ ਤੁਰੰਤ ਫੜੋ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਇਹ "ਪ੍ਰੋਜੈਕਟ ਦਾ ਤਰੀਕਾ" ਬਣੇ।
ਫਰੇਮਵਰਕ-ਫਲੈਗਲਿੰਗ ਰਹਿਣ ਦਾ ਮਤਲਬ ਫਰੇਮਵਰਕ ਤੋਂ ਬਚਣਾ ਨਹੀਂ—ਇਹ ਉਹਨਾਂ ਨੂੰ ਗਤੀ ਲਈ ਵਰਤਣ ਬਾਰੇ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਾਹਰ ਨਿਕਲਣ ਦੀ ਲਾਗਤ ਪੈਦਾ ਕਰਨ ਯੋਗ ਰੱਖਦੇ ਹੋ। AI-ਨਿਰਮਿਤ ਕੋਡ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਲਚਕ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ seams ਕਿੱਥੇ ਰੱਖਦੇ ਹੋਂ।
ਸ਼ੁਰੂ ਤੋਂ ਇਨ੍ਹਾਂ ਚਾਰ ਤਕਨਿਕਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ:
ਕੋਡਬੇਸ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ:
/core (ਜਾਂ ਮਿਲਦਾ-ਜੁਲਦਾ) ਫੋਲਡਰ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਹੋਵੇ ਅਤੇ ਕੋਈ framework imports ਨਾ ਹੋਣ।ਹਰ 1–2 ਹਫ਼ਤੇ 'ਚ seams ਨੂੰ ਦੁਬਾਰਾ ਦੇਖੋ:
ਜੇ ਤੁਸੀਂ prototype ਤੋਂ MVP ਵੱਲ ਜਾਣ ਲਈ ਵਿਕਲਪਾਂ ਦੀ ਗਲ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਪੋਰਟੇਬਿਲਟੀ ਬਣਾਈ ਰੱਖਣੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਯੋਜਨਾਵਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਦੀ ਸਮੀਖਿਆ /pricing ਤੇ ਕਰ ਸਕਦੇ ਹੋ।
ਫਰੇਮਵਰਕ ਲੌਕ-ਇਨ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਉਤਪਾਦ ਦਾ ਮੁੱਖ ਵਿਵਹਾਰ ਕਿਸੇ ਖਾਸ ਫਰੇਮਵਰਕ ਜਾਂ ਵੈਂਡਰ ਦੀਆਂ ਰੀਤਾਂ (controllers, ORM ਮਾਡਲ, middleware, UI ਪੈਟਰਨ) ਨਾਲ ਅਟੁੱਟ ਹੋ ਜਾਵੇ। ਉਸ ਮੋੜ ਤੇ, ਫਰੇਮਵਰਕ ਬਦਲਨਾ ਸਿਰਫ਼ ਸਵੈਪ ਨਹੀਂ ਰਹਿੰਦਾ—ਇਹ ਇੱਕ ਪੂਰੀ ਰੀਰਾਈਟ ਬਣ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕਾਰੋਬਾਰੀ ਨਿਯਮ ਫਰੇਮਵਰਕ-ਵਿਸ਼ੇਸ਼ ਸੰਕਲਪਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੇ ਹਨ।
ਆਮ ਨਿਸ਼ਾਨੇ:
Request, ORM ਬੇਸ ਮਾਡਲ, UI hooks)ਜੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਭ ਕੁਝ ਛੂਹਣ ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲੌਕ-ਇਨ ਹੋ ਚੁੱਕੇ ਹੋ।
ਸ਼ੁਰੂਆਤੀ ਟੀਮਾਂ ਤੇਜ਼ੀ ਲਈ ਅਤੇ ਅਣਪਛਾਤੇ ਹਾਲਾਤ ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਅਕਸਰ "ਫਰੇਮਵਰਕ ਦੇ ਡਿਫ਼ੌਲਟ ਫੋਲੋ ਕਰੋ" ਹੁੰਦਾ ਹੈ, ਜੋ ਚੁਪਚਾਪ ਤੁਹਾਡੇ ਉਤਪਾਦ ਡਿਜ਼ਾਈਨ ਨੂੰ ਫਰੇਮਵਰਕ ਰੀਤਾਂ ਨਾਲ ਮੇਲ ਕਰਨ ਲੱਗਦਾ ਹੈ। ਐਹੋ ਜਿਹੇ ਛੇਤੀ-ਲਈ ਹੋਏ ਚੌਕਸ਼ਟਸ ਜਲਦੀ ਜੁਟ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ "MVP-plus" ਤੱਕ ਪਹੁੰਚਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਲਗ ਸਕਦਾ ਹੈ ਕਿ ਨਵੇਂ ਲੋੜਾਂ ਨੂੰ ਪੁਰਾਣੇ ਚੋਣਾਂ ਨਾਲ ਮਿਲਾਉਣਾ ਮੁਸ਼ਕਲ ਹੈ।
ਹਾਂ—ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਸੀਮਾਵਾਂ ਬਣਾਉਣ ਲਈ ਵਰਤੋਂ:
AI ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਸਮੇਂ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਫਰੇਮਵਰਕ ਨੂੰ ਕਿਨਾਰੇ ਰੱਖਣ ਲਈ ਦਿਸ਼ਾ ਦਿਓ।
AI ਅਕਸਰ ਸਭ ਤੋਂ idiomatic, ਫਰੇਮਵਰਕ-ਨੇਟਿਵ ਹੱਲ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜੇ ਤੱਕ ਤੁਸੀਂ ਇਸਨੂੰ ਸੀਮਿਤ ਨਾ ਕਰੋ। ਅਜਿਹੇ ਪ੍ਰੋੰਪਟ ਦਿਓ:
/core with no framework imports”ਫਿਰ core ਵਿੱਚ ਛੁਪੇ coupling (ORM ਮਾਡਲ, ਡੈਕੋਰੇਟਰ, request/session ਵਰਤੋਂ) ਲਈ ਰਿਵਿਊ ਕਰੋ।
ਇਕ ਸਧਾਰਨ ਨਿਯਮ ਵਰਤੋ: ਫਰੇਮਵਰਕ ਕੋਡ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਕਾਲ ਕਰੇ, ਉਲਟ ਨਹੀਂ।
ਅਮਲ ਵਿੱਚ:
CreateInvoice ਜਾਂ CancelSubscription ਵਰਗੇ ਮਾਡਿਊਲਾਂ ਵਿੱਚ ਨਿਯਮ ਰੱਖੋਜੇ ਤੁਹਾਡਾ core ਲਾਜਿਕ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਫਰੇਮਵਰਕ ਬੂਟ ਕੀਤੇ ਬਿਨਾਂ ਚੱਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਹੀ ਰਾਹ 'ਤੇ ਹੋ।
ਅਡੈਪਟਰ ਇੱਕ ਛੋਟਾ “ਅਨੁਵਾਦਕ” ਹੈ ਜੋ ਤੁਹਾਡੇ ਐਪ ਅਤੇ ਕਿਸੇ ਖਾਸ ਟੂਲ/ਫਰੇਮਵਰਕ ਵਿਚਕਾਰ ਰਹਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਕੋਰ ਤੁਹਾਡੇ ਆਪਣੇ ਇੰਟਰਫੇਸ (ਉਦਾਹਰਨ: EmailSender, PaymentsStore) ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ, ਤੇ ਅਡੈਪਟਰ ਉਸਨੂੰ ਚੁਣੇ ਹੋਏ SDK ਜਾਂ ਫਰੇਮਵਰਕ API ਨਾਲ ਜੁੜਦਾ ਹੈ।
ਇਸ ਨਾਲ ਮਾਈਗ੍ਰੇਸ਼ਨ ਫੋਕਸਡ ਹੁੰਦੀ ਹੈ: ਅਡੈਪਟਰ ਨੂੰ ਬਦਲੋ, ਸاری ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਨਹੀਂ।
ਪਹਿਲਾਂ ਥੱਲੇ-ਉਸਾਰੀ ਤੇ ਅਨੁਸਾਰ ਸਟੇਬਲ contracts ਬਣਾਓ (request/response shapes, events, domain objects), ਫਿਰ:
ਇਸ ਨਾਲ UI/API ਕਿਸੇ ORM ਮਾਡਲ ਜਾਂ ਫਰੇਮਵਰਕ ਦੀ serialization 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦਾ।
ਟੈਸਟਸ ਵਿਵਹਾਰ ਨੂੰ ਵਰਨਣ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ—ਇਸ ਲਈ ਉਹ ਰੀਫੈਕਟਰ ਅਤੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਂਦੇ ਹਨ। ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ:
ਜੇ ਤੁਹਾਡੇ ਟੈਸਟਸ ਨੂੰ ਪੂਰੇ ਫਰੇਮਵਰਕ ਬੂਟ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਹ ਵੀ ਇੱਕ ਹੋਰ ਡਰਾਇਵਰ ਆਫ ਲੌਕ-ਇਨ ਬਣ ਸਕਦੇ ਹਨ।
PR ਗਾਈਡਰੈਲਸ (ਖਾਸ ਕਰਕੇ AI-ਸਹਾਇਤਾ ਵਾਲੀਆਂ PRs) ਲਈ:
જો diff ਬਹੁਤ ਵੱਡਾ ਹੈ ਤਾਂ ਉਸਨੂੰ ਵੰਡੋ—ਵੱਡੇ AI ਰੀਫੈਕਟਰ ਆਮ ਤੌਰ 'ਤੇ ਬਿਹੇਵਿਅਰ ਬਦਲ ਸਕਦੇ ਹਨ।