02 ਦਸੰ 2025·8 ਮਿੰਟ
ਕੋਡ ਤੋਂ Claude Code ਫੀਚਰ ਸਪੈਸ: ਇੱਕ ਸਾਦਾ ਵਰਕਫਲੋ
ਰੀਅਲ ਐਪ ਬਿਹੈਵਿਯਰ ਨੂੰ ਰੂਟਸ ਅਤੇ ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਨਿਕਾਲ ਕੇ Claude Code ਨਾਲ ਕੋਡ ਤੋਂ ਫੀਚਰ ਸਪੈਸ ਬਣਾਉਣ ਅਤੇ ਲਿਵਿੰਗ ਸਪੈਸ ਅਤੇ ਗੈਪਸ ਲਿਸਟ ਤਿਆਰ ਕਰਨ ਦਾ ਸਧਾਰਨ ਤਰੀਕਾ ਸਿੱਖੋ।
ਰੀਅਲ ਐਪ ਬਿਹੈਵਿਯਰ ਨੂੰ ਰੂਟਸ ਅਤੇ ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਨਿਕਾਲ ਕੇ Claude Code ਨਾਲ ਕੋਡ ਤੋਂ ਫੀਚਰ ਸਪੈਸ ਬਣਾਉਣ ਅਤੇ ਲਿਵਿੰਗ ਸਪੈਸ ਅਤੇ ਗੈਪਸ ਲਿਸਟ ਤਿਆਰ ਕਰਨ ਦਾ ਸਧਾਰਨ ਤਰੀਕਾ ਸਿੱਖੋ।
ਲੋਕ ਇਸ ਗੱਲ 'ਤੇ ਅਸਹਿਮਤ ਹੁੰਦੇ ਹਨ ਕਿ ਐਪ ਕੀ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਵੱਖ-ਵੱਖ ਵਰਜਨਾਂ ਨੂੰ ਯਾਦ ਕਰਦੇ ਹਨ। ਸਪੋਰਟ ਆਖਰੀ ਗੁੱਸੇ ਭਰੇ ਟਿਕਟ ਨੂੰ ਯਾਦ ਰੱਖਦਾ ਹੈ। ਸੇਲਜ਼ ਡੈਮੋ ਪਾਥ ਨੂੰ ਯਾਦ ਰੱਖਦਾ ਹੈ। ਇੰਜੀਨੀਅਰ ਜੋ ਫੀਚਰ ਬਣਾਉਣ ਦਾ ਮਕਸਦ ਸੀ, ਉਹ ਉਸਨੂੰ ਯਾਦ ਰੱਖਦੇ ਹਨ। ਤਿੰਨ ਲੋਕਾਂ ਨੂੰ ਪੁੱਛੋ ਅਤੇ ਤੁਹਾਨੂੰ ਤਿੰਨ ਯਕੀਨੀ ਜਵਾਬ ਮਿਲਣਗੇ, ਪਰ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮੌਜੂਦਾ ਬਿਲਡ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਵਕਤ ਦੇ ਨਾਲ, ਕੋਡ ਹੀ ਇਕਲੌਤਾ ਸਰੋਤ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਅਪ-ਟੂ-ਡੇਟ ਰਹਿੰਦਾ ਹੈ। ਡੌਕਸ ਭਟਕ ਜਾਂਦੇ ਹਨ, ਟਿਕਟ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਛੋਟੀਆਂ ਫਿਕਸਾਂ ਇਕੱਠੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਰੂਟ 'ਤੇ ਨਵਾਂ ਵੈਲਿਡੇਸ਼ਨ ਨਿਯਮ ਆ ਜਾਂਦਾ ਹੈ। UI ਟੌਗਲ ਡਿਫੌਲਟ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਹੈਂਡਲਰ ਵੱਖ-ਵੱਖ ਐਰਰ ਵਾਪਸ ਕਰਨ ਲੱਗ ਪੈਂਦਾ ਹੈ। ਕੋਈ ਵੀ ਸਪੈਸ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦਾ ਕਿਉਂਕਿ ਇਹ ਵਿਕਲਪਿਕ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਹਰ ਬਦਲਾਵ ਕاغਜ਼ 'ਤੇ ਦਰਜ ਕਰਨ ਲਈ ਬਹੁਤ ਛੋਟਾ ਲੱਗਦਾ ਹੈ।
ਇਸ ਨਾਲ ਪੇਸ਼ਗੀ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ। ਟੀਮਾਂ ਐਸੇ ਬਦਲਾਅ ਭੇਜ ਦਿੰਦੀਆਂ ਹਨ ਜੋ ਉਹ ਐਜ ਕੇਸ ਤੋੜ ਦਿੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਉਨ੍ਹਾਂ ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ। QA ਖੁਸ਼ ਰਾਹ ਨੂੰ ਟੈਸਟ ਕਰਦਾ ਹੈ ਅਤੇ ਹੈਂਡਲਰਾਂ ਵਿੱਚ ਛੁਪੇ ਨਿਯਮਾਂ ਨੂੰ ਮਿਸ ਕਰਦਾ ਹੈ। ਨਵੇਂ ਸਾਥੀ UI ਤੋਂ ਬਿਹੈਵਿਯਰ ਨਕਲ ਕਰ ਲੈਂਦੇ ਹਨ ਬਿਨਾਂ ਅਸਲ ਪਾਬੰਦੀਆਂ ਨੂੰ ਸਮਝੇ। ਸਟੇਕਹੋਲਡਰ ਰਾਇਆਂ 'ਤੇ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਕਰਦੇ ਹਨ ਬਜਾਏ ਕਿ ਸਹਿਮਤ ਬਿਹੈਵਿਯਰ ਨੂੰ ਦਰਸਾਉਣ ਦੇ।
ਇੱਕ ਚੰਗਾ ਨਤੀজা ਪੂਰਨ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਹੈ। ਇਹ ਸਾਂਝੀ ਸਪਸ਼ਟਤਾ ਹੈ। ਹਰ ਕੋਈ ਇਹ ਜਵਾਬ ਦੇ ਸਕੇ: "ਜੇ ਮੈਂ X ਕਰਾਂ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?" ਅਤੇ "ਸਿਸਟਮ ਕੀ ਜ਼ਿਮੇਵਾਰੀ ਦਿੰਦਾ ਹੈ?" ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ। ਤੁਹਾਨੂੰ ਘੱਟ ਹੈਰਾਨੀਆਂ, ਛੋਟੀ ਰਿਵਿਊ ਚੱਕਰ, ਅਤੇ ਘੱਟ "ਰੁਕੋ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਕਰਦਾ ਹੈ" ਵਾਲੇ ਮੋਮੈਂਟ ਮਿਲਦੇ ਹਨ ਕਿਉਂਕਿ ਟੀਮ ਇੱਕੋ ਸੱਚ ਦੇਖ ਰਹੀ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਸਪੈਸ ਕੋਡ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਤਾਂ ਬਦਲਾਅ ਯੋਜਨਾ ਬਣਾਉਣਾ ਸੁਰੱਖਿਅਤ ਬਣ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਸਥਿਰ ਹੈ, ਕੀ ਐਕਸੀਡੈਂਟਲ ਹੈ, ਅਤੇ ਕੀ ਗੁੰਮ ਹੈ ਅਗਾਂਹਲੇ ਸ਼ਿਪ ਤੋਂ ਪਹਿਲਾਂ।
ਲਿਵਿੰਗ ਸਪੈਸ ਇੱਕ ਛੋਟੀ, ਸੰਪਾਦਯੋਗ ਵਰਣਨਾ ਹੈ ਕਿ ਐਪ ਅਸਲ ਵਿੱਚ ਅੱਜ ਕੀ ਕਰਦੀ ਹੈ। ਇਹ ਇੱਕ ਇਕ-ਵਾਰ ਦੀ ਫਾਇਲ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਹਰ ਵਾਰ ਬਿਹੈਵਿਯਰ ਬਦਲਣ 'ਤੇ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਜੋ ਟੀਮ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕੇ।
ਜਦ ਲੋਕ ਕੋਡ ਤੋਂ ਲਿਖੀਆਂ ਫੀਚਰ ਸਪੈਸਾਂ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਣ ਦੇ ਤੌਰ Claude Code ਵਰਗੇ ਟੂਲ ਨਾਲ), ਮਕਸਦ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਰੂਟ, ਹੈਂਡਲਰ, ਅਤੇ ਸਕ੍ਰੀਨਾਂ ਤੋਂ ਅਸਲ ਬਿਹੈਵਿਯਰ ਪੜ੍ਹੋ, ਫਿਰ ਉਹਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ।
ਇੱਕ ਉਪਯੋਗੀ ਲਿਵਿੰਗ ਸਪੈਸ ਇਸ ਗੱਲ 'ਤੇ ਧਿਆਨ ਦੇਂਦੀ ਹੈ ਕਿ ਯੂਜ਼ਰ ਕੀ ਦੇਖ ਸਕਦੇ ਹਨ ਅਤੇ ਸਿਸਟਮ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਜੋ ਚੀਜ਼ ਇਹ ਨਹੀਂ ਕਵਰ ਕਰਨੀ ਚਾਹੀ ਉਹ ਹੈ ਕਿ ਕੋਡ ਕਿਵੇਂ ਸੰਗਠਤ ਹੈ। ਜੇ ਤੁਸੀਂ ਫੰਗਸ਼ਨ ਅਤੇ ਕਲਾਸ ਨਾਂਵਾਂ ਜਾਂ ਰੀਫੈਕਟਰ ਯੋਜਨਾਵਾਂ ਨੂੰ ਨਾਮ ਲੈਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੋ, ਤਾਂ ਤੁਸੀਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੇਰਵੇ ਦੀਆਂ ਗੱਲਾਂ ਵਿੱਚ ਚਲੇ ਜਾ ਰਹੇ ਹੋ। ਬਚੋ:
ਗੈਪਸ ਲਿਸਟ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਛੋਟੀ ਲਿਸਟ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਤਕਰਾਅ ਅਤੇ ਅਣਜਾਣੀਆਂ ਗੱਲਾਂ ਦਰਜ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਸਪੈਸ ਲਿਖਦੇ ਸਮੇਂ ਮਿਲਦੀਆਂ ਹਨ।
ਉਦਾਹਰਨ: ਇੱਕ ਰੂਟ 10MB ਤੋਂ ਵੱਧ ਫਾਈਲਾਂ ਨੂੰ ਰੀਜੈਕਟ ਕਰਦਾ ਹੈ, ਪਰ UI 25MB ਦੱਸਦੀ ਹੈ। ਇਹ ਇੱਕ ਗੈਪ ਹੈ ਜਦ ਤੱਕ ਟੀਮ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕਿਹੜਾ ਨਿਯਮ ਸਹੀ ਹੈ ਅਤੇ ਕੋਡ ਜਾਂ ਸਪੈਸ ਅਨੁਸਾਰ ਅਪਡੇਟ ਨਹੀਂ ਹੁੰਦੇ।
ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ ਐਪ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਤਾਂ ਅਖ਼ੀਰ ਵਿੱਚ ਨੋਟਾਂ ਦਾ ਇੱਕ ਢੇਰ ਹੋਵੇਗਾ ਜਿਸ 'ਤੇ ਕਿਸੇ ਨੂੰ ਭਰੋਸਾ ਨਹੀਂ ਰਹੇਗਾ। ਇੱਕ ਸਲਾਇਸ ਚੁਣੋ ਜੋ ਯੂਜ਼ਰ ਇੱਕ ਵਾਕ ਵਿੱਚ ਵਰਨਨ ਕਰ ਸਕੇ, ਜਿਵੇਂ "ਟîm ਨੂੰ invite ਕਰਨਾ," "checkout," ਜਾਂ "password reset." ਚੰਗੇ ਸਕੋਪ ਇੱਕ ਫੀਚਰ ਏਰੀਆ, ਇੱਕ ਮੋਡੀਯੂਲ, ਜਾਂ ਇੱਕ ਯੂਜ਼ਰ ਯਾਤਰਾ ਦਾ ਇਕੱਲਾ ਹਿੱਸਾ ਹੁੰਦੇ ਹਨ।
ਸੱਚਾਈ ਲੱਭਣ ਲਈ ਆਪਣਾ ਐਂਟਰੀ ਪੁਆਇੰਟ ਚੁਣੋ:
ਕੋਡ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਇਨਪੁਟ ਇਕੱਤਰ ਕਰੋ ਤਾਂ ਕਿ ਅਸਮਾਨਤੀਆਂ ਜਲਦੀ ਨਜ਼ਰ ਆਉਣ: ਮੌਜੂਦਾ API ਡੌਕਸ, ਪੁਰਾਣੇ ਪ੍ਰੋਡਕਟ ਨੋਟਸ, ਸਪੋਰਟ ਟਿਕਟ, ਅਤੇ ਲੋਕਾਂ ਵੱਲੋਂ ਦੱਸੀਆਂ ਹੋਈਆਂ "ਜਾਣੀਆਂ ਮੁਸ਼ਕਲਾਂ"। ਇਹ ਕੋਡ ਨੂੰ ਓਵਰਰਾਈਡ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਗੁੰਮ ਸਟੇਟਾਂ ਜਿਵੇਂ ਐਰਰ, ਏਜ ਕੇਸ ਅਤੇ ਪਰਮੇਸ਼ਨਾਂ ਨੂੰ ਨੋਟਿਸ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਸਪੈਸ ਫਾਰਮੈਟ ਨਿਰਸ ਅਤੇ ਲਗਾਤਾਰ ਰੱਖੋ। ਜਦੋਂ ਹਰ ਸਪੈਸ ਇੱਕੋ ਢੰਗ ਨਾਲ ਵੰਨਿਆ ਹੋਵੇ ਤਾਂ ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਸਹਿਮਤ ਹੁੰਦੀ ਹੈ।
ਇਸ ਸਰਚਨਾ ਨੂੰ ਦੁਹਰਾਉ ਅਤੇ ਤੁਹਾਡੀਆਂ ਫੀਚਰ ਸਪੈਸ ਪੜ੍ਹਨਯੋਗ, ਤੁਲਨਯੋਗ ਅਤੇ ਅਪਡੇਟ ਕਰਨ ਯੋਗ ਰਹਿਣਗੀਆਂ।
ਸਰਵਰ ਐਂਟਰੀ ਪੁਆਇੰਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਰੂਟ ਅਤੇ ਹੈਂਡਲਰ "ਐਪ ਕੀ ਕਰਦੀ ਹੈ" ਨੂੰ ਠੋਸ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਉਂਦੇ ਹਨ: ਕੌਣ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਕੀ ਭੇਜਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਕੀ ਵਾਪਸ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਵਿਚ ਕੀ ਬਦਲਦਾ ਹੈ।
ਸਕੋਪ ਵਿੱਚ ਰੂਟਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ ਯੂਜ਼ਰ ਇਰਾਦੇ ਨਾਲ ਮੈਪ ਕਰੋ। "POST /api/orders" ਨਾ ਲਿਖੋ। "Place an order" ਜਾਂ "Save a draft" ਲਿਖੋ। ਜੇ ਤੁਸੀਂ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਇਰਾਦਾ ਨਾਮ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਇੱਕ ਸਪੈਸ ਗੈਪ ਹੈ।
ਹਰ ਹੈਂਡਲਰ ਪੜ੍ਹਦੇ ਸਮੇਂ, ਇਨਪੁਟ ਅਤੇ ਵੈਲਿਡੇਸ਼ਨ ਨਿਯਮਾਂ ਨੂੰ ਯੂਜ਼ਰ-ਸਮਝਣਯੋਗ ਲੋੜਾਂ ਵਜੋਂ ਕੈਪਚਰ ਕਰੋ। ਲਾਜ਼ਮੀ ਖੇਤਰ, ਮਨਜ਼ੂਰ ਫਾਰਮੈਟ, ਅਤੇ ਉਹ ਨਿਯਮ ਜੋ ਅਸਲ ਐਰਰ ਪੈਦਾ ਕਰਦੇ ਹਨ ਸ਼ਾਮਿਲ ਕਰੋ। ਉਦਾਹਰਣ: "Email must be valid", "Quantity must be at least 1", "Start date can't be in the past."
Auth ਅਤੇ ਰੋਲ ਚੈਕਸ ਨੂੰ ਵੀ ਇਕੋ ਤਰ੍ਹਾਂ ਨੋਟ ਕਰੋ। "middleware: requireAdmin" ਦੇ ਬਦਲੇ ਦਸਤਾਵੇਜ਼ ਕਰੋ: "Only admins can cancel any order. Regular users can only cancel their own order within 10 minutes." ਜੇ ਕੋਡ ownership, feature flags, ਜਾਂ tenant boundaries ਨੂੰ ਚੈੱਕ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਵੀ ਸ਼ਾਮਿਲ ਕਰੋ।
ਫਿਰ ਆਉਟਪੁੱਟ ਅਤੇ ਨਤੀਜੇ ਨੋਟ ਕਰੋ। ਸਫਲਤਾ ਕੀ ਵਾਪਸ ਕਰਦੀ ਹੈ (ਬਣਿਆ ID, ਅਪਡੇਟ ਕੀਤੀ ਆਬਜੈਕਟ)? ਆਮ ਫੇਲਿਯਾਂ ਕੀ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ (401 not signed in, 403 not allowed, 404 not found, 409 conflict, 422 validation error)?
ਆਖ਼ਿਰਕਾਰ, ਸਾਈਡ-ਇਫੈਕਟਸ ਰਿਕਾਰਡ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਬਿਹੈਵਿਯਰ ਦਾ ਹਿੱਸਾ ਹਨ: ਬਣਾਏ ਜਾਂ ਅਪਡੇਟ ਕੀਤੇ ਰਿਕਾਰਡ, ਭੇਜੇ ਗਏ ਈਮੇਲ ਜਾਂ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਪਬਲਿਸ਼ ਕੀਤੇ ਇਵੈਂਟ, ਬੈਕਗ੍ਰਾਊਂਡ ਨੌਕ/ਜਾਬ, ਅਤੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਹੋਰ ਫਲੋਜ਼ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੀ ਹੈ। ਇਹ ਵੇਰਵੇ ਬਾਅਦ ਵਿੱਚ ਅਚਾਨਕਾਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।
ਰੂਟ ਤੁਹਾਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਐਪ ਕੀ ਕਰ ਸਕਦੀ ਹੈ। ਕੰਪੋਨੈਂਟ ਦੱਸਦੇ ਹਨ ਕਿ ਯੂਜ਼ਰ ਅਸਲ ਵਿੱਚ ਕੀ ਤਜਰਬਾ ਕਰਦੇ ਹਨ। UI ਨੂੰ ਇੱਕ ਹਿੱਸਾ ਮੰਨੋ: ਕੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਕੀ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਗਲਤ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।
ਫੀਚਰ ਲਈ ਐਂਟਰੀ ਸਕ੍ਰੀਨਾਂ ਲੱਭਣਾ ਸ਼ੁਰੂ ਕਰੋ। ਪੇਜ ਕੰਪੋਨੈਂਟ, ਲੇਆਊਟ ਰੈਪਰ, ਅਤੇ ਕੁਝ "ਫੈਸਲਾ" ਕਰਨ ਵਾਲੇ ਕੰਪੋਨੈਂਟ ਜਿਹੜੇ fetching, permissions, ਅਤੇ navigation ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹਨ, ਉਹ ਅਕਸਰ ਹਕੀਕਤੀ ਬਿਹੈਵਿਯਰ ਦਾ ਸਥਾਨ ਹੁੰਦੇ ਹਨ।
ਕੰਪੋਨੈਂਟ ਪੜ੍ਹਦੇ ਸਮੇਂ, ਉਹ ਨਿਯਮ ਲਿਖੋ ਜੋ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹਨ: ਜਦੋਂ actions disable ਹੁੰਦੇ ਹਨ, ਲਾਜ਼ਮੀ ਕਦਮ, ਸ਼ਰਤਾਂ ਵਾਲੇ ਫੀਲਡ, ਲੋਡਿੰਗ ਸਟੇਟ, ਅਤੇ ਐਰਰ ਕਿਵੇਂ ਦਿਖਦੇ ਹਨ (inline ਫੀਲਡ ਐਰਰ vs toast, auto-retry, "try again" ਬਟਨ)। ਸਟੇਟ ਅਤੇ ਕੈਸ਼ਿੰਗ ਵਰਤਾਰੇ ਵੀ ਨੋਟ ਕਰੋ ਜਿਵੇਂ stale ਡੇਟਾ ਪਹਿਲਾਂ ਦਿਖਣਾ, optimistic updates, ਜਾਂ "last saved" ਟਾਈਮਸਟੈਂਪ।
ਛੁਪੇ ਫਲੋਜ਼ ਲਈ ਧਿਆਨ ਦਿਓ ਜੋ ਗੁਪਤ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਜੋ ਦੇਖਦੇ ਹਨ ਉਸਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ। feature flags, experiment buckets, ਅਤੇ admin-only gates ਲਈ ਖੋਜ ਕਰੋ। ਸਾਇਲੈਂਟ redirects ਨੂੰ ਵੀ ਨੋਟ ਕਰੋ, ਜਿਵੇਂ logged-out ਯੂਜ਼ਰਾਂ ਨੂੰ sign-in ਤੇ ਭੇਜਣਾ ਜਾਂ ਐਕਸੈਸ ਨਾ ਰੱਖਣ ਵਾਲੇ ਯੂਜ਼ਰ ਨੂੰ upgrade ਸਕ੍ਰੀਨ ਤੇ ਭੇਜਣਾ।
ਇੱਕ konkreਟ ਉਦਾਹਰਣ: "Change Email" ਸਕ੍ਰੀਨ 'ਤੇ ਦਰਜ ਕਰੋ ਕਿ Save disable ਰਹਿੰਦਾ ਹੈ ਜਦ ਤੱਕ email valid ਨਹੀਂ ਹੁੰਦੀ, request ਦੌਰਾਨ spinner ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, success 'ਤੇ confirmation banner ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਅਤੇ backend validation errors ਇਨਪੁੱਟ ਹੇਠਾਂ ਰੇਂਡਰ ਹੁੰਦੇ ਹਨ। ਜੇ ਕੋਡ newEmailFlow ਵਰਗਾ ਫਲੈਗ ਦਿਖਾਉਂਦਾ ਹੈ, ਦੁਹਾਂ ਵੈਰੀਅਨਟਾਂ ਨੂੰ ਨੋਟ ਕਰੋ ਅਤੇ ਕੀ ਫਰਕ ਹੈ।
ਹਰ UI ਫਲੋ ਨੂੰ ਛੋਟੇ ਕਦਮਾਂ ਵਜੋਂ ਲਿਖੋ (ਯੂਜ਼ਰ ਕੀ ਕਰਦਾ ਹੈ, UI ਕੀ ਕਰਦੀ ਹੈ) ਅਤੇ ਸ਼ਰਤਾਂ ਅਤੇ ਐਰਰ ਨੂੰ ਉਸੇ ਕਦਮ ਦੇ ਨਾਲ ਰੱਖੋ ਜੋ ਉਹ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ। ਇਸ ਨਾਲ ਸਪੈਸ ਪੜ੍ਹਨਯੋਗ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਗੈਪਸ ਤੇਜ਼ੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਰੂਟ ਅਤੇ ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਮਿਲੀ ਕੱਚੀ ਨੋਟਸ ਲਾਭਦਾਇਕ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਬਹਿਸ ਲਈ ਮੁਸ਼ਕਲ। ਜੋ ਤੁਸੀਂ ਅੰਬਦੀਖਾ ਹੈ ਉਹਨੂੰ ਇੱਕ ਐਸੇ ਸਪੈਸ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖੋ ਜਿਸਨੂੰ PM, ਡਿਜ਼ਾਈਨਰ, QA, ਅਤੇ ਇੰਜੀਨੀਅਰ ਸਭ ਪੜ੍ਹ ਕੇ ਸਹਿਮਤ ਹੋ ਸਕਣ।
ਇੱਕ ਪ੍ਰਯੋਗੀ ਪੈਟਰਨ ਹੈ ਹਰ ਰੂਟ ਜਾਂ ਸਕ੍ਰੀਨ ਲਈ ਇੱਕ ਯੂਜ਼ਰ ਸਟੋਰੀ। ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਨਿਰਧਾਰਤ ਰੱਖੋ। ਉਦਾਹਰਣ: "As a signed-in user, I can reset my password so I can regain access." ਜੇ ਕੋਡ ਰੋਲਾਂ ਅਨੁਸਾਰ ਵੱਖਰਾ ਬਿਹੈਵਿਯਰ ਦਿਖਾਉਂਦਾ ਹੈ (admin vs user), ਤਾਂ ਇਸਨੂੰ ਵੱਖਰੀਆਂ ਕਹਾਣੀਆਂ ਵਿੱਚ ਵੰਡੋ ਨਾ ਕਿ ਫੁੱਟਨੋਟਾਂ ਵਿੱਚ ਲੁਕਾਓ।
ਫਿਰ acceptance criteria ਲਿਖੋ ਜੋ ਅਸਲ ਕੋਡ ਪਾਥਾਂ ਦੀ ਨਕਲ ਕਰਦੇ ਹੋਣ, ਨਾ ਕਿ ਆਦਰਸ਼ ਉਤਪਾਦ। ਜੇ ਹੈਂਡਲਰ token ਗੁਆਚਣ 'ਤੇ 401 ਵਾਪਸ ਕਰਦਾ ਹੈ, ਇਹ ਇੱਕ ਮਾਪਦੰਡ ਹੈ। ਜੇ UI submit ਨੂੰ disable ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਫੀਲਡ valid ਨਹੀਂ, ਇਹ ਵੀ ਇੱਕ ਮਾਪਦੰਡ ਹੈ।
ਡੇਟਾ ਨਿਯਮ ਸਪੱਸ਼ਟ ਭਾਸ਼ਾ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰੋ, ਖਾਸ ਕਰਕੇ ਉਹ ਜਿਹੜੇ ਹੈਰਾਨੀ ਪੈਦਾ ਕਰਦੇ ਹਨ: ਸੀਮਾਵਾਂ, ਆਰਡਰਿੰਗ, uniqueness, ਲਾਜ਼ਮੀ ਫੀਲਡ। "Usernames must be unique (checked on save)" ਜਿਵੇਂ ਲਿਖਣਾ "unique index" ਨਾਲੋਂ ਵੱਧ ਸਪੱਸ਼ਟ ਹੈ।
ਏਜ ਕੇਸ ਅਕਸਰ ਇੱਕ ਚੰਗੀ ਡੌਕ ਤੇ ਇਕ ਉਪਯੋਗ ਡੌਕ ਵਿਚਕਾਰ ਫਰਕ ਬਣਾਉਂਦੇ ਹਨ। ਖਾਲੀ ਸਟੇਟ, null ਵੈਲਿਊਜ਼, ਰੀਟ੍ਰਾਈ, ਟਾਈਮਆਊਟ, ਅਤੇ API ਫੇਲ ਹੋਣ 'ਤੇ ਯੂਜ਼ਰ ਕੀ ਵੇਖਦਾ ਹੈ, ਇਹ ਸਭ ਦਰਜ ਕਰੋ।
ਜਦੋਂ ਤੁਸੀਂ ਅਣਜਾਣੀਆਂ ਤੇ ਪਹੁੰਚਦੇ ਹੋ, ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ—ਉਹਨਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰੋ:
ਇਹ ਚਿੰਨ੍ਹ ਛੋਟੀ ਟੀਮ ਪ੍ਰਸ਼ਨਾਂ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸਾਇਲੇਂਟ ਅਨੁਮਾਨਾਂ ਨਹੀਂ ਬਣਦੇ।
ਗੈਪਸ ਲਿਸਟ ਦੂਜਾ Jira ਨਹੀਂ ਹੈ। ਇਹ ਛੋਟਾ, ਪ੍ਰਮਾਣ-ਆਧਾਰਿਤ ਰਿਕਾਰਡ ਹੈ ਕਿ ਕਿੱਥੇ ਕੋਡ ਅਤੇ ਮਨੋਰਥਿਕ ਬਿਹੈਵਿਯਰ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਜਾਂ ਕਿੱਥੇ ਕਿਸੇ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਪਤਾ ਕਿ "ਸਹੀ" ਕੀ ਹੈ। ਵਧੀਆ ਤਰੀਕੇ ਨਾਲ ਕੀਤੀ ਗਈ ਗੈਪਸ ਲਿਸਟ ਸਹਿਮਤੀ ਦਾ ਉਪਕਰਨ ਬਣਦੀ ਹੈ, ਨ ਕਿ ਯੋਜਨਾ-ਲੜਾਈ।
ਜੋ ਗਲਾਂ ਗੈਪ ਮੰਨੋ:
ਜਦੋਂ ਤੁਸੀਂ ਗੈਪ ਲੌਗ ਕਰੋ, ਤਿੰਨ ਹਿੱਸੇ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਜੋ ਇਹ ਤਥਿ-ਆਧਾਰਿਤ ਰਹੇ:
Evidence ਗੈਪਸ ਲਿਸਟ ਨੂੰ ਰਾਇਆਂ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ। ਉਦਾਹਰਣ: "POST /checkout/apply-coupon expired coupons ਨੂੰ قبول ਕਰਦਾ ਹੈ, ਪਰ CouponBanner.tsx UI ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਬਲੌਕ ਕਰਦਾ ਹੈ। ਪ੍ਰਭਾਵ: ਰੇਵਨਿਊ ਅਤੇ ਯੂਜ਼ਰ ਉਲਝਣ। ਕਿਸਮ: bug ਜਾਂ missing decision (ਇਰਾਦਾ ਪੁਸ਼ਟੀ ਕਰੋ)।"
ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ। ਪਹਿਲੇ ਪਾਸ ਲਈ ਇੱਕ ਹਾਰਡ ਕੈਪ ਜਿਵੇਂ 10 ਆਈਟਮ ਲਗਾਓ। ਜੇ ਤੁਸੀਂ 40 ਮੁੱਦੇ ਲੱਭਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਪੈਟਰਨਾਂ ਵਿੱਚ ਗਰੁੱਪ ਕਰੋ (validation inconsistencies, permission checks, empty states) ਅਤੇ ਕੇਵਲ ਸਿਖਰਲੇ ਉਦਾਹਰਣ ਰੱਖੋ।
ਗੈਪਸ ਲਿਸਟ ਵਿੱਚ ਤਾਰੀਖਾਂ ਅਤੇ ਸ਼ੈਡਿਊਲਿੰਗ ਤੋਂ ਬਚੋ। ਜੇ ownership ਚਾਹੀਦੀ ਹੈ, ਲੇਕਿਨ ਕਠੋਰ ਨਾ ਹੋਵੋ: ਨੋਟ ਕਰੋ ਕਿ ਕੌਣ ਫੈਸਲਾ ਕਰ ਸਕਦਾ (product) ਜਾਂ ਕੌਣ verify ਕਰ ਸਕਦਾ (engineering), ਫਿਰ ਅਸਲੀ ਯੋਜਨਾ ਨੂੰ ਆਪਣੇ ਬੈਕਲੌਗ 'ਚ ਲੇ ਜਾਓ।
ਇੱਕ ਛੋਟੀ, ਵੱਧ-ਟਰੈਫਿਕ ਸਕੋਪ ਚੁਣੋ: promo codes ਅਤੇ shipping options ਨਾਲ checkout. ਮਕਸਦ ਪੂਰਾ ਉਤਪਾਦ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਨਹੀਂ, ਸਗੋਂ ਅੱਜ ਐਪ ਕੀ ਕਰਦੀ ਹੈ ਇਹ ਕੈਪਚਰ ਕਰਨਾ ਹੈ।
ਪਹਿਲਾਂ ਬੈਕਐਂਡ ਰੂਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਅਕਸਰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਦਿਖਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਰੂਟਾਂ ਵਰਗੀਆਂ ਲੱਭ ਸਕਦੇ ਹੋ POST /checkout/apply-promo, GET /checkout/shipping-options, ਅਤੇ POST /checkout/confirm.
ਉਹਨਾਂ ਹੈਂਡਲਰਾਂ ਤੋਂ ਬਿਹੈਵਿਯਰ ਸਧਾਰਨ ਬੋਲੀਆਂ ਵਿੱਚ ਲਿਖੋ:
ਫਿਰ UI ਕੰਪੋਨੈਂਟ ਚੈੱਕ ਕਰੋ। ਇੱਕ PromoCodeInput ਇਹ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ totals ਸਿਰਫ ਸਫਲ response ਤੋਂ ਬਾਅਦ ਤਾਜ਼ਾ ਹੁੰਦੇ ਹਨ ਅਤੇ errors ਇਨਪੁੱਟ ਹੇਠਾਂ ਰੇਂਡਰ ਹੁੰਦੇ ਹਨ। ਇੱਕ ShippingOptions ਕੰਪੋਨੈਂਟ ਪਹਿਲੀ ਲੋਡ 'ਤੇ ਸਸਤਾ ਵਿਕਲਪ auto-select ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਇਸਨੂੰ ਬਦਲਣ 'ਤੇ ਪੂਰਾ price breakdown refresh ਕਰਦਾ ਹੈ।
ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਪੜ੍ਹਨਯੋਗ ਸਪੈਸ ਅਤੇ ਇੱਕ ਛੋਟੀ ਗੈਪਸ ਲਿਸਟ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਣ ਲਈ: promo route ਅਤੇ UI ਵਿੱਚ error messages ਵੱਖ-ਵੱਖ ਹਨ ("Invalid code" vs "Not eligible"), ਅਤੇ ਕਿਸੇ ਕੋਲ tax rounding ਨਿਯਮ (per line vs order total) ਦੀ ਸਪੱਸ਼ਟ ਜਾਣਕਾਰੀ ਨਹੀਂ।
ਯੋਜਨਾ ਬਨਾਉਂਦੇ ਸਮੇਂ, ਟੀਮ ਪਹਿਲਾਂ ਹਕੀਕਤ 'ਤੇ ਸਹਿਮਤ ਹੋ ਜਾਂਦੀ ਹੈ, ਫਿਰ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਬਦਲਣਾ ਹੈ। ਰਾਇਆਂ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਬਿਹੈਵਿਯਰ ਰਿਵੀਊ ਕਰੋ, ਇੱਕ ਅਸੰਗਤਤਾ ਚੁਣੋ ਜਿਸ ਨੂੰ ਠੀਕ ਕਰਨਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਗੱਲਾਂ ਨੂੰ "ਮੌਜੂਦਾ ਜਾਣੀ ਅਸਥਿਤੀ" ਵਜੋਂ ਛੱਡ ਦਿਓ ਜਦ ਤੱਕ ਉਹ ਮੁੜ-ਜਾਂਚ ਕਰਨ ਯੋਗ ਨਾ ਹੋਣ।
ਸਪੈਸ ਉਸ ਸਮੇਂ ਹੀ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟੀਮ ਸਹਿਮਤ ਕਰੇ ਕਿ ਇਹ ਹਕੀਕਤ ਨਾਲ ਮਿਲਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਰੀਡ-ਥਰੂ ਕਰੋ ਇੱਕ ਇੰਜੀਨੀਅਰ ਅਤੇ ਇੱਕ ਪ੍ਰੋਡਕਟ ਵਿਅਕਤੀ ਨਾਲ। ਇਸਨੂੰ ਤੰਗ ਰੱਖੋ: 20-30 ਮਿੰਟ ਕੇਂਦਰਿਤ ਸੈਸ਼ਨ ਜੋ ਯੂਜ਼ਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਕੀ ਕਰਦਾ ਹੈ 'ਤੇ ਧਿਆਨ ਦਿੰਦਾ ਹੈ।
ਰੀਡ-ਥਰੂ ਦੌਰਾਨ, ਬਿਆਨਾਂ ਨੂੰ ਹਾਂ/ਨਹੀਂ ਸਵਾਲਾਂ ਵਿੱਚ ਬਦਲ ਦਿਓ। "ਜਦੋਂ ਯੂਜ਼ਰ ਇਸ ਰੂਟ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ, ਕੀ ਅਸੀਂ ਹਮੇਸ਼ਾ session ਨਾ ਹੋਣ 'ਤੇ 403 ਵਾਪਸ ਕਰਦੇ ਹਾਂ?" "ਕੀ ਇਹ ਖਾਲੀ ਸਟੇਟ ਮਨਭਾਵਨ ਹੈ?" ਇਹ ਇਰਾਦਾ ਅਤੇ ਅੱਚਾਨਕ ਆਏ ਬਿਹੈਵਿਯਰ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ।
ਸੰਪਾਦਨ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ਬਦਾਵਲੀ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ। UI ਵਿੱਚ ਦਿੱਤੇ ਗਏ ਸ਼ਬਦ ਵਰਤੋਂ (ਬਟਨ ਲੇਬਲ, ਪੇਜ ਟਾਈਟਲ, ਐਰਰ ਸਨੇਪਸ਼ੱਟ) ਤਾਂ ਜੋ ਹਰ ਕੋਈ ਇੱਕੋ ਗੱਲ ਦਾ ਅਰਥ ਲਵੇ। ਆੰਤਰੀਕ ਨਾਮਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਸ਼ਾਮਿਲ ਕਰੋ ਜਦੋਂ ਉਹ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਕੋਡ ਲੱਭਣ ਵਿੱਚ ਸਹਾਇਕ ਹੋਣ (ਰੂਟ ਨਾਂ, ਕੰਪੋਨੈਂਟ ਨਾਂ)। ਇਸ ਨਾਲ mismatches ਜਿਵੇਂ product "Workspace" ਕਹਿੰਦਾ ਹੈ ਪਰ ਸਪੈਸ "Org" ਲਿਖਦਾ ਹੈ, ਰੁਕਦੇ ਹਨ।
ਇਸਨੂੰ ਤਾਜ਼ਾ ਰੱਖਣ ਲਈ ownership ਅਤੇ cadence ਸਪੱਸ਼ਟ ਕਰੋ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗਾ ਟੂਲ ਵਰਤ ਰਹੇ ਹੋ, ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ ਤੁਹਾਨੂੰ "ਪਹਿਲਾਂ" ਅਤੇ "ਬਾਅਦ" ਬਿਹੈਵਿਯਰ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਵੱਡੇ ਰੀਫੈਕਟਰ ਤੋਂ ਬਾਅਦ।
ਸਪੈਸ ਦਾ ਭਰੋਸਾ ਤੁਰੰਤ ਖੋਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਉਤਪਾਦ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਵਰਣਨ ਕਰੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਉਹ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ। ਇੱਕ ਕਠੋਰ ਨਿਯਮ ਰੱਖੋ: ਹਰ ਬਿਆਨ ਦਾ ਸਬੂਤ ਹੋਵੇ ਜੋ ਤੁਸੀਂ ਕੋਡ ਜਾਂ ਅਸਲ ਸਕ੍ਰੀਨ ਵਿੱਚ ਦਿਖਾ ਸਕੋ।
ਹੋਰ ਇੱਕ ਫੰਦਾ ਹੈ ਕੋਡ ਦੀ ਸ਼ਕਲ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਨਕਲ ਕਰਨਾ। "Controller -> Service -> Repository" ਵਾਂਗ ਇੱਕ ਸਪੈਸ ਨਹੀਂ ਹੁੰਦੀ, ਇਹ ਫੋਲਡਰ ਨਕਸ਼ਾ ਹੈ। ਯੂਜ਼ਰ-ਮੁਖੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ: ਕਾਰਵਾਈ ਕੀ ਛੇਤੀ ਕਰਦੀ ਹੈ, ਯੂਜ਼ਰ ਕੀ ਵੇਖਦਾ ਹੈ, ਕੀ ਸੇਵ ਹੁੰਦੀ ਹੈ, ਅਤੇ errors ਕਿਵੇਂ ਦਿਖਦੇ ਹਨ।
ਪਰਮੇਸ਼ਨ ਅਤੇ ਰੋਲ ਆਮ ਤੌਰ 'ਤੇ ਅੰਤ ਵਿੱਚ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਫਿਰ ਸਭ ਕੁਝ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਪਹੁੰਚ ਨਿਯਮ ਸ਼ੁਰੂ ਤੋਂ ਸ਼ਾਮਿਲ ਕਰੋ, ਭਾਵੇਂ ਉਹ ਗੁੰਝਲਦਾਰ ਹੋਣ। ਦਰਜ ਕਰੋ ਕਿ ਕਿਹੜੇ ਰੋਲ ਦੇਖ ਸਕਦੇ/ਬਣਾ ਸਕਦੇ/ਸੰਪਾਦਿਤ ਕਰ ਸਕਦੇ/ਹਟਾ ਸਕਦੇ/ਮਨਜ਼ੂਰ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿੱਥੇ ਨਿਯਮ lagu ਹੁੰਦਾ ਹੈ (UI only, API only, ਜਾਂ ਦੋਹਾਂ)।
ਨਾਨ-ਹੈਪੀ ਪਾਥ ਨੂੰ ਨਾ ਛੱਡੋ। ਅਸਲ ਬਿਹੈਵਿਯਰ retries, partial failures, ਅਤੇ ਸਮੇਂ-ਆਧਾਰਿਤ ਨਿਯਮਾਂ (expirations, cooldowns, scheduled jobs, "only once per day" limits) ਵਿੱਚ ਲੁਕਿਆ ਹੁੰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲੀ-ਕਿਸਮ ਦੀ ਬਿਹੈवਿਯਰ ਵਜੋਂ ਵਰਤੋਂ।
ਗੈਪਸ surface ਕਰਨ ਦਾ ਇੱਕ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਚੈੱਕ ਕਰਨਾ ਹੈ:
ਅਖ਼ੀਰ ਵਿੱਚ, ਆਪਣੀ ਗੈਪਸ ਲਿਸਟ ਨੂੰ ਚਲਦ-ਫਿਰਦ ਰੱਖੋ। ਹਰ ਗੈਪ ਨੂੰ ਇੱਕ ਵਿਚਕਾਰਦੀ ਟੈਗ ਦਿਓ: "unknown, needs decision," "bug, fix," ਜਾਂ "missing feature, plan." ਜੇ ਕੁਝ ਲੇਬਲ ਨਹੀਂ ਹੁੰਦੇ ਤਾਂ ਲਿਸਟ ਰੁਕੀ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਸਪੈਸ ਫਿਰੋਂ ਭਟਕ ਜਾਂਦੀ ਹੈ।
ਸਪੈਸ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਤੇਜ਼ ਪਾਸ ਕਰੋ: ਸਪਸ਼ਟਤਾ, ਕਵਰਜ, ਅਤੇ ਕਾਰਵਾਈਯੋਗਤਾ। ਜਿਸ ਵਿਅਕਤੀ ਨੇ ਇਹ ਨਹੀਂ ਲਿਖੀ ਉਹਾਂ ਨੂੰ ਸਮਝ ਆਉਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਫੀਚਰ ਅੱਜ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਅਜੇ ਅਸਪਸ਼ਟ ਹੈ।
ਨਵੇਂ ਸਾਥੀ ਦੇ ਦਿਨ ਇੱਕ ਵਜੋਂ ਸਪੈਸ ਪੜ੍ਹੋ। ਜੇ ਉਹ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਫੀਚਰ ਦਾ ਸਾਰ ਨਿਕਾਲ ਸਕੇ, ਤਾਂ ਤੁਸੀਂ ਕਰੀਬ ਹੋ। ਜੇ ਉਹ ਸਵਾਲ ਪੁੱਛਦੇ ਰਹਿਣ "ਇਹ ਕਿੱਥੇ start ਹੁੰਦਾ ਹੈ?" ਜਾਂ "happy path ਕੀ ਹੈ?" ਤਾਂ ਮੁਖਭਾਗ ਤੰਗ ਕਰੋ।
ਚੈੱਕ ਕਰੋ:
ਹਰ ਗੈਪ ਵਿਸ਼ੇਸ਼ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। "Error handling unclear" ਦੀ ਬਜਾਏ, ਲਿਖੋ: "If payment provider returns 402, UI shows a generic toast; confirm desired message and retry behavior." ਇੱਕ ਇਕੱਲੀ ਅਗਲੀ ਕਾਰਵਾਈ ਜੋੜੋ (product ਤੋਂ ਪੁڇੋ, ਇੱਕ ਟੈਸਟ ਜੋੜੋ, ਲਾਗ ਇੰਸਪੈਕਟ ਕਰੋ) ਅਤੇ ਜੋ ਇਸਨੂੰ ਉੱਤਰ ਦੇ ਸਕਦਾ ਉਹ ਨੋਟ ਕਰੋ।
ਇੱਕ ਫੀਚਰ ਏਰੀਆ ਚੁਣੋ ਅਤੇ 60 ਮਿੰਟ ਲਈ ਸਮਾਂ ਸੀਮਿਤ ਕਰੋ। ਕੁਝ ਛੋਟਾ ਪਰ ਅਸਲ ਚੁਣੋ (login, checkout, search, ਇੱਕ admin ਸਕ੍ਰੀਨ)। ਇੱਕ ਵਾਕ ਦੀ ਸਕੋਪ ਲਿਖੋ: ਕੀ ਸ਼ਾਮਿਲ ਹੈ ਅਤੇ ਕੀ ਬਾਹਰ ਹੈ।
ਵਰਕਫਲੋ ਇੱਕ ਵਾਰੀ end-to-end ਚਲਾਓ: ਮੁੱਖ routes/handlers ਸਖ਼ਤੀ ਨਾਲ ਵੇਖੋ, ਮੁੱਖ UI ਫਲੋ ਠਹਿਰਾਓ, ਅਤੇ ਨਿਰੀਖਣਯੋਗ ਬਿਹੈਵਿਯਰ ਲਿਖੋ (inputs, outputs, validation, error states)। ਜੇ ਅਪਸੀ ਰੁਕਾਵਟ ਆਏ ਤਾਂ ਗੈਪ ਵਜੋਂ ਲਿਖੋ ਅਤੇ ਅੱਗੇ ਵਧੋ।
ਜਦੋਂ ਤਿਆਰ ਹੋ ਜਾਓ, ਸਪੈਸ ਟੀਮ ਦੇ ਸਾਹਮਣੇ ਸਾਂਝਾ ਕਰੋ ਅਤੇ ਇਕ ਨਿਯਮ ਰੱਖੋ: ਕੋਈ ਵੀ ਸ਼ਿਪ ਕੀਤੀ ਬਿਹੈਵਿਯਰ ਚੇਨਜ ਸਪੈਸ ਨੂੰ ਉਸੇ ਡਿਲਿਵਰੀ ਵਿੰਡੋ ਵਿੱਚ ਅਪਡੇਟ ਕਰੇ, ਭਾਵੇਂ ਉਹ ਪੰਜ ਲਾਈਨਾਂ ਹੋਣ।
ਗੈਪਸ ਨੂੰ ਬੈਕਲੌਗ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ। ਉਹਨਾਂ ਨੂੰ "unknown behavior," "inconsistent behavior," ਅਤੇ "missing tests" ਵਿਚ ਗਰੁੱਪ ਕਰੋ, ਫਿਰ ਹਰ ਹਫਤੇ ਛੋਟੀ ਸਮੀਖਿਆ ਕਰਕੇ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਹੁਣ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਜੇ ਡਰੈਫਟ ਅਤੇ ਇਟਰੇਸ਼ਨ ਧੀਮੀ ਲੱਗੇ, ਤਾਂ Koder.ai ਵਰਗਾ ਚੈਟ-ਆਧਾਰਿਤ ਬਿਲਡਰ ਤੁਹਾਨੂੰ ਪਹਿਲੀ ਵਰਜਨ ਤੇਜ਼ੀ ਨਾਲ ਲਿਆਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਫੀਚਰ ਦਾ ਵੇਰਵਾ ਦਿਓ, ਮੁੱਖ ਸਨਿੱਪੇਟ ਜਾਂ ਰੂਟ ਪੇਸਟ ਕਰੋ, ਬੋਲਚਾਲ ਵਿੱਚ ਸ਼ਬਦ ਸੁਧਾਰੋ, ਅਤੇ ਜਦੋਂ ਲੋੜ ਹੋਵੇ source export ਕਰੋ। ਮਕਸਦ ਤੇਜ਼ੀ ਅਤੇ ਸਾਂਝੀ ਸਪਸ਼ਟਤਾ ਹੈ, ਵੱਡੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ।
ਇੱਕ ਛੋਟੇ, ਯੂਜ਼ਰ-ਦਿੱਖਣਯੋਗ ਸਲਾਇਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ, “password reset” ਜਾਂ “invite a teammate”)। routes/handlers ਦਿਖੋ ਤਾਂ ਜੋ ਨਿਯਮ ਅਤੇ ਨਤੀਜੇ ਕੈਪਚਰ ਹੋ ਜਾਣ, ਫਿਰ UI ਫਲੋ ਪੜ੍ਹੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਕੀ ਵੇਖਦੇ ਹਨ (disable ਹੋਏ states, errors, redirects)। ਇੱਕ ਮੁਸੱਁਲ ਟੈਂਪਲੇਟ ਵਰਤ ਕੇ ਲਿਖੋ ਅਤੇ ਅਣਜਾਣੀਆਂ ਗੱਲਾਂ ਨੂੰ ਵੱਖਰੇ gaps ਲਿਸਟ ਵਿੱਚ ਲਿਖੋ।
ਮੂਲ ਨੀਤੀ: ਮੌਜੂਦਾ ਕੋਡ ਬਿਹੈਵਿਯਰ ਨੂੰ ਸੱਚਾਈ ਸੋਤਰ ਮੰਨੋ ਅਤੇ ਇਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ。
ਜੇ ਕਿਸੇ ਬਿਹੈਵਿਯਰ ਨੂੰ ਅਚਾਨਕ ਜਾਂ inconsistent ਲੱਗਦਾ ਹੈ, ਸਪੈਸ ਵਿੱਚ ਉਸਨੂੰ “ਠੀਕ” ਨਾ ਬਣਾਉ—ਬਲਕਿ ਪ੍ਰਮਾਣ ਨਾਲ ਇੱਕ gap ਦਰਜ ਕਰੋ (ਕਿੱਥੇ ਵੇਖਿਆ ਅਤੇ ਕੀ ਹੁੰਦਾ ਹੈ), ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੋਡ ਜਾਂ ਸਪੈਸ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਹੈ।
ਸਧਾਰਨ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਫਾਰਮੈਟ ਨੂੰ ਰੱਖੋ। ਇੱਕ ਪ੍ਰਯੋਗੀ ਟੈਂਪਲੇਟ:
ਇਸ ਤਰ੍ਹਾਂ ਸਪੈਸ ਪੜ੍ਹਨ ਯੋਗ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਅਸਮਾਨਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ।
ਨਿਯਮਾਂ ਨੂੰ ਉਪਭੋਗਤਾ-ਮੁਖੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖੋ, ਨਾ ਕਿ ਕੋਡ-ਨੋਟਾਂ ਦੇ ਤੌਰ ਤੇ。
Examples:
ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਕਿ ਕੀ ਗਲਤੀ ਟ੍ਰਿਗਰ ਹੁੰਦੀ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਦਿੱਖਦਾ ਹੈ।
ਜੋ ਕੁਝ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ ਓਹਥੇ ਧਿਆਨ ਦਿਓ:
ਸਾਈਡ ਇਫੈਕਟਸ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਉਹ ਹੋਰ ਫੀਚਰਾਂ ਅਤੇ ਸਪਰਟ/ਓਪਸ ਉਮੀਦਾਂ 'ਤੇ ਅਸਰ ਕਰਦੇ ਹਨ।
ਜੇ UI ਅਤੇ ਬੈਕਐਂਡ ਅਲੱਗ ਅਲੱਗ ਕੰਮ ਕਰ ਰਹੇ ਹਨ (ਜਿਵੇਂ ਫਾਈਲ ਸਾਈਜ਼ ਸੀਮਾਵਾਂ), ਤਾਂ ਉਸਨੂੰ ਇੱਕ gap ਵਜੋਂ ਦਰਜ ਕਰੋ ਜਦ ਤੱਕ ਫੈਸਲਾ ਨਹੀਂ ਹੁੰਦਾ।
ਲਿਖੋ:
ਫਿਰ ਇੱਕ ਨਿਯਮ 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ ਅਤੇ ਦੋਹਾਂ ਨੂੰ ਕੋਡ ਅਤੇ ਸਪੈਸ 'ਚ ਅਪਡੇਟ ਕਰੋ।
ਗੈਪ ਲਿਸਟ ਨੂੰ ਛੋਟਾ ਅਤੇ ਪ੍ਰਮਾਣ-ਆਧਾਰਿਤ ਰੱਖੋ। ਹਰ ਆਈਟਮ ਵਿੱਚ:
ਸ਼ੈਡਿਊਲਿੰਗ ਤੋਂ ਬਚੋ ਅਤੇ ਇਸਨੂੰ ਦੂਜੇ ਜਿਰਾ ਜੇਵਾਂ ਬੈਕਲੌਗ ਵਿੱਚ ਨਾ ਬਦਲੋ।
ਇਹਨਾਂ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਦਰਜ ਕਰੋ:
ਇਹ ਆਮ ਤੌਰ ‘ਤੇ ਅਫਸੋਸ ਅਤੇ ਬੱਗ ਦਾ ਸੋਰਸ ਹੁੰਦੇ ਹਨ।
ਛੋਟੀ ਰੀਡ-ਥਰੂ: ਇੱਕ ਇੰਜੀਨੀਅਰ ਅਤੇ ਇੱਕ ਪ੍ਰੋਡਕਟ ਪੇਰਸਨ ਨਾਲ 20–30 ਮਿੰਟ।
ਬਿਆਨਾਂ ਨੂੰ ਹਾਂ/ਨਹੀਂ ਸਵਾਲਾਂ ਵਿੱਚ ਬਦਲ ਦਿਓ (ਜਿਵੇਂ “ਕੀ ਅਸੀਂ ਹਮੇਸ਼ਾ 403 ਰਿਟਰਨ ਕਰਦੇ ਹਾਂ ਜਦੋਂ session ਨਹੀਂ ਹੁੰਦੀ?”) ਅਤੇ UI ਦੇ ਲੇਬਲ ਵਰਤੇ ਜਾਵਨ ਤਾਂ ਸਬ ਦਾ ਸਮਝ ਇੱਕੋ ਜਿਹੀ ਰਹੇ।
ਸਪੈਸ ਨੂੰ ਕੋਡ ਦੇ ਨੇੜੇ ਰੱਖੋ ਅਤੇ ਸ਼ਿਪਿੰਗ ਦਾ ਹਿੱਸਾ ਬਣਾਓ।
ਪ੍ਰੈਕਟਿਕਲ ਨੀਤੀਆਂ:
ਮਕਸਦ: ਵੱਡੇ ਰੀਵਰਾਈਟ ਨਹੀਂ, ਛੋਟੇ ਤੇ ਆਮ ਅਪਡੇਟ।