ਬਣਾਏ ਗਏ ਕੋਡ ਨੂੰ ਰੱਖਿਆਯੋਗ ਰੱਖੋ: ਬੋਰਿੰਗ ਆਰਕੀਟੈਕਚਰ ਨਿਯਮ

ਬਣਾਏ ਗਏ ਕੋਡ ਨਾਲ ਮੈਨਟੇਨੇਬਿਲਟੀ ਕਿਉਂ ਮੁਸ਼ਕਿਲ ਹੁੰਦੀ ਹੈ

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

ਜਨਰੇਟ ਕੀਤਾ ਨਤੀਜਾ ਅਕਸਰ ਅਲੱਗ ਵਿਚ ਠੀਕ ਲਗਦਾ ਹੈ। ਲਾਗਤ ਦੂਜੇ ਜਾਂ ਤੀਜੇ ਬਦਲਾਅ 'ਤੇ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: ਤੁਸੀਂ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਕਿ ਕੋਈ ਟੁਕੜਾ ਕਿਸ ਥਾਂ ਹੈ, ਇੱਕੋ ਬਿਹੈਵਿਅਰ ਦੋ ਥਾਵਾਂ 'ਤੇ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਾਂ ਤੁਸੀਂ ਕਿਸੇ ਫਾਇਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਘਬਰਾਂਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਹੋਰ ਕੀ ਪ੍ਰਭਾਵ ਪਾਵੇਗਾ।

“ਚਤੁਰ” ਢਾਂਚਾ ਮਹਿੰਗਾ ਪੈਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ। ਕਸਟਮ ਪੈਟਰਨ, ਲੁਕਿਆ ਹੋਇਆ ਜਾਦੂ ਅਤੇ ਭਾਰੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਪਹਿਲੇ ਦਿਨ ਸਮਝ ਆਉਂਦੀਆਂ ਹਨ। ਛੇ ਹਫ਼ਤੇ 'ਤੇ, ਅਗਲਾ ਬਦਲਾਅ ਸਲੋ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅੱਪਡੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫਿਰ ਤੋਂ ਉਹ ਟ੍ਰਿਕ ਸਿੱਖਣੀ ਪੈਂਦੀ ਹੈ। AI-ਸਹਾਇਤ ਜਨਰੇਸ਼ਨ ਨਾਲ, ਉਹ ਚਤੁਰਾਈ ਭਵਿੱਖ ਦੀਆਂ ਜਨਰੇਸ਼ਨਾਂ ਨੂੰ ਵੀ ਉਲਝਾ ਸਕਦੀ ਹੈ ਅਤੇ ਤਰਤੀਆਨ ਲੌਜਿਕ ਦੀ ਨਕਲ ਜਾਂ ਨਵੇਂ ਲੇਅਰਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ।

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

ਇੱਕ ਸਧਾਰਨ ਮਕਸਦ: ਅਗਲਾ ਬਦਲਾਅ ਆਸਾਨ ਬਣਾਓ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਹੀਂ। ਅਕਸਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਹਰ ਕਿਸਮ ਦੇ ਕੋਡ ਲਈ ਇੱਕ ਸਾਫ਼ ਥਾਂ (UI, API, ਡੇਟਾ, ਸ਼ੇਅਰਡ ਯੂਟੀਲੀਟੀਆਂ), ਉਸ ਫਾਇਲ ਦੇ ਕੰਮ ਨਾਲ ਮਿਲਦੇ ਨਾਂ ਅਤੇ ਘੱਟ ਤੋਂ ਘੱਟ “ਜਾਦੂ” ਜਿਵੇਂ ਆਟੋ-ਵਾਇਰਿੰਗ, ਲੁਕਿਆ ਗੋਲਬਲ ਜਾਂ ਮੈਟା-ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਤੋਂ ਬਚਨਾ।

ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ Koder.ai ਨੂੰ “ਟੀਮ ਇਨਵਾਈਟ” ਜੋੜਨ ਲਈ ਕਹੋ, ਤਾਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ UI ਨੂੰ UI ਖੇਤਰ ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇ, API ਵਿੱਚ ਇੱਕ ਰੂਟ ਹੋਵੇ, ਅਤੇ ਇਨਵਾਈਟ ਡੇਟਾ ਡੇਟਾ ਲੇਅਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ—ਨਵਾਂ ਫੋਲਡਰ ਜਾਂ ਨਵੀਂ ਪੈਟਰਨ ਬਣਾਉਂਦੇ ਬਿਨਾਂ। ਇਹ ਬੋਰਿੰਗ ਸਟਿਕਤਾ ਹੀ ਭਵਿੱਖੀ ਸੋਧ ਸਸਤੀ ਰੱਖਦੀ ਹੈ।

ਬੋਰਿੰਗ ਆਰਕੀਟੈਕਚਰ ਨਿਯਮ

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

ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਇਹ ਫੀਚਰ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ?
• ਨਵੀਂ ਫਾਇਲ ਕਿੱਥੇ ਪਾਉਂਦਾ/ਪਾਉਂਦੀ ਹਾਂ?
• ਮੈਂ ਇਸਦਾ ਨਾਮ ਕੀ ਰੱਖਾਂ?
• UI ਤੋਂ ਡੇਟਾ ਤੱਕ ਸਭ ਤੋਂ ਸਿੱਧਾ ਰਸਤਾ ਕੀ ਹੈ?

ਨਿਯਮ

ਇੱਕ ਸਧਾਰਨ ਢਾਂਚਾ ਚੁਣੋ ਅਤੇ ਸਭ ਥਾਂ ਇਸ ਤੇ ਠਾਹਰੋ। ਜਦੋਂ ਕੋਈ ਟੂਲ (ਜਾਂ ਸਾਥੀ) ਕੋਈ ਫੈਂਸੀ ਪੈਟਰਨ ਸੁਝਾਏ, ਤਦੱਕੀ ਡਿਫੌਲਟ ਜਵਾਬ “ਨਹੀਂ” ਹੁੰਦਾ ਹੈ ਜਦ ਤੱਕ ਉਹ ਅਸਲ ਦਰਦ ਦੂਰ ਨਾ ਕਰੇ।

ਲੰਬੇ ਸਮੇਂ ਤਕ ਟਿਕਦੇ ਪ੍ਰੈਕਟਿਕਲ ਡਿਫੌਲਟ:

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

ਇਕ ਛੋਟਾ ਮਨੋ-ਟੈਸਟ

ਕੱਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਨਵਾਂ ਡੈਵਲਪਰ ਤੁਹਾਡੇ ਰੇਪੋ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ “Cancel subscription” ਬਟਨ ਜੋੜਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਉਸਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਕਸਟਮ ਆਰਕੀਟੈਕਚਰ ਸਿੱਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਉਸਨੂੰ ਇੱਕ ਸਾਫ਼ ਫੀਚਰ ਖੇਤਰ, ਇੱਕ ਸਾਫ਼ UI ਕੰਪੋਨੈਂਟ, ਇੱਕ ਏਕ API ਕਲਾਇੰਟ ਥਾਂ, ਅਤੇ ਇੱਕ ਏਕ ਡੇਟਾ ਐਕਸੇਸ ਰਸਤਾ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਹ ਨਿਯਮ vibe-coding ਟੂਲਾਂ ਵਰਗੇ Koder.ai ਨਾਲ ਖਾਸ ਤੌਰ 'ਤੇ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਹਰ ਵਾਰੀ ਆਉਟਪੁਟ ਨੂੰ ਇਕੋ ਬੋਰਿੰਗ ਸੀਮਾਵਾਂ ਵਿੱਚ ਦਿਸ਼ਾ ਦਿਓ।

ਆਸਾਨ ਫੋਲਡਰ ਸੀਮਾਵਾਂ ਜੋ ਸਕੇਲ ਕਰਦੀਆਂ ਹਨ

ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ। ਇਸਨੂੰ ਮੈਨਟੇਨ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਇੱਕ ਬੋਰਿੰਗ ਫੋਲਡਰ ਨਕਸ਼ਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਵੀ ਅਨੁਮਾਨ ਲਗਾ ਸਕੇ ਕਿ ਬਦਲਾਅ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ।

ਕਈ ਵੈੱਬ ਐਪਸ ਲਈ ਇੱਕ ਛੋਟਾ ਟੌਪ-ਲੇਵਲ ਲੇਆਉਟ:

• app/ ਸਕ੍ਰੀਨ, ਰਾਊਟਿੰਗ, ਅਤੇ ਪੇਜ਼-ਸਤਰ ਸਟੇਟ
• components/ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ UI ਟੁਕੜੇ
• features/ ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਫੋਲਡਰ (billing, projects, settings)
• api/ API ਕਲਾਇੰਟ ਕੋਡ ਅਤੇ ਰਿਕਵੈਸਟ ਹੈਲਪਰ
• server/ ਬੈਕਐਂਡ ਹੈਂਡਲਰ, ਸਰਵਿਸ ਅਤੇ ਬਿਜ਼ਨਸ ਰੂਲ

ਇਸ ਨਾਲ ਸੀਮਾਵਾਂ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ: UI app/ ਅਤੇ components/ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, API ਕਾਲਾਂ api/ ਵਿੱਚ ਹਨ, ਅਤੇ ਬੈਕਐਂਡ ਲਾਜ਼ਿਕ server/ ਵਿੱਚ।

ਡੇਟਾ ਐਕਸੇਸ ਵੀ ਬੋਰਿੰਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। SQL ਕੁਏਰੀਆਂ ਅਤੇ ਰਿਪੋਜ਼ਿਟਰੀ ਕੋਡ ਨੂੰ ਬੈਕਐਂਡ ਨੇੜੇ ਰੱਖੋ, UI ਫਾਇਲਾਂ ਵਿੱਚ ਆਪਣੇ-ਆਪ ਹੀ ਨਾਂ ਫਿਖਲਾਓ। Go + PostgreSQL ਸੈੱਟਅਪ ਵਿੱਚ, ਸਧਾਰਨ ਨਿਯਮ ਇਹ ਹੈ: HTTP ਹੈਂਡਲਰ ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਸਰਵਿਸਿਜ਼ ਰਿਪੋਜ਼ਿਟਰੀਜ਼ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਰਿਪੋਜ਼ਿਟਰੀਜ਼ ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ।

ਸ਼ੇਅਰਡ ਟਾਈਪਸ ਅਤੇ ਯੂਟੀਲੀਟੀਜ਼ ਲਈ ਸਪਸ਼ਟ ਘਰ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਕ੍ਰਾਸ-ਕੱਟਿੰਗ ਟਾਈਪਸ types/ ਵਿੱਚ ਰੱਖੋ (DTOs, enums, shared interfaces) ਅਤੇ ਛੋਟੇ ਹੈਲਪਰ utils/ ਵਿੱਚ (date formatting, simple validators). ਜੇ utils/ ਦੂਜੇ ਐਪ ਵਾਂਗ ਭਰਣ ਲੱਗੇ, ਤਾਂ ਕੋਡ ਸ਼ਾਇਦ ਫੀਚਰ ਫੋਲਡਰ ਵਿੱਚ ਹੀ ਹੋਵੈ।

ਜਨਰੇਟ ਕੀਤੇ ਕੌਨਟਰਾਸٹ ਤੇ ਹੱਥ ਨਾਲ ਲਿਖੇ ਕੋਡ

ਜਨਰੇਟ ਹੋਏ ਫੋਲਡਰਾਂ ਨੂੰ ਬਦਲਣਯੋਗ ਸਮਝੋ।

• ਜਨਰੇਟ ਆਉਟਪੁਟ generated/ (ਜਾਂ gen/) ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਸਿੱਧਾ ਸੋਧਣ ਤੋਂ ਬਚੋ।
• ਕਸਟਮ ਲਾਜ਼ਿਕ features/ ਜਾਂ server/ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਰੀ-ਜਨਰੇਸ਼ਨ ਇਸਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰੇ।
• ਜੇ ਤੁਹਾਨੂੰ ਜਨਰੇਟ ਕੀਤੇ ਵਿਵਹਾਰ ਵਿੱਚ ਸੋਧ ਕਰਨੀ ਪਏ, ਤਾਂ ਉਸਨੂੰ ਰੈਪ ਕਰੋ (adapter ਫਾਇਲ) ਨਾ ਕਿ ਸਰੋਤ ਨੂੰ ਸੋਧੋ।

ਉਦਾਹਰਨ: ਜੇ Koder.ai API ਕਲਾਇੰਟ ਜਨਰੇਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ generated/api/ ਵਿੱਚ ਰੱਖੋ, ਫਿਰ api/ ਵਿੱਚ ਡਿੱਠੇ wrapper ਲਿਖੋ ਜਿੱਥੇ ਤੁਸੀਂ retries, logging ਜਾਂ ਸਪਸ਼ਟ error messages ਜੋੜ ਸਕੋ ਬਿਨਾਂ ਜਨਰੇਟ ਕੀਤੇ ਫਾਇਲਾਂ ਨੂੰ ਛੇੜੇ।

ਨਾਂਕਰਨ ਨਿਯਮ ਜੋ ਭ੍ਰਮ ਰੋਕਦੇ ਹਨ

ਜਨਰੇਟ ਕੋਡ ਬਣਾਉਣਾ ਆਸਾਨ ਅਤੇ ਇਕੱਠਾ ਪਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਨਾਂਕਰਨ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਮਹੀਨੇ ਬਾਦ ਇਸਨੂੰ ਪঢ়ਨਯੋਗ ਰੱਖਦੀ ਹੈ।

ਇੱਕ ਨਾਂਕਰਨ ਸਟਾਈਲ ਚੁਣੋ ਅਤੇ ਮਿਲਾਉਣ ਨਾ ਕਰੋ:

• ਫੋਲਡਰ ਅਤੇ ਫਾਇਲਾਂ: kebab-case (user-profile-card.tsx, billing-settings)
• React ਕੰਪੋਨੈਂਟਸ: PascalCase (UserProfileCard)
• ਫੰਕਸ਼ਨ ਅਤੇ ਵੈਰੀਏਬਲ: camelCase (getUserProfile)
• constants: SCREAMING_SNAKE_CASE (MAX_RETRY_COUNT)

ਰੋਲ ਨਾਲ ਨਾਂ ਕਰੋ, ਨਾ ਕਿ ਇਸ ਨਾਲ ਕਿ ਇਹ ਅਜੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। user-repository.ts ਇਕ ਰੋਲ ਹੈ। postgres-user-repository.ts ਇੱਕ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਵੇਰਵਾ ਹੈ ਜੋ ਬਦਲ ਸਕਦਾ ਹੈ। ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ ਸਫਿਕਸ صرف ਉਦੋਂ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਵਾਸਤਵ ਵਿੱਚ ਇਕ ਤੋਂ ਵੱਧ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨਾਂ ਹੋਣ।

misc, helpers, ਜਾਂ ਵੱਡਾ utils ਜਿਹੇ ਜੰਕ ਡਰਾਵਰ ਤੋਂ ਬਚੋ। ਜੇ ਕੋਈ ਫੰਕਸ਼ਨ ਸਿਰਫ ਇੱਕ ਫੀਚਰ ਵੱਲੋਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਉਸ ਫੀਚਰ ਦੇ ਨੇੜੇ ਰੱਖੋ। ਜੇ ਇਹ ਸ਼ੇਅਰਡ ਹੈ, ਤਾਂ ਨਾਮ ਕੈਪੇਬਿਲਟੀ ਦਰਸਾਏ (date-format.ts, money-format.ts, id-generator.ts) ਅਤੇ ਮੋਡੀਊਲ ਛੋਟਾ ਰੱਖੋ।

ਨੈਵੀਗੇਸ਼ਨ ਤੇਜ਼ ਕਰਨ ਵਾਲੇ ਕਨਵੈਨਸ਼ਨ

ਜਦੋਂ ਰੂਟਸ, ਹੈਂਡਲਰ ਅਤੇ ਕੰਪੋਨੈਂਟ ਇੱਕ ਪੈਟਰਨ ਫਾਲੋ ਕਰਨ, ਤੁਸੀਂ ਖੋਜੇ ਬਿਨਾਂ ਚੀਜ਼ਾਂ ਲੱਭ ਸਕਦੇ ਹੋ:

• Routes: routes/users.ts ਨਾਲ paths ਵਰਗੇ /users/:userId
• Handlers (HTTP): handlers/users.get.ts, handlers/users.update.ts
• Services (business rules): services/user-profile-service.ts
• Data access: repositories/user-repository.ts
• UI components: components/user/UserProfileCard.tsx

ਜੇ ਤੁਸੀਂ Koder.ai (ਜਾਂ ਕੋਈ ਵੀ ਜਨਰੇਟਰ) ਵਰਤਦੇ ਹੋ, ਤਾਂ ਇਹ ਨਿਯਮ ਪ੍ਰੰਪਟ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਸੰਪਾਦਨਾਂ ਦੌਰਾਨ ਇਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਰੱਖੋ। ਮੁਦਦਾ ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਹੈ: ਜੇ ਤੁਸੀਂ ਫਾਇਲ ਨਾਮ ਦਾ ਅਨੁਮਾਨ ਲਗਾ ਸਕਦੇ ਹੋ, ਤਦ ਭਵਿੱਖੀ ਸੋਧ ਸਸਤੀ ਰਹੇਗੀ।

ਕੋਈ-ਚਤੁਰਾਈ ਡਿਫੌਲਟ (ਰੂਲ ਆਫ਼ ਥੰਬ)

ਜਨਰੇਟ ਕੋਡ ਪਹਿਲੇ ਦਿਨ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਅਤੇ ਤੀਜੇ ਹਫ਼ਤੇ ਦਰਦਨਾਕ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ। ਉਹ ਡਿਫੌਲਟ ਚੁਣੋ ਜੋ ਕੋਡ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ, ਭਾਵੇਂ ਥੋੜ੍ਹਾ ਦੁਹਰਾਉ ਹੋਵੇ।

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

ਸਪਸ਼ਟ ਇਮਪੋਰਟਸ ਅਤੇ dependencies ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਜੇ ਕਿਸੇ ਫਾਇਲ ਨੂੰ ਕੁਝ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਸਿੱਧਾ import ਕਰੋ। ਜੇ ਮੋਡੀਊਲਜ਼ ਨੂੰ ਵਾਇਰਿੰਗ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕ ਵੀਜ਼ੀਬਲ ਥਾਂ 'ਤੇ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ single composition ਫਾਇਲ)। ਪਾਠਕ ਨੂੰ ਇਹ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਣਾ ਚਾਹੀਦਾ ਕਿ ਪਹਿਲਾ ਕੀ ਚਲਦਾ ਹੈ।

ਕੰਫਿਗਰੇਸ਼ਨ ਨੂੰ ਬੋਰਿੰਗ ਅਤੇ ਕੇਂਦ੍ਰਿਤ ਰੱਖੋ। environment variables, feature flags, ਅਤੇ app-ਵਿਆਪੀ ਸੈਟਿੰਗਜ਼ ਇੱਕ ਮੋਡੀਊਲ ਵਿੱਚ ਇਕੋ ਨਾਂਕਰਨ ਯੋਜਨਾ ਨਾਲ ਰੱਖੋ। ਆਸਾਨੀ ਲਈ ਕੁਝ ਫਾਇਲਾਂ ਵਿੱਚ ਕੰਫਿਗ ਨਾ ਫੈਲਾਓ।

ਕੁਝ ਰੂਲ ਆਫ਼ ਥੰਬ:

• explicit ਨੂੰ implicit 'ਤੇ ਤਰਜੀਹ ਦਿਓ (imports, routing, DI, side effects)
• ਜੇ 10 ਲਾਈਨਾਂ ਬਚਦੀਆਂ ਹੋਣ ਪਰ ਇੱਕ ਨਵੀਂ ਸੰਕਲਪਵਾਦੀ ਚੀਜ਼ ਆ ਜਾਂਦੀ ਹੈ ਤਾਂ ਉਸਨੂੰ ਛੱਡ ਦਿਓ
• ਇਕੋ ਤਰੀਕੇ ਦੀ ਚੀਜ਼ ਰੱਖੋ (ਇਕ logging tool, ਇਕ config module)
• hidden observers ਜਾਂ event chains ਦੇ ਬਦਲੇ ਸਧਾਰਨ ਡੇਟਾ ਫਲੋ ਨੂੰ ਤਰਜੀਹ ਦਿਓ
• ਡੀਬਰੱਗਿੰਗ ਦੌਰਾਨ ਪਹਿਲਾਂ ਚਤੁਰ ਕੋਡ ਹਟਾਓ

ਗਲਤੀ ਸੰਭਾਲਣ ਓਥੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਪਹੁੰਚਾਂਦੀ ਹੈ। ਇੱਕ ਪੈਟਰਨ ਚੁਣੋ ਅਤੇ ਹਰ ਥਾਂ ਉਹੀ ਵਰਤੋ: ਡੇਟਾ ਲੇਅਰ ਤੋਂ ਸੰਰਚਿਤ errors ਵਾਪਸ ਕਰੋ, ਉਨ੍ਹਾਂ ਨੂੰ HTTP responses ਵਿੱਚ ਇੱਕ ਸਥਾਨ 'ਤੇ ਮੈਪ ਕਰੋ, ਅਤੇ UI ਬਾਊਂਡਰੀ 'ਤੇ ਉਪਭੋਗਤਾ ਲਈ ਸੁਨੇਹੇ ਤਿਆਰ ਕਰੋ। ਫਾਇਲਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਤਿੰਨ ਵੱਖ-ਵੱਖ error types ਨਾ ਸੁੱਟੋ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਐਪ ਜਨਰੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਸ਼ੁਰੂ ਵਿੱਚ ਇਹ ਡਿਫੌਲਟ ਮੰਗੋ: ਸਪਸ਼ਟ ਮੋਡੀਊਲ ਵਾਇਰਿੰਗ, ਕੇਂਦ੍ਰਿਤ ਕੰਫਿਗ, ਅਤੇ ਇੱਕ error ਪੈਟਰਨ।

UI, API ਅਤੇ ਡੇਟਾ ਵਿਚਕਾਰ ਦੀਆਂ ਸੀਮਾਵਾਂ

UI, API, ਅਤੇ ਡੇਟਾ ਵਿਚਕਾਰ ਸਾਫ਼ ਲਾਈਨਾਂ ਬਦਲਾਅ ਨੂੰ ਘੱਟ ਰੱਖਦੀਆਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਰਹੱਸਮਈ ਬੱਗ ਉਸ ਵੇਲੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਇੱਕ ਲੇਅਰ ਦੂਜੇ ਲੇਅਰ ਦਾ ਕੰਮ ਕਰਨ ਲੱਗੇ।

UI: ਸਥਿਤੀ ਦਿਖਾਓ, ਇਨਪੁਟ ਇਕੱਠਾ ਕਰੋ

UI (ਅਕਸਰ React) ਨੂੰ ਸਕ੍ਰੀਨ ਰੈਂਡਰ ਕਰਨ ਅਤੇ UI-ਕੇਵਲ ਸਟੇਟ ਮੈਨੇਜ ਕਰਨ ਲਈ ਰੱਖੋ: ਕਿਹੜਾ ਟੈਬ ਖੁਲਿਆ ਹੈ, ਫਾਰਮ ਐਰਰ, ਲੋਡਿੰਗ ਸਪਿਨਰ ਅਤੇ ਮੁਢਲੀ ਇਨਪੁਟ ਹੈਂਡਲਿੰਗ।

ਸਰਵਰ ਸਟੇਟ ਨੂੰ ਅਲੱਗ ਰੱਖੋ: ਫੈਚ ਕੀਤੇ ਗਏ ਲਿਸਟ, cache ਕੀਤੇ profile, ਅਤੇ ਜੋ ਕੁਝ backend ਨਾਲ ਮਿਲਣਾ ਰਹਿੰਦਾ ਹੈ। ਜਦ UI ਕੰਪੋਨੈਂਟ ਟੋਟਲ ਗਣਨਾ, ਜਟਿਲ ਨਿਯਮਾਂ ਦੀ ਜਾਂਚ, ਜਾਂ permissions ਦਾ ਫੈਸਲਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਲਾਜ਼ਿਕ ਸਕ੍ਰੀਨਾਂ 'ਚ ਫੈਲ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸੋਧ ਮਹਿੰਗੀ ਹੋ ਜਾਂਦੀ ਹੈ।

API: ਪਤਲਾ, ਸਥਿਰ ਸ਼ੇਪ

API ਲੇਅਰ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਰੱਖੋ। ਇਸਨੂੰ HTTP ਬੇਨਤੀ ਨੂੰ ਬਿਜ਼ਨਸ ਕੋਡ ਤੱਕ translate ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਵਾਪਸ ਸਥਿਰ request/response ਸ਼ੇਪ ਵਿੱਚ ਬਦਲਨਾ ਚਾਹੀਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਮਾਡਲਾਂ ਨੂੰ ਸਿੱਧਾ ਵਾਇਰ 'ਤੇ ਨਾ ਭੇਜੋ। ਸਥਿਰ responses ਤੁਹਾਨੂੰ ਅੰਦਰੂਨੀ ਰੀਫੈਕਟਰਨ ਬਿਨਾਂ UI ਨੂੰ ਤੋੜੇ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੀਆਂ ਹਨ।

ਇੱਕ ਸਧਾਰਨ ਰਸਤਾ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:

• UI typed request/response objects ਨਾਲ API client ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।
• API handlers ਇਨਪੁਟ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕ service method ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ।
• Services ਬਿਜ਼ਨਸ ਰੂਲ ਅਤੇ ਵਰਕਫਲੋ ਰੱਖਦੇ ਹਨ।
• Repositories ਡੇਟਾਬੇਸ ਕੁਏਰੀਆਂ ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ ਛੋਟੇ ਮੈਥਡਸ ਦੇ ਰਾਹੀਂ।

ਡੇਟਾ: ਕੁਏਰੀਜ਼ ਨੂੰ repositories ਦੇ ਪਿੱਛੇ ਰੱਖੋ

SQL (ਜਾਂ ORM) ਲਾਜ਼ਿਕ ਨੂੰ repository ਬਾਊਂਡਰੀ ਦੇ ਪਿੱਛੇ ਰੱਖੋ ਤਾਂ ਕਿ ਬਾਕੀ ਐਪ ਨੂੰ ਪਤਾ ਨਾ ਲੱਗੇ ਕਿ ਡੇਟਾ ਕਿਵੇਂ ਸਟੋਰ ਹੈ। Go + PostgreSQL ਵਿੱਚ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ repositories ਜਿਵੇਂ UserRepo ਜਾਂ InvoiceRepo ਹੁੰਦੇ ਹਨ ਜਿੰਨ੍ਹਾਂ ਵਿੱਚ ਛੋਟੇ, ਸਪਸ਼ਟ ਮੈਥਡ ਹਨ (GetByID, ListByAccount, Save)।

ਠੋਸ ਉਦਾਹਰਨ: discount codes ਜੋੜਨਾ। UI ਇੱਕ ਫੀਲਡ ਰੈਂਡਰ ਕਰਦਾ ਹੈ ਅਤੇ ਅਪਡੇਟ ਕੀਤੀ ਕੀਮਤ ਦਿਖਾਉਂਦਾ ਹੈ। API code ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ {total, discount} ਵਾਪਸ ਕਰਦਾ ਹੈ। ਸੇਵਾ ਨਿਰਣਯ ਕਰਦੀ ਹੈ ਕਿ ਕੋਡ ਵੈਧ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ছੂਟ ਕਿਵੇਂ ਜੋੜੀ ਜਾਂਦੀ ਹੈ। ਰਿਪੋਜ਼ਿਟਰੀ ਲੋੜੀਂਦੀਆਂ ਪੰਗਤੀਆਂ ਨੂੰ ਫੈਚ ਅਤੇ ਪਰਸਿਸਟ ਕਰਦੀ ਹੈ।

ਕਦਮ-ਦਰ-कਦਮ: ਮੈਨਟੇਨੇਬਲ ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਸੈੱਟਅਪ ਕਰੋ

ਜਨਰੇਟ ਐਪਜ਼ ਤੇਜ਼ੀ ਨਾਲ “ਪੂਰੇ” ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਢਾਂਚਾ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਭਵਿੱਖੀ ਸੋਧਾਂ ਨੂੰ ਸਸਤਾ ਰੱਖਦੀ ਹੈ। ਪਹਿਲਾਂ ਬੋਰਿੰਗ ਨਿਯਮ ਤੈਅ ਕਰੋ, ਫਿਰ ਸਿਰਫ ਕਾਫ਼ੀ ਕੋਡ ਜਨਰੇਟ ਕਰੋ ਤਾਂ ਜੋ ਉਹ ਸਾਬਤ ਹੋਵੇ।

ਪ੍ਰੈਕਟਿਕਲ ਸੈਟਅਪ ਫਲੋ

ਛੋਟੀ ਯੋਜਨਾ ਪਾਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ ਤਾਂ Planning Mode ਇੱਕ ਵਧੀਆ ਥਾਂ ਹੈ ਫੋਲਡਰ ਨਕਸ਼ਾ ਅਤੇ ਕੁਝ ਨਾਂਕਰਨ ਨਿਯਮ likhne ਲਈ ਪਹਿਲਾਂ।

ਫਿਰ ਇਹ ਕ੍ਰਮ ਅਨੁਸਰ ਕਰੋ:

1. ਨਕਸ਼ਾ ਅਤੇ ਨਿਯਮ ਲਿਖ ਕੇ ਪਯਾਰ ਕਰਲੋ। ਸੀਮਾਵਾਂ ਚੁਣੋ (ਉਦਾਹਰਨ: ui/, api/, data/, features/) ਅਤੇ ਕੁਝ ਨਾਂਕਰਨ ਨਿਯਮ।
2. ਇੱਕ ਪਤਲਾ ਵਰਟਿਕਲ ਸਲਾਈਸ ਜਨਰੇਟ ਕਰੋ। ਇੱਕ ਛੋਟਾ ਫੀਚਰ ਚੁਣੋ ਜੋ UI, API ਅਤੇ ਸਟੋਰੇਜ ਨੂੰ ਛੂਹਦਾ ਹੋ, ਜਿਵੇਂ “create a contact।” ਮਕਸਦ end-to-end ਰਸਤਾ ਹੈ, ਪੂਰਨਤਾ ਨਹੀਂ।
3. ਤੁਰੰਤ ਰੀਫੈਕਟਰ ਕਰੋ ਤਾਂ ਕਿ ਸੀਮਾਵਾਂ ਮਿਲਣ। ਕੋਡ ਨੂੰ ਯੋਜਿਤ ਫੋਲਡਰਾਂ ਵਿੱਚ move ਕਰੋ, ਅਸਪਸ਼ਟ ਫਾਇਲਾਂ ਦੇ ਨਾਮ ਬਦਲੋ, ਅਤੇ ਨਕਲ ਹਟਾਓ। ਉਹ ਫੰਕਸ਼ਨ ਜੋ “ਸਭ ਕੁਝ” ਕਰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ UI, ਹੈਂਡਲਰ ਅਤੇ ਡੇਟਾ ਐਕਸੇਸ ਵਿੱਚ ਵੰਡੋ।
4. ਦੂਜਾ ਫੀਚਰ ਜੋੜੋ ਤਾਂ ਕਿ ਆਕਾਰ ਪਰੀਖਿਆ ਹੋ ਸਕੇ। ਕੁਝ ਮਿਲਦਾ ਜੁਲਦਾ ਚੁਣੋ, ਜਿਵੇਂ “list contacts।” ਜੇ ਤੁਹਾਨੂੰ ਆਪਣੇ ਨਿਯਮ ਤੋੜਣ ਲਈ ਮੱਜਬੂਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਸੀਮਾਵਾਂ ਸ਼ਾਇਦ ਗਲਤ ਹਨ।
5. ਰੱਖਿਆ ਨੂੰ ਜਲਦੀ ਲੌਕ ਕਰੋ। ਇੱਕ ਛੋਟੀ CONVENTIONS.md ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਇਕ ਕਾਨਟਰੈਕਟ ਵਾਂਗ ਪ੍ਰਵਾਹਿਤ ਕਰੋ। ਜਦੋਂ ਕੋਡਬੇਸ ਵਧਦਾ ਹੈ, ਨਾਂ ਅਤੇ ਫੋਲਡਰ ਪੈਟਰਨ ਬਦਲਣਾ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ।

ਹਕੀਕਤ ਚੈੱਕ: ਜੇ ਨਵਾਂ ਵਿਅਕਤੀ “edit contact” ਕਿੱਥੇ ਪਾਉਣਾ ਹੈ ਬਿਨਾਂ ਪੁੱਛੇ ਅਨੁਮਾਨ ਨਹੀਂ ਲਗਾ ਸਕਦਾ, ਤਾਂ ਆਰਕੀਟੈਕਚਰ ਅਜੇ ਵੀ ਕਾਫ਼ੀ ਬੋਰਿੰਗ ਨਹੀਂ ਹੈ।

ਉਦਾਹਰਨ ਦ੍ਰਿਸ਼: ਫੀਚਰ ਜੋੜਨਾ ਬਿਨਾਂ ਗੰਦਾ ਕੀਤੇ

ਇੱਕ ਸਧਾਰਨ CRM ਦੀ ਕਲਪਨਾ ਕਰੋ: contacts list ਪੇਜ਼ ਅਤੇ contact edit ਫਾਰਮ। ਪਹਿਲੀ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾਈ, ਫਿਰ ਹਫ਼ਤੇ ਬਾਦ “tags” ਜੋੜਣੀ ਹੈ।

ਐਪ ਨੂੰ ਤਿੰਨ ਬੋਰਿੰਗ ਡਿਬਬਕਸ ਵਾਂਗ ਸੋਚੋ: UI, API, ਅਤੇ ਡੇਟਾ। ਹਰ ਡਿਬਬਕਸ ਨੂੰ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਤੇ ਲੇਖੇ ਨਾਮ ਦਿਓ ਤਾਂ ਕਿ “tags” ਬਦਲਾਅ ਛੋਟਾ ਰਹੇ।

ਇੱਕ ਸਾਫ਼ ਲੇਆਉਟ ਅਜਿਹਾ ਹੋ ਸਕਦਾ ਹੈ:

• web/src/pages/ContactsPage.tsx and web/src/components/ContactForm.tsx
• server/internal/http/contacts_handlers.go
• server/internal/service/contacts_service.go
• server/internal/repo/contacts_repo.go
• server/migrations/

ਹੁਣ “tags” ਅਕਸਰਨਾ ਬਹੁਤ ਹੀ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ। schema ਅੱਪਡੇਟ ਕਰੋ (ਨਵਾਂ contact_tags ਟੇਬਲ ਜਾਂ tags ਕੌਲਮ), ਫਿਰ ਇੱਕ-ਇਕ ਲੇਅਰ ਨੂੰ ਛੂਹੋ: repo tags ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ, service ਵੈਧਤਾ ਕਰਦਾ ਹੈ, handler ਫੀਲਡ ਨੂੰ ਐਗਜ਼ਪੋਜ਼ ਕਰਦਾ ਹੈ, UI ਉਸਨੂੰ ਰੈਂਡਰ ਅਤੇ ਐਡਿਟ ਕਰਦਾ ਹੈ। handlers ਵਿੱਚ SQL ਛੱਡੋ ਜਾਂ React ਵਿੱਚ ਬਿਜ਼ਨਸ ਲਾਜ਼ਿਕ ਨਾ ਪਾਉ।

Tests ਅਤੇ fixtures ਲਈ ਚੀਜ਼ਾਂ ਨੂੰ ਕੋਡ ਦੇ ਨੇੜੇ ਛੋਟਾ ਰੱਖੋ:

• server/internal/service/contacts_service_test.go ਜਿਵੇਂ ਨਿਯਮਾਂ ਲਈ “tag names should be unique per contact”
• server/internal/repo/testdata/ ਲਈ ਘੱਟੋ-ਘੱਟ fixtures
• web/src/components/__tests__/ContactForm.test.tsx ਫਾਰਮ ਵਿਹਾਰ ਲਈ

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਇਹ ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ export ਤੋਂ ਬਾਅਦ ਵੀ ਇਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਫੋਲਡਰਾਂ ਨੂੰ ਬੋਰਿੰਗ ਰੱਖੋ, ਨਾਂਕਰਨ ਲਿਟਰਲ ਰੱਖੋ, ਅਤੇ ਸੋਧਾਂ ਅਰਕੀਓਲੋਜੀ ਵਰਗੀ ਮਹਿਸੂਸ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਭਵਿੱਖੀ ਸੋਧ ਮਹਿੰਗੀ ਬਣਾਉਂਦੀਆਂ ਹਨ

ਜਨਰੇਟ ਕੀਤਾ ਕੋਡ ਪਹਿਲੇ ਦਿਨ ਸਾਫ਼ ਦikhda ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਬਾਦ ਵਿੱਚ ਮਹਿੰਗਾ ਪੈ ਸਕਦਾ ਹੈ। ਆਮ ਕਾਰਨ “ਖਰਾਬ ਕੋਡ” ਨਹੀਂ, ਬਲਕਿ ਅਸੰਗਤਤਾ ਹੈ।

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

ਦੂਜਾ ਫੰਦਰ ਲੇਅਰਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੈ। ਜਦ UI ਕੰਪੋਨੈਂਟ ਡੇਟਾਬੇਸ ਨਾਲ ਗੱਲ ਕਰੇ ਜਾਂ API handler SQL ਬਣਾਏ, ਛੋਟੇ ਬਦਲਾਅ ਐਪ ਚੌੜੇ ਖਤਰਨਾਕ ਐਡੀਟ ਬਣ ਜਾਂਦੇ ਹਨ। ਸੀਮਾ ਰੱਖੋ: UI API ਨੂੰ ਕਾਲ ਕਰਦਾ, API service ਨੂੰ ਕਾਲ ਕਰਦਾ, service data access ਨੂੰ ਕਾਲ ਕਰਦੀ।

ਵੱਡੀ-ਪੈਮਾਨੇ 'ਤੇ ਜਨਰਲ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਵੱਧ ਵਰਤਣਾ ਵੀ ਲਾਗਤ ਵਧਾਉਂਦਾ ਹੈ। ਇੱਕ Universal “BaseService” ਜਾਂ “Repository” ਫਰੇਮਵਰਕ ਸ਼ੁਰੂ ਵਿੱਚ ਚੰਗਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਸ਼ੁਰੂਆਤੀ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਅਨੁਮਾਨ ਹਨ। ਜਦ ਅਸਲ 현실 ਬਦਲਦੀ ਹੈ, ਤੁਸੀਂ ਆਪਣੇ ਫਰੇਮਵਰਕ ਨਾਲ ਲੜਦੇ ਹੋ ਬਜਾਏ ਸ਼ਿਪ ਕਰਨ ਦੇ।

ਲਗਾਤਾਰ ਨਾਂ-ਬਦਲਣਾ ਅਤੇ reorganizing ਵੀ ਚੁਪੀ-ਚੁਪੀ ਕਰਜ਼ ਵਧਾਉਂਦਾ ਹੈ। ਜੇ ਫਾਇਲਆਂ ਹਫ਼ਤੇ ਵਿੱਚ ਹਰ ਵੇਲੇ move ਹੁੰਦੀਆਂ ਹਨ, ਲੋਕ layout 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ਅਤੇ ਤੇਜ਼ fixes ਬੇਰਤੀ ਥਾਵਾਂ 'ਤੇ ਆਉਂਦੀਆਂ ਹਨ। ਪਹਿਲਾਂ ਫੋਲਡਰ ਨਕਸ਼ਾ ਸਥਿਰ ਕਰੋ, ਫਿਰ ਯੋਜਨਾਬੱਧ ਰੀਫੈਕਟਰ ਕਰੋ।

ਅਖੀਰਕਾਰ, “ਪਲੇਟਫਾਰਮ ਕੋਡ” ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ ਜਿਸਦੀ ਕੋਈ ਅਸਲ ਯੂਜ਼ਰ ਡੀਮਾਂਡ ਨਾ ਹੋਵੇ। ਸ਼ੇਅਰਡ লাইਬਰੇਰੀਆਂ ਅਤੇ ਘਰੇਲੂ ਟੂਲਿੰਗ ਸਿਰਫ਼ ਉਹ ਸਮੇਂ ਹੀ ਲਾਭਦੇ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਵਾਰ-ਵਾਰ ਦੀ ਲੋੜ ਸਾਬਤ ਹੋਵੇ। ਉਸ ਤੱਕ, ਡਿਫੌਲਟ ਸਿੱਧਾ ਰੱਖੋ।

ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਛੇਤੀ ਚੈੱਕਲਿਸਟ

ਜੇ ਕੋਈ ਨਵਾਂ ਬੰਦਾ ਰੇਪੋ ਖੋਲ੍ਹੇ, ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਪ੍ਰਸ਼ਨ ਦਾ ਜਵਾਬ ਦੇ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ: “ਮੈਂ ਇਹ ਕਿੱਥੇ ਜੋੜਾਂ?”

2-ਮਿੰਟ ਨੈਵੀਗੇਸ਼ਨ ਟੈਸਟ

ਪ੍ਰੋਜੈਕਟ ਕਿਸੇ ਸਾਥੀ (ਜਾਂ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ) ਨੂੰ ਦਿਓ ਅਤੇ ਪੁੱਛੋ ਕਿ ਉਹ ਇੱਕ ਛੋਟੀ ਫੀਚਰ ਜੋੜੇ, ਜਿਵੇਂ “signup ਫਾਰਮ ਵਿੱਚ ਇੱਕ ਫੀਲਡ ਜੋੜੋ।” ਜੇ ਉਹ ਸਹੀ ਜਗ੍ਹਾ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭਦੇ, ਤਾਂ ਢਾਂਚਾ ਆਪਣਾ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਤਿੰਨ ਸਪਸ਼ਟ ਘਰਾਂ ਦੀ ਜਾਂਚ ਕਰੋ:

• UI ਬਦਲਾਅ ਇੱਕ ਸਪਸ਼ਟ ਥਾਂ 'ਤੇ ਹਨ।
• UI ਤੋਂ API routes/handlers ਲਭਣੇ ਆਸਾਨ ਹਨ।
• ਡੇਟਾ ਮਾਡਲ ਅਤੇ DB ਬਦਲਾਅ ਦੀ ਇੱਕ ਸਪਸ਼ਟ ਥਾਂ ਹੈ।

ਰਿਵਿਊ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਯੋਗ ਨਿਯਮ

• UI, API, ਅਤੇ ਡੇਟਾ ਹਰ ਇੱਕ ਦਾ ਘਰ ਹੈ, ਅਤੇ ਇਸਦੇ ਅਪਵਾਦ ਘਟੀਆ ਹਨ।
• ਨਾਂ ਲੇਬਲ ਵਾਂਗ ਪੜ੍ਹੇ ਜਾਂ, ਪਹੇਚਾਨੇ ਨਹੀਂ।
• ਲੇਅਰ ਦੀਆਂ ਹੱਦਾਂ ਲੰਘਣ ਵਾਲੇ ਮਾਮਲੇ ਫ਼ਲੈਗ ਹੋਣ (ਜਿਵੇਂ UI ਦਾ DB ਵਿੱਚ ਦਾਖ਼ਲਾ)।
• ਚਤੁਰ ਛਲਾਂਗਾਂ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਰੱਦ ਕੀਤਾ ਜਾਵੇ।

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

ਅਗਲੇ ਕਦਮ: ਬੋਰਿੰਗ ਰੱਖੋ, ਖ਼ਰਚੇ ਘਟਾਓ

ਮੈਨਟੇਨੇਬਿਲਟੀ ਤੇਜ਼ੀ ਨਾਲ ਸੁਧਾਰਦੀ ਹੈ ਜਦ ਤੁਸੀਂ ਅੰਦਾਜ਼ ਤੇ ਵਿਚਾਰ ਵੱਸ-ਵਿੱਚ ਨਾ ਕਰਕੇ ਕੁਝ ਫੈਸਲੇ ਲੈ ਲਓ ਜੋ ਟਿਕ ਸਕਣ।

ਛੋਟੀ ਕਿਸਮ ਦੀਆਂ conventions ਲਿਖੋ ਜੋ ਰੋਜ਼ਾਨਾ ਦੇ ਸੰਦੇਹ ਹਟਾ ਦੇਂ: ਫਾਇਲਾਂ ਕਿੱਥੇ ਜਾਣ, ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਨਾਂਕਰਨ ਕਰਨਾ, ਅਤੇ errors ਤੇ config ਕਿਵੇਂ ਸੰਭਾਲਣੇ। ਇਸਨੂੰ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਪੜ੍ਹਨ ਯੋਗ ਛੋਟਾ ਰੱਖੋ।

ਫਿਰ ਇੱਕ ਸਾਫ਼-ਸੁਥਰਾ cleanup ਪਾਸ ਕਰੋ ਤਾਂ ਕਿ ਉਹ ਨਿਯਮ ਮਿਡ-ਕੋਡ 'ਤੇ ਲਾਗੂ ਹੋ ਜਾਣ। ਹਰ ਹਫ਼ਤਾ reorganize ਕਰਨ ਉਡੀਕ ਬੰਦ ਕਰੋ—ਅਕਸਰ reorganizing ਅਗਲਾ ਬਦਲਾਅ ਧੀਮਾ ਕਰ ਦਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਡ ਸੁੰਦਰ ਲੱਗੇ।

ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ (koder.ai), ਇਹ ਮਦਦਗਾਰ ਹੈ ਕਿ ਇਹਨਾਂ conventions ਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੰਪਟ ਵਜੋਂ ਸੇਵ ਕਰੋ ਤਾਂ ਕਿ ਹਰ ਨਵੀਂ ਜਨਰੇਸ਼ਨ ਇੱਕੋ ਢਾਂਚੇ ਵਿੱਚ ਆਵੇ। ਟੂਲ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ, ਪਰ ਬੋਰਿੰਗ ਸੀਮਾਵਾਂ ਹੀ ਕੋਡ ਨੂੰ ਆਸਾਨ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਯੋਗ ਰੱਖਦੀਆਂ ਹਨ।