23 ਅਕਤੂ 2025·8 ਮਿੰਟ
AI-ਨਿਰਮਿਤ ਕੋਡ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਣਾ: ਪ੍ਰੋਟੋਟਾਈਪ ਤੋਂ ਟੀਮ ਹੈਂਡਾਫ ਤੱਕ
ਫੋਲਡਰ, ਨਾਂਵਾਕਰਨ ਅਤੇ ਲਿਖਤ ਇਨਵੈਰੀਅੰਟਸ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਕੇ AI-ਨਿਰਮਿਤ ਕੋਡ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਓ, ਤਾਂ ਜੋ ਇਕ ਮਨੁੱਖੀ ਟੀਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲ ਕੇ ਤਬਦੀਲੀਆਂ ਸ਼ਿਪ ਕਰ ਸਕੇ।
ਫੋਲਡਰ, ਨਾਂਵਾਕਰਨ ਅਤੇ ਲਿਖਤ ਇਨਵੈਰੀਅੰਟਸ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਕੇ AI-ਨਿਰਮਿਤ ਕੋਡ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਓ, ਤਾਂ ਜੋ ਇਕ ਮਨੁੱਖੀ ਟੀਮ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲ ਕੇ ਤਬਦੀਲੀਆਂ ਸ਼ਿਪ ਕਰ ਸਕੇ।
AI ਪ੍ਰੋਟੋਟਾਈਪ ਅਕਸਰ ਇੱਕ ਹੀ ਕਾਰਨ ਲਈ ਕੰਮਯਾਬ ਹੁੰਦੇ ਹਨ: ਇਹ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ “ਚਲਦਾ” ਹਲ ਦਿੰਦੇ ਹਨ। ਮੁਸ਼ਕਲ ਉਸ ਵੇਲੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ “ਚਲਦਾ” ਨੂੰ “ਟੀਮ ਵੱਲੋਂ ਮੈਨਟੇਨ ਹੋ ਸਕਣ ਵਾਲਾ” ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਛੋਟੇ ਰਾਹਤ-ਰਸਤੇ ਬर्दਾਸ਼ਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਕੋ ਵਿਅਕਤੀ (ਜਾਂ ਇਕੋ ਚੈਟ ਥ੍ਰੇਡ) ਕੋਲ ਸਾਰਾ ਸੰਦਰਭ ਹੁੰਦਾ ਹੈ। ਟੀਮ ਕੋਲ ਇਹ ਨਹੀ ਹੁੰਦਾ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਨਕਲ-ਪਹਿਲੇ ਮਨੁੱਖੀ ਲਿਖੇ ਕੋਡ ਨਾਲੋਂ ਸਮੀਖਿਆ ਵਿੱਚ ਥੋੜ੍ਹਾ ਮੁਸ਼ਕਲ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਨੀਅਤ ਹਮੇਸ਼ਾਂ ਵੀਜ਼ਿਬਲ ਨਹੀਂ ਹੁੰਦੀ। ਮਨੁੱਖੀ ਕੋਡ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਟਰੇਲ ਹੁੰਦੀ ਹੈ: ਸਮਰੂਪ ਪੈਟਰਨ, ਦੁਹਰਾਈਆਂ ਚੋਣਾਂ, ਤੇ ਕੁੱਝ ਟਿੱਪਣੀਆਂ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕੋਈ ਚੀਜ਼ ਕਿਉਂ ਮੌਜੂਦ ਹੈ। AI ਆਉਟਪੁੱਟ ਸਹੀ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ 스타일 ਮਿਲਾ-ਝੁਲਾ ਸਕਦੀ ਹੈ, ਫਾਇਲਾਂ ਦਰਮਿਆਨ ਪੈਟਰਨ ਬਦਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਧਾਰਨਾਵਾਂ ਉਹਨਾਂ ਜਗ੍ਹਾਂ 'ਤੇ ਛੁਪ ਜਾ ਸਕਦੀਆਂ ਹਨ ਜਿੱਥੇ ਸਮੀਖਿਆਕਾਰ ਅਨੁਮਾਨ ਨਹੀਂ ਕਰਦੇ।
ਲਕੜੀ ਦਾ ਮੰਤਵ ਪੂਰਣਤਾ ਹੈ: ਪੂਰਨ ਭਵਿੱਖ-ਪਸ਼ਚਾਤ, ਪੂਰਨ ਨਾਂ, ਪੂਰਨ ਵਰਤਾਰ। ਜਦੋਂ ਟੀਮ-ਮੈਂਬਰ ਅੰਦਾਜਾ ਲਾ ਸਕੇ ਕਿ ਕਿਸ ਚੀਜ਼ ਦਾ ਅਸਥਾਨ ਕਿੱਥੇ ਹੈ, ਇਸ ਦਾ ਨਾਮ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਕਿਵੇਂ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਸਮੀਖਿਆ ਤੇਜ਼ ਜਾਂਦੀ ਹੈ ਨਾ ਕਿ ਇਕ ਡਿਟੈਕਟਿਵ ਕਹਾਣੀ।
ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਪ੍ਰੋਟੋਟਾਈਪ ਟੀਮ ਪ੍ਰੋਜੈਕਟ ਬਣ ਜਾਂਦਾ ਹੈ:
userId vs userid vs user_id), ਜੋ ਖੋਜ ਨੂੰ ਅਣਵਿਸ਼ਵਾਸਨੀਅਕ ਬਣਾਂਦਾ ਹੈ ਅਤੇ ਬੱਗਸ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਛੱਡ ਦਿੰਦਾ ਹੈ।ਛੋਟੀਆਂ ਅਸਮਰਥਾਵਾਂ ਮੁਰੰਮਤ ਸਮੇਂ ਨੂੰ ਗੁਣਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਹਰ ਵਾਰੀ ਫੈਸਲੇ ਮੁੜ-ਕਰਵਾਉਂਦੇ ਹਨ। ਜੇ ਹਰ ਨਵੀ ਸਕ੍ਰੀਨ ਦਾ ਇੱਕ ਥੋੜਾ ਵੱਖਰਾ ਫੋਲਡਰ ਸਥਾਨ, ਕੰਪੋਨੈਂਟ ਨਾਮ, ਅਤੇ ਡਾਟਾ-ਫੈਚਿੰਗ ਸੁਟਾਈਲ ਹੋਵੇ, ਤਾਂ ਸਮੀਖਿਆਕਾਰ ਇੱਕ ਸਥਿਰ ਮਾਨਸਿਕ ਮਾਡਲ ਨਹੀਂ ਬਣਾ ਸਕਦੇ। ਉਹ ਹਰ ਵਾਰੀ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਸਿੱਖਣਾ ਪੈਂਦਾ ਹੈ।
ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇਕ ਗੈਰ-ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਇੱਕ vibe-coding ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਧਾਰਨ CRM ਤਿਆਰ ਕਰਦਾ ਹੈ। ਇਹ ਡੈਮੋ ਵਿੱਚ ਚੰਗਾ ਲੱਗਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਇਕ ਛੋਟੀ ਟੀਮ ਇਸਨੂੰ ਸੰਭਾਲਦੀ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਤਰੀਕੇ ਮਿਲਦੇ ਹਨ auth state ਸਟੋਰ ਕਰਨ ਦੇ, React ਕੰਪੋਨੈਂਟ ਲਈ ਦੋ ਨਾਂਵਾਂ ਦੇ ਸਟਾਈਲ, ਅਤੇ ਬਿਜ਼ਨਸ ਨਿਯਮ UI ਕੋਡ ਅਤੇ ਬੈਕਐਂਡ ਹੈਂਡਲਰਾਂ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਮਿਲਦੇ ਹਨ। ਕੁਝ ਵੀ “ਟੁੱਟਿਆ” ਨਹੀਂ, ਪਰ ਹਰ ਤਬਦੀਲੀ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਕਿਹੜੇ ਪੈਟਰਨ ਅਸਲ ਹਨ।
ਹੈਂਡਾਫ ਅਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਚੋਇਸਾਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹੋ। ਟੀਮ ਤੇਜ਼ ਚਲਦੀ ਹੈ ਜਦੋਂ ਕੋਡਬੇਸ ਲਗਾਤਾਰ ਦੱਸਦਾ ਹੈ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
“ਸਮੀਖਿਆਯੋਗ” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨਵਾਂ ਵਿਕਾਸਕ ਰਿਪੋ ਖੋਲ੍ਹ ਕੇ ਸਹੀ ਜਗ੍ਹਾ ਤੇ ਸੋਧ ਕਰ ਸਕੇ, ਸੋਧ ਕਰਕੇ ਇਹ ਜਾਂਚ ਸਕੇ ਕਿ ਹੋਰ ਕੁਝ ਟੁੱਟਿਆ ਤਾਂ ਨਹੀਂ। ਇਹ ਬੁਨਿਆਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਬਹੁਤ ਸਾਰੇ AI ਪ੍ਰੋਟੋਟਾਈਪ ਛੱਡ ਦਿੰਦੇ ਹਨ।
AI-ਨਿਰਮਿਤ ਕੋਡ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਣ ਲਈ, ਚਤੁਰਾਈ 'ਤੇ ਘੱਟ ਧਿਆਨ ਦੇ ਕੇ ਇਹ ਵੇਖੋ ਕਿ ਮਨੁੱਖ ਇਸਨੂੰ ਕਿੰਨੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਛੂਹ ਸਕਦਾ ਹੈ। ਸਮੀਖਿਆਯੋਗਤਾ ਤਬਦੀਲੀ ਦੇ ਖਤਰੇ ਨੂੰ ਘਟਾਉਣ ਬਾਰੇ ਹੈ।
ਜਦੋਂ ਟੀਮ-ਮੈਂਬਰ ਇੱਕ pull request ਦੀ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ, ਉਹ ਕੁਝ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਜਲਦੀ ਚਾਹੁੰਦਾ ਹੈ:
ਛੋਟੇ diffs ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ, ਪਰ “ਛੋਟਾ” ਸਿਰਫ ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ ਨਹੀਂ। ਇਸਦਾ ਮਤਲਬ ਸਥਿਰ ਸਰਹੱਦ ਵੀ ਹੈ: ਇੱਕ ਖੇਤਰ ਵਿੱਚ ਤਬਦੀਲੀ ਨੂੰ ਬੇਸਬੰਧੀ ਫਾਇਲਾਂ ਨੂੰ ਛੇੜਨਾ ਨਹੀਂ ਚਾਹੀਦਾ।
ਤੁਹਾਨੂੰ ਪੂਰਨਤਾ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਰਿਵਾਜ, ਥੋੜੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ, ਕੁਝ ਟੈਸਟਾਂ ਅਤੇ ਭਵਿੱਖੀ ਡ੍ਰਿਫਟ ਰੋਕਣ ਵਾਲੇ ਗਾਰਡਰੇਲ ਦੀ ਲੋੜ ਹੈ।
ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਇਹ ਵੇਖ ਸਕੇ:
ਉਦਾਹਰਨ: ਤੁਸੀਂ React frontend ਅਤੇ Go API ਬਣਾਇਆ। ਪ੍ਰੋਟੋਟਾਈਪ ਚਲਦਾ ਹੈ, ਪਰ “create customer” ਫਲੋ UI ਕੋਡ, API ਹੈਂਡਲਰ ਅਤੇ ਡੇਟਾਬੇਸ ਕਾਲਾਂ ਵਿੱਚ ਵੱਖਰੇ ਫੀਲਡ ਨਾਮਾਂ ਨਾਲ ਫੈਲਿਆ ਹੋਇਆ ਹੈ। ਇਸਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਣ ਦਾ ਮਤਲਬ ਹੈ ਉਹਨਾਂ ਨਾਮਾਂ ਨੂੰ ਮਿਲਾਉਣਾ, API ਬਾਊਂਡਰੀ ਨਿਰਧਾਰਤ ਰੱਖਣਾ, ਅਤੇ ਨਿਯਮ ਲਿਖ ਦੇਣਾ (ਉਦਾਹਰਨ ਲਈ, “email unique ਹੋਣਾ ਚਾਹੀਦਾ” ਅਤੇ “status ਸਿਰਫ active ਜਾਂ paused ਹੋ ਸਕਦਾ”).
ਸਭ ਕੁਝ ਪੁਨਰਲੇਖਣ ਕਰਨ ਦਾ ਟੀਚਾ ਨਾ ਰੱਖੋ ਜਦ ਤੱਕ ਇਹ ਟੈਕਸਟਬੁੱਕ ਪ੍ਰੋਜੈਕਟ ਵਰਗੀ ਨਾ ਲੱਗੇ। ਹੈਂਡਾਫ-ਰੈਡੀ ਕੋਡ ਸਾਫ, ਸੰਗਤ ਅਤੇ ਬਦਲਣ ਲਈ ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਇਹ ਸਭ ਤੋਂ ਸੁੰਦਰ ਵਰਜ਼ਨ ਨਾ ਹੋਵੇ।
ਟੀਮ ਅਣਪੂਰਨ ਕੋਡ ਨੂੰ ਮੁਆਫ ਕਰ ਸਕਦੀ ਹੈ। ਉਹਨੂੰ ਮੁਸ਼ਕਲ ਇਸ ਗੱਲ ਦੀ ਹੁੰਦੀ ਹੈ ਕਿ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਅਸਥਾਨ ਪਤਾ ਨਾ ਲੱਗੇ। ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ AI-ਨਿਰਮਿਤ ਕੋਡ ਸਮੀਖਿਆਯੋਗ ਹੋਵੇ, ਤਾਂ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸਕੈਨ ਕਰਨਾ ਆਸਾਨ ਬਣਾਓ: ਥੋੜ੍ਹੇ ਸਿੱਧੇ ਟਾਪ-ਲੈਵਲ ਫੋਲਡਰ, ਸਥਿਰ ਨਾਂवਾਂ, ਅਤੇ ਇੱਕ ਸਪੱਸ਼ਟ ਘਰ ਕਨਫਿਗਰੇਸ਼ਨ ਲਈ।
ਟਾਪ-ਲੈਵਲ ਨਕਸ਼ਾ ਐਪ ਵੱਧਣ 'ਤੇ ਸਥਿਰ ਰੱਖੋ। ਬਹੁਤ ਸਾਰੇ ਹੈਂਡਾਫ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਹਰ ਪਰਯੋਗ ਲਈ ਨਵੇਂ ਫੋਲਡਰ ਬਣ ਜਾਂਦੇ ਹਨ। ਇਸ ਦੀ ਵਜ੍ਹਾ ਹੈ ਤਿੰਨ ਚਿੰਤਾਵਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖੋ: app composition (screens, routes), core business rules, ਅਤੇ infrastructure.
ਇੱਥੇ ਇੱਕ ਪ੍ਰਯੋਗਯੋਗ ਪੈਟਰਨ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ (web app ਉਦਾਹਰਨ):
/
/app # routes/pages and UI composition
/core # domain logic: entities, rules, use-cases
/ui # reusable components, styles, design tokens
/infra # db, api clients, queues, auth adapters
/config # env schema, feature flags, app settings
/scripts # local tooling, seed data, one-off tasks
/docs # handoff notes, invariants, decisions
ਜੇ ਤੁਹਾਡੀ ਪਹਿਲੀ ਵਰਜ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਜਨਰੇਟ ਹੋਈ ਸੀ, ਤਾਂ ਉਸ ਵੰਡ ਨੂੰ ਦਿਖਾਉ। ਬਦਲਣਯੋਗ ਜਨਰੇਟ ਕੀਤੇ ਮਾਡਿਊਲਾਂ ਨੂੰ /generated ਜਿਹੇ ਫੋਲਡਰ ਦੇ ਅੰਦਰ ਰੱਖੋ, ਅਤੇ ਮਨੁੱਖ-ਸੰਪਾਦਿਤ ਮੌਡੀਊਲਾਂ ਨੂੰ /core ਜਾਂ /app ਵਿੱਚ ਰੱਖੋ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸ ਕੋਡ ਨੂੰ ਗਲਤੀ ਨਾਲ ਨੋਚ-ਫਿਰਾ ਕੇ ਬਦਲ ਨਾ ਦਿਓ ਜਿਹੜਾ ਬਾਅਦ ਵਿੱਚ ਫਿਰ ਜਨਰੇਟ ਹੋ ਸਕਦਾ ਹੈ।
ਹੈਂਡਾਫ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਕ ਤੇਜ਼ ਨੈਵੀਗੇਸ਼ਨ ਟੈਸਟ ਕਰੋ ਕਿਸੇ ਟੀਮ-ਸਾਥੀ (ਜਾਂ ਆਪਣੇ ਭਵਿੱਖ ਦੇ ਸਵੈ) ਨਾਲ। ਪੁੱਛੋ: ਲੋਗਿਨ UI ਕਿੱਥੇ ਹੈ, ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਨਿਯਮ ਕਿੱਥੇ ਹਨ, ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਕਿੱਥੇ ਡਿਫਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ, API ਬੇਸ URLs ਅਤੇ ਫੀਚਰ ਫਲੈਗ ਕਿੱਥੇ ਸੈਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਖਾਸ ਸਕ੍ਰਿਪਟ ਕਿੱਥੇ ਹਨ।
ਜੇ ਕਿਸੇ ਵੀ ਜਵਾਬ ਦੀ ਸ਼ੁਰੂਆਤ “ਇਹ ਮਤੇਦਾਰ ਹੈ” ਜਾਂ “ਸਰਚ ਕਰੋ” ਨਾਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸੰਰਚਨਾ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਢਾਲੋ ਕਿ ਹਰ ਵਿਸ਼ੇ ਲਈ ਇਕ ਸਧਾਰਨ, ਨਿਰਾਸ਼ਜਨਕ ਘਰ ਹੋਵੇ। ਉਹ ਸਧਾਰਣ ਮਹਿਸੂਸ ਹੀ ਰੱਖਰਖਾਅ ਤੇ ਤੇਜ਼ੀ ਲਿਆਉਂਦਾ ਹੈ।
ਇੱਕ ਨਾਂਵ ਪਾਲਿਸੀ ਇੱਕ ਵਾਅਦਾ ਹੈ: ਸਮੀਖਿਆਕਾਰ ਨੂੰ ਫਾਇਲ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਅੰਦਾਜ਼ਾ ਲਗ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਕੀ ਹੈ, ਕਿੱਥੇ ਰਹੇਗਾ, ਅਤੇ ਕਿਵੇਂ ਵਰਤੇਗਾ।
ਫਾਇਲ ਨਾਂਉਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਰਿਪੋ 'ਚ ਇਕ ਸਟਾਈਲ ਤੇ ਟਿਕੇ ਰਹੋ। ਇੱਕ ਸਧਾਰਨ ਡਿਫਾਲਟ ਹੈ: ਫੋਲਡਰ kebab-case ਵਿੱਚ, React ਕੰਪੋਨੈਂਟ PascalCase ਵਿੱਚ, ਅਤੇ ਨਾਨ-ਕੰਪੋਨੈਂਟ TypeScript ਫਾਇਲਾਂ camelCase ਵਿੱਚ। ਜਦੋਂ ecosystem ਕਿਸੇ ਹੋਰ ਰਵਾਇਤ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ (ਜਿਵੇਂ Flutter ਜਾਂ README ਵਰਗੀਆਂ ਸਟੈਂਡਰਡ ਫਾਇਲਾਂ), ਤਾਂ ਇਸਨੂੰ ਤੋੜੋ।
ਨਾਂਵਾਂ ਦਾ ਮਕਸਦ ਨੀਅਤ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇੰਪਲੀਮੇਂਟੇਸ਼ਨ:
BillingSummaryCard.tsx (ਇਹ ਕੀ ਦਰਸਾਂਦਾ ਹੈ)StripeCard.tsx (ਇੱਕ vendor ਚੋਣ ਨੂੰ ਫਿਕਸ ਕਰਦਾ)RenderBilling.tsx (ਕਿਵੇਂ ਕਿਸੇ ਨੂੰ ਕਰਦਾ, ਕਿਉਂ ਨਹੀਂ)ਵਿਗੜੇ ਬਕਟਾਂ ਨਾਲ ਸਖ਼ਤ ਰਹੋ। utils, helpers, ਜਾਂ common ਵਰਗੀਆਂ ਫਾਇਲਾਂ ਜਲਦੀ ਹੀ ਕੂੜੇ-ਦਰਾਜ਼ ਬਣ ਜਾਂਦੀਆਂ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਕੋਡ ਜਨਰੇਟ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸਾਂਝਾ ਕੋਡ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸਕੋਪ ਅਤੇ ਮਕਸਦ ਅਨੁਸਾਰ ਨਾਂਵ ਦਿਓ, ਉਦਾਹਰਨ ਲਈ auth/tokenStorage.ts ਜਾਂ billing/billingCalculations.ts।
ਫੀਚਰ ਫੋਲਡਰ ਯੂਜ਼ਰ ਦੀ ਸਮੱਸਿਆ ਦਾ ਵਰਨਨ ਕਰਦੇ ਹਨ। ਤਕਨੀਕੀ ਫੋਲਡਰ ਕੱਟ-ਫਰਮਾ ਇਨਫਰਾ ਦੇ ਕੰਮ ਵੇਖਾਉਂਦੇ ਹਨ। ਦੋਹਾਂ ਦਾ ਮਿਲਾਉ ਛੁਪੀਆਂ ਸਰਹੱਦਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਇੱਕ ਕਾਰਗਰ ਵੰਡ ਹੋ ਸਕਦੀ ਹੈ: ਫੀਚਰ billing, onboarding, inventory ਵਰਗੇ, ਅਤੇ ਤਕਨੀਕੀ ਖੇਤਰ api, db, routing, design-system ਵਰਗੇ। ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕਈ clients (web, server, mobile) ਹੋਣ, ਤਦ ਹਰ ਲੇਅਰ ਵਿੱਚ ਇੱਕੋ ਫੀਚਰ ਨਾਂਵ ਰੱਖਣਾ ਸੋਧਾਂ ਨੂੰ ਟ੍ਰੇਸ ਕਰਨ 'ਚ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ।
ਸਮੀਖਿਆ ਵਿੱਚ ਇਹ ਛੋਟੀ ਚੈਕਲਿਸਟ ਰੱਖੋ:
ਪਹਿਲੇ-ਹਫਤੇ ਵਿੱਚ rename ਕਰਨਾ ਸਸਤਾ ਹੈ। ਹੈਂਡਾਫ ਤੋਂ ਬਾਅਦ ਇਹ ਮਹਿੰਗਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਨਵੈਰੀਅੰਟ ਇੱਕ ਨਿਯਮ ਹੈ ਜਿਸ 'ਤੇ ਤੁਹਾਡੀ ਐਪ ਸਹੀ ਰਹਿੰਦੀ ਹੈ, ਭਾਵੇਂ ਫੀਚਰ ਬਦਲਦੇ ਹਨ। AI-ਨਿਰਮਿਤ ਕੋਡ ਅਕਸਰ ਇਸ ਲਈ “ਚਲਦਾ” ਹੈ ਕਿਉਂਕਿ ਜਨੇਰੇਟਰ ਨੇ ਕੁਝ ਨਿਯਮ ਮੰਨੇ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਨਿਯਮ ਸਿਰਫ ਪ੍ਰਾਂਪਟਾਂ ਜਾਂ ਕਿਸੇ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਰਹਿ ਸਕਦੇ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਲਿਖੋ ਤਾਂ ਜੋ ਸਮੀਖਿਆਕਾਰ ਜਾਣ ਸਕਣ ਕਿ ਕੀ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ।
ਚੰਗੇ ਇਨਵੈਰੀਅੰਟਸ ਬੋਰੀਂਗ, ਨਿਰਧਾਰਤ ਅਤੇ ਟੈਸਟ-ਯੋਗ ਹੁੰਦੇ ਹਨ। vague ਬਿਆਨਾਂ ਤੋਂ ਬਚੋ ਜਿਵੇਂ “validate inputs.” ਬਜਾਏ ਇਸਦੇ ਸਹੀ ਤੌਰ ਤੇ ਦੱਸੋ ਕਿ ਕੀ ਮਨਜ਼ੂਰ ਹੈ, ਕੌਣ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਜਦ ਨਿਯਮ ਟੁੱਟੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
ਹੈਂਡਾਫ ਦਰਦ ਅਕਸਰ ਹੇਠਾਂ ਵਾਲੇ ਖੇਤਰਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਉਸ ਪ੍ਰਸਤਾਵ ਨੂੰ ਇੱਕ unit test ਜਾਂ API test ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਠੀਕ ਪੱਧਰ ਹੈ।
ਇਨਵੈਰੀਅੰਟਸ ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਲੋਕ ਸਮੀਖਿਆ ਦੌਰਾਨ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੇਖਦੇ ਹਨ:
ਲੰਬੀਆਂ ਡੌਕਸ ਵਿੱਚ ਇਨਵੈਰੀਅੰਟ ਛੁਪਾਉਣ ਤੋਂ ਬਚੋ; ਜੇ ਇਹ ਸਧਾਰਨ PR ਸਮੀਖਿਆ ਦੌਰਾਨ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਇਹ ਭੁੱਲ ਜਾਦਾ ਹੈ।
ਹਰ ਇਨਵੈਰੀਅੰਟ ਨੂੰ ਸਕੋਪ, ਨਿਯਮ ਅਤੇ ਲਾਗੂ ਕਰਨ ਵਾਲੀ ਜਗ੍ਹਾ ਨਾਲ ਫਰਮੇ ਕਰੋ। ਉਦਾਹਰਨ: “For all endpoints under /api/projects/:id, the requester must be a project member; enforced in auth middleware and checked again on task updates.”
ਜਦੋਂ ਇਨਵੈਰੀਅੰਟ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ। ਡੌਕ ਅੱਪਡੇਟ ਕਰੋ, ਉਹ ਕੋਡ लोਕੇਸ਼ਨਾਂ ਦੱਸੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਦਲਿਆ ਗਿਆ, ਅਤੇ ਉਹ ਟੈਸਟ ਜੋ ਪੁਰਾਣੇ ਨਿਯਮ 'ਤੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਸੀ ਅਪਡੇਟ ਜਾਂ ਨਵਾਂ ਕਰੋ। ਨਹੀਂ ਤਾਂ ਟੀਮ ਅਨੇਕ ਘੱਟ-ਪੁਰਾਣੇ ਅਤੇ ਨਵੀਂ ਵਰਤਾਰ ਦਾ ਅਧ-ਹੁਸਲਾ ਰੱਖ ਲੈਂਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕੋਈ vibe-coding ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਇਕ ਉਪਯੋਗ ਹੈਂਡਾਫ ਕਦਮ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਪੁੱਛੋ ਕਿ ਉਸਨੇ ਐਪ ਜਨਰੇਟ ਕਰਦਿਆਂ ਕਿਹੜੀਆਂ ਇਨਵੈਰੀਅੰਟਸ ਮਨੀਆਂ। ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਟੈਸਟ-ਯੋਗ ਨਿਯਮਾਂ ਵਿੱਚ ਰੱਖੋ ਜੋ ਟੀਮ ਰਿਵਿਊ ਕਰ ਸਕੇ।
ਹੈਂਡਾਫ ਉਹੀ ਨਹੀਂ ਹੈ ਜੋ "ਮੇਰੇ ਲੈਪਟੌਪ 'ਤੇ ਚਲਦਾ ਹੈ"। ਟੀਚਾ ਇਹ ਹੈ ਕਿ ਪ੍ਰੋਜੈਕਟ ਪੜ੍ਹਨ ਯੋਗ, ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਯੋਗ, ਅਤੇ ਨਵਾਂ ਵਿਕਾਸਕ ਖੋਲ੍ਹ ਕੇ ਅਸਾਨੀ ਨਾਲ ਸਮਝ ਸਕੇ।
ਸ਼ੁਰੂਆਤ scope ਨੂੰ freeze ਕਰ ਕੇ ਕਰੋ। ਇੱਕ ਮਿਤੀ ਅਤੇ ਇੱਕ ਛੋਟੀ ਲਿਸਟ ਪੱਕੀ ਕਰੋ ਕਿ ਕੀ ਸਥਿਰ ਰਹੇਗਾ (core screens, key flows, integrations)। ਇਹ ਵੀ ਲਿਖੋ ਕਿ ਕੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਆਉਟ-ਆਫ-ਸਕੋਪ ਹੈ ਤਾਂ ਕੋਈ ਫੀਚਰ ਚਿਪਕਾਉਂਦਾ ਨਾ ਰਹਿ ਜਾਵੇ ਜਦ ਤੁਸੀਂ ਸਾਫ਼-ਸੁਥਰਾ ਕਰ ਰਹੇ ਹੋ।
ਫਿਰ ਸਾਫ਼-ਸੁਥਰਾ ਕਰੋ, ਕਿਸੇ ਵੀ ਨਵੀਂ ਚੀਜ਼ ਨੂੰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ। ਇੱਥੇ ਹੀ ਸਮੀਖਿਆਯੋਗਤਾ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: ਕੋਡਬੇਸ ਇਕ ਉਤਪਾਦ ਵਾਂਗ ਵਰਤਿਆ ਜਾਉਂਦਾ ਹੈ, ਨਕੀ ਡੈਮੋ ਵਾਂਗ ਨਹੀਂ।
ਇੱਕ ਪ੍ਰਯੋਗਕ੍ਰਮ:
Smoke test ਯੋਜਨਾ ਛੋਟੀ ਪਰ ਯਥਾਰਥ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। React ਐਪ, Go API ਅਤੇ Postgres ਵਾਲੀ ਸੈਟਅਪ ਲਈ ਇਹ ਹੋ ਸਕਦਾ ਹੈ: ਸਾਈਨ ਇਨ, ਇੱਕ ਰਿਕਾਰਡ ਬਣਾਓ, ਰੀਫ੍ਰੈਸ਼, ਯਕੀਨ ਕਰੋ ਕਿ ਇਹ ਪਕਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਯਕੀਨ ਕਰੋ ਕਿ ਇਕ ਰਿਸਟ੍ਰਿਕਟਿਡ ਐਕਸ਼ਨ ਫੇਲ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਸਮੀਖਿਆ ਚੱਕਰ ਕਰੋ ਜੋ ਪੜ੍ਹਨਯੋਗਤਾ 'ਤੇ ਕੇਂਦਰਿਤ ਹੋਵੇ, ਨਾ ਕਿ ਫੀਚਰਾਂ 'ਤੇ। ਕਿਸੇ ਟੀਮ-ਸਾਥੀ ਨੂੰ 30 ਮਿੰਟ ਦਿਓ ਤੇ ਪੂਛੋ: “ਕੀ ਮੈਂ ਚੀਜ਼ਾਂ ਲੱਭ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?” “ਕੀ ਨਾਮ ਵਰਤਾਰ ਨਾਲ ਮਿਲਦੇ ਹਨ?” “ਕੀ ਇਨਵੈਰੀਅੰਟਸ ਸਪਸ਼ਟ ਹਨ?” ਜੋ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਠੀਕ ਕਰੋ, ਫਿਰ ਰੁਕੋ।
ਹੈਂਡਾਫ ਤੋਂ ਪਹਿਲਾਂ "fresh eyes" ਟੈਸਟ ਕਰੋ। ਕਿਸੇ ਅਜਿਹੇ ਵਿਅਕਤੀ ਨੂੰ ਦਿਓ ਜਿਸ ਨੇ ਪ੍ਰੋਟੋਟਾਈਪ ਨਹੀਂ ਬਣਾਇਆ ਅਤੇ ਪੁੱਛੋ ਕਿ ਉਹ ਰਿਪੋ ਖੋਲ੍ਹ ਕੇ ਕਿੱਦਾ ਨੈਰੇਟ ਕਰਦਾ ਹੈ। ਜੇ ਉਹ ਪਰਮੁੱਖ ਅਰੰਭਕ ਬਿੰਦੂਜ਼ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਲੱਭ ਪਾਂਦੇ, ਤਾਂ ਟੀਮ ਹਰ ਤਬਦੀਲੀ 'ਤੇ ਇਹ ਲਾਗਤ ਭਰੇਗੀ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਨਵਾਂ ਵਿਕਾਸਕ ਮੁੱਖ entry points 2 ਮਿੰਟ ਵਿੱਚ ਲੱਭ ਸਕੇ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਤਲਬ ਹੈ ਇੱਕ ਸਾਫ README ਜੋ ਇੱਕ-ਦੋ ਸ਼ੁਰੂਆਤੀ ਜਗ੍ਹਾਂ ਨੂੰ ਨਾਂ ਦਿੰਦਾ: web app entry, API entry, config, ਅਤੇ ਉਹ ਫਾਇਲਾਂ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹਨ।
ਸਮੀਖਿਆ ਆਕਾਰ ਵੀ ਚੈੱਕ ਕਰੋ। ਜੇ ਮੁੱਖ ਮੋਡੀਊਲਾਂ ਦੀ ਲੰਬੀ ਸਕ੍ਰੋਲਿੰਗ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ ਸਮੀਖਿਆਕਾਰ ਸਮੱਸਿਆਆਂ ਫੜਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਲੰਬੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਤੋੜੋ ਤਾਂ ਕਿ ਹਰ ਇੱਕ ਦਾ ਇਕ ਇੱਕ ਕੰਮ ਹੋਵੇ ਅਤੇ ਇਕ ਹੀ ਬੈਠਕ ਵਿੱਚ ਸਮਝ ਆ ਸਕੇ।
ਛੋਟਾ ਹੈਂਡਾਫ ਚੈੱਕਲਿਸਟ:
validateUser ਵੈਰੀਫਾਈ ਕਰਦਾ ਹੈ; ਇਹ ਡੇਟਾਬੇਸ ਨੂੰ ਨਹੀਂ ਲਿਖਦਾ।Maya ਇਕ ਗੈਰ-ਤਕਨੀਕੀ ਫਾਊਂਡਰ ਹੈ। ਉਸਨੇ ਚੈਟ ਵਿੱਚ ਪ੍ਰੋਡਕਟ ਵਰਣਨ ਦੇ ਕੇ ਇੱਕ MVP ਬਣਾਇਆ: ਇੱਕ ਸਧਾਰਨ CRM ਇੱਕ ਛੋਟੀ ਸਰਵਿਸ ਬਿਜ਼ਨਸ ਲਈ। ਇਹ ਚਲਦਾ ਹੈ: login, customers, deals, notes, ਅਤੇ ਬੇਸਿਕ admin ਸਕ੍ਰੀਨ। ਕੁਝ ਹਫਤੇ ਬਾਅਦ, ਉਹ ਦੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਨਿਯੌਕਤ ਕਰਦੀ ਹੈ ताकि ਇਹ “ਮੇਰੇ ਲੈਪਟਾਪ 'ਤੇ ਚਲਦਾ” ਤੋਂ ਇੱਕ ਭਰੋਸੇਯੋਗ ਬਿਜ਼ਨਸ ਟੂਲ ਬਣ ਜਾਵੇ।
ਉਹਨਾਂ ਦਾ ਪਹਿਲਾ ਕੰਮ rewrite ਨਹੀਂ ਹੁੰਦਾ। ਉਹਨਾਂ ਦਾ ਪਹਿਲਾ ਕੰਮ ਕੋਡ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਬਣਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਉਹ ਆਪਣਾ ਪਹਿਲਾ ਕਦਮ ਅਪਪ ਨੂੰ ਦੋ ਬੱਕੇਟ ਵਿੱਚ ਮੈਪ ਕਰਨਾ ਹੈ: core modules (ਉਹ ਚੀਜ਼ਾਂ ਜਿਨ੍ਹਾਂ 'ਤੇ ਹਰ ਫੀਚਰ ਨਿਰਭਰ ਕਰਦਾ ਹੈ) ਅਤੇ features (ਉਹ ਸਕ੍ਰੀਨ ਅਤੇ ਵਰਕਫਲੋਜ਼ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ)। ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਫੈਸਲੇ ਰੱਖਣ ਦਾ ਅਤੇ ਬਦਲਣ ਦਾ ਇਕ ਸਪਸ਼ਟ ਸਥਾਨ ਦਿੰਦਾ ਹੈ।
ਉਹ ਸਧਾਰਨ ਫੀਚਰ ਮੈਪ ਤੇ ਸਹਿਮਤ ਹੁੰਦੇ ਹਨ: core (auth, database access, permissions, logging, UI components) ਅਤੇ features (customers, deals, notes, admin).
ਫਿਰ ਉਹ ਫੋਲਡਰਾਂ ਨੂੰ ਇਸ ਮੈਪ ਦੇ ਅਨੁਸਾਰ ਢਾਲਦੇ ਹਨ। ਪਹਿਲਾਂ ਫਾਇਲਾਂ scatter ਹੋਈਆਂ ਸਨ, ਨਾਂਵ ਮਿਲੇ-ਝੁਲੇ ਸੀ: CustomerPage.tsx, customer_view.tsx, ਅਤੇ custPageNew.tsx. ਬਾਅਦ ਵਿੱਚ ਹਰ ਫੀਚਰ ਦਾ ਇਕ ਘਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ core ਕੋਡ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੱਖ ਹੈ। ਸਮੀਖਿਆ ਤੇਜ਼ ਹੋ ਗਈ ਕਿਉਂਕਿ pull requests ਹੁਣ ਅਕਸਰ ਇੱਕ ਫੀਚਰ ਫੋਲਡਰ ਵਿੱਚ ਹੀ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ core ਬਦਲਾਅ ਸਪਸ਼ਟ ਹੋ ਗਏ ਹਨ।
ਇੱਕ ਛੋਟਾ ਨਾਂਵ ਨਿਯਮ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰਦਾ ਹੈ: “folders nouns ਹੋਣ, components PascalCase ਹੋਣ, functions verbs ਹੋਣ, ਅਤੇ ਅਸੀਂ abbreviate ਨਹੀਂ ਕਰਦੇ।” ਇਸ ਤਰ੍ਹਾਂ custPageNew.tsx ਬਣ ਜਾਂਦਾ CustomerDetailsPage.tsx, ਅਤੇ doStuff() ਬਣ ਜਾਂਦਾ saveCustomerNote()।
ਉਹ ਇੱਕ ਮੂਲ ਨਿਯਮ ਲਿਖ ਕੇ feature ਫੋਲਡਰ ਵਿੱਚ ਛੋਟੀ INVARIANTS.md ਰੱਖਦੇ ਹਨ।
CRM ਲਈ ਉਦਾਹਰਨ ਇਨਵੈਰੀਅੰਟ:
Only the deal owner or an admin can edit a deal. Everyone else can view it, but can’t change status, value, or notes.
ਇਹ ਵਾਕ ਵੈੱਬਹੀंड, ਡੇਟਾਬੇਸ ਕਵੇਰੀਆਂ ਅਤੇ ਫਰੰਟਐਂਡ UI ਸਟੇਟਾਂ ਨੂੰ ਦਿਸ਼ਾ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਬਾਅਦ ਵਿੱਚ “bulk edit” ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਸਮੀਖਿਆਕਾਰਾਂ ਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਨਹੀਂ ਟੁੱਟਣਾ ਚਾਹੀਦਾ।
ਇੱਕ ਹਫਤੇ ਬਾਅਦ, ਕੋਡ ਪਰਫੈਕਟ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਹੈਂਡਾਫ ਹਕੀਕਤ ਬਣ ਗਿਆ:
AI ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਪ੍ਰੋਟੋਟਾਈਪ ਤੱਕ ਲੈ ਜਾ ਸਕਦਾ ਹੈ। ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ “ਚਲਦਾ” ਅਕਸਰ ਛੁਪੇ ਹੋਏ ਅਨੁਮਾਨਾਂ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਟੀਮ ਬਾਅਦ ਵਿੱਚ ਛੇੜ-ਛਾੜ ਕਰਦੀ ਹੈ, ਛੋਟੀ-ਛੋਟੀ ਬਦਲਾਵ ਅਣਦੇਖੇ ਥਾਵਾਂ 'ਤੇ ਟੁੱਟ ਜਾਂਦੇ ਹਨ।
ਇੱਕ ਆਮ ਗਲਤੀ ਸਾਰੀ ਰੀਫੈਕਟਰਿੰਗ ਇਕੱਠੇ ਕਰਨਾ ਹੈ। ਵੱਡੀਆਂ ਸਾਫ਼-ਸੁਥਾਰੀਆਂ ਮਨੋਹਰ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਲੋਕਾਂ ਲਈ ਦੇਖਣਾ ਮੁਸ਼ਕਲ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ। ਪਹਿਲਾਂ ਸਰਹੱਦ ਤੈਅ ਕਰੋ: ਕਿਹੜੇ ਮੋਡੀਊਲ ਸਥਿਰ ਹਨ, ਨਵੇਂ ਕੋਡ ਕਿੱਥੇ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਵਰਤਾਰ ਬਦਲਣ ਦੀ ਮਨਾਹੀ ਹੈ। ਫਿਰ ਇੱਕ ਖੇਤਰ 'ਤੇ ਇਕ ਵਾਰੀ ਸੁਧਾਰ ਕਰੋ।
ਦੂਜੀ ਆਮ ਸਮੱਸਿਆ ਵੱਖ-ਵੱਖ ਨਾਂਵਾਂ ਨਾਲ duplicate ਅਵਧਾਰਨਾਵਾਂ ਹਨ। AI ਖੁਸ਼ੀ-ਖੁਸ਼ੀ UserService ਅਤੇ AccountManager ਬਣਾਈ ਦੇਵੇਗਾ ਇੱਕੋ ਕੰਮ ਲਈ, ਜਾਂ plan vs pricingTier ਇਕੋ ਹੀ ਵਿਚਾਰ ਲਈ। ਹਰ ਕੋਰ ਸੰਕਲਪ ਲਈ ਇੱਕ ਨਾਂਵ ਚੁਣੋ ਅਤੇ UI, API ਅਤੇ ਡੇਟਾਬੇਸ 'ਚ ਇੱਕਸਾਰਤਾ ਲਿਆਓ।
ਛੁਪੇ ਨਿਯਮ ਵੀ ਨਾਜ਼ੁਕਤਾ ਦਾ ਮੁੱਖ ਸਰੋਤ ਹਨ। ਜੇ ਸੱਚੀ ਬਿਜ਼ਨਸ ਲਾਜ਼ਿਕ ਪ੍ਰਾਂਪਟਾਂ ਜਾਂ ਚੈਟ ਇਤਿਹਾਸ ਵਿੱਚ ਰਹਿ ਜਾਏ, ਤਾਂ ਰਿਪੋ ਨੂੰ ਸੰਭਾਲਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ। ਨਿਯਮਾਂ ਨੂੰ ਕੋਡਬੇਸ ਵਿੱਚ ਸਪਸ਼ਟ ਟਿੱਪਣੀਆਂ, ਟੈਸਟਾਂ ਜਾਂ ਛੋਟੀ ਇਨਵੈਰੀਅੰਟਸ ਡੌਕ ਵਾਂਗ ਰੱਖੋ।
shared, common, ਜਾਂ utils ਵਰਗੇ catch-all ਫੋਲਡਰ ਚੁਪਕੇ ਹੀ ਕੂੜੇ ਡਰਾਅ ਬਣ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਸਾਂਝਾ ਮੋਡੀਊਲ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸਦੀ ਜ਼ਿੰਮੇਵਾਰੀ (inputs, outputs, responsibilities) ਦਰਜ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਤੰਗ ਰੱਖੋ।
ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਦਾ UI ਕੋਡ ਵਿੱਚ ਮਿਲਾਉਣਾ ਵੀ ਇੱਕ ਫੇੰਸ ਹੈ। React ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਇਕ ਛੋਟੀ conditional ਇਕੱਲੀ ਜਗ੍ਹਾ ਤੇ pricing rule ਰੱਖ ਦੇਵੇ, ਫਿਰ mobile app ਜਾਂ ਬੈਕਐਂਡ ਦੇ ਨਾਲ ਅਸਹਿਮਤੀ ਆਉਂਦੀ ਹੈ। ਬਿਜ਼ਨਸ ਨਿਯਮ ਇੱਕ ਹੀ ਲੇਅਰ (ਅਕਸਰ ਬੈਕਐਂਡ ਜਾਂ domain module) ਵਿੱਚ ਰੱਖੋ ਅਤੇ UI ਓਹਨੂੰ ਕਾਲ ਕਰੇ, ਦੁਬਾਰਾ ਨਚਾਉਣ ਦੀ ਬਜਾਏ।
ਅੰਤ ਵਿਚ, brittle ਕੋਡ ਅਕਸਰ ਸਮੀਖਿਆ ਨਿਯਮ ਛੱਡਣ ਨਾਲ ਬਣਦਾ ਹੈ। ਟੀਮਾਂ ਨੂੰ ਛੋਟੇ diffs, ਸਪਸ਼ਟ commits, ਅਤੇ ਸਪਸ਼ਟ ਇਰਾਦੇ ਚਾਹੀਦੇ ਹਨ। ਭਾਵੇਂ ਜਨਰੇਟਰ ਨੇ ਤਬਦੀਲੀ ਬਣਾਈ, ਉਸਨੂੰ ਇੱਕ ਆਮ PR ਵਾਂਗ ਹੀ ਵਰਤੋ: scope ਤਿੱਖਾ ਰੱਖੋ, ਦੱਸੋ ਕਿ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਆਸਾਨ ਬਣਾਉ।
ਹੈਂਡਾਫ ਨੂੰ ਮਿਰਚ ਨਹੀਂ ਸਮਝੋ; ਇਹ ਮੈਨਟੇਨੈਂਸ ਦੀ ਸ਼ੁਰੂਆਤ ਹੈ, ਖਤਮ ਨਹੀਂ। ਟੀਚਾ ਸਾਦਾ ਰਹਿੰਦਾ ਹੈ: ਨਵਾਂ ਵਿਅਕਤੀ ਇਕ ਛੋਟੀ ਸੋਧ ਕਰ ਸਕੇ ਬਿਨਾਂ ਛੁਪੇ ਨਿਯਮ ਟੁੱਟੇ।
ਟੀਮ ਪ੍ਰੇਫਰੰਸਾਂ ਨੂੰ ਕੁਝ ਲਿਖਤ ਡੀਫੌਲਟਾਂ ਵਿੱਚ ਬਦਲ ਦਿਓ: ਇਕ ਫੋਲਡਰ ਨਕਸ਼ਾ, ਇਕ ਨਾਂਵ ਸਟਾਈਲ, ਅਤੇ ਇਕ ਛਾਂਚਾ ਇਨਵੈਰੀਅੰਟਸ ਲਈ। ਜਦੋਂ ਉਹ ਨਿਯਮ ਪਹਿਲਾਂ ਹੀ ਸਹਿਮਤ ਹੋ ਜਾਂਦੇ ਹਨ, ਸਮੀਖਿਆ ਟਿੱਪਣੀਆਂ ਨਿੱਜੀ ਰੁਚੀ ਨਾ ਰਹਿੰਦੀਆਂ ਅਤੇ ਸਥਿਰ ਚੈੱਕ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇੱਕ “handoff README” ਰੱਖੋ ਜੋ ਕੁਝ ਮੁੱਖ ਥਾਵਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ: ਇਨਵੈਰੀਅੰਟਸ ਕਿੱਥੇ ਹਨ, ਐਪ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਨ, ਫੀਚਰ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਕਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਬਿਨਾਂ ਗੱਲ ਕੀਤੇ ਨਹੀਂ ਬਦਲਣੀਆਂ। ਨਵਾਂ ਟੀਮ-ਮੈਂਬਰ 5 ਮਿੰਟ ਵਿੱਚ ਜਵਾਬ ਲੱਭ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਵਰਕਫਲੋ ਰਿਵਰਸੀਬਲ ਹੈ, ਤਾਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ। ਉਦਾਹਰਨ ਲਈ, Koder.ai snapshots ਅਤੇ rollback ਨੂੰ ਸਮਰਥਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਰੀਫੈਕਟਰਿੰਗ ਜਾਂ ਨੈੜੇ-ਅਪਗਰੇਡ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਣ ਸੁਰੱਖਿਅਤ ਜਾਲ ਹੋ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਮਲਕੀਅਤ ਤਬਦੀਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ, koder.ai ਤੋਂ ਕੋਂਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨਾ ਟੀਮ ਨੂੰ ਸਧਾਰਨ Git-ਆਧਾਰਿਤ ਕੰਮ ਲਈ ਇੱਕ ਸਾਫ਼ ਸ਼ੁਰੂਆਤ ਦਿੰਦਾ ਹੈ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੋਡ ਨੂੰ ਭਵਿੱਖ-ਪਛਾਣਯੋਗ ਬਣਾਓ। ਫੋਲਡਰ ਸਟ੍ਰਕਚਰ, ਨੈਮਿੰਗ ਅਤੇ ਸਰਹੱਦਾਂ ਨੂੰ ਏਨ੍ਹੇ ਹੀ ਲਾਈਨ 'ਤੇ ਲਿਆਓ ਤਾਂ ਜੋ ਟੀਮ ਮੈਂਬਰ ਬਿਨਾਂ ਪੂਰੇ ਰਿਪੋ ਨੂੰ ਖੋਜੇ ਹੀ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕੇ ਕਿ ਕੁਝ ਕਿੱਥੇ ਹੈ ਤੇ ਕਿਵੇਂ ਵਹਿਵਾਰ ਕਰਦਾ ਹੈ।
ਹਰ ਮੁੜ-ਉਪਯੋਗ ਜ਼ਿੰਮੇਵਾਰੀ ਲਈ ਇੱਕ ਪੈਟਰਨ ਚੁਣੋ (ਜਿਵੇਂ auth state, data fetching, validation, error handling) ਅਤੇ ਉਹੀ ਪੈਟਰਨ ਹਰ ਜਗ੍ਹਾ ਲਗਾਓ। ਮਕਸਦ "ਸਭ ਤੋਂ ਵਧੀਆ" ਨਹੀਂ, ਬਲਕਿ "ਇਕਸਾਰ" ਹੋਣਾ ਹੈ, ਤਾਂ ਕਿ ਸਮੀਖਿਆਕਾਰ ਹਰ ਤਬਦੀਲੀ 'ਤੇ ਨਵਾਂ ਸਿਸਟਮ ਨਾ ਸਿੱਖਣ ਪਵੇ।
ਇੱਕ ਸਮੀਖਿਆਯੋਗ ਕੋਡਬੇਸ ਉਹ ਹੈ ਜਿਸ ਵਿੱਚ ਨਵਾਂ ਵਿਕਾਸਕ ਠੀਕ ਜਗ੍ਹਾ ਲਭ ਕੇ ਛੋਟੀ ਸੋਧ ਕਰ ਸਕੇ ਅਤੇ ਉਹ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜਾਂਚ ਸਕੇ। ਜੇ ਸੋਧ ਰਿਪੋ ਦੇ ਬੇਰੁਖ ਲੋੜੀਂਦੇ ਫਾਇਲਾਂ ਵਿੱਚ ਫੈਲ ਜਾਂਦੀ ਹੈ ਜਾਂ ਨਿਯਮਾਂ ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਮੀਖਿਆਯੋਗ ਨਹੀਂ ਹੈ।
ਚੋਟੀ ਦੀਆਂ, ਸਥਿਰ ਟੋਪ-ਲੈਵਲ ਫੋਲਡਰਾਂ ਰੱਖੋ ਅਤੇ ਹਰ ਚਿੰਤਾ (app composition, core business rules, infra) ਨੂੰ ਇੱਕ ਸਾਫ਼ ਘਰ ਦਿਓ. ਇਸ ਤਰ੍ਹਾਂ ਨੈਵੀਗੇਸ਼ਨ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਹੋ ਜਾਦੀ ਹੈ।
ਜਿਹੇ ਕੋਡ ਨੂੰ ਤੁਸੀਂ ਮੁੜ-ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਫਾਇਲਾਂ ਨੂੰ /generated ਵਰਗੇ ਸਪਸ਼ਟ ਫੋਲਡਰ 'ਚ ਰੱਖੋ। ਮਨੁੱਖੀ-ਸੰਪਾਦਿਤ ਫਾਇਲਾਂ ਨੂੰ /core ਜਾਂ /app ਵਰਗੇ ਸਥਿਰ ਖੇਤਰਾਂ 'ਚ ਰੱਖੋ ਤਾਂ ਕਿ ਗਲਤੀ ਨਾਲ ਹੋਣ ਵਾਲੀਆਂ تبدیلیاں ਜੇਨਰੇਟ ਹੋ ਕੇ ਖੋ ਨਾਹ ਜਾਣ।
ਇੱਕ ਨਿਯਮ ਤੈਅ ਕਰੋ ਅਤੇ ਉਸ ਨੂੰ ਰੀਪੋ 'ਚ ਲਗਾਓ: ਫੋਲਡਰਾਂ ਲਈ ਇੱਕ ਕੇਸ, ਕੰਪੋਨੈਂਟ ਲਈ PascalCase, TypeScript ਦੇ ਬਾਹਰ ਫਾਇਲਾਂ ਲਈ camelCase ਆਦਿ. ਫਾਇਲ ਨਾਂ ਤੋਂ ਹੀ ਮਕਸਦ ਜ਼ਾਹਿਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇਕ ਇੰਪਲੀਮੇਨਟੇਸ਼ਨ-ਵਰਣਨ।
ਇਨਵੈਰੀਅੰਟਸ ਉਹ ਨਿਯਮ ਹਨ ਜੋ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸਹੀ ਚਾਲ ਲਈ ਲਾਜ਼ਮੀ ਹਨ—ਜਿਵੇਂ permissions, unique constraints, state transitions. ਇਨ੍ਹਾਂ ਨੂੰ ਲਿਖ ਕੇ ਛੱਡਣ ਨਾਲ ਛੁਪੇ ਅਨੁਮਾਨ ਸਾਹਮਣੇ ਆ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਮੀਖਿਆਕਾਰ ਇਨ੍ਹਾਂ ਦੀ ਰੱਖਿਆ ਕਰ ਸਕਦੇ ਹਨ।
ਉਹਨਾਂ ਥਾਵਾਂ 'ਤੇ ਜਿਹੜੀਆਂ ਸਮੀਖਿਆ ਦੌਰਾਨ ਕਦੇ-ਕਦੇ ਵੇਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: README ਵਿੱਚ ਇੱਕ ਛੋਟਾ "System rules" section ਅਤੇ ਕੋਡ ਡਾਕੀੂਮੈਂਟੇਸ਼ਨ ਜਾਂ ਕੋਡ ਦੇ ਨੇੜੇ ਛੋਟੇ ਟਿੱਪਣੀਆਂ। ਜੇ ਨਿਯਮ PR ਸਮੀਖਿਆ 'ਚ ਨਜ਼ਰ ਨਾ ਆਏ ਤਾਂ ਉਹ ਭੁੱਲ ਜਾਉਂਦਾ ਹੈ।
ਆਉਟ-ਆਫ-ਸਕੋਪ ਚੀਜ਼ਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ। ਫਿਰ ਫੋਲਡਰਾਂ ਅਤੇ ਨਾਂਵਾਂ ਨੂੰ ਸਮਾਨ ਕਰੋ, ਮੁਰਝਾਈ ਕੋਡ ਹਟਾਓ, ਫੀਚਰ-ਸਪੈਸ ਚਿਕਿਸਟ ਬਣਾਓ ਅਤੇ ਸਿਰਫ ਪੜ੍ਹਨਯੋਗਤਾ ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਇੱਕ ਸਮੀਖਿਆ ਚੱਕਰ ਕਰੋ।
ਬਹੁਤ ਵੱਡੀ ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ ਸਾਧਾਰਨ ਗਲਤੀ ਹੈ। ਇਸ ਦੇ ਨਾਲ-ਨਾਲ utils ਜਹਾਜ਼ੀਆਂ ਫੋਲਡਰ, ਬਿਜ਼ਨਸ ਲਾਜਿਕ ਦਾ UI 'ਚ ਮਿਲਾਉਣਾ ਅਤੇ ਇੱਕੋ ਹੀ ਅਵਧਾਰਨਾ ਲਈ ਵੱਖ-ਵੱਖ ਨਾਂ ਵਰਤਨਾ brittle ਕੋਡ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਛੋਟੇ PRs, ਸਾਫ਼ commits ਅਤੇ ਸਪਸ਼ਟ ਇਰਾਦੇ ਰੱਖੋ।