ਘੱਟ-ਖਤਰੇ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਨੂੰ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰੋ

ਕਿਉਂ ਪ੍ਰੋਟੋਟਾਈਪ ਬਦਲਣ ਵਿੱਚ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦੇ ਹਨ

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਟੁੱਟਦਾ ਹੈ, ਅਕਸਰ ਨਵਾਂ ਕੋਡ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਪੁਰਾਣੀਆਂ ਧਾਰਣਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।

ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ route ਵਿੱਚ ਚੁੱਪਚਾਪ ਜਵਾਬ ਦਾ ਆਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਦੋ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਟੁੱਟਦਾ ਹੈ। ਇੱਕ “ਅਸਥਾਈ” query ਜੋ ਤਿੰਨ ਥਾਂਆਂ 'ਤੇ ਕਾਪੀ ਕੀਤੀ ਗਈ ਹੁੰਦੀ ਹੈ, ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਡੇਟਾ ਵਾਪਸ ਕਰਨ ਲੱਗਦੀ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਹੜੀ ਸਹੀ ਹੈ।

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

ਘੱਟ-ਖਤਰੇ ਵਾਲੀ ਰੀਫੈਕਟਰਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਬਦਲਾਅ ਨੂੰ ਛੋਟੇ ਅਤੇ ਵਾਪਸ ਕਰਨਯੋਗ ਰੱਖਣਾ। ਤੁਸੀਂ ਹਰ ਕਦਮ ਤੋਂ ਬਾਅਦ ਰੁਕ ਸਕੋ ਅਤੇ ਫਿਰ ਵੀ ਇੱਕ ਕੰਮ ਕਰਦੀ ਐਪ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪ੍ਰਾਇਗਮੈਟਿਕ ਨਿਯਮ ਸਧਾਰਨ ਹਨ:

• ਹਰ ਬਦਲਾਅ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਲਕੜੀ ਦਾ ਹਦਫ (ਕੋਡ ਮੂਵ ਕਰੋ, ਜੋ ਇਹ ਕਰਦਾ ਹੈ ਉਹ ਨਾ ਬਦਲੋ)
• ਛੋਟੇ ਸਾਈਕਲ ਜਿੱਥੇ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਇੱਕੋ ਯੂਜ਼ਰ ਫਲੋ ਨੂੰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰ ਸਕੋ
• ਇੱਕ ਬੋਰਿੰਗ rollback ਯੋਜਨਾ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾ ਸਕੋ
• ਨਵਾਂ ਕੋਡ ਪੁਰਾਣੇ ਕੋਡ ਦੇ ਨੇੜੇ ਰਹੇ ਜਦ ਤੱਕ ਉਹ ਆਪਣੀ ਯੋਗਤਾ ਨਹੀਂ ਸਾਬਤ ਕਰਦਾ

ਜਦ ਹਰ ਲੇਅਰ ਹੋਰਾਂ ਦੇ ਕੰਮ ਕਰਨ लगਦੀ ਹੈ ਤਾਂ routes, services, database access, ਅਤੇ UI ਉਲਝ ਜਾਂਦੇ ਹਨ। ਇਹ ਉਲਝਣ “ਪਰਫੈਕਟ ਆਰਕੀਟੈਕਚਰ” ਦੇ ਪਿੱਛੇ ਭੱਜਣ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ। ਇਹ ਇਕ ਵਾਰੀ ਵਿੱਚ ਇੱਕ ਸੂਤ ਨੂੰ ਹਿਲਾਉਣ ਬਾਰੇ ਹੈ।

ਕੋਡ ਛੇੜਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਸੈੱਟ ਕਰੋ

ਰੀਫੈਕਟਰਿੰਗ ਨੂੰ ਇੱਕ ਮੋਰਟੋ-ਟ੍ਰਾਂਸਫਰ ਦੇ ਤੌਰ ਤੇ ਵਰਤੋਂ, ਨਾ ਕਿ ਇੱਕ ਰੀਮਾਡਲ। ਵਿਹਾਰ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਰੱਖੋ ਅਤੇ ਢਾਂਚਾ ਆਸਾਨ ਬਦਲਣਯੋਗ ਬਣਾਓ। ਜੇ ਤੁਸੀਂ ਦੁਬਾਰਾ ਠੀਕ ਕਰਨ ਦੇ ਦੌਰਾਨ ਫੀਚਰ ਵੀ “ਸੁਧਾਰ” ਕਰ ਲੈਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਜਾਣ ਸਕੋਗੇ ਕਿ ਕੀ ਟੁੱਟਿਆ ਅਤੇ ਕਿਉਂ।

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

ਇੱਕ “ਗੋਲਡਨ ਪਾਥ” ਯੂਜ਼ਰ ਫਲੋ ਚੁਣੋ ਅਤੇ ਉਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ। ਕੁਝ ਐਸਾ ਚੁਣੋ ਜੋ ਲੋਕ ਰੋਜ਼ਾਨਾ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ:

sign in -> create item -> view list -> edit item -> save

ਤੁਸੀਂ ਹਰ ਛੋਟੇ ਕਦਮ ਤੋਂ ਬਾਅਦ ਇਸ ਫਲੋ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਓਗੇ। ਜੇ ਇਹ ਇੱਕੋ ਜਿਹਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ।

ਪਹਿਲੇ commit ਤੋਂ ਪਹਿਲਾਂ rollback 'ਤੇ ਸਮਝੋਤਾਂ ਕਰੋ। rollback boring ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਇੱਕ git revert, ਇੱਕ short-lived feature flag, ਜਾਂ ਇੱਕ ਪਲੇਟਫਾਰਮ snapshot ਜਿਸਨੂੰ ਤੁਸੀਂ ਮੁੜ-ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ snapshots ਅਤੇ rollback ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਸਹਾਇਕ ਸੁਰੱਖਿਆ ਜਾਲ ਹੋ ਸਕਦੇ ਹਨ ਜਦ ਤੁਸੀਂ ਦੁਬਾਰਾ ਸੰਗਠਿਤ ਕਰ ਰਹੇ ਹੋ।

ਹਰ ਪੜਾਅ ਲਈ ਇੱਕ ਛੋਟੀ-ਚੋਟੀ definition of done ਰੱਖੋ। ਤੁਹਾਨੂੰ ਵੱਡੀ ਚੈਕਲਿਸਟ ਦੀ ਲੋੜ ਨਹੀਂ, ਸਿਰਫ ਐਨੀ ਕਿ “move + change” ਚੁਪਚਾਪ ਨਾਂ ਹੋਵੇ:

• ਇੱਕੋ inputs ਉਹੀ outputs ਪੈਦਾ ਕਰਨ (errors ਅਤੇ empty states ਸميت)
• ਗੋਲਡਨ ਪਾਥ ਇੱਕ ਤੇਜ਼ ਮੈਨੁਅਲ ਟੈਸਟ ਪਾਸ ਕਰੇ (ਜਾਂ ਇੱਕ ਛੋਟੀ ਆਟੋਮੇਟੇਡ ਚੈਕ)
• ਬਦਲਾਅ ਉਸ ਪੜਾਅ ਦੀ ਸਕੋਪ 'ਚ ਹੀ ਰਹਿਣ (ਸਿਰਫ routes, ਜਾਂ ਸਿਰਫ services) -Rollback ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰੀ ਚੈੱਕ ਕੀਤਾ ਗਿਆ (ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਕਰੋ)
• ਇੱਕ ਛੋਟਾ ਨੋਟ ਇਹ ਵਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਮੂਵ ਹੋਇਆ ਅਤੇ ਹੁਣ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ

ਜੇ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਇਕ ਫਾਇਲ ਹੈ ਜੋ routes, DB queries ਅਤੇ UI ਫਾਰਮੈਟਿੰਗ ਸਭ ਸੰਭਾਲਦੀ ਹੈ, ਤਾਂ ਸਭ ਕੁਝ ਇਕੱਠੇ ਨਾ ਵੰਡੋ। ਪਹਿਲਾਂ ਸਿਰਫ route handlers ਨੂੰ ਇੱਕ ਫੋਲਡਰ ਵਿੱਚ ਮੂਵ ਕਰੋ ਅਤੇ ਲਾਜਿਕ ਨੂੰ ਉਹੀ ਰੱਖੋ, ਚਾਹੇ ਇਹ ਕਾਪੀ-ਪੇਸਟ ਹੋਵੇ। ਜਦ ਇਹ ਥਿਰ ਹੋ ਜਾਵੇ, ਤਦ ਹੀ services ਅਤੇ DB access ਨੂੰ ਅਗਲੇ ਪੜਾਅ ਵਿੱਚ ਕੱਢੋ।

ਤੇਜ਼ ਇਨਵੈਂਟਰੀ: routes, ਸਕ੍ਰੀਨਸ, ਅਤੇ ਡੇਟਾ ਪਾਥ

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਜੋ ਅੱਜ ਮੌਜੂਦ ਹੈ ਉਸਦਾ ਮੈਪ ਬਣਾਓ। ਇਹ ਇੱਕ ਰੀਡਿਜ਼ਾਇਨ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਕਦਮ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਛੋਟੇ, ਵਾਪਸ ਕਰਨਯੋਗ ਮੂਵ ਕਰ ਸਕੋ।

ਹਰ ਰੂਟ ਜਾਂ ਐਂਡਪਾਇੰਟ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਇਹ ਲਿਖੋ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ। UI routes (ਪੇਜ) ਅਤੇ API routes (ਹੈਂਡਲਰ) ਦੋਹਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ chat-driven generator ਵਰਤਿਆ ਅਤੇ ਕੋਡ ਐਕਸਪੋਰਟ ਕੀਤਾ, ਤਾਂ ਇਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਟਰੀਟ ਕਰੋ: ਇਨਵੈਂਟਰੀ ਨੂੰ ਜੋ ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ ਉਸ ਨਾਲ ਕੋਡ ਜੋ ਛੂਹਦਾ ਹੈ, ਉਸਦੇ ਨਾਲ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਕ ਹਲਕਾ ਫੁਲਕਾ ਇਨਵੈਂਟਰੀ ਜੋ ਵਰਤਣਯੋਗ ਰਹੇ:

• Route/endpoint + ਮਕਸਦ (ਉਦਾਹਰਨ: "/checkout" ਪੇਮੈਂਟ ਫਾਰਮ ਦਿਖਾਉਂਦਾ ਹੈ)
• UI screen/component ਜੋ ਇਸ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦਾ ਹੈ
• ਸ਼ਾਮਿਲ ਬਿਜਨੈਸ ਨਿਯਮ (pricing, validation, permissions)
• ਡੇਟਾਬੇਸ ਟੇਬਲ ਸਪਸ਼ਟ ਅਤੇ ਐਕਸੈਸ ਕਿਸਮ (read/write/transaction)
• ਨਕਲਾਂ ਅਤੇ ਦੁਹਰਾਅ (ਉਹੀ validation ਤਿੰਨ ਫਾਇਲਾਂ ਵਿੱਚ ਕਾਪੀ ਕੀਤੀ ਗਈ)

ਹਰ ਰੂਟ ਲਈ ਇੱਕ ਛੋਟਾ “ਡੇਟਾ ਪਾਥ” ਨੋਟ ਲਿਖੋ:

UI event -> handler -> logic -> DB query -> response -> UI update

ਜਦ ਤੁਸੀਂ ਜਾ ਰਹੇ ਹੋ, ਤਾਂ ਜੋਖਿਮ ਵਾਲੇ ਖੇਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਸ-ਪਾਸ ਦੇ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਕਰਦਿਆਂ ਉਹਨਾਂ ਨੂੰ ਨਾ ਛੇੜੋ:

• Payments ਅਤੇ billing
• Auth, sessions, roles
• ਡੇਟਾਬੇਸ migrations ਅਤੇ seed ਸਕ੍ਰਿਪਟ
• Background jobs ਅਤੇ scheduled tasks
• ਕੁਝ ਵੀ ਜੋ transaction ਵਿੱਚ ਚੱਲਦਾ ਹੈ

ਅਖੀਰ ਵਿੱਚ, ਇੱਕ ਸਧਾਰਨ ਟਾਰਗਟ ਮੋਡੀਊਲ ਨਕਸ਼ਾ ਸਕੈਚ ਕਰੋ। ਇਸਨੂੰ ਗਹਿਰਾ ਨਾ ਰੱਖੋ। ਤੁਸੀਂ ਗੰਤਵਯ ਚੁਣ ਰਹੇ ਹੋ, ਨਿੱਕੀ ਸਰਚਨਾ ਨਹੀਂ ਬਣਾ ਰਹੇ:

routes/handlers, services, db (queries/repositories), ui (screens/components)

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

ਪੜਾਅ 1: ਲਾਜਿਕ ਬਦਲੇ ਬਗੈਰ routes ਨੂੰ ਸਥਿਰ ਕਰੋ

ਰੂਟਸ (ਜਾਂ controllers) ਨੂੰ ਇੱਕ ਬਾਊਂਡਰੀ ਮੰਨੋ, ਨਾ ਕਿ ਕੋਡ ਸੁਧਾਰਨ ਦੀ ਜਗ੍ਹਾ। ਮਕਸਦ ਹੈ ਹਰ ਬੇਨਤੀ ਦਾ ਵਿਵਹਾਰ ਇੱਕੋ ਜਿਹਾ ਰੱਖਣਾ ਜਦੋਂ ਤੁਸੀਂ endpoints ਨੂੰ ਉਸਥਿਤੀ ਸਥਾਨਾਂ 'ਤੇ ਰੱਖ ਰਹੇ ਹੋ।

ਹਰ ਫੀਚਰ ਖੇਤਰ ਲਈ ਇੱਕ ਪਤਲਾ ਮੋਡੀਊਲ ਬਣਾਓ, ਜਿਵੇਂ users, orders, ਜਾਂ billing। “ਹੁਣੇ-ਹੀ ਸਾਫ਼ ਕਰਨ” ਤੋਂ ਬਚੋ। ਜੇ ਤੁਸੀਂ ਇੱਕੋ commit ਵਿੱਚ rename, ਫਾਇਲਾਂ ਦਾ reorganize, ਅਤੇ ਲਾਜਿਕ rewrite ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਮੁਸ਼ਕਲ ਹੈ ਪਤਾ ਲਗਾਉਣਾ ਕਿ ਕੀ ਟੁੱਟਿਆ।

ਇੱਕ ਸੁਰੱਖਿਅਤ ਕ੍ਰਮ:

• ਮੌਜੂਦਾ route handlers ਨੂੰ ਫੀਚਰ ਅਨੁਸਾਰ ਗਰੁੱਪ ਕਰੋ, ਭਾਵੇਂ ਅੰਦਰੂਨੀ ਗੰਦੇ ਹੋਣ
• ਪਹਿਲਾਂ ਸਿਰਫ਼ wiring code ਮੂਵ ਕਰੋ: params ਪੜ੍ਹੋ, ਬੇਸਿਕ validation, ਇੱਕੋ ਮੌਜੂਦਾ ਫੰਕਸ਼ਨਾਂ ਨੂੰ کال ਕਰੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਦੇ ਹੋ
• ਜਵਾਬ ਇਕੋ ਜਿਹੇ ਰੱਖੋ: status codes, error messages, ਅਤੇ payload shapes
• ਹਰ route ਲਈ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਗੋਲਡਨ ਪਾਥ ਚੈਕ ਜੋੜੋ (ਹੈਪੀ-ਪਾਥ ਕਾਲ ਜੋ ਕੰਮ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ)

ਠੋਸ ਉਦਾਹਰਨ: ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਿੰਗਲ ਫਾਇਲ ਹੈ ਜਿਸ ਵਿੱਚ POST /orders JSON parse ਕਰਦਾ ਹੈ, ਫੀਲਡ ਚੈਕ ਕਰਦਾ ਹੈ, totals ਗਣਨਾ ਕਰਦਾ ਹੈ, DB ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਨਵਾਂ ਆਰਡਰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ rewrite ਨਾ ਕਰੋ। ਹੈਂਡਲਰ ਨੂੰ orders/routes ਵਿੱਚ ਨਿਕਾਲੋ ਅਤੇ ਪੁਰਾਣੀ ਲਾਜਿਕ ਨੂੰ ਕਾਲ ਕਰੋ, ਜਿਵੇਂ createOrderLegacy(req)। ਨਵਾਂ ਰੂਟ ਮੋਡੀਊਲ ਦਰਵਾਜ਼ਾ ਬਣ ਜਾਂਦਾ ਹੈ; ਲੇਗੇਸੀ ਲਾਜਿਕ ਫਿਲਹਾਲ ਅਛੇਤੀ ਰਹਿੰਦੀ ਹੈ।

ਜੇ ਤੁਸੀਂ generated ਕੋਡ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Go ਬੈਕਐਂਡ ਜੋ Koder.ai ਵਿੱਚ ਬਣਿਆ), ਮਨੋਵਿਗਿਆਨ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ। ਹਰ endpoint ਨੂੰ ਇੱਕ ਭਵਿੱਖ-ਭਰੋਸੇਯੋਗ ਥਾਂ ਤੇ ਰੱਖੋ, ਲੇਗੇਸੀ ਲਾਜਿਕ ਨੂੰ ਰੈਪ ਕਰੋ, ਅਤੇ ਆਮ request ਸਫਲ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਪੜਾਅ 2: ਬਿਜਨੈਸ ਲਾਜਿਕ ਨੂੰ services ਵਿੱਚ ਖਿੱਚੋ

ਰੂਟਸ ਬਿਜਨੈਸ ਨਿਯਮਾਂ ਲਈ ਚੰਗੀ ਜਗ੍ਹਾ ਨਹੀਂ ਹਨ। ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੇ ਹਨ, ਕਾਂਸਨਰੰਸ ਮਿਕਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਨੂੰ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਾਰਾ ਕੁਝ ਛੇੜ ਰਹੇ ਹੋ।

ਹਰ ਯੂਜ਼ਰ-ਸਾਮ੍ਹਣਾ ਕਾਰਵਾਈ ਲਈ ਇੱਕ ਸਰਵਿਸ ਫੰਕਸ਼ਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਇੱਕ ਰੂਟ ਨੂੰ ਇਨਪੁੱਟ ਇਕੱਠੇ ਕਰਨੇ, ਇੱਕ ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰਨਾਂ, ਅਤੇ ਜਵਾਬ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਕਾਲਾਂ, pricing rules, ਅਤੇ permission checks ਨੂੰ ਰੂਟਸ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।

ਸਰਵਿਸ ਫੰਕਸ਼ਨ ਇੱਕ ਕੰਮ ਰੱਖਣ 'ਤੇ ਅਸਾਨ ਰਹਿੰਦੇ ਹਨ, ਸਪਸ਼ਟ ਇਨਪੁੱਟਸ, ਅਤੇ ਸਪਸ਼ਟ ਆਉਟਪੁੱਟ। ਜੇ ਤੁਸੀਂ “ਅਤੇ ਵੀ…” ਜੋੜਦੇ ਰਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਵੰਡੋ।

ਇੱਕ ਨਾਮਕਰਨ ਪੈਟਰਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ:

• CreateOrder(input) -> order
• CancelOrder(orderId, actor) -> result
• GetOrderSummary(orderId) -> summary

ਨਿਯਮਾਂ ਸਰਵਿਸਾਂ ਵਿੱਚ ਰਹਿਣ, UI ਵਿੱਚ ਨਹੀਂ। ਉਦਾਹਰਨ ਲਈ: UI ਨੂੰ ਬਟਨ ਡਿਜੇਬਲ ਕਰਨਾ ਆਧਾਰਿਤ ਹੋ ਸਕਦਾ ਹੈ “premium users 10 orders ਬਣਾਉ ਸਕਦੇ ਹਨ” // ਪਰ ਇਹ ਨਿਯਮ ਸਰਵਿਸ ਵਿੱਚ ਅਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। UI ਹਾਲੇ ਦੋਸਤਾਨਾ ਸੁਨੇਹਾ ਦਿਖਾ ਸਕਦੀ ਹੈ, ਪਰ ਨਿਯਮ ਇੱਕ ਜਗ੍ਹਾ ਤੇ ਰਹਿੰਦਾ ਹੈ।

ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ, ਬਦਲਾਅ ਵਾਪਸ ਕਰਨਯੋਗ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਟੈਸਟ ਜ਼ੋੜੋ:

• ਇੱਕ ਹੈਪੀ-ਪਾਥ ਟੈਸਟ ਜੋ create/update ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ
• ਇੱਕ error-path ਟੈਸਟ (ਕੋਈ ਜਰੂਰੀ ਫੀਲਡ ਗਾਇਬ, permission denied)

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਕੋਈ ਤਕਨੀਕੀ ਸੰਦ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਸਰਵਿਸਾਂ ਤੁਹਾਡੀ ਨਹਿਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਰੂਟ ਅਤੇ UI ਵਿਕਸਤ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਨਿਯਮ ਅਸਥਿਰ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਰਹਿੰਦੇ ਹਨ।

ਪੜਾਅ 3: ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅਲੱਗ ਕਰੋ

ਜਦ ਰੂਟਸ ਸਥਿਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਸਰਵਿਸਾਂ ਮੌਜੂਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਡੇਟਾਬੇਸ ਨੂੰ “ਸਭ ਜਗ੍ਹਾ” ਨਾ ਚਲਾਉਣ ਦਿਓ। ਰਾ ਕੁਐਰੀਆਂ ਨੂੰ ਇੱਕ ਛੋਟੇ, ਬੋਰਿੰਗ ਡੇਟਾ ਐਕਸੈਸ ਲੇਅਰ ਦੇ ਪਿੱਛੇ ਲੁਕਾਓ।

ਇੱਕ ਛੋਟਾ ਮੋਡੀਊਲ (repository/store/queries) ਬਣਾਓ ਜੋ ਕੁਝ ਸਪਸ਼ਟ ਨਾਮਾਂ ਵਾਲੀਆਂ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਇਕਸਪੋਜ਼ ਕਰੇ, ਜਿਵੇਂ GetUserByEmail, ListInvoicesForAccount, ਜਾਂ SaveOrder। ਇਥੇ ਸੁੰਦਰਤਾ ਦੀ ਪਾਲਣਾ ਨਾ ਕਰੋ। ਹਰ SQL ਸਟਰਿੰਗ ਜਾਂ ORM ਕਾਲ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਘਰ ਬਣਾਉ।

ਇਸ ਪੜਾਅ ਨੂੰ ਸਖਤੀ ਨਾਲ ਢਾਂਚੇ ਬਾਰੇ ਰੱਖੋ। ਸਕੀਮਾ ਬਦਲਾਅ, ਇੰਡੈਕਸ ਟਵੀਕਸ, ਜਾਂ “ਇੱਥੇ ਹੋ ਕੇ” migrations ਤੋਂ ਬਚੋ। ਉਹਨਾਂ ਲਈ ਆਪਣੀ ਯੋਜਨਾ ਅਤੇ rollback ਚਾਹੀਦੀ ਹੈ।

ਇੱਕ ਥਾਂ ਤੇ transactions ਰੱਖੋ

ਇੱਕ ਆਮ ਪ੍ਰੋਟੋਟਾਈਪ ਸੁਗੰਧ ਹੈ ਫੈਲੀ ਹੋਈ transactions: ਇੱਕ ਫੰਕਸ਼ਨ transaction ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਚੁਪਚਾਪ ਆਪਣੀ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ error handling ਫਾਇਲਾਂ ਅਨੁਸਾਰ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।

ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਐਨਟਰੀ ਪੌਇੰਟ ਬਣਾਓ ਜੋ callback ਨੂੰ transaction ਦੇ ਅੰਦਰ ਚਲਾਏ, ਅਤੇ repositories ਨੂੰ transaction context ਮਿਲੇ।

ਮੂਵਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ:

• ਇੱਕ ਸਮੇਂ ਇੱਕ query repository ਵਿੱਚ ਮੂਵ ਕਰੋ, ਇੱਕੋ inputs/outputs ਰੱਖਦੇ ਹੋਏ
• ਸਰਵਿਸਾਂ ਸਿੱਧਾ ਨਵੀਂ repository ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨ
• transaction begin/commit/rollback ਨੂੰ ਇੱਕ helper ਵਿੱਚ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰੋ
• error mapping ਨੂੰ ਸਟੈਂਡਰਡ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, “not found” ਵਸੁਲ vs “unexpected error”)

ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ “Create Project” ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਇੰਸਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਡੀਫਾਲਟ settings ਇੰਸਰਟ ਕਰਦਾ ਹੈ, ਦੋਹਾਂ ਕਾਲਾਂ ਨੂੰ ਇੱਕ transaction helper ਵਿੱਚ ਰੱਖੋ। ਜੇ ਕੁਝ ਅੱਧ-ਰਸਤੇ ਵਿੱਚ FAIL ਕਰੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਉਹ ਪ੍ਰੋਜੈਕਟ ਨਾ ਹੋਵੇ ਜਿਸਦੇ settings ਨਹੀਂ ਹਨ।

ਜਦ ਸਰਵਿਸਾਂ ਇੱਕ concrete DB client ਦੀ ਬਜਾਏ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਵਿਹਾਰ ਨੂੰ ਅਸਲੀ ਡੇਟਾਬੇਸ ਬਿਨਾਂ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਡਰ ਘਟਾਉਂਦਾ ਹੈ, ਜਿਸੇ ਇਹ ਪੜਾਅ ਦਾ ਮਕਸਦ ਹੈ।

ਪੜਾਅ 4: UI ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ redesign ਤੋਂ ਬਿਨਾਂ ਸਾਫ਼ ਕਰੋ

UI ਸਾਫ਼-ਕਰਨ ਸੁੰਦਰ ਬਣਾਉਣ ਬਾਰੇ ਨਹੀਂ। ਇਹ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਭਵਿੱਖਬਾਣੀਯੋਗ ਬਣਾਉਣ ਅਤੇ ਅਚਾਨਕ side-effects ਘਟਾਉਣ ਬਾਰੇ ਹੈ।

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

props ਨੂੰ ਸਧਾਰਨ ਰੱਖੋ। ਸਿਰਫ ਉਹੀ ਪਾਸ ਕਰੋ ਜੋ ਕੰਪੋਨੈਂਟ ਨੂੰ ਚਾਹੀਦਾ ਹੈ (strings, ids, booleans, callbacks)। ਜੇ ਤੁਸੀਂ ਇੱਕ ਵੱਡਾ object “ਸ=false” ਕਰਕੇ ਪਾਸ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਛੋਟੀ ਸ਼ੇਪ ਨਿਰਧਾਰਿਤ ਕਰੋ।

UI ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ API ਕਾਲਾਂ ਨੂੰ ਬਾਹਰ ਲਵੋ। ਭਾਵੇਂ سرਵਿਸ ਲੇਅਰ ਹੋਵੇ, UI ਕੋਡ ਅਕਸਰ fetch ਲਾਜਿਕ, retries, ਅਤੇ mapping ਰੱਖਦਾ ਹੈ। ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਛੋਟਾ client ਮੋਡਿਊਲ ਬਣਾਓ ਜੋ ਸਕ੍ਰੀਨ ਲਈ ਤਿਆਰ-ਹੈ ਡੇਟਾ ਵਾਪਸ ਕਰੇ।

ਫਿਰ ਲੋਡਿੰਗ ਅਤੇ error handling ਨੂੰ ਸਕ੍ਰੀਨਾਂ 'ਚ ਲਗਾਤਾਰ ਬਣਾ ਦਿਓ। ਇੱਕ ਪੈਟਰਨ ਚੁਣੋ ਅਤੇ ਦੁਹਰਾਓ: ਇੱਕ ਪੂਰਨpredictable loading state, ਇੱਕ ਸਟੈਂਡਰਡ error message ਇੱਕ retry action ਨਾਲ, ਅਤੇ empty states ਜੋ ਅਗਲਾ ਕਦਮ ਸਮਝਾਉਂਦੇ ਹਨ।

ਹਰ ਨਿਕਾਸ ਤੋਂ ਬਾਅਦ ਸਕਰੀਨ ਦੀ ਇੱਕ ਤੇਜ਼ visual ਜਾਂਚ ਕਰੋ। ਮੁੱਖ actions 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਪੇਜ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ, ਅਤੇ ਇੱਕ error ਕੇਸ ਟ੍ਰਿਗਰ ਕਰੋ। ਛੋਟੇ ਕਦਮ ਵੱਡੇ UI rewrites ਨਾਲੋਂ ਬਿਹਤਰ ਹਨ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇੱਕ ਫੀਚਰ ਦਾ ਐਂਡ-ਟੁ-ਐਂਡ ਰੀਫੈਕਟਰ

ਧਾਰੋ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਟੋਟਾਈਪ ਹੈ ਜਿੰਨਾਂ ਵਿੱਚ ਤਿੰਨ ਸਕ੍ਰੀਨ ਹਨ: sign in, list items, edit item। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਹਰ ਰੂਟ auth checks, ਬਿਜਨੈਸ ਰੂਲ, SQL, ਅਤੇ UI state ਨੂੰ ਮਿਲਾ ਕੇ ਰੱਖਦਾ ਹੈ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਹੈ ਸਿਰਫ ਇਸ ਫੀਚਰ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਮੋਡੀਊਲ ਵਿੱਚ ਬਦਲਣਾ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰਵਰਸ ਕਰ ਸਕਦੇ ਹੋ।

ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ: ਕੀ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ

ਪਹਿਲਾਂ, “items” ਲਾਜਿਕ ਬਿੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ:

server/
  main.go
  routes.go
  handlers.go          # sign in + items + random helpers
  db.go                # raw SQL helpers used everywhere
web/
  pages/
    SignIn.tsx
    Items.tsx          # fetch + state + form markup mixed

ਬਾਅਦ ਵਿੱਚ, ਵਿਵਹਾਰ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਬਾਊਂਡਰੀਆਂ ਸਾਫ਼ ਹਨ:

server/
  routes/
    items_routes.go
  handlers/
    items_handler.go
  services/
    items_service.go
  repositories/
    items_repo.go
web/
  pages/
    Items.tsx
  components/
    ItemForm.tsx

ਇੱਕ end-to-end ਪਾਸ (ਛੋਟਾ, ਵਾਪਸ-ਯੋਗ)

ਪਹਿਲਾਂ ਕੋਡ ਨੂੰ ਬਦਲੇ ਬਗੈਰ ਮੂਵ ਕਰੋ। ਫੰਕਸ਼ਨ ਨਾਂ ਅਤੇ ਵਾਪਸੀ ਰੂਪ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ, ਤਾਂ ਜੋ rollback ਮੁੱਖ ਤੌਰ 'ਤੇ ਫਾਇਲ ਮੂਵ ਹੋਵੇ।

ਪਹਿਲਾਂ ਇੱਕ ਰੂਟ ਰੀਫੈਕਟਰ ਕਰੋ। ਹੈਂਡਲਰ ਸਿਰਫ HTTP ਨਾਲ ਨਿਪਟੇ, ਨਾ ਕਿ ਨਿਯਮਾਂ ਜਾਂ SQL ਨਾਲ:

// handlers/items_handler.go
func (h *ItemsHandler) UpdateItem(w http.ResponseWriter, r *http.Request) {
  userID := h.auth.UserIDFromRequest(r) // same auth logic as before
  itemID := mux.Vars(r)["id"]

  var in UpdateItemInput
  json.NewDecoder(r.Body).Decode(&in)

  item, err := h.itemsService.UpdateItem(r.Context(), userID, itemID, in)
  if err != nil { writeError(w, err); return }
  writeJSON(w, item)
}

ਅਗਲੇ ਕਦਮ ਵਿੱਚ, ਬਿਜਨੈਸ ਨਿਯਮਾਂ ਨੂੰ ਸਰਵਿਸ ਵਿੱਚ ਖਿੱਚੋ। ਇੱਥੇ ਤੁਸੀਂ ਐਸੇ ਚੈੱਕ ਰੱਖਦੇ ਹੋ ਜਿਵੇਂ “ਯੂਜ਼ਰ ਸਿਰਫ ਆਪਣੇ ਹੀ ਆਈਟਮ ਸਾਂਭ ਸਕਦਾ ਹੈ” ਜਾਂ “ਨਾਂ ਖਾਲੀ ਨਹੀਂ ਹੋ ਸਕਦਾ।” ਸਰਵਿਸ ਇੱਕ repository ਨੂੰ DB ਕੰਮ ਲਈ ਕਾਲ ਕਰਦੀ ਹੈ:

// services/items_service.go
func (s *ItemsService) UpdateItem(ctx context.Context, userID, itemID string, in UpdateItemInput) (Item, error) {
  if strings.TrimSpace(in.Name) == "" { return Item{}, ErrInvalidName }
  return s.repo.UpdateItem(ctx, userID, itemID, in)
}

ਫਿਰ DB ਐਕਸੈਸ ਨੂੰ repository ਫੰਕਸ਼ਨ ਵਿੱਚ ਅਲੱਗ ਕਰੋ:

// repositories/items_repo.go
func (r *ItemsRepo) UpdateItem(ctx context.Context, userID, itemID string, in UpdateItemInput) (Item, error) {
  row := r.db.QueryRowContext(ctx,
    `UPDATE items SET name=$1 WHERE id=$2 AND user_id=$3 RETURNING id, name`,
    in.Name, itemID, userID,
  )
  var it Item
  err := row.Scan(&it.ID, &it.Name)
  return it, err
}

UI ਪਾਸੇ, ਪੇਜ ਦਾ layout ਰੱਖੋ, ਪਰ ਨਵਾਂ ਅਤੇ ਸੰਪਾਦਨ ਫਲੋ ਵਿੱਚ ਵਰਤੇ ਗਏ ਦੁਹਰਾਏ ਫਾਰਮ ਮਾਰਕਅਪ ਨੂੰ ਸਾਂਝੀ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਨਿਕਾਲੋ:

• pages/Items.tsx ਫੈਚਿੰਗ ਅਤੇ ਨੈਵੀਗੇਸ਼ਨ ਰੱਖਦਾ ਹੈ
• components/ItemForm.tsx ਇਨਪੁਟ ਫੀਲਡ, validation ਸੁਨੇਹੇ, ਅਤੇ submit ਬਟਨ ਨੂੰ ਮਾਲਕਾਨਾ ਹੈ

ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਦਾ source code export ਗਹਿਰੇ ਰੀਫੈਕਟਰ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਹਾਇਕ ਸੰਦ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ snapshots/rollback ਦੇ ਨਾਲ ਤੁਸੀਂ ਜਲਦੀ ਬਰਾਮਦ ਹੋ ਸਕਦੇ ਹੋ ਜੇ ਕੋਈ ਮੂਵ ਗਲਤ ਹੋ ਜਾਵੇ।

ਆਮ ਫੰਦ ਜੋ ਜੋਖਮ ਵਧਾ ਦਿੰਦੇ ਹਨ

ਸਭ ਤੋਂ ਵੱਡਾ ਜੋਖਿਮ “move” ਕੰਮ ਨੂੰ “change” ਕੰਮ ਨਾਲ ਮਿਲਾਉਣਾ ਹੈ। ਜਦ ਤੁਸੀਂ ਫਾਇਲਾਂ ਨੂੰ ਰੀਲੋਕੇਟ ਕਰਦੇ ਹੋ ਅਤੇ ਇੱਕੋ commit ਵਿੱਚ ਲਾਜਿਕ ਨੂੰ ਵੀ rewrite ਕਰਦੇ ਹੋ, ਤਾਂ ਬੱਗ ਸ਼ੋਰ-ਭਰੇ diffs ਵਿੱਚ ਚੁਪ ਜਾ ਸਕਦੇ ਹਨ। ਮੂਵ ਨੂੰ ਨੀਰਸ ਰੱਖੋ: ਉਹੀ ਫੰਕਸ਼ਨ, ਉਹੀ ਇਨਪੁੱਟਸ, ਉਹੀ ਆਉਟਪੁੱਟਸ, ਨਵਾਂ ਘਰ।

ਦੂਜਾ ਫੰਦ ਸੁਧਾਰ ਜੋ ਵਿਹਾਰ ਬਦਲਦਾ ਹੈ। ਵੇਰੀਏਬਲਾਂ ਦਾ ਨਾਮ ਬਦਲਣਾ ਠੀਕ ਹੈ; ਧਾਰਣਾਵਾਂ ਦੇ ਨਾਮਾਂ ਨੂੰ ਬਦਲਣਾ ਨਹੀਂ। ਜੇ status ਸਟਰਿੰਗ ਤੋਂ ਨੰਬਰਾਂ ਵੱਲ ਬਦਲੇ, ਤਾਂ ਤੁਸੀਂ ਕੋਡ ਨਹੀਂ, ਉਤਪਾਦ ਬਦਲ ਰਹੇ ਹੋ। ਉਹ ਬਾਅਦ ਵਿੱਚ ਕਰੋ ਜਿਸਦੇ ਕੋਲ ਸਾਫ਼ ਟੈਸਟ ਅਤੇ ਸੰਕੇਤਤ ਰਿਲੀਜ਼ ਹੋਵੇ।

ਉਹ ਪੈਟਰਨ ਜੋ ਚੁਪਚਾਪ ਮੁਸ਼ਕਲ ਖੜੇ ਕਰਦੇ ਹਨ

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

ਇਸਦੇ ਨਾਲ-ਨਾਲ UI ਦਾ ਸਿੱਧਾ ਡੇਟਾਬੇਸ ਤੱਕ ਪੁੱਜਣਾ ਜਾਂ raw queries ਨੂੰ ਹੇਲਪਰ ਰਾਹੀਂ ਕਾਲ ਕਰਵਾਉਣਾ ਵੀ ਛੁਟੀਆਂ ਰਾਹਾਂ ਹਨ। ਇਹ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਹਰ ਸਕ੍ਰੀਨ ਨੂੰ permissions, data ਨਿਯਮ, ਅਤੇ error handling ਦੇ ਜ਼ਿੰਮੇਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।

ਖਤਰੇ ਵਧਾਉਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਤੋਂ ਬਚੋ:

• ਵੱਡੇ ਰੀਫੈਕਟਰ commits ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਛੇੜਦੇ ਹਨ ਅਤੇ ਲਾਜਿਕ ਵੀ ਬਦਲਦੇ ਹਨ
• ਸ਼ੇਅਰ ਕੀਤੇ return shapes ਬਿਨਾਂ ਹਰ caller ਨੂੰ ਅਪਡੇਟ ਕੀਤੇ ਬਦਲ ਦਿੱਤੇ ਜਾਣ
• ਕੋਈ ਸਪਸ਼ਟ ਕਾਰਨ ਬਿਨਾਂ ਨਵੀਆਂ ਲੇਅਰਾਂ ਜੋੜੀ ਜਾਣ
• Error handling ਨੂੰ ਫਲੈਟ ਕਰ ਦੇਣਾ (ਸਭ ਕੁਝ null ਜਾਂ ਇੱਕ ਸਮਾਨ ਸੁਨੇਹੇ)

ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ { ok: true, data } ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਪਰ ਨਵੀਂ ਸਰਵਿਸ { data } ਵਾਪਸ ਕਰਦੀ ਹੈ ਅਤੇ errors 'ਤੇ throw ਕਰਦੀ ਹੈ, ਤਾਂ ਅਧਾ ਐਪ ਦੋਸਤਾਨਾ ਸੁਨੇਹੇ ਦਿਖਾਉਣਾ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਬਾਊਂਡਰੀ 'ਤੇ ਪੁਰਾਣਾ ਆਕਾਰ ਰੱਖੋ, ਫਿਰ callers ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਮਾਈਗ੍ਰੇਟ ਕਰੋ।

ਅਗਲੇ ਪੜਾਅ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈੱਕ

ਅਗਲੇ ਕਦਮ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਬਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਮੁੱਖ ਅਨੁਭਵ ਨੂੰ ਨਹੀਂ ਤੋੜਿਆ। ਹਰ ਵਾਰੀ ਇੱਕੋ ਗੋਲਡਨ ਪਾਥ ਚਲਾਓ (sign in, create an item, view it, edit it, delete it)। ਸਥਿਰਤਾ ਤੁਹਾਨੂੰ ਛੋਟੇ ਰਿਗ੍ਰੈਸ਼ਨਜ਼ ਨੂੰ ਪਛਾਣਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।

ਹਰ ਪੜਾਅ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਿਆਣਾ go/no-go ਗੇਟ ਵਰਤੋ:

• ਗੋਲਡਨ ਪਾਥ ਅਜੇ ਵੀ end-to-end ਕੰਮ ਕਰਦਾ ਹੈ, ਆਮ error ਕੇਸ ਸਮੇਤ
• Routes/controllers ਪਤਲੇ ਹਨ: input ਪੜ੍ਹੋ, ਇੱਕ ਸਰਵਿਸ ਕਾਲ ਕਰੋ, ਜਵਾਬ ਦਿਓ
• Services ਪੋਰਟੇਬਲ ਹਨ: routes, background jobs, ਜਾਂ UI actions ਤੋਂ ਬਿਨਾਂ HTTP ਜਾਣਕਾਰੀ ਦੇ ਬਿਨਾਂ ਕਾਲ ਕੀਤੇ ਜਾ ਸਕਦੇ
• ਡੇਟਾਬੇਸ ਐਕਸੈਸ ਕੇਂਦਰੀਕ੍ਰਿਤ ਹੈ ਇੱਕ transaction ਪੈਟਰਨ ਅਤੇ ਇੱਕਸਾਰ error handling ਨਾਲ
• Rollback ਤੇਜ਼ ਅਤੇ ਸਾਬਤ ਹੋਇਆ

ਜੇ ਇਕ ਵੀ ਫੇਲ ਹੋਵੇ, ਰੁਕੋ ਅਤੇ ਠੀਕ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਉਸ 'ਤੇ ਅਧਾਰਿਤ ਹੋਵੋ। ਛੋਟੀ ਦਰਾਰਾਂ ਬਾਅਦ ਵੱਡੀਆਂ ਬਣ ਜਾਦੀਆਂ ਹਨ।

“ਕੀ ਅਸੀਂ ਇਸਨੂੰ ਅਣਡੂ ਕਰ ਸਕਦੇ ਹਾਂ?” ਇੱਕ ਛੋਟੀ ਡ੍ਰਿਲ

ਮਿਊਜ਼ਿਕ ਨਾਲ ਮਰਜ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਪੰਜ ਮਿੰਟ ਲਗਾ ਕੇ ਜਾਂਚ ਕਰੋ ਕਿ ਤੁਸੀਂ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ:

• ਆਖਰੀ commit ਨੂੰ revert ਕਰੋ ਇੱਕ ਲੋਕਲ ਸ਼ਾਖਾ 'ਤੇ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਐਪ ਬੂਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਗੋਲਡਨ ਪਾਥ ਚੱਲਦੀ ਹੈ
• ਨਵੀਂ ਕੋਡ ਪਥ ਨੂੰ ਬੰਦ ਕਰੋ (feature flag, config switch, ਜਾਂ conditional) ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਪੁਰਾਣਾ ਵਿਹਾਰ ਅਜੇ ਮੌਜੂਦ ਹੈ
• ਗੋਲਡਨ ਪਾਥ ਲਈ ਲੌਗ ਅਤੇ DB ਲਿਖਤਾਂ ਇੱਕ ਵਾਰੀ ਚੈੱਕ ਕਰੋ ਤਾਂ ਕਿ ਸਟੋਰੇਜ ਵਿਹਾਰ ਬਦਲਿਆ ਨਾ ਹੋਵੇ

ਅਗਲੇ ਕਦਮ: ਉਤਪਾਦ ਵਧਣ ਤੇ ਮੋਡੀਊਲਰ ਬਣਾਈ ਰੱਖੋ

ਜਿੱਤ ਪਹਿਲੀ ਸਾਫ਼-ਕਰਨ ਨਹੀਂ ਹੈ। ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਜਿਵੇਂ ਤੁਸੀਂ ਫੀਚਰ ਜੋੜਦੇ ਹੋ, ਢਾਂਚਾ ਕਾਇਮ ਰੱਖਣਾ। ਤੁਸੀਂ “ਪਰਫੈਕਟ ਆਰਕੀਟੈਕਚਰ” ਨਹੀਂ ਤਲਾਸ਼ ਰਹੇ—ਤੁਸੀਂ ਭਵਿੱਖ ਦੇ ਬਦਲਾਅਾਂ ਨੂੰ ਭਵਿੱਖਬਾਣੀਯੋਗ, ਛੋਟੇ, ਅਤੇ ਆਸਾਨ ਵਾਪਸ ਕਰਨਯੋਗ ਬਣਾਉਂਦੇ ਹੋ।

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

ਸਧਾਰਨ ਕੈਡੰਸ ਰੱਖੋ: ਇੱਕ ਚੀਜ਼ ਨੂੰ ਮੂਵ ਕਰਨ ਵਾਲੇ ਛੋਟੇ PR, ਛੋਟੀ ਸਮੀਖਿਆਆਂ, ਆਮ ਰਿਲੀਜ਼, ਅਤੇ ਇੱਕ ਥੰਮ-ਰੇਖਾ ਨਿਯਮ (ਜੇ ਸਕੋਪ ਵੱਧੇ, ਤਾਂ ਇਸਨੂੰ ਵੰਡੋ ਅਤੇ ਛੋਟਾ ਹਿੱਸਾ ਸ਼ਿਪ ਕਰੋ)।

ਹਰ ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ rollback ਬਿੰਦੂ ਸੈੱਟ ਕਰੋ: ਇੱਕ git tag, ਇੱਕ release branch, ਜਾਂ ਇੱਕ deployable build ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾਓ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਪੜਾਅਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਟੇਜ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਕੱਠੇ ਤਿੰਨ ਲੇਅਰਾਂ ਦਾ ਰੀਫੈਕਟਰ ਨਾ ਕਰ ਬੈਠੋ।

ਮੋਡੀਊਲਰ ਐਪ ਆਰਕੀਟੈਕਚਰ ਲਈ ਇੱਕ ਵਿਹਾਰਕ ਨਿਯਮ: ਹਰ ਨਵੇਂ ਫੀਚਰ ਨੂੰ ਇੱਕੋ ਹੱਦਾਂ ਦੇ ਅਨੁਸਾਰ ਬਣਾਓ। Routes ਪਤਲੇ ਰਹਿਣ, services ਬਿਜਨੈਸ ਨਿਯਮਾਂ ਦੇ ਮਾਲਕ ਹੋਣ, ਡੇਟਾਬੇਸ ਕੋਡ ਇੱਕ ਥਾਂ 'ਤੇ ਰਹੇ, ਅਤੇ UI ਕੰਪੋਨੈਂਟ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਧਿਆਨ ਦੇਣ। ਜਦ ਕੋਈ ਨਵਾਂ ਫੀਚਰ ਇਹ ਨਿਯਮ ਤੋੜਦਾ ਹੈ, ਤਾਂ ਛੋਟੇ ਹੋਣ 'ਤੇ ਹੀ ਰੀਫੈਕਟਰ ਕਰੋ।