ਇੱਕ ਮੰਚਬੱਧ ਯੋਜਨਾ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਨੂੰ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰੋ—ਹਰ ਬਦਲਾਅ ਨੂੰ ਛੋਟਾ, ਟੈਸਟਯੋਗ ਅਤੇ ਰੋਲਬੈਕ ਕਰਨਯੋਗ ਰੱਖਦੇ ਹੋਏ routes, services, DB ਅਤੇ UI ਵਿੱਚ।

ਪ੍ਰੋਟੋਟਾਈਪ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਾਰਾ ਕੁਝ ਨੇੜੇ-ਨੇੜੇ ਹੋnda ਹੈ. ਇੱਕ ਰੂਟ ਡੈਟਾਬੇਸ ਨੂੰ ਹਿਟ ਕਰਦਾ ਹੈ, ਜਵਾਬ ਨੂੰ ਸ਼ੇਪ ਕਰਦਾ ਹੈ, ਅਤੇ UI ਉਹ ਰੇਂਡਰ ਕਰਦਾ ਹੈ। ਉਹ ਤੇਜ਼ੀ ਅਸਲ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਲਾਗਤ ਨੂੰ ਛੁਪਾਉਂਦੀ ਹੈ: ਜਿਵੇਂ-ਜਿਵੇਂ ਹੋਰ ਫੀਚਰ ਆਉਂਦੇ ਹਨ, ਪਹਿਲਾ “ਤੇਜ਼ ਰਸਤਾ” ਉਹ ਰਸਤਾ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਸਾਰਾ ਕੁਝ ਨਿਰਭਰ ਹੋ ਜਾਂਦਾ ਹੈ.
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਟੁੱਟਦਾ ਹੈ, ਅਕਸਰ ਨਵਾਂ ਕੋਡ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਪੁਰਾਣੀਆਂ ਧਾਰਣਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ route ਵਿੱਚ ਚੁੱਪਚਾਪ ਜਵਾਬ ਦਾ ਆਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਦੋ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਟੁੱਟਦਾ ਹੈ। ਇੱਕ “ਅਸਥਾਈ” query ਜੋ ਤਿੰਨ ਥਾਂਆਂ 'ਤੇ ਕਾਪੀ ਕੀਤੀ ਗਈ ਹੁੰਦੀ ਹੈ, ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਡੇਟਾ ਵਾਪਸ ਕਰਨ ਲੱਗਦੀ ਹੈ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਹੜੀ ਸਹੀ ਹੈ।
ਈਸੇ ਲਈ ਵੱਡੇ ਰੀਰਾਈਟ ਵੀ ਅਛੇ ਇਰਾਦੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਸਫਲ ਹੁੰਦੇ ਹਨ। ਉਹ ਢਾਂਚਾ ਅਤੇ ਵਿਵਹਾਰ ਇਕੱਠੇ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਜਦ ਬੱਗ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਕਾਰਨ ਨਵਾਂ ਡਿਜ਼ਾਇਨ ਚੋਣ ਹੈ ਜਾਂ ਮੂਲ ਗਲਤੀ। ਭਰੋਸਾ ਘਟਦਾ ਹੈ, ਸਕੋਪ ਵੱਧਦਾ ਹੈ, ਅਤੇ ਰੀਰਾਈਟ ਲੰਬਾ ਖਿੱਚਦਾ ਹੈ।
ਘੱਟ-ਖਤਰੇ ਵਾਲੀ ਰੀਫੈਕਟਰਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਬਦਲਾਅ ਨੂੰ ਛੋਟੇ ਅਤੇ ਵਾਪਸ ਕਰਨਯੋਗ ਰੱਖਣਾ। ਤੁਸੀਂ ਹਰ ਕਦਮ ਤੋਂ ਬਾਅਦ ਰੁਕ ਸਕੋ ਅਤੇ ਫਿਰ ਵੀ ਇੱਕ ਕੰਮ ਕਰਦੀ ਐਪ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪ੍ਰਾਇਗਮੈਟਿਕ ਨਿਯਮ ਸਧਾਰਨ ਹਨ:
ਜਦ ਹਰ ਲੇਅਰ ਹੋਰਾਂ ਦੇ ਕੰਮ ਕਰਨ लगਦੀ ਹੈ ਤਾਂ 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” ਚੁਪਚਾਪ ਨਾਂ ਹੋਵੇ:
ਜੇ ਪ੍ਰੋਟੋਟਾਈਪ ਵਿੱਚ ਇਕ ਫਾਇਲ ਹੈ ਜੋ routes, DB queries ਅਤੇ UI ਫਾਰਮੈਟਿੰਗ ਸਭ ਸੰਭਾਲਦੀ ਹੈ, ਤਾਂ ਸਭ ਕੁਝ ਇਕੱਠੇ ਨਾ ਵੰਡੋ। ਪਹਿਲਾਂ ਸਿਰਫ route handlers ਨੂੰ ਇੱਕ ਫੋਲਡਰ ਵਿੱਚ ਮੂਵ ਕਰੋ ਅਤੇ ਲਾਜਿਕ ਨੂੰ ਉਹੀ ਰੱਖੋ, ਚਾਹੇ ਇਹ ਕਾਪੀ-ਪੇਸਟ ਹੋਵੇ। ਜਦ ਇਹ ਥਿਰ ਹੋ ਜਾਵੇ, ਤਦ ਹੀ services ਅਤੇ DB access ਨੂੰ ਅਗਲੇ ਪੜਾਅ ਵਿੱਚ ਕੱਢੋ।
ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਜੋ ਅੱਜ ਮੌਜੂਦ ਹੈ ਉਸਦਾ ਮੈਪ ਬਣਾਓ। ਇਹ ਇੱਕ ਰੀਡਿਜ਼ਾਇਨ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਕਦਮ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਛੋਟੇ, ਵਾਪਸ ਕਰਨਯੋਗ ਮੂਵ ਕਰ ਸਕੋ।
ਹਰ ਰੂਟ ਜਾਂ ਐਂਡਪਾਇੰਟ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਇਹ ਲਿਖੋ ਕਿ ਇਹ ਕੀ ਕਰਦਾ ਹੈ। UI routes (ਪੇਜ) ਅਤੇ API routes (ਹੈਂਡਲਰ) ਦੋਹਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਇੱਕ chat-driven generator ਵਰਤਿਆ ਅਤੇ ਕੋਡ ਐਕਸਪੋਰਟ ਕੀਤਾ, ਤਾਂ ਇਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਟਰੀਟ ਕਰੋ: ਇਨਵੈਂਟਰੀ ਨੂੰ ਜੋ ਯੂਜ਼ਰ ਵੇਖਦੇ ਹਨ ਉਸ ਨਾਲ ਕੋਡ ਜੋ ਛੂਹਦਾ ਹੈ, ਉਸਦੇ ਨਾਲ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਕ ਹਲਕਾ ਫੁਲਕਾ ਇਨਵੈਂਟਰੀ ਜੋ ਵਰਤਣਯੋਗ ਰਹੇ:
ਹਰ ਰੂਟ ਲਈ ਇੱਕ ਛੋਟਾ “ਡੇਟਾ ਪਾਥ” ਨੋਟ ਲਿਖੋ:
UI event -> handler -> logic -> DB query -> response -> UI update
ਜਦ ਤੁਸੀਂ ਜਾ ਰਹੇ ਹੋ, ਤਾਂ ਜੋਖਿਮ ਵਾਲੇ ਖੇਤਰਾਂ ਨੂੰ ਟੈਗ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਆਸ-ਪਾਸ ਦੇ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਕਰਦਿਆਂ ਉਹਨਾਂ ਨੂੰ ਨਾ ਛੇੜੋ:
ਅਖੀਰ ਵਿੱਚ, ਇੱਕ ਸਧਾਰਨ ਟਾਰਗਟ ਮੋਡੀਊਲ ਨਕਸ਼ਾ ਸਕੈਚ ਕਰੋ। ਇਸਨੂੰ ਗਹਿਰਾ ਨਾ ਰੱਖੋ। ਤੁਸੀਂ ਗੰਤਵਯ ਚੁਣ ਰਹੇ ਹੋ, ਨਿੱਕੀ ਸਰਚਨਾ ਨਹੀਂ ਬਣਾ ਰਹੇ:
routes/handlers, services, db (queries/repositories), ui (screens/components)
ਜੇ ਤੁਸੀਂ ਸਮਝਾ ਨਹੀਂ ਸਕਦੇ ਕਿ ਇੱਕ ਕੋਡ ਟੁਕੜਾ ਕਿੱਥੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਉਹ ਖੇਤਰ ਬਾਅਦ ਵਾਰ ਰੀਫੈਕਟਰ ਕਰਨ ਲਈ ਚੰਗਾ ਉਮੀਦਵਾਰ ਹੈ, ਜਦ ਤੁਸੀਂ ਵਧੇਰੇ ਵਿਸ਼ਵਾਸ ਬਣਵਾ ਲਓ।
ਰੂਟਸ (ਜਾਂ controllers) ਨੂੰ ਇੱਕ ਬਾਊਂਡਰੀ ਮੰਨੋ, ਨਾ ਕਿ ਕੋਡ ਸੁਧਾਰਨ ਦੀ ਜਗ੍ਹਾ। ਮਕਸਦ ਹੈ ਹਰ ਬੇਨਤੀ ਦਾ ਵਿਵਹਾਰ ਇੱਕੋ ਜਿਹਾ ਰੱਖਣਾ ਜਦੋਂ ਤੁਸੀਂ endpoints ਨੂੰ ਉਸਥਿਤੀ ਸਥਾਨਾਂ 'ਤੇ ਰੱਖ ਰਹੇ ਹੋ।
ਹਰ ਫੀਚਰ ਖੇਤਰ ਲਈ ਇੱਕ ਪਤਲਾ ਮੋਡੀਊਲ ਬਣਾਓ, ਜਿਵੇਂ users, orders, ਜਾਂ billing। “ਹੁਣੇ-ਹੀ ਸਾਫ਼ ਕਰਨ” ਤੋਂ ਬਚੋ। ਜੇ ਤੁਸੀਂ ਇੱਕੋ commit ਵਿੱਚ rename, ਫਾਇਲਾਂ ਦਾ reorganize, ਅਤੇ ਲਾਜਿਕ rewrite ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਮੁਸ਼ਕਲ ਹੈ ਪਤਾ ਲਗਾਉਣਾ ਕਿ ਕੀ ਟੁੱਟਿਆ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਕ੍ਰਮ:
ਠੋਸ ਉਦਾਹਰਨ: ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਿੰਗਲ ਫਾਇਲ ਹੈ ਜਿਸ ਵਿੱਚ POST /orders JSON parse ਕਰਦਾ ਹੈ, ਫੀਲਡ ਚੈਕ ਕਰਦਾ ਹੈ, totals ਗਣਨਾ ਕਰਦਾ ਹੈ, DB ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਨਵਾਂ ਆਰਡਰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ rewrite ਨਾ ਕਰੋ। ਹੈਂਡਲਰ ਨੂੰ orders/routes ਵਿੱਚ ਨਿਕਾਲੋ ਅਤੇ ਪੁਰਾਣੀ ਲਾਜਿਕ ਨੂੰ ਕਾਲ ਕਰੋ, ਜਿਵੇਂ createOrderLegacy(req)। ਨਵਾਂ ਰੂਟ ਮੋਡੀਊਲ ਦਰਵਾਜ਼ਾ ਬਣ ਜਾਂਦਾ ਹੈ; ਲੇਗੇਸੀ ਲਾਜਿਕ ਫਿਲਹਾਲ ਅਛੇਤੀ ਰਹਿੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ generated ਕੋਡ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, Go ਬੈਕਐਂਡ ਜੋ Koder.ai ਵਿੱਚ ਬਣਿਆ), ਮਨੋਵਿਗਿਆਨ ਇੱਕੋ ਜਿਹਾ ਰਹਿੰਦਾ ਹੈ। ਹਰ endpoint ਨੂੰ ਇੱਕ ਭਵਿੱਖ-ਭਰੋਸੇਯੋਗ ਥਾਂ ਤੇ ਰੱਖੋ, ਲੇਗੇਸੀ ਲਾਜਿਕ ਨੂੰ ਰੈਪ ਕਰੋ, ਅਤੇ ਆਮ request ਸਫਲ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਰੂਟਸ ਬਿਜਨੈਸ ਨਿਯਮਾਂ ਲਈ ਚੰਗੀ ਜਗ੍ਹਾ ਨਹੀਂ ਹਨ। ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੇ ਹਨ, ਕਾਂਸਨਰੰਸ ਮਿਕਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਹਰ ਬਦਲਾਅ ਨੂੰ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਸਾਰਾ ਕੁਝ ਛੇੜ ਰਹੇ ਹੋ।
ਹਰ ਯੂਜ਼ਰ-ਸਾਮ੍ਹਣਾ ਕਾਰਵਾਈ ਲਈ ਇੱਕ ਸਰਵਿਸ ਫੰਕਸ਼ਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਇੱਕ ਰੂਟ ਨੂੰ ਇਨਪੁੱਟ ਇਕੱਠੇ ਕਰਨੇ, ਇੱਕ ਸਰਵਿਸ ਨੂੰ ਕਾਲ ਕਰਨਾਂ, ਅਤੇ ਜਵਾਬ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਡੇਟਾਬੇਸ ਕਾਲਾਂ, pricing rules, ਅਤੇ permission checks ਨੂੰ ਰੂਟਸ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
ਸਰਵਿਸ ਫੰਕਸ਼ਨ ਇੱਕ ਕੰਮ ਰੱਖਣ 'ਤੇ ਅਸਾਨ ਰਹਿੰਦੇ ਹਨ, ਸਪਸ਼ਟ ਇਨਪੁੱਟਸ, ਅਤੇ ਸਪਸ਼ਟ ਆਉਟਪੁੱਟ। ਜੇ ਤੁਸੀਂ “ਅਤੇ ਵੀ…” ਜੋੜਦੇ ਰਹਿੰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਵੰਡੋ।
ਇੱਕ ਨਾਮਕਰਨ ਪੈਟਰਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ:
CreateOrder(input) -> orderCancelOrder(orderId, actor) -> resultGetOrderSummary(orderId) -> summaryਨਿਯਮਾਂ ਸਰਵਿਸਾਂ ਵਿੱਚ ਰਹਿਣ, UI ਵਿੱਚ ਨਹੀਂ। ਉਦਾਹਰਨ ਲਈ: UI ਨੂੰ ਬਟਨ ਡਿਜੇਬਲ ਕਰਨਾ ਆਧਾਰਿਤ ਹੋ ਸਕਦਾ ਹੈ “premium users 10 orders ਬਣਾਉ ਸਕਦੇ ਹਨ” // ਪਰ ਇਹ ਨਿਯਮ ਸਰਵਿਸ ਵਿੱਚ ਅਮਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। UI ਹਾਲੇ ਦੋਸਤਾਨਾ ਸੁਨੇਹਾ ਦਿਖਾ ਸਕਦੀ ਹੈ, ਪਰ ਨਿਯਮ ਇੱਕ ਜਗ੍ਹਾ ਤੇ ਰਹਿੰਦਾ ਹੈ।
ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ, ਬਦਲਾਅ ਵਾਪਸ ਕਰਨਯੋਗ ਬਣਾਉਣ ਲਈ ਕਾਫ਼ੀ ਟੈਸਟ ਜ਼ੋੜੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਕੋਈ ਤਕਨੀਕੀ ਸੰਦ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਸਰਵਿਸਾਂ ਤੁਹਾਡੀ ਨਹਿਰ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਰੂਟ ਅਤੇ UI ਵਿਕਸਤ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਨਿਯਮ ਅਸਥਿਰ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਰਹਿੰਦੇ ਹਨ।
ਜਦ ਰੂਟਸ ਸਥਿਰ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਸਰਵਿਸਾਂ ਮੌਜੂਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਡੇਟਾਬੇਸ ਨੂੰ “ਸਭ ਜਗ੍ਹਾ” ਨਾ ਚਲਾਉਣ ਦਿਓ। ਰਾ ਕੁਐਰੀਆਂ ਨੂੰ ਇੱਕ ਛੋਟੇ, ਬੋਰਿੰਗ ਡੇਟਾ ਐਕਸੈਸ ਲੇਅਰ ਦੇ ਪਿੱਛੇ ਲੁਕਾਓ।
ਇੱਕ ਛੋਟਾ ਮੋਡੀਊਲ (repository/store/queries) ਬਣਾਓ ਜੋ ਕੁਝ ਸਪਸ਼ਟ ਨਾਮਾਂ ਵਾਲੀਆਂ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਇਕਸਪੋਜ਼ ਕਰੇ, ਜਿਵੇਂ GetUserByEmail, ListInvoicesForAccount, ਜਾਂ SaveOrder। ਇਥੇ ਸੁੰਦਰਤਾ ਦੀ ਪਾਲਣਾ ਨਾ ਕਰੋ। ਹਰ SQL ਸਟਰਿੰਗ ਜਾਂ ORM ਕਾਲ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਘਰ ਬਣਾਉ।
ਇਸ ਪੜਾਅ ਨੂੰ ਸਖਤੀ ਨਾਲ ਢਾਂਚੇ ਬਾਰੇ ਰੱਖੋ। ਸਕੀਮਾ ਬਦਲਾਅ, ਇੰਡੈਕਸ ਟਵੀਕਸ, ਜਾਂ “ਇੱਥੇ ਹੋ ਕੇ” migrations ਤੋਂ ਬਚੋ। ਉਹਨਾਂ ਲਈ ਆਪਣੀ ਯੋਜਨਾ ਅਤੇ rollback ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਆਮ ਪ੍ਰੋਟੋਟਾਈਪ ਸੁਗੰਧ ਹੈ ਫੈਲੀ ਹੋਈ transactions: ਇੱਕ ਫੰਕਸ਼ਨ transaction ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਚੁਪਚਾਪ ਆਪਣੀ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ error handling ਫਾਇਲਾਂ ਅਨੁਸਾਰ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
ਇਸ ਦੀ ਬਜਾਏ, ਇੱਕ ਐਨਟਰੀ ਪੌਇੰਟ ਬਣਾਓ ਜੋ callback ਨੂੰ transaction ਦੇ ਅੰਦਰ ਚਲਾਏ, ਅਤੇ repositories ਨੂੰ transaction context ਮਿਲੇ।
ਮੂਵਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ:
ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ “Create Project” ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਇੰਸਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਡੀਫਾਲਟ settings ਇੰਸਰਟ ਕਰਦਾ ਹੈ, ਦੋਹਾਂ ਕਾਲਾਂ ਨੂੰ ਇੱਕ transaction helper ਵਿੱਚ ਰੱਖੋ। ਜੇ ਕੁਝ ਅੱਧ-ਰਸਤੇ ਵਿੱਚ FAIL ਕਰੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਉਹ ਪ੍ਰੋਜੈਕਟ ਨਾ ਹੋਵੇ ਜਿਸਦੇ settings ਨਹੀਂ ਹਨ।
ਜਦ ਸਰਵਿਸਾਂ ਇੱਕ concrete DB client ਦੀ ਬਜਾਏ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੇ ਵਿਹਾਰ ਨੂੰ ਅਸਲੀ ਡੇਟਾਬੇਸ ਬਿਨਾਂ ਟੈਸਟ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਡਰ ਘਟਾਉਂਦਾ ਹੈ, ਜਿਸੇ ਇਹ ਪੜਾਅ ਦਾ ਮਕਸਦ ਹੈ।
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
ਪਹਿਲਾਂ ਕੋਡ ਨੂੰ ਬਦਲੇ ਬਗੈਰ ਮੂਵ ਕਰੋ। ਫੰਕਸ਼ਨ ਨਾਂ ਅਤੇ ਵਾਪਸੀ ਰੂਪ ਇੱਕੋ ਜਿਹੇ ਰੱਖੋ, ਤਾਂ ਜੋ 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 ਦੇ ਜ਼ਿੰਮੇਦਾਰ ਬਣਾਉਂਦਾ ਹੈ।
ਖਤਰੇ ਵਧਾਉਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਤੋਂ ਬਚੋ:
null ਜਾਂ ਇੱਕ ਸਮਾਨ ਸੁਨੇਹੇ)ਇੱਕ ਛੋਟਾ ਉਦਾਹਰਨ: ਜੇ ਇੱਕ ਸਕ੍ਰੀਨ { ok: true, data } ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਪਰ ਨਵੀਂ ਸਰਵਿਸ { data } ਵਾਪਸ ਕਰਦੀ ਹੈ ਅਤੇ errors 'ਤੇ throw ਕਰਦੀ ਹੈ, ਤਾਂ ਅਧਾ ਐਪ ਦੋਸਤਾਨਾ ਸੁਨੇਹੇ ਦਿਖਾਉਣਾ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ। ਪਹਿਲਾਂ ਬਾਊਂਡਰੀ 'ਤੇ ਪੁਰਾਣਾ ਆਕਾਰ ਰੱਖੋ, ਫਿਰ callers ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਮਾਈਗ੍ਰੇਟ ਕਰੋ।
ਅਗਲੇ ਕਦਮ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਬਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਮੁੱਖ ਅਨੁਭਵ ਨੂੰ ਨਹੀਂ ਤੋੜਿਆ। ਹਰ ਵਾਰੀ ਇੱਕੋ ਗੋਲਡਨ ਪਾਥ ਚਲਾਓ (sign in, create an item, view it, edit it, delete it)। ਸਥਿਰਤਾ ਤੁਹਾਨੂੰ ਛੋਟੇ ਰਿਗ੍ਰੈਸ਼ਨਜ਼ ਨੂੰ ਪਛਾਣਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ।
ਹਰ ਪੜਾਅ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਿਆਣਾ go/no-go ਗੇਟ ਵਰਤੋ:
ਜੇ ਇਕ ਵੀ ਫੇਲ ਹੋਵੇ, ਰੁਕੋ ਅਤੇ ਠੀਕ ਕਰੋ ਪਹਿਲਾਂ ਕਿ ਉਸ 'ਤੇ ਅਧਾਰਿਤ ਹੋਵੋ। ਛੋਟੀ ਦਰਾਰਾਂ ਬਾਅਦ ਵੱਡੀਆਂ ਬਣ ਜਾਦੀਆਂ ਹਨ।
ਮਿਊਜ਼ਿਕ ਨਾਲ ਮਰਜ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਪੰਜ ਮਿੰਟ ਲਗਾ ਕੇ ਜਾਂਚ ਕਰੋ ਕਿ ਤੁਸੀਂ ਵਾਪਸ ਆ ਸਕਦੇ ਹੋ:
ਜਿੱਤ ਪਹਿਲੀ ਸਾਫ਼-ਕਰਨ ਨਹੀਂ ਹੈ। ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਜਿਵੇਂ ਤੁਸੀਂ ਫੀਚਰ ਜੋੜਦੇ ਹੋ, ਢਾਂਚਾ ਕਾਇਮ ਰੱਖਣਾ। ਤੁਸੀਂ “ਪਰਫੈਕਟ ਆਰਕੀਟੈਕਚਰ” ਨਹੀਂ ਤਲਾਸ਼ ਰਹੇ—ਤੁਸੀਂ ਭਵਿੱਖ ਦੇ ਬਦਲਾਅਾਂ ਨੂੰ ਭਵਿੱਖਬਾਣੀਯੋਗ, ਛੋਟੇ, ਅਤੇ ਆਸਾਨ ਵਾਪਸ ਕਰਨਯੋਗ ਬਣਾਉਂਦੇ ਹੋ।
ਅਗਲਾ ਮੋਡੀਊਲ ਪ੍ਰਭਾਵ ਅਤੇ ਜੋਖਮ ਅਧਾਰ 'ਤੇ ਚੁਣੋ, ਨਾ ਕਿ ਜੋ ਤੈਨੂੰ ਤਕਲੀਫ਼ ਦੇ ਰਿਹਾ ਹੈ। ਚੰਗੇ ਨਿਸ਼ਾਨੇ ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਪਭੋਗਤਾ ਅਕਸਰ ਛੂਹਦੇ ਹਨ ਅਤੇ ਜਿੱਥੇ ਵਿਵਹਾਰ ਪਹਿਲਾਂ ਹੀ ਸਮਝਿਆ ਗਿਆ ਹੈ। ਅਸਪਸ਼ਟ ਜਾਂ ਨਾਜ਼ੁਕ ਖੇਤਰਾਂ ਨੂੰ ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਚੰਗੇ ਟੈਸਟ ਜਾਂ ਬਿਹਤਰ ਉਤਪਾਦੀ ਜਵਾਬ ਨਾ ਹੋਣ।
ਸਧਾਰਨ ਕੈਡੰਸ ਰੱਖੋ: ਇੱਕ ਚੀਜ਼ ਨੂੰ ਮੂਵ ਕਰਨ ਵਾਲੇ ਛੋਟੇ PR, ਛੋਟੀ ਸਮੀਖਿਆਆਂ, ਆਮ ਰਿਲੀਜ਼, ਅਤੇ ਇੱਕ ਥੰਮ-ਰੇਖਾ ਨਿਯਮ (ਜੇ ਸਕੋਪ ਵੱਧੇ, ਤਾਂ ਇਸਨੂੰ ਵੰਡੋ ਅਤੇ ਛੋਟਾ ਹਿੱਸਾ ਸ਼ਿਪ ਕਰੋ)।
ਹਰ ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ rollback ਬਿੰਦੂ ਸੈੱਟ ਕਰੋ: ਇੱਕ git tag, ਇੱਕ release branch, ਜਾਂ ਇੱਕ deployable build ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਿੱਚ ਬਣਾਓ ਰਹੇ ਹੋ, ਤਾਂ Planning Mode ਤੁਹਾਨੂੰ ਪੜਾਅਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸਟੇਜ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਇਕੱਠੇ ਤਿੰਨ ਲੇਅਰਾਂ ਦਾ ਰੀਫੈਕਟਰ ਨਾ ਕਰ ਬੈਠੋ।
ਮੋਡੀਊਲਰ ਐਪ ਆਰਕੀਟੈਕਚਰ ਲਈ ਇੱਕ ਵਿਹਾਰਕ ਨਿਯਮ: ਹਰ ਨਵੇਂ ਫੀਚਰ ਨੂੰ ਇੱਕੋ ਹੱਦਾਂ ਦੇ ਅਨੁਸਾਰ ਬਣਾਓ। Routes ਪਤਲੇ ਰਹਿਣ, services ਬਿਜਨੈਸ ਨਿਯਮਾਂ ਦੇ ਮਾਲਕ ਹੋਣ, ਡੇਟਾਬੇਸ ਕੋਡ ਇੱਕ ਥਾਂ 'ਤੇ ਰਹੇ, ਅਤੇ UI ਕੰਪੋਨੈਂਟ ਪ੍ਰਦਰਸ਼ਨ 'ਤੇ ਧਿਆਨ ਦੇਣ। ਜਦ ਕੋਈ ਨਵਾਂ ਫੀਚਰ ਇਹ ਨਿਯਮ ਤੋੜਦਾ ਹੈ, ਤਾਂ ਛੋਟੇ ਹੋਣ 'ਤੇ ਹੀ ਰੀਫੈਕਟਰ ਕਰੋ।
ਮੂਲ: ਇਸਨੂੰ ਰਿਸਕ ਵਜੋਂ ਲਓ। ਛੋਟੇ ਜਵਾਬ-ਆਕਾਰ (response shape) ਦੇ ਬਦਲਾਅ ਵੀ ਕਈ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਟੁੱਟ ਸਕਦੇ ਹਨ।
ਇਸ ਦੀ ਬਜਾਏ ਕਰੋ:
ਲੋਕਾਂ ਦੀ ਦੈਨਿਕ ਵਰਤੋਂ ਵਾਲਾ ਇੱਕ ਫਲੋ ਚੁਣੋ ਜੋ ਮੁੱਖ ਲੇਅਰਾਂ (auth, routes, DB, UI) ਨੂੰ ਛੂੰਹਦਾ ਹੋਵੇ।
ਇੱਕ ਚੰਗਾ ਡਿਫੌਲਟ ਹੈ:
ਇਹਨਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਰੋਜ਼ਾਨਾ ਦੁਹਰਾਉਂ ਸਕੋ। ਇੱਕ ਆਮ ਫੇਲਿਯਰ ਕੇਸ ਵੀ ਜੋੜੋ (ਉਦਾਹਰਨ ਲਈ, ਜਰੂਰੀ ਫੀਲਡ ਦੀ ਘਾਟ) ਤਾਂ ਕਿ ਤੁਸੀਂ error-handling ਰਿਗ੍ਰੈਸ਼ਨਜ਼ ਨੂੰ ਜਲਦੀ ਪਛਾਣ ਸਕੋ।
ਉਹ rollback ਜਿਸਨੂੰ ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਚਲਾ ਸਕੋ।
ਵਹਿਕਤਿਕ ਵਿਕਲਪ:
ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਵਾਰੀ rollback ਭਾਲ ਕਰਕੇ ਵੇਰਵਾ ਕਰੋ (ਅਸਲ ਵਿੱਚ ਕਰੋ), ਤਾਂ ਜੋ ਇਹ ਸਿਧਾਂਤਕ ਯੋਜਨਾ ਨਾ ਰਹਿ ਜਾਵੇ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ ਕ੍ਰਮ ਹੈ:
ਇਹ ਕ੍ਰਮ ਬਲਾਸਟ ਰੇਡੀਅਸ ਘਟਾਉਂਦਾ ਹੈ: ਹਰ ਲੇਅਰ ਨੂੰ ਅਗਲੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਾਫ਼ ਬਾਊਂਡਰੀ ਬਣਾਉ।
“ਮੂਵ” ਅਤੇ “ਚੇਂਜ” ਦੋ ਵੱਖ-ਵੱਖ ਕੰਮ ਬਣਾਓ।
ਮਦਦ ਕਰਨ ਵਾਲੇ ਨਿਯਮ:
ਜੇ ਤੁਹਾਨੂੰ ਬਿਹੈਵੀਅਰ ਬਦਲਣਾ ਹੀ ਹੋਵੇ ਤਾਂ ਬਾਅਦ ਵਿੱਚ, ਸਾਫ਼ ਟੈਸਟਾਂ ਅਤੇ ਮਹਿਤੱਵਪੂਰਨ ਰਿਲੀਜ਼ ਨਾਲ ਕਰੋ।
ਹਾਂ—ਇਸਨੂੰ ਹੋਰ Legacy ਕੋਡਬੇਸ ਵਾਂਗ ਵਰਤੋ।
ਇੱਕ ਵਰਤੋਂਯੋਗ ਰਸਤਾ:
CreateOrderLegacy)Generated ਕੋਡ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਮੁੜ-ਸੰਗਠਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇ ਬਾਹਰੀ ਵਿਹਾਰ ਸਮਰੂਪ ਰਹੇ।
ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਾਂ ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰੋ ਅਤੇ ਸਧਾਰਨ ਬਣਾਓ।
ਮੂਲ ਨਮੂਨਾ:
ਇਸ ਨਾਲ ਅਧੂਰੇ ਲਿਖਤਾਂ (partial writes) ਰੋਕੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਫੇਲਿਊਰ ਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਬਦਲਾਅ ਨੂੰ ਵਾਪਸ ਕਰਨਯੋਗ ਬਣਾਉਣ ਲਈ ਥੋੜ੍ਹਾ ਜਿਹਾ ਟੈਸਟਿੰਗ ਹੀ ਕਾਫ਼ੀ ਹੈ।
ਨਿਊਨਤਮ ਲਾਭਦਾਇਕ ਸੈਟ:
ਉਦੇਸ਼ ਹੈ ਡਰ ਘਟਾਉਣਾ, ਨਾ ਕਿ ਇੱਕ ਬਿਲਕੁਲ ਪੂਰਨ ਟੈਸਟ ਸੂਟ ਤੁਰੰਤ ਬਣਾਉਣਾ।
ਪਹਿਲਾਂ layout ਅਤੇ styling ਨੂੰ ਵਹੀ ਰੱਖੋ; ਮਕਸਦ predictability ਹੈ।
ਸੁਰੱਖਿਅਤ UI ਸਾਫ਼-ਕਦਮ:
ਹਰ ਨਿਕਾਸ ਤੋਂ ਬਾਅਦ ਇੱਕ ਛੋਟੀ visual ਜਾਂਚ ਕਰੋ ਅਤੇ ਇੱਕ error ਕੇਸ ਟ੍ਰਿਗਰ ਕਰੋ।
ਪਲੇਟਫਾਰਮ ਦੀਆਂ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਤਾਂ ਜੋ ਬਦਲਾਅ ਛੋਟੇ ਅਤੇ ਰਿਕਵਰ ਕਰਨਯੋਗ ਰਹਿਣ।
ਵਿਆਵਹਾਰਿਕ ਡਿਫੌਲਟ:
ਇਹ ਆਦਤਾਂ ਮੁਖ ਮਕਸਦ ਨੂੰ ਸਹਾਇਕ ਬਨਾਉਂਦੀਆਂ ਹਨ: ਛੋਟੇ, ਵਾਪਸ-ਯੋਗ ਰੀਫੈਕਟਰਜ ਜੋ ਟਿਕਾਊ ਭਰੋਸਾ ਦਿੰਦੀਆਂ ਹਨ।