08 ਦਸੰ 2025·8 ਮਿੰਟ
Claude Code ਲਈ ਕੋਡਬੇਸ ਨਬੋਰਡਿੰਗ: ਐਪ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਣ ਵਾਲੇ ਪ੍ਰਾਂਪਟ
Claude Code ਲਈ ਕੋਡਬੇਸ ਨਬੋਰਡਿੰਗ: Q&A ਪ੍ਰਾਂਪਟਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਾਡਿਊਲ, ਮੁੱਖ ਫਲੋਜ਼ ਅਤੇ ਜੋਖਮ ਮੈਪ ਕਰੋ, ਫਿਰ ਨੋਟਸ ਨੂੰ ਇੱਕ ਛੋਟੀ ਨਬੋਰਡਿੰਗ ਡੌਕ ਵਿੱਚ ਬਦਲੋ।
Claude Code ਲਈ ਕੋਡਬੇਸ ਨਬੋਰਡਿੰਗ: Q&A ਪ੍ਰਾਂਪਟਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮਾਡਿਊਲ, ਮੁੱਖ ਫਲੋਜ਼ ਅਤੇ ਜੋਖਮ ਮੈਪ ਕਰੋ, ਫਿਰ ਨੋਟਸ ਨੂੰ ਇੱਕ ਛੋਟੀ ਨਬੋਰਡਿੰਗ ਡੌਕ ਵਿੱਚ ਬਦਲੋ।
ਫਾਈਲਾਂ ਨੂੰ ਬੇਤਰਤੀਬੀ ਨਾਲ ਪੜ੍ਹਨਾ ਆਮ ਤੌਰ 'ਤੇ ਧੀਮਾ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਕੋਡਬੇਸ ਇੱਕ ਕਹਾਣੀ ਵਰਗੇ ਢੰਗ ਨਾਲ ਸਜਾਏ ਨਹੀਂ ਹੁੰਦੇ। ਤੁਸੀਂ ਫੋਲਡਰ ਖੋਲਦੇ ਹੋ, ਦੱਸ ਨਾਂਵਾਂ ਦਿੱਖਦੇ ਹਨ ਜੋ ਮਹੱਤਵਪੂਰਨ ਲੱਗਦੇ ਹਨ, ਇਕ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹੋ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਤੁਹਾਨੂੰ ਹੇਲਪਰ, ਕਨਫਿਗ ਅਤੇ ਕੋਨੇ-ਕੇਸ ਮਿਲਦੇ ਹਨ। ਇੱਕ ਘੰਟੇ ਬਾਅਦ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੀਆਂ ਵਿਚਾਰ ਹਨ ਪਰ ਫਿਰ ਵੀ ਤੁਸੀਂ ਸਮਝਾ ਨਹੀਂ ਪਾਉਂਦੇ ਕਿ ਐਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।
Claude Code ਨਾਲ ਨਬੋਰਡਿੰਗ ਦਾ ਇੱਕ ਵਧੀਆ ਮਕਸਦ ਇੱਕ ਸਧਾਰਣ ਮੈਨਟਲ ਮੈਪ ਤਿਆਰ ਕਰਨਾ ਹੈ। ਉਹ ਮੈਪ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਵੇ:
1-2 ਦਿਨਾਂ ਵਿੱਚ "ਚੰਗੀ ਨੀਂਹ" ਨਬੋਰਡਿੰਗ ਇਹ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਹਰ ਕਲਾਸ ਸਮਝਾ ਸਕੋ। ਇਹ ਹੋਰ ਨਜ਼ਦੀਕੀ ਹੁੰਦਾ ਹੈ:
ਕੁਝ ਗੱਲਾਂ ਬਾਅਦ ਲਈ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਡੂੰਘੀ ਰੀਫੈਕਟਰਿੰਗ, ਹਰ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਦੀ ਪੂਰੀ ਸਮਝ ਅਤੇ ਪੁਰਾਣਾ ਕੋਡ ਪੜ੍ਹਨਾ ਜੋ ਕਿਸੇ ਨੇ ਛੁਹਿਆ ਨਹੀਂ, ਆਮ ਤੌਰ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕਾਰਗਰ ਨਹੀਂ ਹੁੰਦਾ।
ਨਬੋਰਡਿੰਗ ਨੂੰ ਇੱਕ ਨਕਸ਼ਾ ਬਣਾਉਣ ਵਾਂਗ ਸਮਝੋ, ਗਲੀਆਂ ਯਾਦ ਕਰਨ ਵਾਲਾ ਕੰਮ ਨਹੀਂ। ਤੁਹਾਡੇ ਪ੍ਰਾਂਪਟਸ ਨੂੰ ਹਰ ਵਾਰੀ ਤੁਹਾਨੂੰ ਵapis ਖਿੱਚਣਾ ਚਾਹੀਦਾ ਹੈ: "ਮੈਂ ਸਿਸਟਮ ਵਿਚ ਕਿੱਥੇ ਹਾਂ, ਅਗਲਾ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇੱਥੇ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?" ਇੱਕ ਵਾਰੀ ਇਹ ਹੋ ਜਾਵੇ, ਤਫਸੀਲਾਂ ਮੰਗਣ 'ਤੇ ਸਿੱਖਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਸਵਾਲ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਇਕੱਠੀਆਂ ਕਰੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੇ ਦਿਨ ਤੈਨੂੰ ਲੋੜ ਹੁੰਦੀਆਂ ਹਨ। Claude Code ਸਭ ਤੋਂ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਅਸਲ ਫਾਈਲਾਂ, ਅਸਲ ਕਨਫਿਗ ਅਤੇ ਅਸਲ ਵਿਹਾਰ ਨੂੰ ਵੇਖ ਸਕੇ ਜੋ ਤੁਸੀਂ ਦੁਹਰਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤ ਕਰੋ ਐਕਸੈਸ ਅਤੇ ਇੱਕ ਚੱਲਣ ਵਾਲੇ ਰਨ ਨਾਲ। ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਰੇਪੋ ਕਲੋਨ ਕਰ ਸਕਦੇ ਹੋ, ਡਿਪੈਡੈਂਸੀਜ਼ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਐਪ ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਚਲਾ ਸਕਦੇ ਹੋ (ਜਾ कम ਤੋਂ कम ਇੱਕ ਛੋਟੀ ਭਾਗ)। ਜੇ ਲੋਕਲ ਸੈੱਟਅਪ ਮੁਸ਼ਕਲ ਹੈ, ਤਾਂ ਸਟੇਜਿੰਗ ਇਨਵਾਇਰਨਮੈਂਟ ਅਤੇ ਲੋਕਾਂ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਲੌਗਸ ਤੱਕ ਪਹੁੰਚ ਲਵੋ, ਤਾਂ ਕਿ ਤੁਸੀਂ ਵੇਰਵਾ ਕਰ ਸਕੋ ਕਿ ਕੋਡ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ।
ਅਗਲਾ, "ਸਰੋਤ-ਸੱਚਾਈ" ਦਸਤਾਵੇਜ਼ ਲੱਭੋ। ਤੁਸੀਂ ਉਹ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਟੀਮ ਅਸਲ ਵਿੱਚ ਚੇਂਜ ਹੋਣ 'ਤੇ ਅਪਡੇਟ ਕਰਦੀ ਹੈ: README, ਇੱਕ ਛੋਟੀ ਆਰਕੀਟੈਕਚਰ ਨੋਟ, ADR ਫੋਲਡਰ, ਰਨਬੁੱਕ, ਜਾਂ ਡਿਪਲੋਇਮੈਂਟ ਨੋਟ। ਭਾਵੇਂ ਉਹ ਗੰਦੇ ਹੋਣ, ਉਹ ਮਾਡਿਊਲਾਂ ਅਤੇ ਫਲੋਜ਼ ਨੂੰ ਨਾਂ ਦਿੰਦੇ ਹਨ, ਜੋ Q&A ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਹੀ ਬਣਾਉਂਦਾ ਹੈ।
ਰੁਟੀਨ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਕਰੋ। ਕਈ ਰੇਪੋ ਵਿੱਚ ਕਈ ਐਪ, ਸਰਵਿਸेज਼ ਅਤੇ ਸ਼ੇਅਰਡ ਪੈਕੇਜ ਹੁੰਦੇ ਹਨ। ਸੀਮਾਵਾਂ ਚੁਣੋ ਜਿਵੇਂ "ਸਿਰਫ਼ API ਅਤੇ billing worker" ਜਾਂ "ਸਿਰਫ਼ web app ਅਤੇ ਇਸ ਦਾ auth flow." ਸਾਫ਼ ਸਕੋਪ ਅਨਵੰਛਿਤ ਮੰਝੇ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਜੋ ਅਸੂਮptions ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ਅਸਿਸਟੈਂਟ ਅਨੁਮਾਨ ਲਗਾਏ, ਉਹ ਲਿਖ ਲਵੋ। ਇਹ ਛੋਟਾ ਸੁਣਾਉਂਦਾ ਹੈ ਪਰ ਬਾਅਦ ਵਿੱਚ ਗਲਤ ਮੈਨਟਲ ਮਾਡਲਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਘੰਟਿਆਂ ਨੁਕਸਾਨ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਥੇ ਇੱਕ ਸਧਾਰਣ ਤਿਆਰੀ ਚੈੱਕਲਿਸਟ ਹੈ:
ਜੇ ਕੁਝ ਗੁੰਮ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਸਵਾਲ ਵਜੋਂ ਟੀਮ ਮੀਟ ਨਾਲ ਰਿਕਾਰਡ ਕਰੋ। ਗੁੰਮ ਸੰਦਭਾਂ ਨਾਲ "ਘੁਮਕੇ ਕੰਮ" ਨਾ ਕਰੋ।
ਮੈਨਟਲ ਮੈਪ ਇੱਕ ਛੋਟਾ ਨੋਟ ਸੈਟ ਹੈ ਜੋ ਇਹ ਬਤਾਉਂਦਾ ਹੈ: ਐਪ ਦੇ ਮੁੱਖ ਹਿੱਸੇ ਕਿਹੜੇ ਹਨ, ਓਹ ਇਕ ਦੂਜੇ ਨਾਲ ਕਿਵੇਂ ਗੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਕਿੱਥੇ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ। ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ, ਨਬੋਰਡਿੰਗ ਫਾਈਲਾਂ ਬ੍ਰਾਊਜ਼ ਕਰਨ ਬਜਾਏ ਇੱਕ ਤਸਵੀਰ ਬਣਾਉਣ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮੁੜ ਇਸਤੇਮਾਲ ਕਰ ਸਕੋ।
ਆਉਟਪੁੱਟ ਪਹਿਲਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਤੁਸੀਂ ਇੱਕ ਮਾਡਿਊਲ ਲਿਸਟ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਪ੍ਰਯੋਗਿਕ ਹੋਵੇ, ਨਾ ਕਿ ਪੂਰੀ। ਹਰ ਮਾਡਿਊਲ ਲਈ, ਲਿਖੋ ਕਿ ਉਹ ਕੀ ਕਰਦਾ ਹੈ, ਕੌਣ ਉਸਦਾ ਮਾਲਕ ਹੈ (ਟੀਮ ਜਾਂ ਵਿਅਕਤੀ) ਅਤੇ ਉਸਦੀਆਂ ਮੁੱਖ ਨਿਰਭਰਤਾਵਾਂ (ਹੋਰ ਮਾਡਿਊਲ, ਸਰਵਿਸ, ਡੇਟਾਬੇਸ, ਬਾਹਰੀ APIs)। ਮੁੱਖ ਇੰਟ੍ਰੀ ਪੌਇੰਟ ਵੀ ਨੋਟ ਕਰੋ: UI ਰੂਟ, API ਐਂਡਪੋਇੰਟ, ਬੈਕਗਰਾਉਂਡ ਜੌਬ ਅਤੇ ਸਕੈਜੂਲ ਟਾਸਕ।
ਫਿਰ, ਕੁਝ ਉਪਭੋਗਤਾ ਯਾਤਰਾਵਾਂ ਚੁਣੋ। 3-5 ਕਾਫੀ ਹਨ। ਉਹ ਫਲੋਜ਼ ਚੁਣੋ ਜੋ ਪੈਸਾ, ਪਰਮਿਸ਼ਨ, ਜਾਂ ਡੇਟਾ ਬਦਲਦੇ ਹਨ। ਉਦਾਹਰਨ: ਸਾਈਨਅਪ ਅਤੇ ਈਮੇਲ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਪੇਡ ਪਲੈਨ ਜਾਂ ਖਰੀਦ ਬਣਾਉਣਾ, ਇੱਕ ਐਡਮਿਨ ਕਾਰਵਾਈ ਜੋ ਯੂਜ਼ਰ ਐਕਸੈੱਸ ਬਦਲਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਦੈਨਿਕ-ਉਪਯੋਗ ਫਲੋ ਜੋ ਜ਼ਿਆਦਾਤਰ ਯੂਜ਼ਰਾਂ ਲਈ ਆਵਸ਼ਯਕ ਹੈ।
ਰਿਸਕ ਲੇਬਲBefore you start collecting notes, decide how you'll label risk. Keep categories simple so you can scan later. A useful set is security, data integrity, uptime, and cost. When you mark something as risky, add one sentence explaining why, plus what would prove it's safe (a test, a log, a permission check).
Use a consistent format so you can turn notes into an onboarding doc without rewriting everything:
Example: if Checkout calls Billing which writes to payments and invoices, tag it as data integrity and cost. Then note where retries happen and what prevents double-charging.
ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਨਵੇਂ ਰੇਪੋ 'ਚ ਸ਼ਾਮਿਲ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ ਓਰਿਏਂਟੇਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਪੂਰੀ ਸਮਝ। ਇਹ ਪ੍ਰਾਂਪਟ ਤੁਹਾਨੂੰ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਕਦਮਾਂ ਵਿੱਚ ਇੱਕ ਮੈਨਟਲ ਮੈਪ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤ ਕਰਕੇ ਅਸਿਸਟੈਂਟ ਨੂੰ ਰੇਪੋ ਟਰੀ (ਜਾਂ ਚੁਣੀਂਦਾ ਹਿੱਸਾ) ਦਿਓ ਅਤੇ ਇੱਕ ਟੂਰ ਮੰਗੋ। ਹਰ ਰਾਊਂਡ ਨੂੰ ਧਿਆਨ ਕੇਂਦਰਿਤ ਰੱਖੋ, ਫਿਰ ਇੱਕ ਸਵਾਲ ਨਾਲ ਖਤਮ ਕਰੋ ਜੋ ਦੱਸੇ ਕਿ ਅਗਲਾ ਕੀ ਪੜ੍ਹਨਾ ਹੈ।
1) Repo tour
"Here is the top-level folder list: <paste>. Explain what each folder likely contains and which ones matter for core product behavior."
2) Entry points
"Find the app entry points and boot process. What files start the app, set up routing, configure DI/env, and start background jobs? Name the exact files and what they do."
3) Module index
"Create a module index: module name, purpose, key files, and important external dependencies. Keep it to the modules that affect user-facing behavior."
4) Data model hints
"Based on migrations/models, list the key tables/entities, critical fields, and relationships. Call out fields that look security-sensitive or used for billing/permissions."
5) Flow trace
"Trace this flow end-to-end: <flow>. Where does the request/event start, where does it end, and what does it call in between? List the main functions/files in order."
6) Next inspection
"What should I inspect next and why? Give me 3 options: fastest clarity, riskiest area, and best long-term payoff."
ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ: ਜੇ ਤੁਸੀਂ "user signs up and creates their first project," ਨੂੰ ਮੈਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ API ਰੂਟ ਹੈਂਡਲਰ, ਵੈਲਿਡੇਸ਼ਨ, DB ਰਾਇਟ, ਅਤੇ ਕੋਈ async ਜੌਬ ਜੋ ਈਮੇਲ ਭੇਜਦਾ ਹੈ ਜਾਂ ਰਿਸੋਰਸ ਪ੍ਰੋਵਾਈਡ ਕਰਦਾ ਹੈ, ਦੀ ਮੰਗ ਕਰੋ। ਫਿਰ "user deletes project" ਲਈ ਫਲੋ ਟ੍ਰੇਸ ਨੂੰ ਮੁੜ ਚਲਾਓ ਤਾਂ ਕਿ ਕਲਿੰਅਪ ਗੈਪਜ਼ ਪਤਾ ਲੱਗਣ।
ਜਵਾਬਾਂ ਨੂੰ ਕਾਰਗਰ ਬਣਾਉਣ ਲਈ, ਵਿਸ਼ੇਸ਼ ਆਰਟੀਫੈਕਟ ਮੰਗੋ, ਸਿਰਫ਼ ਸਾਰਾਂਸ਼ ਨਹੀਂ:
ਸਭ ਤੋਂ ਵੱਡੀ ਨਬੋਰਡਿੰਗ ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਚਰਚਿਤ Q&A ਨੂੰ ਇਨ੍ਹਾਂ ਨੋਟਾਂ ਵਿੱਚ ਬਦਲਣਾ ਜੋ ਦੂਸਰਾ ਡਿਵੈਲਪਰ ਮੁੜ ਵਰਤ ਸਕੇ। ਜੇ ਨੋਟ ਸਿਰਫ ਤੁਹਾਡੇ ਲਈ ਸਮਝਦੇ ਯੋਗ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਉਹੀ ਖੋਜ ਮੁੜ ਕਰੋਗੇ।
ਇੱਕ ਸਧਾਰਣ ਸੰਰਚਨਾ ਲੰਬੇ ਪੰਨਿਆਂ ਤੋਂ ਬਿਹਤਰ ਹੈ। ਹਰ ਖੋਜ ਸੈਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਜਵਾਬਾਂ ਨੂੰ ਪੰਜ ਛੋਟੇ ਆਰਟੀਫੈਕਟਾਂ (ਇੱਕ ਫਾਈਲ ਜਾਂ ਡੌਕ ਠੀਕ ਹੈ) ਵਿੱਚ ਸੇਵ ਕਰੋ: ਇੱਕ ਮਾਡਿਊਲ ਟੇਬਲ, ਇੱਕ ਗਲੋਸਰੀ, ਕੁੰਜੀ ਫਲੋਜ਼, ਅਣਜਾਣ ਗੱਲਾਂ, ਅਤੇ ਇੱਕ ਰਿਸਕ ਰਜਿਸਟਰ।
ਇੱਥੇ ਇੱਕ ਕੰਪੈਕਟ ਟੈਮਪਲੇਟ ਜਿਹਨੂੰ ਤੁਸੀਂ ਨੋਟਸ ਵਿੱਚ ਪੇਸਟ ਕਰਕੇ ਭਰਦੇ ਜਾ ਸਕਦੇ ਹੋ:
Module table
- Module:
Owns:
Touches:
Entry points:
Glossary
- Term:
Meaning:
Code name(s):
Key flow (name)
1.
2.
3.
Unknowns
- Question:
Best person to ask:
Where to look next:
Risk register
- Risk:
Location:
Why it matters:
How to verify:
ਮੁੱਖ ਫਲੋਜ਼ ਨੂੰ ਜਾਣਬੂਝ ਕੇ ਛੋਟਾ ਰੱਖੋ। ਉਦਾਹਰਨ: 1) ਯੂਜ਼ਰ ਸਾਈਨ-ਇਨ, 2) ਬੈਕਐਂਡ ਸੈਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ, 3) ਕਲਾਇੰਟ ਡੈਸ਼ਬੋਰਡ ਲੋਡ ਕਰਦਾ ਹੈ, 4) API ਡੇਟਾ ਫੈਚ ਕਰਦਾ ਹੈ, 5) UI ਰੇਂਡਰ ਕਰਦਾ ਹੈ ਅਤੇ ਐਰਰਾਂ ਸੰਭਾਲਦਾ ਹੈ। ਜੇ ਇੱਕ ਫਲੋ ਨੂੰ ਪੰਜ ਕਦਮਾਂ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਉਸਨੂੰ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ (ਲੌਗਇਨ ਬਣਾਮ ਡੈਸ਼ਬੋਰਡ ਲੋਡ)।
Claude Code ਵਰਤਦੇ ਵੇਲੇ, ਹਰ ਜਵਾਬ ਦੇ ਨਾਲ ਇੱਕ ਲਾਈਨ ਜੋੜੋ: "How would I test this?" ਇਹ ਇਕ ਸਚੈਕਲਿਸਟ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਅਣਜਾਣੀਆਂ ਅਤੇ ਰਿਸਕ ਇਕੱਠੇ ਹੋਣ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ vibe-coding ਪਲੇਟਫਾਰਮ 'ਤੇ ਵਿਕਸਿਤ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਨੋਟ-ਲੇਖਣ ਤੁਹਾਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਨਰੇਟ ਕੀਤੇ ਬਦਲਾਅ ਦੇ ਸਾਈਡ-ਇਫੈਕਟ ਕਿੱਥੇ ਹੋ ਸਕਦੇ ਹਨ। ਜ਼ਿਆਦਾ ਟੱਚਪੌਇੰਟ ਵਾਲੇ ਮਾਡਿਊਲ ਬਦਲਾਅ ਖਿੱਚਣ ਵਾਲੇ ਹੁੰਦੇ ਹਨ।
ਕੋਡਬੇਸ ਵਿੱਚ ਖਤਰਾ ਆਮ ਤੌਰ 'ਤੇ ਯਾਦੀਂ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਓਹਨਾਂ ਸਥਾਨਾਂ 'ਤੇ ਇਕੱਠਾ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਐਪ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੌਣ ਹੋ, ਡੇਟਾ ਬਦਲਦਾ ਹੈ, ਹੋਰ ਸਿਸਟਮਾਂ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ, ਜਾਂ ਪਿਛੋਕੜ ਵਿੱਚ ਕੰਮ ਚਲਦਾ ਹੈ। ਤੁਸੀਂ ਜ਼ਿਆਦਾਤਰ ਨੂੰ ਨਿਸ਼ਾਨੀ ਵਾਲੇ ਸਵਾਲਾਂ ਅਤੇ ਕੁਜ ਕੇਂਦਰਿਤ ਖੋਜਾਂ ਨਾਲ ਲੱਭ ਸਕਦੇ ਹੋ।
ਔਖਾ ਦਾ ਆਰੰਭ ਆਈਡੈਂਟਿਟੀ ਨਾਲ ਕਰੋ। ਪੁੱਛੋ ਕਿ authentication ਕਿੱਥੇ ਹੁੰਦੀ ਹੈ (ਲੌਗਿਨ, ਸੈਸ਼ਨ, ਟੋਕਨ) ਅਤੇ authorization ਦੇ ਫੈਸਲੇ ਕਿੱਥੇ ਲੱਗਦੇ ਹਨ (ਰੋਲ ਚੈਕ, ਫੀਚਰ ਫਲੈਗ, ਓਨਰਸ਼ਿਪ ਨਿਯਮ)। ਇੱਕ ਆਮ ਜਾਲ ਇਹ ਹੈ ਕਿ ਚੈਕ UI, API ਹੈਂਡਲਰ, ਅਤੇ DB ਕ್ವੇਰੀਜ਼ 'ਚ ਫੈਲੇ ਹੋਏ ਨੇ ਅਤੇ ਕੋਈ ਸਿੰਗਲ ਸੋਰਸ ਆਫ਼ ਟਰੂਥ ਨਹੀਂ।
ਅਗਲਾ, ਲਿਖਣ ਵਾਲੇ ਰਸਤਿਆਂ ਨੂੰ ਮੈਪ ਕਰੋ। ਉਹ ਐਂਡਪੋਇੰਟ ਜਾਂ ਫੰਕਸ਼ਨ ਲੱਭੋ ਜੋ ਰਿਕਾਰਡ ਬਣਾਉਂਦੇ, ਅੱਪਡੇਟ ਜਾਂ ਡਿਲੀਟ ਕਰਦੇ ਹਨ, ਨਾਲ ਹੀ ਮਾਈਗ੍ਰੇਸ਼ਨਾਂ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਡੇਟਾ ਨੂੰ ਬਦਲਦੀਆਂ ਹਨ। ਬੈਕਗਰਾਊਂਡ ਜੌਬਜ਼ ਵੀ ਸ਼ਾਮਿਲ ਕਰੋ। ਬਹੁਤ ਸਾਰੀਆਂ ਆਸਾਨੀ ਬੱਗ ਅਸਿੰਕ ਵਰਕਰਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਇਕ ਰਿਕਵੈਸਟ ਦੇ ਬਾਅਦ ਅਚਾਨਕ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਲਿਖਦੇ ਹਨ।
ਖਤਰਾ ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਲਿਆਉਣ ਵਾਲੇ ਪ੍ਰਾਂਪਟ:
ਫਿਰ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ סਿਕ੍ਰੇਟਸ ਹੈਂਡਲਿੰਗ ਦੀ ਜਾਂਚ ਕਰੋ। env vars, ਰਨਟਾਈਮ ਕਨਫਿਗ ਫਾਈਲਾਂ, ਅਤੇ ਡਿਫੌਲਟ ਫਾਲਬੈਕ ਲਈ ਲੱਭੋ। ਡਿਫੌਲਟ ਲਾਭਕਾਰੀ ਹੁੰਦੇ ਹਨ, ਪਰ ਖਤਰਨਾਕ ਵੀ ਜਦੋਂ ਉਹ ਮਿਸਕਾਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਪ੍ਰੋਡ ਵਿੱਚ dev ਕੀ ਦੀ ਵਰਤੋਂ ਕਿਉਂਕਿ ਕੋਈ ਮੁੱਲ ਗੈਰ ਮੌਜੂਦ ਸੀ)।
ਇੱਕ ਤੇਜ਼ ਉਦਾਹਰਨ: ਇੱਕ Go ਬੈਕਐਂਡ ਅਤੇ PostgreSQL ਨਾਲ, ਤੁਸੀਂ ਇੱਕ "send email" ਜੌਬ ਲੱਭ ਸਕਦੇ ਹੋ ਜੋ ਨਾਕਾਮੀ 'ਤੇ ਰੀਟ੍ਰਾਈ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ ਰੀਟ੍ਰਾਈ ਬਿਨਾਂ idempotency key ਦੇ ਕਰਦਾ ਹੈ, ਤਾਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਡੁਪਲਿਕੇਟ ਈਮੇਲ ਮਿਲ ਸਕਦੇ ਹਨ। ਜੇ ਫੇਲਿਅਰ ਸਿਰਫ਼ ਵਾਰਨਿੰਗ ਲੌਗ ਕਰਦੇ ਹਨ ਅਤੇ ਕੋਈ ਅਲਰਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਚੁੱਪ ਚਾਪ ਤੋੜਦਾ ਹੈ। ਇਹ ਇੱਕ ਉੱਚ-ਖਤਰਾ ਖੇਤਰ ਹੈ ਜਿਸ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਪਹਿਲਾਂ ਟੈਸਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਅਸਲ ਫਲੋ ਵੀ ਵਰਤੋ ਤਾਂ ਕਿ ਤੁਹਾਡੀ ਪਹਿਲੀ ਐਂਡ-ਟੂ-ਐਂਡ ਧਾਰ ਬਣ ਜਾਵੇ। ਲੌਗਿਨ ਚੰਗਾ ਸਟਾਰਟਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਰੂਟਿੰਗ, ਵੈਲਿਡੇਸ਼ਨ, ਸੈਸ਼ਨ ਜਾਂ ਟੋਕਨ, ਅਤੇ ਡੇਟਾਬੇਸ ਰੀਡਾਂ ਨੂੰ ਛੂਹਦਾ ਹੈ।
ਦ੍ਰਿਸ਼: ਇੱਕ React ਵੈੱਬ ਐਪ ਇੱਕ Go API ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ API PostgreSQL ਪੜ੍ਹਦਾ/ਲਿਖਦਾ ਹੈ। ਤੁਹਾਡਾ ਮਕਸਦ ਹਰ ਫਾਈਲ ਨੂੰ ਸਮਝਣਾ ਨਹੀਂ, ਬਲਕਿ ਇਹ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੈ: "ਜਦ ਉਪਭੋਗਤਾ Login 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਅਗਲੇ ਕੀ ਕੋਡ ਚੱਲਦਾ ਹੈ, ਕੀ ਡੇਟਾ ਹਿਲਦਾ ਹੈ, ਅਤੇ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?" ਇਹ ਨਬੋਰਡਿੰਗ ਨੂੰ ਠੋਸ ਬਣਾਉਂਦਾ ਹੈ।
UI ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਇੱਕ-ਹੱਪ ਅੱਗੇ ਵਧੋ। ਖਾਸ ਫਾਈਲ ਨਾਂ, ਫੰਕਸ਼ਨ, ਅਤੇ ਰਿਕਵੈਸਟ/ਰਿਸਪੌਂਸ ਸ਼ੇਪ ਮੰਗੋ।
ਹਰ ਜਵਾਬ ਤੋਂ ਬਾਦ ਆਪਣੇ ਮੈਨਟਲ ਮੈਪ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਲਾਈਨ ਲਿਖੋ: "UI component -> API endpoint -> handler -> service -> DB query -> response." ਨਾਮ ਲਿਖੋ, ਸਿਰਫ਼ "ਕਿਸੇ ਫੰਕਸ਼ਨ" ਨਹੀਂ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਰਸਤਾ ਹੋ ਜਾਵੇ, ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਰਨ ਨਾਲ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਤੁਸੀਂ ਜਾਂਚ ਰਹੇ ਹੋ ਕਿ ਜੋ ਰਸਤਾ ਤੁਸੀਂ ਮੈਪ ਕੀਤਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਬਰਾਊਜ਼ਰ ਡੈਵ ਟੂਲਜ਼ ਵਿੱਚ ਨੈੱਟਵਰਕ ਰਿਕਵੈਸਟ ਵੇਖੋ (ਪਾਥ, ਸਟੇਟਸ ਕੋਡ, ਰਿਸਪੌਂਸ ਬਾਡੀ)। ਹੈਂਡਲਰ ਅਤੇ DB ਕਾਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੇਰਟਰੀ ਲੌਗਸ ਸ਼ਾਮਿਲ ਕਰੋ (ਜੇ ਆਈਡ ਹੈ ਤਾਂ)। PostgreSQL ਵਿੱਚ ਉਮੀਦ ਕੀਤੀ ਗਈ ਤਬਦੀਲੀਆਂ ਲਈ ਕੁਐਰੀ ਚਲਾਓ (ਉਦਾਹਰਨ ਲਈ login ਲਈ last_login_at, sessions, ਜਾਂ audit ਰਿਕਾਰਡ)। ਇੱਕ ਫੇਲਿਓਰ ਨੂੰ ਜਬਰਬੰਦ ਕਰੋ (ਗਲਤ ਪਾਸਵਰਡ, ਗੁੰਮ ਫੀਲਡ) ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਐਰਰ ਸੁਨੇਹਾ ਕਿੱਥੇ ਬਣਾਇਆ ਜਾਂਦਾ ਅਤੇ ਕਿੱਥੇ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ। ਸਫਲਤਾ ਅਤੇ ਨਾਕਾਮੀ ਲਈ ਉਮੀਦੀਆਂ ਨੂੰ ਦਰਜ ਕਰੋ (ਸਟੇਟਸ ਕੋਡ ਅਤੇ ਮੁੱਖ ਫੀਲਡ), ਤਾਂ ਜੋ ਅਗਲਾ ਡਿਵੈਲਪਰ ਤੇਜ਼ੀ ਨਾਲ ਸੈਨਿਟੀ-ਚੈੱਕ ਕਰ ਸਕੇ।
ਇਹ ਇਕਲ ਫਲੋ ਅਕਸਰ ਮਾਲਕੀ ਹੱਦਾਂ ਨੂੰ ਉਤਪਨ ਕਰਦੀ ਹੈ: UI ਕਿਸ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ, API ਕੀ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿੱਥੇ ਐਰਰ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ ਜਾਂ ਡਬਲ-ਹੈਂਡਲ ਹੁੰਦੇ ਹਨ।
ਜਦ ਤੁਹਾਡੇ ਕੋਲ ਇਕ ਵਧੀਆ ਮੈਪ ਹੋਵੇ, ਉਸਨੂੰ 1-2 ਪੇਜ ਨੋਟ ਵਿੱਚ ਬੰਦ ਕਰੋ। ਮਕਸਦ ਪੂਰਾ ਹੋਣਾ ਨਹੀਂ, ਬਲਕਿ ਅਗਲੇ ਡਿਵੈਲਪਰ ਲਈ ਇਹ ਸਪੱਸ਼ਟ ਕਰਨਾ ਹੈ: ਇਹ ਐਪ ਕੀ ਕਰਦਾ ਹੈ, ਪਹਿਲਾਂ ਕਿੱਥੇ ਦੇਖਣਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ Claude Code ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਡੌਕ ਨੂੰ ਆਪਣੇ Q&A ਦੇ ਆਉਟਪੁੱਟ ਵਜੋਂ ਦਿਓ: ਸਾਫ਼, ਠੋਸ, ਅਤੇ ਅਸਾਨੀ ਨਾਲ ਸਕੈਨ ਕਰਨਯੋਗ।
ਡੌਕ ਨੂੰ ਪੇਸ਼ਗੀ ਰੱਖੋ ਤਾਂ ਕਿ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ चीਜ਼ਾਂ ਲੱਭ ਸਕਣ। ਇੱਕ ਚੰਗੀ ਸੰਰਚਨਾ ਇਹ ਹੈ:
"Where things live" ਲਈ ਅਨੁਦੇਸ਼ਾਂ ਜਿਵੇਂ "Auth X ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, session logic Y ਵਿੱਚ, UI routes Z ਵਿੱਚ" ਦਿਓ। ਪੂਰਾ ਟ੍ਰੀ ਡੰਪ ਕਰਨ ਤੋਂ ਬਚੋ। ਸਿਰਫ਼ ਉਹ ਚੁਣੋ ਜੋ ਲੋਕ ਹੱਥ ਲਗਾਉਣਗੇ।
"Key flows" ਲਈ 4-7 ਕਦਮ ਲਿਖੋ: ਟ੍ਰਿਗਰ, ਕੰਟਰੋਲਰ ਜਾਂ ਹੈਂਡਲਰ, ਕੋਰ ਮਾਡਿਊਲ, ਡੇਟਾਬੇਸ ਕਾਲ, ਅਤੇ ਬਾਹਰਲਾ ਪ੍ਰਭਾਵ (ਈਮੇਲ ਭੇਜੀ ਗਈ, ਸਟੇਟ ਅਪਡੇਟ ਹੋਇਆ, ਜੌਬ ਕਿਊ ਕੀਤਾ ਗਿਆ)। ਹਰ ਕਦਮ 'ਤੇ ਫਾਈਲ ਨਾਂ ਜੋੜੋ।
"Risky areas" ਵਿੱਚ ਫੇਲ ਮੋਡ ਅਤੇ ਸਭ ਤੋਂ ਤੇਜ਼ ਸੁਰੱਖਿਆ ਜਾਂਚ (ਖਾਸ ਟੈਸਟ, ਸਮੋਕ ਰਨ, ਜਾਂ ਲੌਗ ਦੇਖਣਾ) ਦਿਓ।
ਅੰਤ ਵਿੱਚ ਇੱਕ ਛੋਟੇ ਪਹਿਲੇ-ਟਾਸਕਾਂ ਦੀ ਸੂਚੀ ਦਿਓ ਤਾਂ ਕਿ ਕੋਈ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਯੋਗਦਾਨ ਦੇ ਸਕੇ:
ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਅਸਿਸਟੈਂਟ ਨੂੰ ਵਰਤ ਨੂੰ ਖਰਾਬ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ: "ਪੂਰੇ ਰੇਪੋ ਦੀ ਇੱਕ ਪੂਰੀ ਵਿਆਖਿਆ ਦਿਓ।" ਤੁਹਾਨੂੰ ਇੱਕ ਲੰਬਾ ਸਾਰ ਮਿਲੇਗਾ ਜੋ ਭਰੋਸੇਯੋਗ ਲੱਗਦਾ ਹੈ ਪਰ ਧੁੰਦਲਾ ਰਹਿੰਦਾ ਹੈ। ਇਸਦੀ ਥਾਂ, ਇੱਕ ਛੋਟੇ ਸਲਾਇਸ (ਇੱਕ ਮਾਡਿਊਲ + ਇੱਕ ਯੂਜ਼ਰ ਫਲੋ) ਚੁਣੋ, ਫਿਰ ਬਾਹਰ ਫੈਲੋ।
ਦੂਜੀ ਸੁਝਾਅ ਵਾਲੀ ਗਲਤੀ ਇਹ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਯਾਤਰਾਵਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਇਹ ਨਹੀਂ ਦੱਸਣਾ। ਜੇ ਤੁਸੀਂ "checkout", "login", ਜਾਂ "admin edit" ਨਹੀਂ ਕਹਿੰਦੇ, ਤਾੰ ਜਵਾਬ ਆਮ ਆਰਕੀਟੈਕਚਰ ਗੱਲਾਂ ਵੱਲ ਭਟਕ ਜਾਂਦੇ ਹਨ। ਹਰ ਸੈਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਠੋਸ ਲਕੜੀ ਤੇ ਕਰੋ: "ਮੇਰੀ ਮਦਦ ਕਰੋ signup ਫਲੋ ਨੂੰ ਐਂਡ-ਟੂ-ਐਂਡ ਸਮਝਣ ਵਿੱਚ, validation, error states, ਅਤੇ ਡੇਟਾ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ।"
ਹੋਰ ਇੱਕ ਜਾਲ ਇਹ ਹੈ ਕਿ ਅਸਿਸਟੈਂਟ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦਿਓ। ਜੇ ਕੁਝ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਅਣਜਾਣ ਵਜੋਂ ਲੇਬਲ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੋ। ਪੁੱਛੋ ਕਿ ਉਹ ਜੋ ਸਾਬਤ ਕਰ ਸਕਦਾ ਹੈ ਕੋਡ ਤੋਂ ਅਤੇ ਜੋ ਅਨੁਮਾਨ ਹੈ, ਉਹ ਵੱਖ-ਵੱਖ ਦਰਸਾਏ।
ਆਪਣੇ ਨੋਟਸ ਵਿੱਚ ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਵਰਤੋ: ਹਰ ਦਾਅਵਾ ਇੱਕ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਨੋਟਸ ਟੁੱਟਦੇ ਹਨ ਜਦ ਉਹ ਬਿਨਾਂ ਸੰਰਚਨਾ ਇਕੱਠੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਸਧਾਰਣ ਟੈਮਪਲੇਟ ਰੱਖੋ: ਸ਼ਾਮਿਲ ਮਾਡਿਊਲ, ਐਂਟਰੀ ਪੁਆਇੰਟ, ਮੁੱਖ ਫੰਕਸ਼ਨਾਂ ਅਤੇ ਫਾਈਲਾਂ, ਡੇਟਾ ਛੁਹਿਆ, ਸਾਈਡ-ਐਫੈਕਟ, ਐਰਰ ਪਾਥ, ਅਤੇ ਚਲਾਉਣ ਲਈ ਟੈਸਟ।
Claude Code ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਆਉਟਪੁੱਟ ਨੂੰ ਡਰਾਫਟ ਮੰਨੋ। ਮਹੱਤਵਪੂਰਨ ਫਲੋਜ਼ ਨੂੰ ਚੱਲ ਕੇ ਵੈਰੀਫਾਈ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਉਹ ਹਿੱਸੇ ਜੋ ਉਤਪਾਦਨ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹਨ: auth, payments, permissions, background jobs, ਅਤੇ migrations।
ਇਕ ਵਿਆਵਹਾਰਿਕ ਉਦਾਹਰਨ: ਜੇ ਅਸਿਸਟੈਂਟ ਕਹਿੰਦਾ ਹੈ "password reset sends an email via X," ਤਾਂ ਇਸਨੂੰ dev ਵਾਤਾਵਰਣ ਵਿੱਚ trigger ਕਰਕੇ ਲੌਗ ਜਾਂ ਈਮੇਲ ਸੈਂਡਬਾਕਸ ਨੂੰ ਚੈੱਕ ਕਰੋ। ਇਹ ਰੀਅਲਿਟੀ ਚੈਕ ਤੁਹਾਨੂੰ ਇੱਕ ਗਲਤ ਕਹਾਣੀ ਵਿੱਚ ਨਬੋਰਡਿੰਗ ਕਰਨ ਤੋਂ ਬਚਾਂਦਾ ਹੈ।
ਤੁਹਾਨੂੰ ਰੇਪੋ ਯਾਦ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਪੂਰੀ ਆਤਮ-ਵਿਸ਼ਵਾਸ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇੱਕ ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ ਕਰ ਸਕੋ, ਇੱਕ ਅਸਲੀ ਮੁੱਦੇ ਨੂੰ ਡੀਬੱਗ ਕਰ ਸਕੋ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਅਗਲੇ ਵਿਅਕਤੀ ਕੋਲ ਸਮਝਾ ਸਕੋ।
ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਬਿਨਾ ਅਨੁਮਾਨ ਦੇ ਜਵਾਬ ਦੇ ਸਕੋ:
ਜੇ ਤੁਸੀਂ ਇੱਕ ਆਈਟਮ ਗੁੰਮ ਹੈ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਕੇਂਦਰਿਤ ਪਾਸ ਕਰੋ ਨਾ ਕਿ وسیع ਖੋਜ। ਇੱਕ ਫਲੋ ਚੁਣੋ, ਉਸਨੂੰ ਡੇਟਾਬੇਸ ਬਾਉਂਡਰੀ ਤਕ ਫੋਲੋ ਕਰੋ, ਫਿਰ ਰੁਕੋ ਅਤੇ ਜੋ ਸਿੱਖਿਆ ਉਹ ਲਿਖੋ। ਜਦ ਕੁਝ ਅਸਪਸ਼ਟ ਹੋਵੇ, ਉਸਨੂੰ ਇੱਕ ਸਵਾਲ ਵਜੋਂ ਰੱਖੋ, ਇੱਕ ਪੈਰਾ ਨਾ: "Where is role X created?" "auth is confusing" ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਵਰਤੋਗੀ ਹੈ।
ਇਕ ਚੰਗਾ ਆਖਰੀ ਟੈਸਟ: ਸੋਚੋ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਛੋਟੀ ਫੀਚਰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਜੋੜਨ ਲਈ ਕਿਹਾ ਗਿਆ ਹੈ। ਜੇ ਤੁਸੀਂ ਫਾਈਲਾਂ ਦਾ ਨਾਮ ਦੱਸ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਛੂਹੋ, ਟੈਸਟ ਜੋ ਤੁਸੀਂ ਚਲਾਉਗੇ, ਅਤੇ ਅਸਫਲਤਾ ਮੋਡ ਜੋ ਤੁਸੀਂ ਦੇਖੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਯੋਗਦਾਨ ਦੇਣ ਲਈ ਕਾਫੀ ਨਬੋਰਡ ਹੋ।
ਮੈਨਟਲ ਮੈਪ ਸਿਰਫ ਤਦ ਤੱਕ ਲਾਭਦਾਇਕ ਹੈ ਜਦ ਇਹ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦਾ ਰਹੇ। ਇਸਨੂੰ ਇਕ ਜੀਵੰਤ ਆਰਟੀਫੈਕਟ ਸਮਝੋ, ਇੱਕ ਇਕ ਵਾਰੀ ਦਾ ਕੰਮ ਨਹੀਂ। ਸਾਧਾਰਣ ਤਰੀਕੇ ਨਾਲ ਇਸਨੂੰ ਅਪਡੇਟ ਰੱਖਣਾ ਸਭ ਤੋਂ ਅਸਾਨ ਹੈ: ਬਦਲਾਅ ਦੇ ਤੁਰੰਤ ਬਾਅਦ।
ਇੱਕ ਹਲਕਾ ਰੁਟੀਨ ਵੱਡੇ ਰੀ-ਰਾਈਟ ਤੋਂ ਵਧੀਆ ਹੈ। ਇਹ ਕੰਮ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਰ ਰਹੇ ਹੋ, ਉਸ ਨਾਲ ਅਪਡੇਟ ਜੋੜੋ:
ਨਬੋਰਡਿੰਗ ਡੌਕ ਨੂੰ ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖੋ ਅਤੇ ਇਸਨੂੰ ਕੋਡਬੇਸ ਨਾਲ ਇੱਕੋ ਹੀ ਅਨੁਸ਼ਾਸਨ ਨਾਲ ਵਰਜ਼ਨ ਕਰੋ। ਛੋਟੇ ਡਿਫ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ। ਵੱਡੀਆਂ ਡੌਕ ਰੀ-ਰਾਈਟ ਆਮ ਤੌਰ 'ਤੇ ਅਣਦੇਖੀਆਂ ਰਹਿ ਜਾਂਦੀਆਂ ਹਨ।
ਜਦ ਡਿਪਲੋਇਮੈਂਟ ਖਤਰਨਾਕ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਲਿਖੋ ਕਿ ਅਗਲੇ ਬੰਦੇ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਕਿਸ ਤਰ੍ਹਾਂ ਰੀਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ: ਕੀ ਬਦਲਿਆ, ਕੀ ਦੇਖਣਾ ਹੈ, ਅਤੇ ਕਿਵੇਂ ਰੋਲ ਬੈਕ ਕਰਨਾ ਹੈ। ਜੇ ਪਲੈਟਫਾਰਮ ਸਪੋਰਟ ਸਨੇਪਸ਼ੌਟ ਅਤੇ ਰੋਲਬੈਕ, ਤਾਂ ਸਨੇਪਸ਼ੌਟ ਨਾਂ, ਕਾਰਨ, ਅਤੇ ਠੀਕ ਹੋਣ ਦੀ ਪਰਿਭਾਸ਼ਾ ਜੋੜੋ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ planning mode ਤੁਹਾਨੂੰ Q&A ਤੋਂ ਇੱਕ ਸਥਿਰ ਮਾਡਿਊਲ ਮੈਪ ਅਤੇ ਨਬੋਰਡਿੰਗ ਨੋਟ ਤਿਆਰ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ source code export ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਨਤੀਜਾ ਵੈਰੀਫਾਈ ਕਰਨ ਦਾ ਸਾਫ਼ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਹੇੰਡਆਫ਼ ਚੈੱਕਲਿਸਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਕਿ ਅਗਲਾ ਡਿਵੈਲਪਰ ਬਿਨਾਂ ਅਨੁਮਾਨ ਦੇ ਅਨੁਸਰਣ ਕਰ ਸਕੇ:
ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੋਣ 'ਤੇ, Claude Code কোਡਬੇਸ ਨਬੋਰਡਿੰਗ ਇੱਕ ਆਦਤ ਬਣ ਜਾਂਦੀ ਹੈ: ਹਰ ਬਦਲਾਅ ਅਗਲੇ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਸਾਫ਼ ਨਕਸ਼ਾ ਛੱਡ ਜਾਂਦਾ ਹੈ।
Aim for a usable mental map, not total understanding.
A solid 1–2 day outcome is:
Give it concrete artifacts so it can point to real code instead of guessing:
Pick a narrow slice with clear boundaries.
A good default scope is:
Write down what’s explicitly out of scope (other services, legacy modules, rarely used features) so the assistant doesn’t wander.
Start from known triggers, then walk forward:
Ask for file paths and function names in order, and end with: “How would I test this quickly?”
Look where the system makes decisions or changes state:
Use a simple label system and attach one proof step.
Example format:
Force the assistant to separate evidence from inference.
Ask it to tag each claim as one of:
When something is unknown, turn it into a teammate question (“Where is role X defined?”) instead of filling the gap with a guess.
Keep one lightweight note file with five sections:
Default to a quick, real check:
This validates you mapped the path the app actually uses.
Use platform features to reduce blast radius and keep changes reviewable.
Practical defaults:
Then ask: “What breaks silently, and how would we notice?”
Keep it short so you actually update it as you learn.
Add one line to each flow: “How would I test this?” so it becomes a checklist.
This works especially well for onboarding tasks like “add a guardrail,” “tighten validation,” or “improve an error path.”