Claude Code ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰੋ

ਰੀਅਲ ਕੋਡ ਵਿੱਚ React ਰੀਫੈਕਟਰਾਂ ਨੂੰ ਖਤਰਨਾਕ ਕਿੱਤੇ ਬਣਾਉਂਦਾ ਕੀ ਹੈ

React ਰੀਫੈਕਟਰ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਕੰਪੋਨੈਂਟ ਛੋਟੇ, ਸਾਫ਼ ਬਿਲਡਿੰਗ ਬਲਾਕ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ UI, state, effects ਅਤੇ “ਹੋਰ ਇੱਕ prop” ਵਾਲੀਆਂ ਠੀਕਸ ਨੁਕਤਿਆਂ ਦਾ ਜਿਹੜਾ ਜੀਵਤ ਗੜਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਢਾਂਚਾ ਬਦਲਦੇ ਹੋ, ਅਕਸਰ ਤੁਸੀਂ ਬਿਨਾਂ ਮਨਸੂਬੇ ਦੇ ਟਾਈਮਿੰਗ, ਪਛਾਣ ਜਾਂ ਡੇਟਾ ਫਲੋ ਬਦਲ ਦਿੰਦੇ ਹੋ।

ਰੀਫੈਕਟਰ ਵਹਿਵਾਹਿਕਤਾ ਨੂੰ ਅਕਸਰ ਤਦ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਇਹ ਅਜਿਹੇ ਤਰੀਕਿਆਂ ਨਾਲ ਐਕਸੀਡੈਂਟਲ ਹੁੰਦਾ ਹੈ:

• state ਰੀਸੈਟ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਕਮਪੋਨੈਂਟ ਬਾਊਂਡਰੀ ਹਲੀ ਜਾਂ key ਬਦਲ ਗਿਆ।
• effects ਦਾ ਚੱਲਣ ਦਾ ਸਮਾਂ ਬਦਲ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਡੀਪੈਂਡੈਂਸੀਸ਼ਿਪਸ ਜਾਂ ਮਾਊਂਟ/ਅਨਮਾਊਂਟ ਬਦਲ ਗਈ।
• memoization ਟੁੱਟ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਹੈਂਡਲਰ ਅਤੇ ਡੈਰਾਈਵਡ ਵੇਲਯੂ ਹਰ render 'ਤੇ ਬਦਲ ਜਾਂਦੇ ਹਨ।
• ਇਵੈਂਟ ਹੈਂਡਲਿੰਗ (focus, blur, keyboard, pointer) ਸਥਿਤੀ ਬਦਲ ਸਕਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ markup ਨੂੰ ਰੈਪ ਜਾਂ ਸਪਲਿਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• fetching ਜਾਂ subscriptions ਡੁਪਲੀਕੇਟ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਲੌਜਿਕ ਨੂੰ centralized ਕਰਨ ਦੀ ਥਾਂ ਨਕਲ ਕੀਤਾ ਗਿਆ।

ਰੀਫੈਕਟਰ rewrite ਵਿੱਚ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ ਜਦੋਂ “ਸਾਫ਼-ਸੁਥਰਾ” ਅਤੇ “ਸੁਧਾਰ” ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਸੀਂ ਇਕ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕਸਟਰੈਕਟ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਫਿਰ ਕਈ ਚੀਜ਼ਾਂ rename ਕਰਦੇ ਹੋ, ਫਿਰ state shape “ਸਹੀ” ਕਰਦੇ ਹੋ, ਫਿਰ ਇੱਕ hook ਬਦਲ ਦਿੰਦੇ ਹੋ। ਜਲਦੀ ਹੀ ਤੁਸੀਂ ਲੌਜਿਕ ਅਤੇ ਲੇਆਉਟ ਦੋਹਾਂ ਬਦਲ ਰਹੇ ਹੋ। ਬਿਨਾਂ ਗਾਰਡਰੇਲਸ ਦੇ, ਪਤਾ ਲੱਗਣਾ ਔਖਾ ਹੁੰਦਾ ਕਿ ਕਿਹੜੇ ਬਦਲਾਅ ਕਾਰਨ bug ਆਇਆ।

ਇੱਕ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਦੀ ਇੱਕ ਸਧਾਰਣ ਵਾਅਦਾ ਹੁੰਦਾ ਹੈ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਉਹੀ ਬਰਤਾਓ ਮਿਲੇ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਸਾਫ਼ ਕੋਡ ਬਚੇ। Props, events, loading states, error states ਅਤੇ ਏਡਜ ਕੇਸਾਂ ਨੂੰ ਉਹੀ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਬਰਤਾਓ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਜਾਣਬੂਝ ਕੇ, ਛੋਟਾ ਅਤੇ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ Claude Code (ਜਾਂ ਕੋਈ ਵੀ ਕੋਡ ਸਹਾਇਕ) ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਤੇਜ਼ pair programmer ਵਾਂਗ ਲਓ, autopilot ਨਹੀਂ। ਇਸਨੂੰ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਖਤਰੇ ਵਰਣਨ ਕਰਨ ਲਈ ਕਹੋ, ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਕਦਮਾਂ ਨਾਲ ਯੋਜਨਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ ਅਤੇ ਦੱਸੋ ਕਿ ਇਸਨੇ ਬਰਤਾਓ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਰੱਖਣ ਲਈ ਕਿਵੇਂ ਚੈੱਕ ਕੀਤਾ। ਫਿਰ ਖੁਦ ਵੈਲਿਡੇਟ ਕਰੋ: ਐਪ ਚਲਾਓ, ਅਜੀਬ ਰਾਹਾਂ 'ਤੇ ਕਲਿੱਕ ਕਰੋ, ਅਤੇ ਉਹਨਾਂ ਟੈਸਟਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰੋ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਕੰਪੋਨੈਂਟ ਅੱਜ ਕੀ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਉਹ ਕੀ ਕਰੇ।

ਲਕੜੀ (ਟਾਰਗਟ) ਚੁਣੋ ਅਤੇ ਸਪਸ਼ਟ ਰੀਫੈਕਟਰ ਲਕੜੀ ਸੈੱਟ ਕਰੋ

ਉਹ ਇਕ ਕੰਪੋਨੈਂਟ ਚੁਣੋ ਜੋ ਤੁਹਾਨੂੰ ਸਮਾਂ ਖਰਚ ਕਰਾਉਂਦਾ ਹੈ। ਨਾ ਪੂਰਾ ਪੇਜ, ਨਾ "UI ਲੇਅਰ", ਅਤੇ ਨਾ ਹੀ ਧੁੰਦਲਾ "ਸਾਫ਼-ਸੁਥਰਾ"। ਇੱਕ ਇਕੱਲਾ ਕੰਪੋਨੈਂਟ ਚੁਣੋ ਜੋ ਪੜ੍ਹਨ ਵਿੱਚ ਮੁਸ਼ਕਲ, ਬਦਲਣ ਵਿੱਚ ਮੁਸ਼ਕਲ, ਜਾਂ state ਅਤੇ side effects ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਹੋਵੇ। ਇਕ ਟਾਈਟ ਟਾਰਗਟ ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਸਹਾਇਕ ਦੀਆਂ ਸੁਝਾਵਾਂ ਦੇਖਣ ਅਤੇ ਸਰੋਟ ਕਰਨ 'ਚ ਆਸਾਨੀ ਹੁੰਦੀ ਹੈ।

ਇੱਕ ਟੀਚਾ ਲਿਖੋ ਜਿਸਨੂੰ ਪੰਜ ਮਿੰਟ ਵਿੱਚ ਚੈੱਕ ਕੀਤਾ ਜਾ ਸਕੇ। ਚੰਗੇ ਟੀਚੇ ਸਟ੍ਰਕਚਰ ਬਾਰੇ ਹੁੰਦੇ ਹਨ, ਨਤੀਜਿਆਂ ਬਾਰੇ ਨਹੀਂ: “ਛੋਟੀ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਵੰਡੋ”, “state ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਓ”, ਜਾਂ “ਟੈਸਟੇਬਲ ਬਣਾਓ ਬਿਨਾਂ ਐਪ ਦਾ ਅਧਾ ਮੌਕ ਕਰਨ ਦੇ”। "ਇਸਨੂੰ ਬਿਹਤਰ ਬਣਾਓ" ਜਾਂ "ਪਰਫ਼ਾਰਮੈਂਸ ਸੁਧਾਰੋ" ਵਰਗੇ ਟੀਚਿਆਂ ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਮੈਟਰਿਕ ਅਤੇ ਜਾਣਿਆ ਹੋਇਆ ਬੋਤਲ-ਨੇਕ ਨਾ ਹੋਵੇ।

ਇਡੀਟਰ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਹੱਦੇ ਸੈੱਟ ਕਰੋ। ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰੀਫੈਕਟਰ ਬੋਰਿੰਗ ਹੁੰਦੇ ਹਨ:

• ਕੋਈ ਵਿਜ਼ੂਅਲ ਬਦਲਾਅ ਨਹੀਂ (ਉਹੀ ਲੇਆਉਟ, ਉਹੀ ਕਾਪੀ, ਉਹੀ spacing)।
• ਕੋਈ ਨਵੀਂ ਫੀਚਰ ਨਹੀਂ।
• ਉਹੀ ਬਾਹਰੀ ਬਰਤਾਓ (props ਆਉਣ, UI ਅਤੇ callbacks ਬਾਹਰ ਜਾਣ)।
• ਇੱਕ ਵਾਰੀ ਵਿੱਚ ਇੱਕ ਕੰਪੋਨੈਂਟ (ਇੱਕ ਨੂੰ ਪੂਰਾ ਕਰੋ ਫਿਰ ਦੂਜੇ ਉਤੇ ਜਾਓ)।

ਫਿਰ ਉਹ ਡੀਪੈਂਡੈਂਸੀਜ਼ ਲਿਸਟ ਕਰੋ ਜਿਹੜੀਆਂ ਕੋਡ ਹਿਲਾਉਣ ਵੇਲੇ ਖਾਮੋਸ਼ੀ ਨਾਲ ਬਰਤਾਓ ਤੋੜ ਸਕਦੀਆਂ ਹਨ: API calls, context providers, routing params, feature flags, analytics events ਅਤੇ ਸਾਂਝਾ ਗਲੋਬਲ state।

ਇੱਕ ਠੋਸ ਉਦਾਹਰਣ: ਤੁਹਾਡੇ ਕੋਲ 600-line OrdersTable ਹੈ ਜੋ ਡੇਟਾ ਫੈਚ ਕਰਦਾ, ਫਿਲਟਰ ਕਰਦਾ, ਸਿਲੈਕਸ਼ਨ ਨੂੰ ਮੈਨੇਜ ਕਰਦਾ ਅਤੇ ਡੀਟੇਲ ਲਈ ਇੱਕ ਡ੍ਰਾਅਰ dikhaunda। ਇਕ ਸਪਸ਼ਟ ਲਕੜੀ ਹੋ ਸਕਦੀ ਹੈ: "row rendering ਅਤੇ drawer UI ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਕੱਢੋ, ਅਤੇ selection state ਨੂੰ ਇੱਕ reducer ਵਿੱਚ ਲਿਆਓ, ਬਿਨਾਂ UI ਬਦਲਾਅ ਦੇ।" ਇਹ ਲਕੜੀ ਦੱਸਦੀ ਹੈ ਕਿ "done" ਦਿਖਣ 'ਤੇ ਕੀ ਹੋਵੇਗਾ ਅਤੇ ਕੀ scope ਤੋਂ ਬਾਹਰ ਹੈ।

ਕੋਡ ਨੂੰ ਛੁਹਣ ਤੋਂ ਪਹਿਲਾਂ ਬਰਤਾਓ ਨੂੰ ਫ੍ਰੀਜ਼ ਕਰੋ

ਰੀਫੈਕਟਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਕੰਪੋਨੈਂਟ ਨੂੰ ਕਾਲਾ ਬਾਕਸ ਸਮਝੋ। ਤੁਹਾਡੀ ਨੌਕਰੀ ਅੱਜ ਜੋ ਕਰਦਾ ਉਹ.capture ਕਰਨ ਦੀ ਹੈ, ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਕਰੇ। ਇਸ ਨਾਲ ਰੀਫੈਕਟਰ redesign ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ।

ਸ਼ੁਰੂਆਤ ਕਰੋ ਮੌਜੂਦਾ ਬਰਤਾਓ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖ ਕੇ: ਇਹ ਇਨਪੁਟ ਦਿੱਤੇ ਜਾਣ 'ਤੇ UI ਇਹ ਨਤੀਜਾ ਦਿਖਾਉਂਦਾ। Props, URL params, feature flags ਅਤੇ context/ਸਟੋਰ ਤੋਂ ਆਉਣ ਵਾਲੇ ਡੇਟਾ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਤੁਸੀਂ Claude Code ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟਾ, ਫੋਕਸ ਕੀਤਾ snippet ਪੇਸਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਆਖਣ ਲਈ ਕਹੋ ਕਿ ਇਹ ਪਹਿਨੇ ਵਾਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਵਰਨਨ ਕਰੇ ਜਿਹੜੀਆਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਚੈੱਕ ਕਰ ਸਕੋ।

ਉਹ UI ਹਾਲਤਾਂ ਕਵਰ ਕਰੋ ਜੋ ਲੋਕ ਅਸਲ ਵਿੱਚ ਵੇਖਦੇ ਹਨ। ਇੱਕ ਕੰਪੋਨੈਂਟ ਖੁਸ਼-ਰਾਹ 'ਤੇ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਲੋਡਿੰਗ, empty ਜਾਂ error ਦੇ ਸਮੇਂ ਟੁੱਟ ਸਕਦਾ ਹੈ।

ਉਹ ਇੰਪਲਿਸਿਟ ਨਿਯਮ ਵੀ ਕੈਪਚਰ ਕਰੋ ਜੋ ਆਸਾਨੀ ਨਾਲ ਲੁਕ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਰੀਫੈਕਟਰ ਨੂੰ ਤੋੜਦੇ ਹਨ:

• ਡਿਫਾਲਟ ਚੋਣਾਂ (ਚੁਣਿਆ ਹੋਇਆ ਟੈਬ, ਡਿਫਾਲਟ ਸੋਰਟ ਕਾਲਮ, ਸ਼ੁਰੂਆਤੀ ਫਿਲਟਰ)
• ਫਾਰਮੈਟਿੰਗ ਨਿਯਮ (ਤਾਰਿੱਖ, ਕਰੰਸੀ, truncation, capitalization)
• ਆਰਡਰਿੰਗ ਨਿਯਮ (ਸਥਿਰ ਸੌਰਟ, ਗਰੁੱਪਿੰਗ, pinned items)
• ਇੰਟਰੈਕਸ਼ਨ ਨਿਯਮ (ਕਿਸ ਚੀਜ਼ ਨਾਲ ਕੀ ਰੀਸੈਟ ਹੁੰਦਾ ਹੈ, ਕੀ ਫੋਕਸ ਰੱਖਦਾ ਹੈ)
• ਐਡਜ ਕੇਸ ਜਿਨ੍ਹਾਂ 'ਤੇ ਯੂਜ਼ਰ ਨਿਰਭਰ ਕਰਦੇ ਹਨ (empty strings vs null, zero values, partial data)

ਉਦਾਹਰਣ: ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਯੂਜ਼ਰ ਟੇਬਲ ਹੈ ਜੋ ਨਤੀਜੇ ਲੋਡ ਕਰਦੀ, ਸਰਚ ਦਾ ਸਹਾਰਾ ਦਿੰਦੀ, ਅਤੇ "Last active" ਅਨੁਸਾਰ ਸੋਰਟ ਕਰਦੀ। ਲਿਖੋ ਕਿ ਜਦੋਂ search ਖਾਲੀ ਹੋਵੇ, ਜਦੋਂ API ਖਾਲੀ ਸੂਚੀ ਵਾਪਸ ਕਰੇ, ਜਦੋਂ API error ਕਰੇ, ਅਤੇ ਜਦੋਂ ਦੋ ਯੂਜ਼ਰਾਂ ਦੀ "Last active" ਸਮੇਂ ਇੱਕੋ ਜਿਹਾ ਹੋਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਵਿਸਥਾਰਾਂ ਨੂੰ ਦਰਜ ਕਰੋ ਜਿਵੇਂ ਕਿ ਸੋਰਟ case-insensitive ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਜਦੋਂ ਫਿਲਟਰ ਬਦਲਦਾ ਹੈ ਟੇਬਲ ਇਕੋ page ਰੱਖਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।

ਜਦੋਂ ਤੁਹਾਡੇ ਨੋਟ ਬੋਰਿੰਗ ਅਤੇ ਵਿਸਥਾਰ ਨਾਲ ਭਰੇ ਹੋਣ, ਤਾਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ।

ਮੌਜੂਦਾ ਬਰਤਾਓ ਨੂੰ ਲਾਕ ਕਰਨ ਵਾਲੇ characterization tests ਸ਼ਾਮਲ ਕਰੋ

Characterization tests "ਇਹ ਅੱਜ ਇਸ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ" ਟੈਸਟ ਹੁੰਦੇ ਹਨ। ਉਹ ਮੌਜੂਦਾ ਬਰਤਾਓ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ajeeb ਹੋਵੇ ਜਾਂ ਲੰਮੇ ਸਮੇਂ ਲਈ ਠੀਕ ਨਾ ਲੱਗੇ। ਇਹ ਉਲਟ ਸੁਝਾਅ ਜਿਹਾ ਹੈ, ਪਰ ਇਹ ਰੀਫੈਕਟਰ ਨੂੰ ਲਾਪਰਵਾਹੀ ਨਾਲ rewrite ਬਣਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ Claude Code ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਰਹੇ ਹੋ, ਇਹ ਟੈਸਟ ਤੁਹਾਡੇ ਸੁਰੱਖਿਆ ਰੇਲਾਂ ਹਨ। ਟੂਲ ਕੋਡ ਨੂੰ ਰੀਸ਼ੇਪ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਨਹੀਂ ਬਦਲਣਾ।

ਯੂਜ਼ਰ ਅਤੇ ਹੋਰ ਕੋਡ ਜਿਸ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਉਸ 'ਤੇ ਧਿਆਨ ਦਿਓ:

• Rendering: ਮੁੱਖ ਹਾਲਤਾਂ ਲਈ ਕੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ (empty, loading, error, normal)
• Interactions: ਕਲਿਕ, ਟਾਈਪਿੰਗ, ਕੀਬੋਰਡ ਨੈਵੀਗੇਸ਼ਨ, ਚੋਣ, pagination
• Derived values: totals, filtered counts, formatting rules, disabled states
• Side effects: analytics calls, drafts ਸੇਵ ਕਰਨਾ, URL ਅਪਡੇਟ, focus management
• Error handling: ਜਦੋਂ ਕੋਈ action fail ਕਰਦੀ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ

ਟੈਸਟਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਣ ਲਈ, ਨਤੀਜਿਆਂ 'ਤੇ assert ਕਰੋ, implementation 'ਤੇ ਨਹੀਂ। "Save button disabled ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸੁਨੇਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ" ਨੂੰ ترجیح ਦਿਓ ਬਜਾਏ "setState ਕਾਲ ਹੋਈ" ਜਾਂ "ਇਹ hook ਚੱਲਿਆ"। ਜੇ ਟੈਸਟ ਟੁੱਟੇ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਕ ਕੰਪੋਨੈਂਟ ਦਾ ਨਾਮ ਬਦਲਿਆ ਜਾਂ hooks ਦੀ ਕ੍ਰਮਬੱਧਤਾ ਬਦਲੀ, ਤਾਂ ਉਹ ਬਰਤਾਓ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰ ਰਿਹਾ।

ਐਸਿੰਕ ਬਰਤਾਓ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਰੀਫੈਕਟਰ ਅਕਸਰ ਟਾਈਮਿੰਗ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਵਰਤੋ: UI ਦੇ settle ਹੋਣ ਦੀ ਉਡੀਕ ਕਰੋ, ਫਿਰ assert ਕਰੋ। ਜੇ timers ਹਨ (debounced search, delayed toasts), fake timers ਵਰਤੋ ਅਤੇ ਸਮਾਂ ਅੱਗੇ ਵਧਾਓ। ਜੇ ਨੈੱਟਵਰਕ ਕਾਲ ਹਨ, fetch ਨੂੰ mock ਕਰੋ ਅਤੇ success ਅਤੇ failure ਸਥਿਤੀਆਂ 'ਚ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਚੀਜ਼ assert ਕਰੋ। Suspense-ਵਾਂਗੇ flows ਲਈ, fallback ਅਤੇ resolved view ਦੋਹਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ।

ਉਦਾਹਰਣ: "Users" ਟੇਬਲ "No results" ਸਿਰਫ਼ search ਪੂਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦਿਖਾਉਂਦੀ ਹੈ। ਇੱਕ characterization test ਉਸ ਸੀਕਵੈਂਸ ਨੂੰ ਲਾਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ: ਪਹਿਲਾਂ loading indicator, ਫਿਰ rows ਜਾਂ empty message, ਭਾਵੇਂ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਕੰਪੋਨੈਂਟ ਕਿਵੇਂ ਵੀ ਵੰਡੋ।

Claude Code ਨਾਲ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਕਦਮ-ਬਾਈ-ਕਦਮ ਤਰੀਕਾ

ਜਿੱਤ "ਵੱਡੇ ਬਦਲਾਅ ਤੇਜ਼ ਹੋਣਾ" ਨਹੀਂ, ਜਿੱਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਮਝੋ ਕਿ ਕੰਪੋਨੈਂਟ ਕੀ ਕਰਦਾ ਹੈ, ਫਿਰ ਹਰ ਵਾਰ ਇੱਕ ਛੋਟਾ ਚੇਜ਼ ਬਦਲੋ ਜਦੋਂ ਬਰਤਾਓ ਇਕੋ ਜਿਹਾ ਰਹੇ।

ਸ਼ੁਰੂ ਕਰੋ ਕੰਪੋਨੈਂਟ ਪੇਸਟ ਕਰਕੇ ਅਤੇ ਇਸ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੀ ਸਧਾਰਨ ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ summary ਮੰਗੋ। ਵਿਸਥਾਰ ਲਈ ਧੱਕੋ: ਇਹ ਕਿਹੜਾ ਡੇਟਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਕਿਹੜੀਆਂ ਯੂਜ਼ਰ ਕਾਰਵਾਈਆਂ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ side effects ਟ੍ਰਿਗਰ ਹੁੰਦੇ ਹਨ (fetching, timers, subscriptions, analytics)। ਇਸ ਨਾਲ ਅਕਸਰ ਉਹ ਲੁਕਿਆ ਹੋਇਆ ਕੰਮ ਸਾਹਮਣੇ ਆ ਜਾਂਦਾ ਹੈ ਜੋ ਰੀਫੈਕਟਰ ਨੂੰ ਖਤਰਨਾਕ ਬਣਾਉਂਦਾ ਹੈ।

ਅਗਲੇ, dependency map ਮੰਗੋ। ਹਰ input ਅਤੇ output ਦਾ ਇਨਵੈਂਟਰੀ ਚਾਹੀਦਾ ਹੈ: props, context reads, custom hooks, local state, derived values, effects, ਅਤੇ ਕੋਈ module-level helpers। ਇੱਕ ਯੂਜ਼ਫੁਲ ਨਕਸ਼ਾ ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ move ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਹੈ (pure calculations) ਅਤੇ ਕੀ "sticky" ਹੈ (ਟਾਈਮਿੰਗ, DOM, ਨੈੱਟਵਰਕ)।

ਫਿਰ ਇਸਨੂੰ extraction candidates ਦੇਣ ਲਈ ਕਹੋ, ਇੱਕ ਸਖਤ ਨਿਯਮ ਨਾਲ: pure view ਹਿੱਸਿਆਂ ਨੂੰ stateful controller ਹਿੱਸਿਆਂ ਤੋਂ ਅਲਗ ਕਰੋ। JSX-ਭਾਰੀ ਸੈਕਸ਼ਨ ਜੋ ਸਿਰਫ props ਦੀ ਲੋੜ ਰੱਖਦੇ ਹਨ, ਪਹਿਲੇ ਹਨ। ਜਿਹੜੇ ਹਿੱਸੇ event handlers, async calls, ਅਤੇ state updates ਮਿਸ਼ਰਤ ਕਰਦੇ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ ਹਨ।

ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਅਸਲ ਕੋਡ ਵਿੱਚ ਟਿਕਦਾ ਹੈ:

• Responsibility summary ਅਤੇ dependency map ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• ਇਕ extraction candidate ਚੁਣੋ ਜੋ ਜ਼ਿਆਦਾਤਰ presentation ਹੈ, ਅਤੇ ਸਿਰਫ ਉਹੀ move ਕਰੋ।
• characterization tests ਦੁਬਾਰਾ ਚਲਾਓ ਅਤੇ ਤੁਰੰਤ ਮੈਨੁਅਲ click-through ਕਰੋ।
• ਅਗਲਾ ਇੱਕ state/effect tangled ਹਿੱਸਾ ਹੱਲ ਕਰੋ (ਸਾਰੇ ਨਹੀਂ), ਅਤੇ ਫਿਰ tests ਚਲਾਓ।
• ਦੁਹਰਾਓ ਜਦ ਤੱਕ ਮੂਲ ਕੰਪੋਨੈਂਟ ਇਕ ਛੋਟੇ ਕੋਆਰਡੀਨੇਟਰ ਵਾਂਗ ਨਹੀਂ ਪੜ੍ਹਦਾ।

Checkpoint ਮਹੱਤਵਪੂਰਨ ਹਨ। Claude Code ਤੋਂ ਇੱਕ ਨਿਊਨਤਮ ਯੋਜਨਾ ਮੰਗੋ ਜਿੱਥੇ ਹਰ ਕਦਮ commit ਅਤੇ revert ਕੀਤਾ ਜਾ ਸਕੇ। ਇੱਕ ਪ੍ਰਯੋਗਿਕ checkpoint ਹੋ ਸਕਦਾ ਹੈ: "<TableHeader> ਨੂੰ extraction ਕਰੋ ਬਿਨਾਂ ਲੌਜਿਕ ਬਦਲਾਅ ਦੇ" ਪਹਿਲਾਂ sorting state ਨੂੰ ਛੂਹਣ ਤੋਂ।

ਉਦਾਹਰਣ: ਜੇ ਇੱਕ ਕੰਪੋਨੈਂਟ ਗਾਹਕ ਟੇਬਲ ਰੈਂਡਰ ਕਰਦਾ, ਫਿਲਟਰਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ, ਅਤੇ ਡੇਟਾ ਫੈਚ ਕਰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਟੇਬਲ ਮਾਰਕਅਪ (headers, rows, empty state) ਨੂੰ pure component ਵਿੱਚ ਕੱਢੋ। ਫਿਰ ਹੀ filter state ਜਾਂ fetch effect ਨੂੰ move ਕਰੋ। ਇਹ ਕ੍ਰਮ bugs ਨੂੰ JSX ਨਾਲ ਨਾਲ ਭੇਜਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਬਗਾਂ ਨੂੰ ਇੰਜੈਕਟ ਕੀਤੇ ਬਿਨਾਂ ਕੰਪੋਨੈਂਟ ਇਕਸਟਰੈਕਟ ਕਰੋ

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵੱਡੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੰਡਦੇ ਹੋ, ਖਤਰਾ JSX move ਕਰਨ ਨਾਲ ਨਹੀਂ ਹੁੰਦਾ; ਖਤਰਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਡੇਟਾ ਫਲੋ, ਟਾਈਮਿੰਗ, ਜਾਂ ਇਵੈਂਟ ਵਾਇਰਿੰਗ ਅਕਸਿਡੈਂਟਲ ਬਦਲ ਦਿੰਦੇ ਹੋ। ਪਹਿਲਾਂ extraction ਨੂੰ copy-and-wire ਵਰਗਾ ਮਾਨੋ, ਅਤੇ cleanup ਬਾਅਦ ਕਰੋ।

ਸ਼ੁਰੂਆਤ ਕਰੋ UI ਵਿੱਚ ਪਹਿਲਾਂ ਮੌਜੂਦ ਸੀਮਾਵਾਂ ਨੂੰ ਲੱਭ ਕੇ, ਫਾਇਲ ਸਟ੍ਰਕਚਰ ਵਿੱਚ ਨਹੀਂ। ਉਹ ਹਿੱਸੇ ਲੱਭੋ ਜਿਹੜਿਆਂ ਨੂੰ ਤੁਸੀਂ ਇੱਕ ਵਾਕ ਬਣਾਕੇ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ: ਇੱਕ ਹੈਡਰ with actions, ਇੱਕ filter bar, ਇੱਕ results list, ਇੱਕ footer with pagination।

ਸੁਰੱਖਿਅਤ ਪਹਿਲਾ ਕਦਮ ਹੈ pure presentational components ਕੱਢਣਾ: props ਆਉਂਦੇ ਹਨ, JSX ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਜਾਣਬੂਝ ਕੇ ਬੋਰਿੰਗ ਰੱਖੋ। ਕੋਈ ਨਵੀਂ state, ਕੋਈ ਨਵਾਂ effect, ਕੋਈ ਨਵਾਂ API ਕਾਲ ਨਹੀਂ। ਜੇ ਮੂਲ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਇੱਕ click handler ਸੀ ਜੋ ਤਿੰਨ ਕੰਮ ਕਰਦਾ ਸੀ, ਤਾਂ ਉਹ handler parent ਵਿੱਚ ਹੀ ਰੱਖੋ ਅਤੇ ਨੀਵੇਂ ਕੰਪੋਨੈਂਟ ਨੂੰ pass ਕਰੋ।

ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸਰਹੱਦ: header area, list ਅਤੇ row item, filters (inputs only), footer controls (pagination, totals, bulk actions), ਅਤੇ dialogs (open/close ਅਤੇ callbacks pass ਕੀਤੇ ਜਾ ਸਕਦੇ)।

ਨਾਮ ਚੁਣਨਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਖਾਸ ਨាមਾਂ ਵਰਤੋ ਜਿਵੇਂ UsersTableHeader ਜਾਂ InvoiceRowActions। "Utils" ਜਾਂ "HelperComponent" ਵਰਗੇ ਜੇਨਰਿਕ ਨਾਂਬਾਕਸ ਤੋਂ ਬਚੋ।

ਇੱਕ container component ਤਦ ਹੀ introduce ਕਰੋ ਜਦੋਂ ਵਾਸਤਵ ਵਿੱਚ ਲੋੜ ਹੋਵੇ: ਇੱਕ UI ਦੀ chunk ਜਿਸਨੂੰ state ਜਾਂ effects own ਕਰਨਿਆਂ ਲਾਜ਼ਮੀ ਹੋਵੇ। ਫਿਰ ਵੀ, ਇਸਨੂੰ ਤਾਂਗਰਾ ਰੱਖੋ—ਇੱਕ ਚੰਗਾ container ਇਕ ਹੀ ਮਕਸਦ own ਕਰਦਾ ਹੈ (ਜਿਵੇਂ "filter state") ਅਤੇ باقی ਸਾਰਾ ਕੰਮ props ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ।

state ਅਤੇ effects ਨੂੰ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਕਦਮਾਂ ਵਿੱਚ ਅਲੱਗ ਕਰੋ

ਗੰਦੇ ਕੰਪੋਨੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਕਿਸਮਾਂ ਦੇ ਡੇਟਾ ਮਿਲਾ ਦਿੰਦੇ ਹਨ: ਅਸਲੀ UI state (ਜੋ ਯੂਜ਼ਰ ਸੈਟ ਕਰਦਾ ਹੈ), derived data (ਜੋ ਤੁਸੀਂ compute ਕਰ ਸਕਦੇ ਹੋ), ਅਤੇ server state (ਜੋ ਨੈੱਟਵਰਕ ਤੋਂ ਆਉਂਦਾ ਹੈ)। ਜੇ ਤੁਸੀਂ ਸਾਰਾ ਕੁਝ local state ਵਾਂਗ treat ਕਰੋਗੇ, ਤਾਂ ਰੀਫੈਕਟਰ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਅਕਸਰ ਇਹ ਬਦਲ ਦਿੰਦੇ ਹੋ ਕਿ ਚੀਜ਼ਾਂ ਕਦੋਂ ਅਪਡੇਟ ਹੁੰਦੀਆਂ ਹਨ।

ਸ਼ੁਰੂਆਤ ਕਰੋ ਹਰ piece of data ਨੂੰ ਲੇਬਲ ਕਰਕੇ। ਪੁੱਛੋ: ਕੀ ਇਹ ਯੂਜ਼ਰ ਦੁਆਰਾ ਸੰਪਾਦਿਤ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਮੈਂ ਇਹ props/state/fetched data ਤੋਂ compute ਕਰ ਸਕਦਾ ਹਾਂ? ਇਹ ਵੀ ਪੁੱਛੋ: ਕੀ ਇਹ value ਇੱਥੇ own ਹੁੰਦੀ ਹੈ, ਜਾਂ ਸਿਰਫ਼ pass-through ਹੈ?

Derived values ਨੂੰ state ਤੋਂ ਅਲੱਗ ਕਰੋ

Derived values ਨੂੰ useState ਵਿੱਚ ਨਹੀਂ ਰੱਖਣਾ ਚਾਹੀਦਾ। ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਛੋਟੀ function ਜਾਂ memoized selector ਵਿੱਚ move ਕਰੋ ਜਦੋਂ ਉਹ ਮਹਿੰਗੇ ہوں। ਇਹ state updates ਘਟਾਉਂਦਾ ਅਤੇ ਬਿਹਿਵਿਯਰ ਨੂੰ ਪੇਸ਼ਗੀ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

ਇੱਕ ਸੁਰੱਖਿਅਤ pattern:

• ਸਿਰਫ਼ ਯੂਜ਼ਰ-ਸੰਪਾਦਿਤ values ਨੂੰ useState ਵਿੱਚ ਰੱਖੋ।
• view-only values ਨੂੰ ਉਨਾਂ ਇਨਪੁੱਟਸ ਤੋਂ compute ਕਰੋ।
• computed values ਨੂੰ ਹੇਠਾਂ ਭੇਜੋ, ਨਾ ਕਿ setters, ਜਦ ਤੱਕ child ਨੂੰ ਵਾਕਈ ਉਹ edit ਨਾ ਕਰਨੇ ਹੋਣ।
• ਜੇ ਪ੍ਰਦਰਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ ਤਾਂ ਭਾਰੀ computation ਨੂੰ useMemo ਵਿੱਚ ਰੱਖੋ।

Effects ਨੂੰ boring ਅਤੇ specific ਬਣਾਓ

Effects ਬਰਤਾਓ ਤਦ ਤੋੜਦੇ ਹਨ ਜਦੋਂ ਉਹ ਬਹੁਤ ਕੁਝ ਕਰਦੇ ਹਨ ਜਾਂ ਗਲਤ ਡੀਪੈਂਡੇਂਸੀਜ਼ 'ਤੇ ਰੀਐਕਟ ਕਰਦੇ ਹਨ। ਹਰੇਕ ਮਕਸਦ ਲਈ ਇੱਕ effect ਰੱਖੋ: ਇੱਕ localStorage ਲਈ, ਇੱਕ fetching ਲਈ, ਇੱਕ subscriptions ਲਈ। ਜੇ ਇੱਕ effect ਬਹੁਤ ਸਾਰੀਆਂ values ਪੜ੍ਹਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਜਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਛੁਪਾ ਰਿਹਾ ਹੈ।

ਜੇ ਤੁਸੀਂ Claude Code ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਮੰਗੋ: ਇੱਕ effect ਨੂੰ ਦੋ ਵਿੱਚ ਵੰਡੋ, ਜਾਂ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਨੂੰ helper ਵਿੱਚ move ਕਰੋ। ਫਿਰ ਹਰ move ਤੋਂ ਬਾਅਦ characterization tests ਚਲਾਓ।

prop drilling ਦੇ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਇਸਨੂੰ context ਨਾਲ ਬਦਲਣਾ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਮਦਦਗਾਰ ਹੈ ਜਦੋਂ ਇਹ ਦੋਹਰਾਈ ਹੋ ਰਹੀ wiring ਨੂੰ ਹਟਾਏ ਅਤੇ ownership ਨੂੰ ਸਪਸ਼ਟ ਕਰੇ। ਚੰਗਾ ਇशਾਰਾ ਹੈ ਜਦੋਂ context app-ਲੀਵਲ ਸੰਕਲਪ (current user, theme, feature flags) ਵਾਂਗ ਪੜ੍ਹਿਆ ਜਾ ਰਿਹਾ ਹੋਵੇ, ਨਾ ਕਿ ਇੱਕ ਕੰਪੋਨੈਂਟ ਟਰੀ ਲਈ workaround ਵਾਂਗ।

ਉਦਾਹਰਣ: ਇੱਕ ਟੇਬਲ ਕੰਪੋਨੈਂਟ rows ਅਤੇ filteredRows ਦੋਹਾਂ state ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ। rows ਨੂੰ state ਰੱਖੋ, filteredRows ਨੂੰ rows + query ਤੋਂ compute ਕਰੋ, ਅਤੇ filtering code ਨੂੰ ਇੱਕ pure function ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ ਉਹ ਟੈਸਟ ਕਰਨਾ ਆਸਾਨ ਅਤੇ ਤੋੜਨਾ ਔਖਾ ਹੋਵੇ।

ਤੇਜ਼ ਰਿਵਰਟ ਲਈ checkpoint ਵਰਤੋਂ

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

ਹਰ ਮਹੱਤਵਪੂਰਨ move (component extraction, state flow ਬਦਲਣਾ) ਤੋਂ ਬਾਅਦ ਰੁਕੋ ਅਤੇ ਸਾਬਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਬਰਤਾਓ ਨਹੀਂ ਬਦਲਿਆ। ਇਹ ਸਬੂਤ automated (tests) ਅਤੇ manual (ਤੇਜ਼ ਚੈਕ) ਹੋ ਸਕਦਾ ਹੈ। ਲਕੜੀ ਇਹ ਨਹੀਂ ਕਿ ਸਭ ਕੁਝ ਪੂਰਨ ਹੋਵੇ—ਇਸਦਾ ਮਕਸਦ ਤੇਜ਼ ਪਤਾ ਲਾਉਣਾ ਹੈ।

ਇੱਕ ਪ੍ਰਯੋਗਿਕ checkpoint ਲੂਪ:

• ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਕਰੋ (ਇੱਕ extraction, ਇੱਕ state move, ਇੱਕ effect cleanup)
• ਪੂਰੀ test suite ਚਲਾਓ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਉਸ ਖੇਤਰ ਲਈ characterization tests ਚਲਾਓ
• ਕੁੰਜੀ ਯੂਜ਼ਰ ਪਾਥਾਂ ਦੀ ਤੇਜ਼ मੈਨੁਅਲ ਜाँच ਕਰੋ
• ਇੱਕ rollback point ਸੇਵ ਕਰੋ (git commit, ਜਾਂ ਜੇ ਉਪਲਬਧ ਹੋਵੇ ਤਾਂ platform snapshot)

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, snapshots ਅਤੇ rollback ਤੁਹਾਡੇ ਲਈ ਸੁਰੱਖਿਅਤ ਰੇਲਾਂ ਵਾਂਗ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਫਿਰ ਵੀ, ਸਧਾਰਨ commits ਪਸੰਦ ਕਰੋ, ਪਰ snapshots ਉਹ ਵੇਲੇ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ "known good" ਵਰਜਨ ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ।

ਇੱਕ ਸਰਲ ਬਿਹੈਵਿਅਰ ਲੈਜਰ ਰੱਖੋ ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਕੀ ਵੈਰੀਫਾਈ ਕੀਤਾ—ਇਹ ਸਿਰਫ਼ ਇੱਕ ਛੋਟੀ ਨੋਟ ਹੈ ਜੋ ਇਹ ਰੋਕਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਇਕੋ ਚੀਜ਼ ਇਕੱਥੇ ਬਾਰ-ਬਾਰ ਚੈੱਕ ਕਰੋ।

ਉਦਾਹਰਣ:

• Table sorting: ਉਹੀ ਕਾਲਮ ਨਾਲ ਸੌਰਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੀਰ ਆਈਕਨ ਦੀ ਸਥਿਤੀ ਬਰਕਰਾਰ ਰਹਿੰਦੀ ਹੈ।
• Row selection: selected count ਅਪਡੇਟ ਹੁੰਦੀ ਹੈ, bulk actions ਠੀਕ ਤਰੀਕੇ ਨਾਲ enable ਹੁੰਦੇ ਹਨ।
• Loading ਅਤੇ error states: spinner ਅਤੇ retry button ਉਹੀ ਕੇਸਾਂ ਵਿੱਚ ਦਿਖਦੇ ਹਨ।

ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਲੈਜਰ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਦੁਬਾਰਾ ਚੈੱਕ ਕਰਨਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ checkpoints ਰਿਵਰਟ ਕਰਨਾ ਸਸਤਾ ਬਣਾਉਂਦੇ ਹਨ।

ਰੀਫੈਕਟਰ ਦੌਰਾਨ ਵਰਤਣ ਵਾਲੀਆਂ ਆਮ ਫੰਸ

ਜ਼ਿਆਦਾਤਰ ਰੀਫੈਕਟਰ ਛੋਟੀਆਂ, ਬੋਰਿੰਗ ਗਲਤੀਆਂ ਨਾਲ fail ਹੁੰਦੇ ਹਨ। UI ਹਾਲੇ ਵੀ ਕੰਮ ਕਰਦਾ ਦਿਖਦਾ ਹੈ, ਪਰ spacing rule ਗਾਇਬ, click handler ਦੁਬਾਰਾ ਦੋ ਵਾਰ ਫਾਇਰ, ਜਾਂ ਲਿਸਟ ਟਾਈਪ ਕਰਦੇ ਸਮੇਂ ਫੋਕਸ ਛੱਡ ਸਕਦੀ ਹੈ। ਸਹਾਇਕ ਇੱਥੇ ਹੋਰ ਖ਼ਤਰਾ ਜੋੜ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਡ ਚੰਗਾ ਲੱਗਦਾ ਹੈ ਪਰ ਬਰਤਾਓ ਬਦਲ ਰਿਹਾ ਹੈ।

ਇੱਕ ਆਮ ਕਾਰਨ structure ਬਦਲ ਰਿਹਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਕੱਢਦੇ ਹੋ ਅਤੇ ਵਧੇਰੇ <div> ਰੈਪ ਕਰ ਦਿੰਦੇ ਹੋ, ਜਾਂ <button> ਦੀ ਥਾਂ clickable <div> ਰੱਖ ਦੇਂਦੇ ਹੋ। CSS selectors, layout, keyboard navigation, ਅਤੇ test queries ਬਦਲ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਧਿਆਨ ਵਿੱਚ ਆਏ।

ਵੋ traps ਜੋ ਅਕਸਰ ਬਰਤਾਓ ਤੋੜਦੀਆਂ ਹਨ:

• DOM ਬਦਲਾਅ ਜੋ ਮਾਮੂਲੀ ਲੱਗਦੇ ਹਨ: ਵਧੇਰੇ wrappers, ਗਲਤ element types, ਜਾਂ attributes ਦੀ moved ਹੋਇਆ—ਇਹ CSS ਅਤੇ tests ਤੋੜ ਸਕਦੇ ਹਨ। ਤੱਕਜ਼ਾ ਤੱਕ ਉਹੀ tags ਅਤੇ data attributes ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਦੇਸ਼ਯਕ ਤੌਰ 'ਤੇ ਬਦਲ ਨਹੀ ਰਿਹਾ।
• Referential equality ਨੂੰ ਅਕਸਿਡੈਂਟਲੀ ਤੋੜਣਾ: inline {} ਜਾਂ () => {} ਨਵੀਂ objects/functions ਬਣਾਉਂਦੇ ਹਨ ਜਿਹੜੀਆਂ extra re-renders ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ child state reset ਕਰ ਸਕਦੀਆਂ ਹਨ। ਉਹ props ਜਿਨ੍ਹਾਂ ਦਾ ਪਹਿਲਾਂ stable reference ਸੀ, ਉਹਨਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ।
• Hook dependency ਗਲਤੀਆਂ: logic ਨੂੰ useEffect, useMemo, ਜਾਂ useCallback ਵਿੱਚ move ਕਰਨ ਨਾਲ stale values ਜਾਂ loops ਆ ਸਕਦੇ ਹਨ ਜੇ dependencies ਗਲਤ ਹੋਣ। ਜੇ ਇੱਕ effect ਪਹਿਲਾਂ "on click" ਚਲਦਾ ਸੀ, ਤਾਂ ਉਸਨੂੰ ਕਦੇ "whenever anything changes" ਬਣਾਉਣਾ ਨਹੀਂ।
• ਬਿਨਾਂ ਇਜਾਜ਼ਤ ਵਿਹਾਰ ਨੂੰ upgrade ਕਰਨਾ: edge cases ਨੂੰ "fix" ਕਰਨਾ, sorting rules ਬਦਲਨਾ, ਜਾਂ validation ਸੁਧਾਰਨਾ ਇੱਕ product ਬਦਲਾਅ ਹੈ। ਪਹਿਲਾਂ ਅੱਜ ਵਾਲੇ ਬਰਤਾਓ ਨੂੰ ਮੈਚ ਕਰੋ, ਭਾਵੇਂ ਉਹ ajeeb ਹੋਵੇ।

ਉਦਾਹਰਣ: ਇੱਕ ਟੇਬਲ ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੰਡਦੇ ਸਮੇਂ row keys ਨੂੰ ID ਤੋਂ array index 'ਤੇ ਬਦਲਣਾ ਪਹਿਲੇ ਵਜੋਂ ਠੀਕ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ reorder 'ਤੇ selection state ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ। "ਸਾਫ" ਇੱਕ ਬੋਨਸ ਸਮਝੋ; "ਉਹੀ ਬਰਤਾਓ" ਲਾਜ਼ਮੀ ਹੈ।

ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਚੈਕਲਿਸਟ

ਮਰਜ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਸਬੂਤ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰੀਫੈਕਟਰ ਨੇ ਬਰਤਾਓ ਨੂੰ ਇਕੋ ਜਿਹਾ ਰੱਖਿਆ। ਸਭ ਤੋਂ ਆਸਾਨ ਸਿਗਨਲ ਬੋਰਿੰਗ ਹੈ: ਸਭ ਕੁਝ ਹੁਣ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਟੈਸਟ "ਫਿਕਸ" ਕਰਨ ਦੀ ਲੋੜ ਪਏ।

ਆਖਰੀ ਛੋਟੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਇਹ ਤੇਜ਼ ਗੁਜ਼ਰ-ਚੇਕ ਚਲਾਓ:

• ਪੁਰਾਣੇ ਟੈਸਟ ਬਿਨਾਂ ਸੋਧਾਂ ਦੇ ਪਾਸ ਹੋਣ (ਕੋਈ snapshots/ਅਸਰਦਾਰੀ ਬਦਲਾਅ ਨਹੀਂ), ਅਤੇ ਤੁਹਾਡੇ ਨਵੇਂ characterization tests ਵੀ ਪਾਸ ਹੋਣ।
• UI ਦੇ ਵੇਖਣਯੋਗ ਹਾਲਤਾਂ ਉਹੀਆਂ ਰਹਿਣ: loading, empty, error, success ਅਤੇ ਉਹੀ ਸਥਿਤੀਆਂ 'ਤੇ ਦਿਖਾਈ ਦੇਣ।
• ਪਬਲਿਕ props ਅਤੇ callback contracts ਅਜੇ ਵੀ stable ਰਹਿਣ: ਉਹੀ ਨਾਂ, ਉਹੀ argument ਆਕਾਰ, ਉਹੀ ਟਾਈਮਿੰਗ (onChange ਵਰਗੀ callback ਹਮੇਸ਼ਾਂ ਯੂਜ਼ਰ ਇੰਪੁੱਟ 'ਤੇ ਫਾਇਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, mount 'ਤੇ ਨਹੀਂ)।
• ਫੋਕਸ ਅਤੇ ਕੀਬੋਰਡ ਬਰਤਾਓ ਉਹੀ ਮਹਿਸੂਸ ਹੋਵੇ: tab order, Enter/ Escape handling, ਅਤੇ ਜਦੋਂ save/close/pagination ਵਰਗੇ actions ਹੋਂਦੇ ਹਨ ਤਾਂ ਫੋਕਸ ਕਿੱਥੇ ਲੈਂਡ ਹੁੰਦਾ ਹੈ।
• Analytics ਅਤੇ side effects ਇੱਕ ਵਾਰੀ ਹੀ ਹੋਣ, ਉਹੀ ਪਲ ਤੇ (ਉਦਾਹਰਣ ਲਈ, ਇੱਕ "Viewed" event ਪ੍ਰਤੀ ਸਕਰੀਨ ਲੋਡ ਉੱਤੇ, ਨਾ ਕਿ ਹਰ re-render 'ਤੇ)।

ਇੱਕ ਤੇਜ਼ sanity check: ਕੰਪੋਨੈਂਟ ਖੋਲੋ ਅਤੇ ਇੱਕ ਅਜੀਬ ਫਲੋ ਕਰੋ, ਜਿਵੇਂ error ਟ੍ਰਿਗਰ ਕਰੋ, retry ਕਰੋ, ਫਿਰ filters ਮਿਟਾਓ। ਰੀਫੈਕਟਰ ਅਕਸਰ transitions ਨੂੰ ਤੋੜਦੇ ਹਨ ਭਾਵੇਂ ਮੁੱਖ ਰਾਹ ਕੰਮ ਕਰਦਾ ਹੋਵੇ।

ਜੇ ਕੋਈ item fail ਹੁੰਦਾ ਹੈ, ਤਾਂ ਆਖਰੀ change ਰਿਵਰਟ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਹੋਰ ਛੋਟੇ ਕਦਮ ਵਿੱਚ ਦੁਬਾਰਾ ਕਰੋ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ diff ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਹਕੀਕੀ ਉਦਾਹਰਣ: ਇੱਕ ਗੰਦੇ table ਕੰਪੋਨੈਂਟ ਨੂੰ ਵੰਡਨਾ

ਕਲਪਨਾ ਕਰੋ ProductTable ਕੰਪੋਨੈਂਟ ਦਾ ਜੋ ਸਭ ਕੁਝ ਕਰਦਾ: ਡੇਟਾ ਫੈਚ ਕਰਦਾ, filters ਮੈਨੇਜ ਕਰਦਾ, pagination ਨਿਯੰਤਰਿਤ ਕਰਦਾ, delete ਲਈ confirm dialog ਖੋਲ੍ਹਦਾ, ਅਤੇ row actions (edit, duplicate, archive) ਸੰਭਾਲਦਾ। ਸ਼ੁਰੂ ਵਿੱਚ ਛੋਟਾ ਸੀ, ਫਿਰ 900-line ਫਾਇਲ ਹੋ ਗਿਆ।

ਲੱਛਣਾਂ ਪਰਿਚਿਤ ਹਨ: state useState ਵਿੱਚ ਫੈਲੀ ਹੋਈ, ਕੁਝ useEffects ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕ੍ਰਮ ਵਿੱਚ ਚਲ ਰਹੀਆਂ, ਅਤੇ ਇੱਕ "ਨਿਰਦੋਸ਼" ਬਦਲਾਅ pagination ਨੂੰ ਟੁੱਟ ਦੇਂਦਾ ਹੈ ਜਦੋਂ filter active ਹੋਵੇ। ਲੋਕ ਇਸਨੂੰ ਛੁਹਣਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਅਣਅਨੁਮਿਯਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਸੰਰਚਨਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, ਕੁਝ React characterization tests ਲਾਕ ਕਰੋ। ਯੂਜ਼ਰ ਕੀ ਕਰਦਾ ਹੈ, ਇਸ 'ਤੇ ਧਿਆਨ ਦਿਓ, ਨਾ ਕਿ اندرੂਨੀ state:

• ਫਿਲਟਰ ਲਗਾਉਣ 'ਤੇ ਵਿਸ਼ੂਅਲ ਰੋਜ਼ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ ਅਤੇ page 1 ਤੇ ਰੀਸੈਟ ਹੁੰਦਾ ਹੈ।
• Pagination ਫਿਲਟਰ ਨੂੰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਸਹੀ page count ਦਿਖਾਉਂਦਾ ਹੈ।
• "Archive" ਕਲਿੱਕ ਕਰਨ 'ਤੇ row request ਚਲਣ ਦੌਰਾਨ disable ਹੋ ਜਾਂਦੀ ਹੈ।
• ਜਦੋਂ ਕੋਈ ਨਤੀਜੇ ਫਿਲਟਰਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਤਾਂ empty state ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
• Loading state "No results" ਨੂੰ flash ਨਹੀਂ ਕਰਦੀ।

ਹੁਣ ਤੁਸੀਂ ਛੋਟੇ commits ਵਿੱਚ ਰੀਫੈਕਟਰ ਕਰ ਸਕਦੇ ਹੋ। ਇੱਕ ਸਾਫ਼ extraction ਯੋਜਨਾ ਦਿਿਆਂ ਹੋ ਸਕਦੀ ਹੈ: FilterBar controls ਰੈਂਡਰ ਕਰਦਾ ਅਤੇ filter changes emit ਕਰਦਾ; TableView rows ਅਤੇ pagination ਰੈਂਡਰ ਕਰਦਾ; RowActions action menu ਅਤੇ confirm dialog UI ਨੂੰ own ਕਰਦਾ; ਅਤੇ ਇੱਕ useProductTable hook messy logic (query params, derived state, side effects) ਨੂੰ own ਕਰਦਾ।

ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਪਹਿਲਾਂ dumb UI ( TableView, FilterBar) ਕੱਢੋ ਅਤੇ props unmodified ਰੱਖੋ। ਖਤਰਨਾਕ ਹਿੱਸਾ ਆਖ਼ਿਰ ਨੂੰ ਰੱਖੋ: state ਅਤੇ effects ਨੂੰ useProductTable ਵਿੱਚ move ਕਰਨਾ। ਇਸ ਵੇਲੇ पुराने prop names ਅਤੇ event shapes ਰੱਖੋ ਤਾਂ ਕਿ tests ਪਾਸ ਰਹਿਣ। ਜੇ ਕੋਈ ਟੈਸਟ ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ behavior change ਮਿਲੀ—ਇੱਕ style issue ਨਹੀਂ।

ਅਗਲੇ ਕਦਮ: ਇਸ ਵਿਧੀ ਨੂੰ ਦੁਹਰਾਯੋਗ ਬਣਾਓ

ਜੇ ਤੁਸੀਂ Claude Code ਨਾਲ React ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਰੀਫੈਕਟਰਿੰਗ ਹਰ ਵਾਰੀ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਵਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਜੋ ਕੁਝ ਤੁਸੀਂ ਹਾਲ ਹੀ ਵਿੱਚ ਕੀਤਾ ਉਸਨੂੰ ਇੱਕ ਛੋਟੀ ਟੈਮਪਲੇਟ ਬਣਾ ਲਓ। ਮਕਸਦ ਜ਼ਿਆਦਾ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ, ਘੱਟ ਅਚਾਨਕੀਆਂ ਹੈ।

ਇਕ ਸਧਾਰਨ ਰੀਫੈਕਟਰ ਟੈਮਪਲੇਟ ਰੱਖੋ

ਕੋਈ ਛੋਟੀ ਪਲੇਅਬੁੱਕ ਲਿਖੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਕੰਪੋਨੈਂਟ 'ਤੇ ਫਾਲੋ ਕਰ ਸਕੋ:

• ਇਕ ਵਾਕ ਵਿੱਚ ਟੀਚਾ ਦੱਸੋ (ਕੀ ਸੁਧਰਦਾ ਹੈ, ਕੀ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ)।
• ਮੌਜੂਦਾ ਬਰਤਾਓ ਨੂੰ characterization tests ਨਾਲ ਕੈਪਚਰ ਕਰੋ (ਅਜੀਬ edge cases ਸਮੇਤ)।
• ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਕਰੋ (ਪ੍ਰਸਤੁਤੀ, ਨਾਮ-ਬਦਲਾਅ, state move, effects isolate).
• ਟੈਸਟ ਚਲਾਓ ਅਤੇ UI ਵਿੱਚ ਤੇਜ਼ ਮੈਨੁਅਲ ਚੈੱਕ ਕਰੋ।
• ਇੱਕ checkpoint ਸੇਵ ਕਰੋ ਜੋ ਰਿਵਰਟ ਕਰਨ ਯੋਗ ਹੋਵੇ।

ਇਸਨੂੰ ਆਪਣੇ ਨੋਟ ਜਾਂ ਰੇਪੋ ਵਿੱਚ ਸਕਿੱਪੇਟ ਵਾਂਗ ਸੇਵ ਕਰੋ ਤਾਂ ਕਿ ਅਗਲਾ ਰੀਫੈਕਟਰ ਉੱਪਰੋਂ ਹੀ ਉਸੇ ਸੁਰੱਖਿਆ ਰੇਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋਵੇ।

ਬਰਤਾਓ ਲਾਕ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ ਕੀ ਕਰਨ ਦੀ ਯੋਜਨਾ

ਜਦੋਂ ਕੰਪੋਨੈਂਟ ਸਥਿਰ ਅਤੇ ਪੜ੍ਹਨ ਲਈ ਆਸਾਨ ਹੋ ਜਾਏ, ਤਾਂ ਅਗਲਾ ਪਾਸ ਉਪਭੋਗੀ ਪ੍ਰਭਾਵ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ। ਆਮ ਕ੍ਰਮ: accessibility ਪਹਿਲਾਂ (labels, focus, keyboard), ਫਿਰ performance (memoization, expensive renders), ਫਿਰ cleanup (types, naming, dead code)। ਇੱਕੀ PR ਵਿੱਚ ਇਹ ਤਿੰਨ ਇਕੱਠੇ ਨਾ ਮਿਲਾਓ।

ਜੇ ਤੁਸੀਂ vibe-coding ਵਰਕਫਲੋ ਵਰਤਦੇ ਹੋ ਜਿਵੇਂ Koder.ai (koder.ai), planning mode ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਕਦਮਾਂ ਨੂੰ ਰੂਪ ਰੇਖਾ ਦੇਣ ਵਿੱਚ, ਅਤੇ snapshots/rollback checkpoint ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਖਤਮ ਕਰ ਲਓ, source export final diff ਦੀ ਸਮੀਖਿਆ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਤਿਹਾਸ ਸਾਫ਼ ਰੱਖਦਾ ਹੈ।

ਰੀਫੈਕਟਰ ਕਰਨਾ ਕਦੋਂ ਰੋਕਣਾ ਹੈ ਅਤੇ ਸ਼ਿਪ ਕਰਨਾ ਹੈ

ਜਦੋਂ ਟੈਸਟ ਉਹ ਰਸਤੇ ਕਵਰ ਕਰ ਲੈਂ ਜੋ ਤੁਹਾਨੂੰ ਤੋੜਣ ਤੋਂ ਡਰਾਉਂਦੇ ਸਨ, ਅਗਲਾ change feature ਹੋਵੇ, ਜਾਂ ਤੁਸੀਂ ਇੱਕੋ PR ਵਿੱਚ perfect ਕਰਨ ਦੀ ਲਾਲਸ ਮਹਿਸੂਸ ਕਰੋ—ਉਸਤੋਂ ਬਾਅਦ ਰੋਕੋ। ਜੇ ਵੱਡੇ ਫਾਰਮ ਨੂੰ ਵੰਡਣ ਨਾਲ tangled state ਹਟ ਗਿਆ ਅਤੇ ਤੁਹਾਡੇ tests validation ਅਤੇ submit ਨੂੰ ਕਵਰ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਸ਼ਿਪ ਕਰੋ। ਬਾਕੀ ਵਿਚਾਰ ਛੋਟੇ ਬੈਕਲੌਗ ਵਜੋਂ ਰੱਖੋ।