ਕਿਉਂ ਵਾਇਬ ਕੋਡਿੰਗ ਅਧੂਰੇ ਪਨ ਅਤੇ ਤਬਦੀਲੀ 'ਤੇ ਫਲੇਟਾ ਹੈ

ਵਾਇਬ ਕੋਡਿੰਗ ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)

“ਵਾਇਬ ਕੋਡਿੰਗ” ਸੋਫਟਵੇਅਰ ਬਣਾਉਣ ਦੀ ਇੱਕ ਪਹੁੰਚ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਗਤੀ ਨੂੰ ਗلے ਲਗਾਉਂਦੇ ਹੋ: ਇੱਕ ਢੁਕਵਾ ਵਿਚਾਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਸਾਰਥਕ ਤਰੀਕੇ ਨਾਲ ਸਭ ਤੋਂ ਸਧਾਰਣ ਚੀਜ਼ ਲਿਖੋ, ਅਤੇ ਅਸਲ ਫੀਡਬੈਕ ਦੇ ਆਧਾਰ 'ਤੇ ਅਗਲਾ ਕੰਮ ਤੈਅ ਕਰੋ। ਇਹ ਇੱਕ ਪੂਰੇ ਯੋਜਨਾ ਦੀ ਪਾਲਣਾ ਕਰਨ ਤੋਂ ਵਧ ਕੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਚਲਦਿਆਂ ਰੱਖਣ ਬਾਰੇ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਉਹ ਜਾਨ ਸਕੋ ਜੋ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇਹ ਕੀ ਹੈ

ਵਾਇਬ ਕੋਡਿੰਗ ਇੱਕ ਵਿਹਾਰਕ ਮਨੋਭਾਵ ਹੈ:

• ਛੋਟੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਕੁਝ ਐਸਾ ਸ਼ਿਪ ਕਰੋ ਜੋ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਸਕੋ।
• ਜੋ ਤੋੜਦਾ ਹੈ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰ ਬਣਾਉਂਦਾ ਹੈ ਜਾਂ ਬਹੁਤ ਸਮਾਂ ਲੈਂਦਾ ਹੈ, ਉਸ ਤੋਂ ਸਿੱਖੋ।
• ਤੇਜ਼ੀ ਨਾਲ ਅਨੁਕੂਲ ਹੋਵੋ, ਭਾਵੇਂ ਇਸ ਦਾ ਮਤਲਬ ਰਸਤਾ ਬਦਲਣਾ ਹੋਵੇ।

ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ ਗਤੀ ਅਹੰਕਾਰਕ ਹੈ ਕਿਉਂਕਿ ਅਨਿਸ਼ਚਿਤਤਾ ਉੱਚੀ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਅਜੇ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕਿਹੜੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਕੀਮਤੀ ਹਨ, ਕਿਹੜੇ ਐਜ ਕੇਸ ਅਸਲ ਹਨ, ਜਾਂ ਕੀ ਵਿਚਾਰ 'final' ਵਰਜਨ ਦੇ ਲਾਇਕ ਹੈ। ਤੇਜ਼ ਦੋੜਾਨ ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟਤਾ ਦਿੰਦੇ ਹਨ।

ਇਹ ਕੀ ਨਹੀਂ ਹੈ

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

ਤੇਜ਼ vs ਲਾਪਰਵਾਹ

“ਤੇਜ਼” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਕਾਰਜ-ਵਿੱਚਾਰ ਕੀਆ ਹਨ ਜੋ ਸਿੱਖਣ ਦੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ:

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

“ਲਾਪਰਵਾਹ” ਦਾ ਮਤਲਬ ਹੈ ਸੋਚਣ ਹੀ ਛੱਡ ਦੇਣਾ:

• ਕੁਝ ਵੀ ਅਸਥਾਈ ਹੋਣ ਦਾ ਨੋਟ ਨਹੀਂ।
• ਨਿ਩ੁਰਮਾਣ ਜਾਂ ਘੱਟ ਤਹਕੀਕਾਤ ਨਹੀਂ।
• ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਦੁਹਰਾਉਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ।

ਅਸਲ ਮਕਸਦ: ਸਿੱਖਣਾ

ਵਾਇਬ ਕੋਡਿੰਗ ਦਾ ਮਕਸਦ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ—ਇਹ ਜਾਣਕਾਰੀ ਹੈ। ਹਰ ਛੋਟਾ ਰਿਲੀਜ਼ ਇੱਕ ਸਵਾਲ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲੀ ਦੁਨੀਆ ਨੂੰ ਪੁੱਛ ਰਹੇ ਹੋ: ਕੀ ਕੋਈ ਇਸ ਨੂੰ ਚਾਹੁੰਦਾ ਹੈ? ਕਿਹੜਾ ਹਿੱਸਾ ਗੁੰਝਲਦਾਰ ਹੈ? ਅਗਲੇ ਕਦਮ ਵਜੋਂ ਕੀ ਆਟੋਮੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ? ਤੁਸੀਂ ਸੋਫਟਵੇਅਰ ਬਣਾ ਰਹੇ ਹੋ ਜਿੰਨਾ ਕਿ ਗਿਆਨ ਬਣਾਉਣ ਵਿੱਚ ਵੀ।

ਅਧੂਰਾ ਹੋਣਾ ਅਸਲੀ ਕੰਮ ਦੀ ਇੱਕ ਖ਼ਾਸੀਅਤ ਹੈ

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

ਕਿਉਂ ਪਰਫੈਕਸ਼ਨ ਤੁਹਾਨੂੰ ਸੁਸਤ ਕਰ ਦਿੰਦਾ ਹੈ

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

“ਬਿਨਾਂ ਰੱਗੜ ਦੇ” ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੇ ਤੁਸੀਂ ਅਕਸਰ:

• ਹਰ ਕੇਸ ਦੀ ਭਵਿੱਖਵਾਣੀ ਕਰਨ ਤੱਕ ਸ਼ਿਪਿੰਗ ਰੋਕ ਦਿੰਦੇ ਹੋ
• ਫੀਡਬੈਕ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਫੈਸਲੇ ਟਾਲਦੇ ਹੋ (ਕਿਉਂਕਿ ਫੀਡਬੈਕ ਨਕਾਰਾਤਮਕ ਹੋ ਸਕਦਾ ਹੈ)
• ਉਹ ਸੁਰੱਖਿਆ ਬਣਾ ਦਿੰਦੇ ਹੋ ਜੋ ਸ਼ਾਇਦ ਕਦੇ ਮੰਗੀ ਹੀ ਨਾ ਜਾਵੇ

ਨਤੀਜਾ ਉੱਚ ਗੁਣਵੱਤਾ ਨਹੀਂ—ਇਹ ਧੀਰੀ ਸਿੱਖਣ ਹੈ।

ਬਗ ਅਤੇ ਰੱਗੜੀਆਂ ਸਿਗਨਲ ਹੁੰਦੇ ਹਨ

ਅਧੂਰੀਆਂ ਚੀਜ਼ਾਂ ਜਾਣਕਾਰੀ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਗੁੰਝਲਦਾਰ ਸਕ੍ਰੀਨ ਦੱਸਦੀ ਹੈ ਕਿ ਲੋਕ ਕਿਥੇ ਫसਦੇ ਹਨ। ਇੱਕ ਭਾਰੀ ਫੰਕਸ਼ਨ ਇਹ ਦਿਖਾਂਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਦੀ ਹੱਦ ਕਿੱਥੇ ਹੈ। ਇਕ “ਅਜੀਬ” ਸਪੋਰਟ ਟਿਕਟ ਦੱਸਦੀ ਹੈ ਕਿ ਯੂਜ਼ਰ ਵਾਸਤਵ ਵਿੱਚ ਕੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ—ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ ਸੋਚਿਆ ਸੀ।

ਇਸ ਨਜ਼ਰੀਏ ਨਾਲ, ਬਗ ਸਿਰਫ ਖ਼ਰਾਬੀ ਨਹੀਂ—ਉਹ ਅਗਲੇ ਕਦਮ ਦੀ ਨਕਸ਼ੀ ਹੈ।

“ਹੁਣ ਲਈ ਕਾਫੀ” ਇੱਕ ਮਾਨਯ ਫੈਸਲਾ ਹੈ

ਅਧੂਰਾ ਕੋਡ ਸ਼ਿਪ ਕਰਨ ਦਾ ਮਤਲਬ ਲਾਪਰਵਾਹ ਕੋਡ ਸ਼ਿਪ ਕਰਨਾ ਨਹੀਂ। ਇਹ ਅਨਿਸ਼ਚਿਤਤਾ ਦੇ ਅਨੁਸਾਰ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਮੇਲ ਖਾਂਦਾ ਹੈ।

“ਹੁਣ ਲਈ ਕਾਫੀ” ਓਹ ਵੇਲੇ ਸਹੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ:

• ਫੀਚਰ ਹਜੇ ਵੀ ਫੀਡਬੈਕ ਨਾਲ ਬਣ ਰਿਹਾ ਹੋਵੇ
• ਗਲਤ ਹੋਣ ਦੀ ਲਾਗਤ ਘੱਟ ਅਤੇ ਵਾਪਸੀਯੋਗ ਹੋਵੇ
• ਤੁਹਾਨੂੰ ਸਹੀ ਦਿਸ਼ਾ ਚੁਣਨ ਲਈ ਅਸਲੀ ਵਰਤੋਂ ਡੇਟਾ ਚਾਹੀਦਾ ਹੋਵੇ

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

ਅਸਥਾਈ ਹੈਕ: ਚੰਗਾ, ਮਾੜਾ, ਅਤੇ ਉਪਯੋਗੀ

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

ਚੰਗੇ: ਉਹ ਹੈਕ ਜੋ ਤੁਹਾਨੂੰ ਸਿੱਖਣ ਦਿੰਦੇ ਹਨ

ਆਮ “ਇੱਕ ਵਾਰੀ ਚਲਾਉ” ਵਾਲੇ ਹੈਕ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

• ਹਾਰਡਕੋਡ ਕੀਤੀਆਂ ਕਦਰਾਂ (ਲੋਕਲ ਫਾਈਲ ਵਿੱਚ API key, ਨਿਰਧਾਰਤ ID, ਇੱਕ ਯੂਜ਼ਰ ਖਾਤਾ)
• ਮैनੂਅਲ ਕਦਮ (ਕਮਾਂਡ ਚਲਾਉਣਾ, CSV ਕਾਪੀ/ਪੇਸਟ, ਹੈਂਡ ਨਾਲ ਡਿਪਲੋਇ ਟ੍ਰਿਗਰ ਕਰਨਾ)
• ਸਧਾਰਣ ਸਕ੍ਰਿਪਟ (ਫਾਈਲਾਂ ਨਾਂ ਬਦਲਣ ਜਾਂ ਡੇਟਾ ਬੈਕਫਿਲ ਕਰਨ ਲਈ ਇੱਕ ਵਾਰੀ Python/Bash)
• ਪਤਲੇ ਇੰਟੀਗਰੇਸ਼ਨ (“ਸਿੱਧਾ ਐਂਡਪੋਇੰਟ ਨੂੰ ਕਾਲ ਕਰੋ”, ਹੁਣ ਤੱਕ ਕੋਈ ਰੀਟ੍ਰਾਈ ਜਾਂ ਮਾਨੀਟਰਨਗ ਨਹੀਂ)

ਏਹ ਪ੍ਰੋਟੋਟਾਈਪ ਵਜੋਂ ਮਾਣਯ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਕੀ ਕੋਈ ਇਸ ਨੂੰ ਚਾਹੁੰਦਾ ਹੈ? ਕਿਹੜੇ ਇਨਪੁਟ ਮਹੱਤਵਪੂਰਨ ਹਨ? ਅਸਲ ਐਜ-ਕੇਸ ਕਿੱਥੇ ਹਨ? ਹੈਕ ਤਦੋਂ ਉਪਯੋਗੀ ਹੈ ਜਦੋਂ ਇਹ ਅਨਿਸ਼ਚਿਤਤਾ ਘਟਾਉਂਦਾ ਅਤੇ ਸਕੋਪ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।

ਮਾੜੇ: ਉਹ ਹੈਕ ਜੋ ਅਦ੍ਰਿਸ਼ਟ ਨਿਰਭਰਤਾਵਾਂ ਬਣ ਜਾਂਦੇ ਹਨ

ਹੈਕ ਤਦੋਂ ਨੁਕਸਾਨਦੇਹ ਬਣ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਉਹ ਹੈਕ ਹੋਣ ਦਾ ਅਹਿਸਾਸ ਖਤਮ ਹੋ ਜਾਵੇ। ਖਤਰਾ ਇਹ ਹੈ ਕਿ “ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਇਸ ਨੂੰ ਛੇੜਦਾ ਨਹੀਂ।” ਸਮੇਂ ਦੇ ਨਾਲ, ਟੀਮਮੇਟ (ਜਾਂ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ) ਚੁਪਚਾਪ ਛੁਪੇ ਹੋਏ ਧਾਰਣਾਵਾਂ ਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੇ ਹਨ:

• ਇੱਕ ਹਾਰਡਕੋਡ ਕਦਰ ਸਿਸਟਮ ਲਈ “ਸਿਰਫ ਇਕੋ ਹੀ ਕਦਰ” ਬਣ ਜਾਂਦੀ ਹੈ
• ਇੱਕ ਮੈਨੂਅਲ ਕਦਮ ਰਿਲੀਜ਼ ਦਾ ਇਕੱਲਾ ਫੇਲ ਪਾਇੰਟ ਬਣ ਜਾਂਦਾ ਹੈ
• ਇੱਕ ਛੇਤੀ ਸਕ੍ਰਿਪਟ ਡੇਟਾ ਕਿਵੇਂ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ ਇਸ ਦੀ ਇਕੱਲੀ ਰਿਕਾਰਡ ਬਣ ਜਾਂਦੀ ਹੈ

ਇਸ ਤਰ੍ਹਾਂ ਅਸਥਾਈ ਛੋਟੇ ਰਾਹ ਅਦ੍ਰਿਸ਼ਟ ਨਿਰਭਰਤਾਵਾਂ ਬਣ ਜਾਂਦੇ ਹਨ: ਨਾਜ਼ੁਕ ਵਰਤੋਂ ਜੋ ਦਸਤਾਵੇਜ਼, ਟੈਸਟ, ਜਾਂ ਮਾਲਕੀ ਨਹੀਂ ਹੈ।

“ਅਸਥਾਈ” ਇੱਕ ਵਾਅਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮੈਨੇਜ ਕਰਨਾ ਪੈਣਾ ਹੈ

ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਅਸਥਾਈ ਕਹਿਣਾ ਲੇਬਲ ਨਹੀਂ—ਇਹ ਇਕ ਵਚਨਬੱਧਤਾ ਹੈ।

ਵਾਅਦੇ ਨੂੰ ਠੋਸ ਬਣਾਓ:

• ਲਿਖੋ ਕਿਉਂ ਇਹ ਹੈਕ ਹੈ ਅਤੇ “ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੀ ਕਰਨਾ” ਦਾ ਅਰਥ ਕੀ ਹੈ
• ਇਸ 'ਤੇ ਸਮਾਪਤੀ ਤਾਰੀਖ ਜਾਂ ਟ੍ਰਿਗਰ ਲਗਾਓ (“ਪਹਿਲੇ ਪੈਦਾਏ ਗਾਹਕ ਤੋਂ ਬਾਅਦ ਹਟਾਓ”, “ਪਬਲਿਕ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲੋ”)
• ਇਸ ਨੂੰ ਆਪਣੇ ਬੈਕਲੌਗ ਵਿੱਚ ਟ੍ਰੈਕ ਕਰੋ, ਸਿਰਫ ਆਪਣੇ ਦਿਮਾਗ ਵਿੱਚ ਨਹੀਂ

ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਟਰੋਲ ਕੀਤੀ ਹੈਕ ਸਚੀ, ਸਮੇਂ-ਬੱਧ ਅਤੇ ਬਦਲਣ ਯੋਗ ਹੋਵੇਗੀ। ਇਕ ਅਣਮੈਨੇਜ ਕੀਤੀ ਹੈਕ ਸਿਰਫ਼ ਬਿਹਤਰ ਵਾਈਬ ਵਾਲਾ টੈਕਨੀਕਲ ਡੇਬਟ ਹੈ।

ਲਗਾਤਾਰ ਤਬਦੀਲੀ ਬਿਹਤਰ ਹੈ ਪੂਰੇ ਅਨੁਮਾਨ ਤੋਂ

ਅੱਗੇ ਤੋਂ “ਇੱਕदम ਸਹੀ” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਜ਼ਿੰਮੇਵਾਰ ਮਹਿਸੂਸ ਹੁੰਦੀ—ਜਦ ਤੱਕ ਹਕੀਕਤ ਸਾਹਮਣੇ ਨਾ ਆ ਜਾਵੇ। ਵਾਇਬ ਕੋਡਿੰਗ ਇਕ ਸਾਦਾ ਸੱਚਾਈ ਵੱਲ ਝੁਕਦਾ ਹੈ: ਤੁਸੀਂ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਯੂਜ਼ਰ ਕੀ ਮੁੱਲ ਦੇਣਗੇ, ਜਦ ਤੱਕ ਉਹ ਕੁਝ ਅਸਲੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ ਨਾ ਲਗਣ।

ਤੇਜ਼ ਰਿਲੀਜ਼ ਅਸਲ ਫੀਡਬੈਕ ਪੈਦਾ ਕਰਦੇ ਹਨ

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

ਉਹ ਫੀਡਬੈਕ ਨਕਲੀ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਹ ਇੱਕੋ ਹੀ ਤਰੀਕਾ ਹੈ ਜੋ ਵਾਸਤਵਿਕਤਾ 'ਚ ਸੋਚ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਇੱਕ ਯੋਜਨਾ ਅਨੁਮਾਨ ਹੈ; ਇੱਕ ਸ਼ਿਪ ਕੀਤਾ ਫੀਚਰ ਇੱਕ ਟੈਸਟ ਹੈ।

ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਨੂੰ ਦੁਬਾਰਾ ਬਦਲਿਆ ਜਾਣਾ ਮਨਜ਼ੂਰ ਹੈ

ਪਹਿਲਾ ਵਰਜਨ ਇਕ ਨੀਂਹ ਨਹੀਂ—ਇਹ ਇਕ ਪ੍ਰੋਬ ਚਾਹੀਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਅਕਸਰ:

• ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਕ ਵਧੀਆ ਤਰੀਕਾ ਸਿੱਖ ਲੈਂਦੇ ਹੋ
• ਸਧਾਰਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਫੀਚਰ ਉਨਾ重要 ਨਹੀਂ ਸੀ ਜਿੰਨਾ ਤੁਸੀਂ ਸੋਚਿਆ
• ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਯੂਜ਼ਰਾਂ ਨੇ ਅਜਿਹਾ ਆਵਾਜ਼ ਕੀਤਾ ਜੋ ਤੁਸੀਂ ਅਨੁਮਾਨ ਨਹੀਂ ਕੀਤਾ

ਇਹ ਫੇਲ ਨਹੀਂ—ਇਹ ਤੇਜ਼ ਸਿੱਖਣ ਦੀ ਲਾਜ਼ਮੀ ਲਾਗਤ ਹੈ।

ਫੀਡਬੈਕ ਲੂਪ: ਬਣਾਓ → ਸ਼ਿਪ ਕਰੋ → ਸਿੱਖੋ → ਅਨੁਕੂਲ ਕਰੋ

ਤਾਕਤ ਲੂਪ ਵਿੱਚ ਹੈ, ਨਾ ਕਿ ਪਹਿਲੇ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ:

1. ਬਣਾ ਸਭ ਤੋਂ ਘੱਟ ਉਪਯੋਗੀ ਵਰਜਨ
2. ਸ਼ਿਪ ਕਰਕੇ ਅਸਲ ਯੂਜ਼ਰਾਂ ਨੂੰ ਦਿਖਾਓ (ਭਾਵੇਂ ਇਹ ਖ਼ਰਾਬ ਹੋ)
3. ਸਿੱਖੋ ਵਰਤੋਂ ਅਤੇ ਸਪੋਰਟ ਰਿਕਵੈਸਟਾਂ ਤੋਂ
4. ਅਨੁਕੂਲ ਕਰੋ ਸਕੋਪ, ਡਿਜ਼ਾਇਨ ਅਤੇ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ

ਜਦੋਂ ਲੂਪ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਤਬਦੀਲੀ ਸਸਤੀ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਲੂਪ ਲੰਬਾ ਹੁੰਦਾ ਹੈ, ਤਬਦੀਲੀ ਡਰਾਵਨੀ ਬਣ ਜਾਂਦੀ ਹੈ—ਇਸ ਲਈ ਟੀਮਾਂ ਭਵਿੱਖਵਾਣੀਆਂ ਨੂੰ ਫੜਕੇ ਰੱਖ ਲੈਂਦੀਆਂ ਹਨ।

ਸਧਾਰਣ ਉਦਾਹਰਨ: ਪਹਿਲੇ ਡੈਮੋ ਤੋਂ ਬਾਅਦ ਲੋੜਾਂ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ

ਧਰੋ ਤੁਸੀਂ “Saved Searches” ਫੀਚਰ ਡੈਮੋ ਕੀਤਾ। ਤੁਸੀਂ ਇੱਕ UI ਬਣਾਇਆ ਜੋ ਫਿਲਟਰਾਂ ਨੂੰ ਨਾਮ ਦੇਕੇ ਸਟੋਰ ਕਰਦਾ—ਉਮੀਦ ਸੀ ਕਿ ਯੂਜ਼ਰ ਇਕ ਸੰਭਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਚਾਹੁੰਦੇ ਹਨ।

ਡੈਮੋ ਦੇ ਬਾਅਦ, ਤਿੰਨ ਗੱਲਾਂ ਹੁੰਦੀਆਂ ਹਨ:

• ਯੂਜ਼ਰ ਖੋਜਾਂ ਨੂੰ ਨਾਮ ਨਹੀਂ ਦਿੰਦੇ—ਉਹ ਸਿਰਫ “ਇਕ-ਟੈਪ ਦੁਬਾਰਾ ਚਲਾਉ” ਚਾਹੁੰਦੇ ਹਨ।
• ਅਸਲ ਦਰਦ searches ਨੂੰ ਟੀਮਮੈਟਾਂ ਨਾਲ ਸਾਂਝਾ ਕਰਨ ਵਿੱਚ ਹੈ।
• ਸਪੋਰਟ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਸੇਵ ਹੋ ਰਿਹਾ ਹੈ (ਫਿਲਟਰ ਬਨਾਮ ਨਤੀਜੇ) ਇਸ ਬਾਰੇ ਗੁੰਝਲ ਹੈ।

ਜੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਯੋਜਨਾ ਅਨੁਸਾਰ ਕੀਤਾ ਹੋਵੇ, ਫਿਰ ਵੀ ਤੁਸੀਂ ਗਲਤ ਹੁੰਦੇ। ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕੀਤਾ, ਤਾਂ ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਸਪੱਸ਼ਟ ਦਿਸ਼ਾ ਹੈ: “Recent Filters” ਅਤੇ “Shareable Links” ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ, ਅਤੇ ਸਟੋਰੇਜ ਮਾਡਲ ਨੂੰ ਸਧਾਰੋ। ਤੁਸੀਂ ਲਿਖਿਆ ਕੋਡ ਨਿਕਾਰਾਤਮਕ ਨਹੀਂ—ਉਹ ਇਕ કਦਮ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਅਗਲਾ ਕੀ ਬਣਾਯਾ ਜਾਵੇ।

ਮਕਸਦ ਤਬਦੀਲੀ ਦੀ ਭਵਿੱਖਵਾਣੀ ਨਹੀਂ—ਮਗਰ workflow ਨੂੰ ਐਸਾ ਡਿਜ਼ਾਇਨ ਕਰਨਾ ਹੈ ਕਿ ਤਬਦੀਲੀ ਸਧਾਰਨ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਉਤਪਾਦਕ ਹੋਵੇ।

ਅਧੂਰਾ ਕੰਮ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣ ਦੇ ਤਰੀਕੇ

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

ਛੋਟਾ ਰਾਹ ਸਪષ્ટ ਬਣਾਓ

ਸਭ ਤੋਂ ਸਾਦਾ ਸੁਰੱਖਿਆ ਕਦਮ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਜਿੱਥੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਉਸਨੂੰ ਨਾਮ ਦਿਓ। ਕਮਿਟ ਜਾਂ ਟਿਕਟਾਂ ਵਿੱਚ “hack”, “prototype”, ਜਾਂ “v1” ਵਰਗੇ ਲੇਬਲ ਵਰਤੋਂ ਤਾਂ ਜੋ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ ਜਾਂ ਕੋਈ ਟੀਮੀ ਮੈਂਬਰ ਇੱਕ ਛੋਟੀ ਪੈਚ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਦੀ ਡਿਜ਼ਾਇਨ ਨਾ ਮੰਨੇ।

ਜੇ ਤੁਸੀਂ ਇਕਲੌਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਵੀ ਇਹ ਮੱਛੀ ਮਾਮਲਾ ਹੈ। ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ, ਤੁਸੀਂ ਯਾਦ ਨਹੀਂ ਰੱਖੋਗੇ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਇरਾਦਤੀ ਸਨ ਅਤੇ ਕਿਹੜੇ “ਸਿਰਫ ਹੁਣ ਲਈ”।

ਤੁਰੰਤ “ਰਸੀਦ” ਬਣਾਓ

ਛੋਟੇ ਰਾਹ ਠੀਕ ਹਨ; ਭੁੱਲੇ ਹੋਏ ਛੋਟੇ ਰਾਹ ਮਹਿੰਗੇ ਪੈਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਇਕ ਰਾਹ ਬਣਾਉਂਦੇ ਹੋ, ਤੁਰੰਤ ਇਕ ਫਾਲੋਅੱਪ ਟਾਸ्क ਜੋੜੋ—ਜਦੋਂ ਪ੍ਰਸੰਗ ਤਾਜ਼ਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ “ਠੀਕ” ਵਰਜਨ ਕਿਹੜਾ ਹੋਵੇਗਾ।

ਇੱਕ ਉਪਯੋਗੀ ਫਾਲੋਅਪ ਟਾਸਕ ਨਿਰਧਾਰਤ ਅਤੇ ਟੈਸਟ-ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

• ਹਾਰਡ-ਕੋਡ ਕੀਤੀ ਸੀਮਾ ਨੂੰ ਕੰਫਿੱਗ + ਵੈਲੀਡੇਸ਼ਨ ਨਾਲ ਬਦਲੋ
• ਟਾਈਮਆਊਟ ਅਤੇ ਰੀਟ੍ਰਾਈ ਰਣਨੀਤੀ ਲਈ ਐਰਰ ਹੈਂडलਿੰਗ ਜੋੜੋ
• ਅਸਥਾਈ ਫਲੈਗ ਹਟਾਓ ਅਤੇ ਸਟੋਰਡ ਡੇਟਾ ਮਾਈਗਰੇਟ ਕਰੋ

ਅਨੇਕ ਧਾਰਣਾਵਾਂ ਨੂੰ ਲਿਖੋ ਤਾਂ ਜੋ ਉਹ ਤੁਹਾਨੂੰ ਕੱਟ ਨਾ ਮਾਰ੍ਹਣ

ਜਿਆਦਾਤਰ ਹੈਕ ਛੁਪੀਆਂ ਧਾਰਣਾ ਉੱਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਛੋਟੀ ਡੇਟਾ ਸਾਈਜ਼, ਘੱਟ ਟ੍ਰੈਫਿਕ, ਇਕ ਯੂਜ਼ਰ, ਮਿੱਤਰ ਇਨਪੁਟ। ਟਿਕਟ ਦਾ ਵਰਣਨ, ਛੋਟੀ ਡੌਕ, ਜਾਂ ਵਰਕਅਰਾਊਂਡ ਦੇ ਨੇੜੇ ਇੱਕ ਟਿੱਪਣੀ ਵਿੱਚ ਉਹ assumptions ਲਿਖੋ।

ਇਹ ਬੁਰੋਕਰੇਸੀ ਨਹੀਂ—ਇਹ ਇੱਕ ਟ੍ਰਿਗਰ ਹੈ ਜਦੋਂ ਕੋਡ ਤਬਦੀਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਧਾਰਣਾ ਸਚ ਨਹੀਂ ਰਹਿੰਦੀ (ਜਿਵੇਂ “ਸਿਰਫ 100 ਰਿਕਾਰਡ”), ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਦਸਤਾਵੇਜ਼ ਹੈ ਕਿ ਕਿਉਂ ਛੋਟਾ ਰਾਹ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।

ਇੱਕ ਹਲਕੀ “ਜਾਣਿਆ-ਮਸਲੇ” ਲਿਸਟ ਰੱਖੋ

ਖਤਰੇ ਅਤੇ ਰੱਗੜੀਆਂ ਦੀ ਇੱਕ ਛੋਟੀ, ਦਿੱਖਣਯੋਗ ਲਿਸਟ ਬਣਾਓ ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕੇ:

• ਵਾਧੇ ਦੇ ਤਹਿਤ ਕੀ ਟੁੱਟ ਸਕਦਾ ਹੈ?
• ਕੀ ਇਰਾਦਤੀ ਤੌਰ 'ਤੇ ਅਧੂਰਾ ਹੈ?
• ਕਿਸ ਨੂੰ ਧਿਆਨ ਦੀ ਲੋੜ ਹੈ ਇਸਨੂੰ “v1” ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ?

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

ਗਾਰਡਰੇਲ: ਜਿੱਥੇ ਤੁਸੀਂ wing ਨਹੀਂ ਕਰ ਸਕਦੇ

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

ਆਪਣੇ “ਗੈਰ-ਮੁਆਫੀ” ਚੁਣੋ

1–2 ਸ਼੍ਰੇਣੀਆਂ ਚੁਣੋ ਜਿੱਥੇ ਤੁਸੀਂ ਨਹੀਂ improvisation ਕਰੋਗੇ:

• ਸੁਰੱਖਿਆ (auth, access control, secrets, rate limits)
• ਪ੍ਰਾਈਵੇਸੀ (PII ਹੇਅਂਡਲਿੰਗ, consent, retention)
• ਭੁਗਤਾਨ (idempotency, retries, receipts, fraud basics)
• ਬੈਕਅਪ (restore ਟੈਸਟ ਕੀਤੀ ਹੋਈ, ਨਾ ਕਿ ਸਿਰਫ ਬਣਾਈ ਗਈ)

ਤੁਹਾਨੂੰ enterprise compliance ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਰੇਖਾਵਾਂ ਦੀ ਲੋੜ ਹੈ: ਜੇ ਤੁਸੀਂ ਗੈਰ-ਮੁਆਫੀ 'ਤੇ ਕੰਮ ਕਰੋ, ਤਾਂ ਤੁਸੀਂ ਧੀਰੇ ਹੋ, ਸਮੀਖਿਆ ਕਰੋ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ।

ਸਾਰੇ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਨਾ ਕਰੋ—ਸਿਰਫ ਦਰਦ ਵਾਲੀਆਂ

ਉਹ ਜਗਹਾਂ ਤੇ ਮੁੱਢ-ਟੈਸਟ ਜੋ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ ਉੱਤੇ ਮੁੱਖ ਤੌਰ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹਨ:

• ਲੌਗਇਨ/ਸਾਇਨਅਪ ਅਤੇ ਅਨੁਮਤੀ ਜਾਂਚ
• ਕੋਈ ਵੀ ਕੋਡ ਜੋ ਪੈਸੇ ਲਿਖਦਾ ਹੈ
• ਡੇਟਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਾਂ ਬਲਕ ਏਡੀਟ
• “ਇੱਕ-ਰਾਹ ਦਰਵਾਜੇ” (ਡਿਲੀਟ, ਈਮੇਲ, ਅਲਟ-ਵੈਪਤ ਰਾਜ)

ਕੁਝ ਫੋਕਸਡ ਟੈਸਟਾਂ ਨਾਲ ਉਹ ਬਗ ਰੋਕੇ ਜਾ ਸਕਦੇ ਹਨ ਜੋ ਭਰੋਸਾ ਨੁਕਸਾਨ ਕਰਦੇ ਹਨ।

ਸੇਫ਼ ਸ਼ਿਪ: ਫੀਚਰ ਫਲੈਗ, ਸਟੇਜ, ਅਤੇ ਰੋਲਬੈਕ

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

ਖਤਰਨਾਕ ਬਦਲਾਵਾਂ ਲਈ ਰੋਲਬੈਕ ਯੋਜਨਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਸਪਸ਼ਟ ਕਰੋ: ਤੁਸੀਂ ਕਿਹੜੇ ਵਰਜਨ 'ਤੇ ਵਾਪਸ ਜਾਵੋਗੇ, ਕਿਹੜਾ ਡੇਟਾ ਪ੍ਰਭਾਵਿਤ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੇਪਸ ਦੀ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕਰੋਗੇ। ਜੇ ਰੋਲਬੈਕ ਅਸੰਭਵ ਹੈ, ਤਾਂ ਉਸ ਬਦਲਾਅ ਨੂੰ ਜ਼ਿਆਦਾ ਖਤਰਨਾਕ ਮੰਨੋ ਅਤੇ ਵਾਧੂ ਸਮੀਖਿਆ ਜੋੜੋ।

ਜੇ ਤੁਸੀਂ ਇੱਕ ਹਲਕੀ ਚੈੱਕਲਿਸਟ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਆਪਣੀ /release-notes ਜਾਂ /runbook ਪੇਜ਼ ਦੀ ਲਿੰਕ ਰੱਖੋ ਅਤੇ ਸਿੱਖਣ ਦੇ ਸਮੇਂ ਅਨੁਸਾਰ ਇਸ ਨੂੰ ਅਪਡੇਟ ਰੱਖੋ।

ਟੈਕਨੀਕੀ ਡੇਬਟ ਬਿਨਾਂ ਦੋਸ਼ ਭਾਵ ਦੇ

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

ਕਰਜ਼ਾ ਇੱਕ ਸੰਦ ਹੈ, ਨਾਂ ਕਿ ਇੱਕ ਵਿਅਕਤੀਗਤ ਖਾਮੀ

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

ਇਹ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਕਦੋਂ ਵਧ ਰਿਹਾ ਹੈ

ਇਹ عملي ਲੱਛਣ ਵੇਖੋ:

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

ਜਦੋਂ ਇਹ ਨਿਸ਼ਾਨ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ, ਤੁਹਾਡਾ ਕਰਜ਼ਾ ਬਿਆਜ ਵਿਰੋਧ ਕਰ ਰਿਹਾ ਹੈ।

ਇਕ ਛੋਟੀ ਲਿਸਟ ਨਾਲ ਇਸਨੂੰ ਟਰੈਕ ਕਰੋ

ਜਿਆਦਾ ਵੱਡੇ ਰੀਰਾਈਟ ਦੀ ਯੋਜ਼ਨਾ ਨਾ ਬਣਾਓ। ਇੱਕ ਛੋਟੀ “Debt List” (5–15 ਆਈਟਮ) ਰੱਖੋ ਜੋ ਸਕੈਨ ਕਰਨ ਯੋਗ ਹੋਵੇ। ਹਰ ਆਈਟਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਵੇ:

• ਕੀ ਪੀੜਾ ਹੈ (ਉਦਾਹਰਨ: “Checkout validation 3 ਜਗ੍ਹਾਂ ਨਕਲ ਹੋਈ”)
• ਪ੍ਰਭਾਵ (ਗਤੀ, ਭਰੋਸਾ, ਗਾਹਕ ਦਰਦ)
• ਇੱਕ ਛੋਟਾ ਅਗਲਾ ਕਦਮ (ਨਹੀਂ “ਪੇਮੈਂਟ ਰੀਰਾਈਟ”, ਬਲਕਿ “ਵੈਲਿਡੇਸ਼ਨ ਫੰਕਸ਼ਨ ਕੇਂਦਰੀ ਕਰੋ”)

ਇਹ ਅਸਪਸ਼ਟ ਦੋਸ਼ ਨੂੰ ਪ੍ਰਬੰਧਯੋਗ ਕੰਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਇੱਕ ਭੁਗਤਾਨ ਰਿਧਮ ਨਿਰਧਾਰਿਤ ਕਰੋ

ਇੱਕ ਡਿਫੋਲਟ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਪੱਕਾ ਕਰੋ। ਇੱਕ ਆਮ ਨਿਯਮ ਹੈ ਹਰੇਕ ਚੱਕਰ ਦਾ 20% (ਜਾਂ ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਦਿਨ) ਡੇਬਟ ਦੀ ਭੁਗਤਾਨੀ ਲਈ: ਸਫਾਈ, ਖ਼ਤਰਨਾਕ ਖੇਤਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਟੈਸਟ, ਮਰੇ ਹੋਏ ਕੋਡ ਨੂੰ ਹਟਾਉਣਾ, ਗੁੰਝਲਦਾਰ ਪ੍ਰਵਾਹਾਂ ਨੂੰ ਸਧਾਰਨਾ। ਜੇ ਡੈਡਲਾਈਨ ਤੰਗ ਹੋ, ਤਾਂ ਸਕੋਪ ਘਟਾਓ—ਪਰ ਰਿਧਮ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੋ। ਨਿਰੰਤਰ ਰੱਖ-ਰਖਾਵ ਵੀ ਵਾਰ-ਵਾਰ "ਡੇਬਟ ਬੋਨਫਾਇਰ" ਤੋਂ ਵਧੀਆ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਹੁੰਦਾ।

ਵਰਕਫਲੋਅ ਵਿਹਾਰਕ: ਛੋਟਾ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਵਧਾਓ

ਵਾਇਬ ਕੋਡਿੰਗ ਉਸ ਸਮੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੇ ਪਹਿਲੇ ਵਰਜਨ ਨੂੰ ਇੱਕ 'ਚਾਲ' ਸਮਝਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਸਮਾਰਕ। مقصد ਉਹ ਚੀਜ਼ ਦੇਣਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਉਪਯੋਗੀ ਹੋਵੇ, ਫਿਰ ਅਸਲ ਵਰਤੋਂ ਅਗਲੇ ਨਿਰਣਿਆਂ ਨੂੰ ਦਿਖਾਏ।

1) ਸਭ ਤੋਂ ਛੋਟਾ ਉਪਯੋਗੀ ਵਰਜਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਅਸਲ MVP)

“ਉਹ ਸਭ ਫੀਚਰ ਜੋ ਅਸੀਂ ਅਖੀਰ ਵਿੱਚ ਚਾਹੁੰਦੇ ਹਾਂ” ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਇੱਕ ਕੰਕ੍ਰੀਟ ਕੰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਹੜਾ end-to-end ਹੋਵੇ।

ਇੱਕ ਚੰਗੀ MVP ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:

• ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਯੂਜ਼ਰ ਐਕਸ਼ਨ (ਉਦਾਹਰਨ, “ਨੋਟ ਬਣਾਓ ਅਤੇ ਸੰਭਾਲੋਂ”)
• ਇੱਕ ਸਫਲਤਾ ਮੈਟਰਿਕ (“ਇਹ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਲੋਡ ਹੁੰਦਾ ਹੈ”)
• ਇੱਕ ਸੀਮਾ (“ਹੁਣ ਤੱਕ ਖਾਤੇ ਨਹੀਂ”)

ਜੇ MVP ਇੱਕ ਵਾਕ ਵਿੱਚ ਨਹੀਂ ਫਿੱਟ ਹੁੰਦਾ, ਤਾਂ ਇਹ ਸ਼ਾਇਦ v2 ਹੈ।

2) ਪ੍ਰਯੋਗਾਂ ਨੂੰ ਸਮਾਂ-ਸੀਮਾ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਉਹ ਪ੍ਰਯੋਗ ਹੀ ਰਹਿਣ

ਖੋਜ ਮੁੱਲਵਾਨ ਹੁੰਦੀ ਹੈ ਜਦ ਤੱਕ ਇਹ ਚੁਪਚਾਪ ਕਈ ਹਫ਼ਤੇ ਦੀ ਲੰਮਾ ਦੌੜ ਨਾ ਬਣ ਜਾਏ। ਇਸਤੋਂ ਬਚਣ ਲਈ ਘੰਟੇ ਜਾਂ ਦਿਨ ਦੇ ਸਮਾਂ-ਬੰਧ ਲਗਾਓ—ਹਫ਼ਤੇ ਨਹੀਂ।

ਉਦਾਹਰਣ:

• “2 ਤਰੀਕਿਆਂ ਦੀ ਕੋਸ਼ਿਸ਼ 3 ਘੰਟੇ ਲਈ, ਦਿਨ ਦੇ ਅਖੀਰ ਤੱਕ ਇੱਕ ਚੁਣੋ।”
• “UI ਇਕ ਦੁਪਹਿਰ ਵਿੱਚ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰੋ, ਇਕ ਦੋਸਤ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ।”

ਟਾਈਮਬਾਕਸਿੰਗ ਫੈਸਲੇ ਮਜ਼ਬੂਰ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਥੇਕਦਾਰ ਮਰਨ ਪੜਾਅ ਨੂੰ ਬਿਨਾਂ ਮਹਿਸੂਸ ਕੀਤੇ ਹੀ ਖਤਮ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਦਿੰਦੀ ਹੈ।

3) ਸਧਾਰਣ ਹੱਲ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲ ਸਕੋ

ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ, ਉਹ ਵਰਜਨ ਪਸੰਦ ਕਰੋ ਜੋ ਸਭ ਤੋਂ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਬਦਲਣ ਵਿੱਚ ਆਸਾਨ ਹੋਵੇ। ਇੱਕ ਬੇਹਤਰੀਨ ਪਰਿਣਾਮ ਜੋ ਤੁਸੀਂ ਬਦਲ ਸਕਦੇ ਹੋ ਉਹ ਇੱਕ ਕੁੰਜੀ ਵਾਲਾ ਵਜਸ ਹੈ।

ਪੂਛੋ: “ਜੇ ਇਹ ਟੁੱਟ ਗਿਆ, ਕੀ ਮੈਂ 10 ਮਿੰਟ ਵਿੱਚ ਇਸਨੂੰ ਸਮਝਾ ਕੇ ਠੀਕ ਕਰ ਸਕਦਾ ਹਾਂ?” ਜੇ ਨਹੀਂ, ਤਾਂ ਇਹ ਇਸ ਸਟੇਜ ਲਈ ਬਹੁਤ ਚਤੁਰ ਹੋ ਸਕਦਾ ਹੈ।

4) ਸਕੋਪ ਕਟ ਸਪਸ਼ਟ ਕਰੋ

ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਹੁਣ ਕੀ ਨਹੀਂ ਬਣਾ ਰਹੇ—ਸਚਮੁੱਚ ਲਿਖੋ।

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

ਕਿੱਥੇ ਪਲੇਟਫਾਰਮ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ (ਮਨੋਭਾਵ ਬਦਲੇ ਬਿਨਾਂ)

ਜੇ ਤੁਸੀਂ ਇੱਕ ਵਾਇਬ-ਕੋਡਿੰਗ ਪਲੇਟਫਾਰਮ ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਤਾਂ ਇਹ build→ship→learn ਲੂਪ ਨੂੰ ਹੋਰ ਤੀਕਸ ਦਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਚੈਟ ਪ੍ਰੌਂਪਟ ਤੋਂ ਇੱਕ ਕੰਮ ਕਰਦਾ ਵੈੱਬ ਐਪ (React) ਜਾਂ ਬੈਕਐਂਡ (Go + PostgreSQL) ਤੱਕ ਤੇਜ਼ੀ ਨਾਲ ਜਾ ਸਕਦੇ ਹੋ, ਫਿਰ ਫੀਡਬੈਕ ਦੇ ਆਧਾਰ 'ਤੇ ਦੁਹਰਾਅ ਕਰਦੇ ਹੋ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸ ਰਫ਼ਤਾਰ ਨੂੰ ਹਾਇਪ ਕਰੋ ਤਾਂ ਜੋ ਹਿਪੋਥੈਸਿਸਾਂ ਦੀ ਜਾਂਚ ਹੋਵੇ—ਨ ਕਿ ਗਾਰਡਰੇਲਾਂ ਨੂੰ ਛੱਡ ਕੇ। ਆਪਣੇ ਗੈਰ-ਮੁਆਫ਼ੀ (ਸੁਰੱਖਿਆ, ਗੋਪਨੀਯਤਾ, ਭੁਗਤਾਨ) ਸਪਸ਼ਟ ਰੱਖੋ, ਭਾਵੇਂ ਟੂਲਿਂਗ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਨੂੰ ਬਹੁਤ ਆਸਾਨ ਮਹਿਸੂਸ ਕਰਵਾਏ।

ਹੈਕ ਨੂੰ ਇੱਕ ਸੰਭਾਲਯੋਗ v1 ਵਿੱਚ ਬਦਲਣਾ

ਜਦੋਂ ਤੁਸੀਂ ਇਕ ਹੈਕ ਨੂੰ ਆਪਣੀ ਨਿੱਜੀ ਪ੍ਰਯੋਗ ਨੰੂ ਨਹੀਂ ਸਮਝਦੇ ਅਤੇ ਕਿਸੇ ਹੋਰ ਨੇ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ, ਤਦੋਂ ਹੀ ਉਹ v1 ਬਣਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਰੀਰਾਈਟ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਕੁਝ ਇਰਾਦਤੀ ਸੁਧਾਰ ਚਾਹੀਦੇ ਹਨ ਜੋ ਮੌਜੂਦਾ ਵਰਤਾਰ ਨੂੰ ਸਮਝਣਯੋਗ, ਨਿਗਰਾਨੀਯੋਗ ਅਤੇ ਸਹਾਰਨਯੋਗ ਬਣਾਉਣ।

"ਹੁਣ ਲਈ ਮੁਕੰਮਲ" ਚੈੱਕਲਿਸਟ

v1 ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਹਲਕੀ ਚੈੱਕਲਿਸਟ ਚਲਾਓ ਜੋ ਤੇਜ਼ੀ ਨੂੰ ਬਿਨਾਂ ਰੋਕੇ ਸਪਸ਼ਟਤਾ ਮੰਗਦੀ ਹੈ:

• ਕੀ ਕੋਈ ਹੋਰ ਇਸਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ? ਇੱਕ ਕਮਾਂਡ ਜਾਂ ਛੋਟੀ ਕਦਮਾਂ ਦੀ ਸੈੱਟ।
• ਕੀ ਧਾਰਣਾਵਾਂ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ? ਇਨਪੁੱਟ, ਵਾਤਾਵਰਣ, ਪ੍ਰਮਾਣਪੱਤਰ, ਅਤੇ “ਇਹ ਸਿਰਫ਼ ਇਸੇ ਹਾਲਤ ਵਿੱਚ ਕੰਮ ਕਰਦਾ” ਸੀਮਾਵਾਂ।
• ਜਦੋਂ ਇਹ ਫੇਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ? ਏਰਰਜ਼ ਦਿੱਖਣਯੋਗ ਅਤੇ ਕਾਰਵਾਈਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
• ਕੀ ਰੋਲਬੈਕ ਜਾਂ ਆਫ-ਸਵਿੱਚ ਹੈ? ਇੱਕ ਮੈਨੂਅਲ ਵੀ ਕੋਈ ਨਹੀਂ ਹੋਣ ਨਾਲੋਂ ਵਧੀਆ ਹੈ।
• ਕੀ ਇਸ ਵਰਜਨ ਲਈ ਸਕੋਪ ਜਮ੍ਹਾ ਕੀਤਾ ਗਿਆ ਹੈ? ਨਵੇਂ ਵਿਚਾਰ ਇੱਕ ਲਿਸਟ 'ਤੇ ਜਾਣ, ਰਿਲੀਜ਼ ਵਿੱਚ ਨਹੀਂ।

ਰੱਗੜੀਆਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ (ਜਾਣ ਬੁਝ ਕੇ)

ਇੱਕ ਸੰਭਾਲਯੋਗ v1 ਪੂਰੀ ਦਿੱਗ ਨਹੀਂ ਦਿਖਾਉਂਦਾ—ਇਹ ਸਚ ਬਿਆਨ ਕਰਦਾ ਹੈ।

ਛੋਟਾ “ਜਾਣਿਆ ਹੋਇਆ ਸੀਮਾਵਾਂ” ਨੋਟ ਬਣਾਓ ਜੋ ਜਵਾਬ ਦੇ:

• ਕੀ ਟੁੱਟਦਾ ਹੈ? ਐਜ ਕੇਸ, ਸਕੇਲਿੰਗ ਸੀਮਾਵਾਂ, ਬਰਾਉਜ਼ਰ/ਡਿਵਾਈਸ quirks।
• ਕੀ ਗੁਆਚੁਕ ਹੈ? ਓਹ ਫੀਚਰ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਉਮੀਦ ਹੋਣਗੇ।
• ਕੀ ਮੈਨੂਅਲ ਹੈ? ਉਹ ਕਦਮ ਜੋ ਇੰਸਾਨ ਨੂੰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ (ਮਨਜ਼ੂਰੀ, ਡੇਟਾ ਫਿਕਸ, ਸ਼ਡਿਊਲ ਟਾਸਕ)।

ਇਸਨੂੰ ਕੋਡ ਦੇ ਨੇੜੇ ਜਾਂ ਸਧਾਰਨ ਅੰਦਰੂਨੀ ਡੌਕ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ README ਤੋਂ ਲਿੰਕ ਕਰੋ। ਇਹ “ਟ੍ਰਾਈਬਲ ਨੋਲੇਡਜ” ਨੂੰ ਕੁਝ ਐਸਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਭਵਿੱਖ ਦਾ ਤੁਸੀਂ ਵਰਤ ਸਕੇ।

ਸ਼ੁਰੂਆਤੀ ਦੌਰ ਵਿੱਚ ਮੂਲ ਨਿਗਰਾਨੀ ਜੋੜੋ

ਤੁਹਾਨੂੰ ਇੱਕ ਮਾਨੀਟਰਿੰਗ ਪ੍ਰੋਗਰਾਮ ਦੀ ਲੋੜ ਨਹੀਂ—ਤੁਹਾਨੂੰ ਸਿਗਨਲ ਦੀ ਲੋੜ ਹੈ।

ਸ਼ੁਰੂ ਵਿੱਚ:

• ਸੰਰਚਿਤ ਲੌਗ ਮੁੱਖ ਕਾਰਵਾਈਆਂ (ਕੌਣ/ਕੀ/ਕਦੋਂ) ਲਈ, ਨਾਲ ਹੀ ਏਰਰ ਵੇਰਵੇ।
• ਏਰਰ ਟ੍ਰੈਕਿੰਗ ਤਾਂ ਜੋ ਕਰੈਸ਼ ਕਿਸੇ ਦੀ ਰਿਪੋਰਟ ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੇ।
• ਕੁਝ ਕਾਊਂਟਰ: ਸਾਈਨ-ਅੱਪ, ਸਫਲ ਚਲਾਵਾਂ, ਅਸਫਲ ਚਲਾਵਾਂ, ਜੇ ਲਾਗੂ ਹੋਵੇ ਤਾਂ ਲੈਟੈਂਸੀ।

ਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਜਦੋਂ ਕੋਈ ਕਹਿੰਦਾ ਹੈ “ਇਹ ਕੰਮ ਨਹੀਂ ਕੀਤਾ,” ਤੁਸੀਂ ਮਿੰਟਾਂ ਵਿੱਚ ਕਾਰਨ ਲੱਭ ਸਕੋ ਨਾ ਕਿ ਘੰਟਿਆਂ ਵਿੱਚ।

ਇੱਕ ਸਧਾਰਣ ਸਪੋਰਟ ਰਾਸ਼ਤਾ ਬਣਾਓ

ਜੇ ਯੂਜ਼ਰ ਮੁੱਦੇ ਰਿਪੋਰਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਹ ਚੁਪਚਾਪ ਚਲੇ ਜਾਣਗੇ।

ਇੱਕ ਚੈਨਲ ਚੁਣੋ ਅਤੇ ਇਸਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ:

• ਇੱਕ ਛੋਟਾ ਫੀਡਬੈਕ ਫਾਰਮ
• ਇੱਕ ਸਮਰਪਿਤ ਈਮੇਲ ਐਲਿਆਸ
• “ਰਿਪੋਰਟ ਪ੍ਰਾਬਲਮ” ਲਿੰਕ ਜੋ ਇੱਕ ਇਸ਼ੂ ਟੈਮਪਲੇਟ ਖੋਲ੍ਹਦਾ ਹੈ

ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਕੌਣ ਟ੍ਰਾਇਜ ਕਰੇਗਾ, ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਜਵਾਬ ਦੇਣਾ ਹੈ, ਅਤੇ “ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਠੀਕ ਕਰਾਂਗੇ” ਦਾ ਕੀ ਅਰਥ ਹੈ। ਇਹ ਹੀ ਵੇਲਾ ਹੈ ਜਦੋਂ ਇੱਕ ਹੈਕ ਨਾਜੁਕ ਰੰਗ ਤੋਂ ਇਕ ਪ੍ਰੋਡਕਟ ਬਣਦਾ ਹੈ।

ਰੀਫੈਕਟਰਿੰਗ ਜਰੂਰੀ ਵੇਲੇ (ਬਿਨਾਂ ਅਨੰਤ ਰੀਰਾਈਟ)

ਰੀਫੈਕਟਰਿੰਗ ਉਹ ਹੈ ਜੋ ਵਾਇਬ ਕੋਡਿੰਗ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਬਿਨਾਂ fragile ਸ਼ਾਰਟਕੱਟ ਪੈਦਾ ਕੀਤੇ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਇਸਨੂੰ ਛੋਟੇ, ਮਕਸਦੀ ਅੱਪਗਰੇਡਾਂ ਵੱਜੋਂ ਲਓ—ਨ ਕਿ ਇਕ ਡ੍ਰਾਮੈਟਿਕ "ਮੁੜ-ਲੇਖ" ਘਟਨਾ।

ਸਿੱਖਣ ਤੋਂ ਬਾਅਦ ਰੀਫੈਕਟਰ ਕਰੋ, ਪਹਿਲਾਂ ਨਹੀਂ

ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਇਕ ਸਵਾਲ ਹੈ: ਕੀ ਇਹ ਵਰਕਫਲੋ ਵਰਤਿਆ ਜਾਵੇਗਾ? ਕਿਹੜੇ ਏਜ-ਕੇਸ ਮਹੱਤਵਪੂਰਨ ਹਨ? ਸਿੱਖਣ ਤੋਂ ਪਹਿਲਾਂ ਰੀਫੈਕਟਰ ਕਰਨ ਨਾਲ ਤੁਸੀਂ ਅਜਿਹੀਆਂ ਧਾਰਣਾਵਾਂ ਨੂੰ ਪਾਲਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨਾਲ ਟਕਰਾਅ 'ਤੇ ਟਿਕਦੀਆਂ ਨਹੀਂ।

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

ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਹੈਕ ਨੂੰ ਪਹਿਲਾਂ ਬਦਲੋ

ਸਾਰੇ ਹੈਕ ਇੱਕੋ ਜਿਹੇ ਨਹੀਂ। ਕੁਝ ਕੁਰੇਕਾ ਹਨ ਪਰ ਸੁਰੱਖਿਅਤ; ਹੋਰ ਚੁਪਚਾਪ ਸਮੇਂ ਬੰਬ ਹਨ।

ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ ਜੋ ਦੋਹਾਂ ਹੀ ਉੱਚ ਪ੍ਰਭਾਵ ਅਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਫੇਲ ਹੋਣ ਵਾਲੇ ਹਨ:

• ਕੁਝ ਵੀ ਜੋ ਡੇਟਾ ਗੁੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਗਲਤ ਰੀਤ ਨਾਲ ਪੈਸਾ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਨਿੱਜੀ ਜਾਣਕਾਰੀ ਪ੍ਰਕਟ ਕਰ ਸਕਦਾ ਹੈ
• ਇੱਕ ਵਰਕਅਰਾਊਂਡ ਜੋ ਹਰ ਵਾਰੀ ਕਿਸੇ ਨਵੀਂ ਵਿਕਲਪ ਜਾਂ ਗ੍ਰਾਹਕ ਟਾਈਪ ਜੋੜਨ 'ਤੇ ਟੁੱਟ ਜਾਂਦਾ ਹੈ
• ਇੱਕ ਮੈਨੂਅਲ ਕਦਮ ਜੋ ਇਕ ਹੀ ਵਿਅਕਤੀ "ਯਾਦ ਕਰਦਾ" ਹੈ

ਸਭ ਤੋਂ ਖਤਰਨਾਕ ਹੈਕ ਹਟਾਉਣਾ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਆ ਅਤੇ ਆਰਾਮ ਦਿੰਦਾ ਹੈ।

ਸਵਾਦ ਲਈ ਰੀਰਾਈਟ ਤੋਂ ਬਚੋ

ਰੀਰਾਈਟ ਖੁਸ਼ਨੁਮਾ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹ ਸਾਫ਼ ਲੱਗਦੀ ਹੈ। ਪਰ “ਮੈਨੂੰ ਇਹ ਕੋਡ ਪਸੰਦ ਨਹੀਂ” ਇੱਕ ਵਪਾਰਿਕ ਨਤੀਜਾ ਨਹੀਂ। ਰੀਫੈਕਟਰ ਨੂੰ ਨਤੀਜਿਆਂ 'ਤੇ ਲੱਖੋ: ਘੱਟ ਬੱਗ, ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ, ਸਪਸ਼ਟ ਮਾਲਕੀ, ਆਸਾਨ ਟੈਸਟਿੰਗ, ਸਧਾਰਨ ਓਨਬੋਰਡਿੰਗ। ਜੇ ਤੁਸੀਂ ਨਤੀਜਾ ਨਾਂ ਦੱਸ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਸ਼ਾਇਦ ਸਿਰਫ਼ ਸਟਾਈਲ ਲਈ ਰੀਫੈਕਟਰ ਕਰ ਰਹੇ ਹੋ।

ਪਤਲੇ ਟੁਕੜੇ ਵਰਤੋਂ, ਸਭ ਕੁਝ ਨਹੀਂ ਤਬਦੀਲ ਕਰੋ

ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਹਟਾਉਣ ਦੀ ਬਜਾਏ, ਇੱਕ ਤੰਗ ਰਸਤੇ ਨੂੰ end-to-end ਸੁਧਾਰੋ।

ਉਦਾਹਰਨ: ਪੁਰਾਣਾ ਫਲੋ ਕਾਮ ਕਰਦਾ ਰਹਿਣ ਦਿਓ, ਪਰ “Invoice ਬਣਾਉ” ਰਾਸ਼ਤੇ ਨੂੰ ਹੀ ਰੀਫੈਕਟਰ ਕਰੋ—ਵੈਲੀਡੇਸ਼ਨ ਜੋੜੋ, ਇੱਕ ਡਿਪੈਂਡੈਂਸੀ ਅਲੱਗ ਕਰੋ, ਕੁਝ ਟੈਸਟ ਲਿਖੋ—ਫਿਰ ਅਗਲਾ ਟੁਕੜਾ ਕਰੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਸੁਧਰਿਆ ਰਸਤਾ ਡਿਫਾਲਟ ਬਣ ਜਾਵੇਗਾ ਅਤੇ ਪੁਰਾਣਾ ਕੋਡ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਫੇਰ ਹੋ ਜਾਵੇਗਾ।

ਕਦੋਂ ਧੀਮੇ ਹੋ ਕੇ ਸਾਫ਼ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ

ਵਾਇਬ ਕੋਡਿੰਗ ਰਫ਼ਤਾਰ ਨੂੰ ਇਨਾਮ ਦਿੰਦੀ ਹੈ, ਪਰ ਗਤੀ ਪ੍ਰਗਤੀ ਨਹੀਂ ਹੈ। ਕਈ ਵਾਰੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਰੁਕ ਕੇ ਜੋੜ-ਤੋੜ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਅਗਲੇ ਕੁਝ ਬਦਲਾਅ ਸਸਤੇ ਹੋ ਜਾਣ।

ਲਾਲ ਝੰਡੀ ਜੋ “ਰੁਕ ਕੇ ਠੀਕ ਕਰੋ” ਕਹਿੰਦੀ ਹੈ

ਜੇ ਤੁਸੀਂ ਇਹ ਨਿਸ਼ਾਨ ਵੇਖ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਹੁਣ ਸਫਾਈ ਵੱਲ ਵੱਲ ਵੱਧ ਰਹੇ ਹੋ—ਤੁਹਾਡੀ ਧੀਲੀ ਆਦਤ ਸੌਭਾ ਨਹੀਂ ਦੇ ਰਹੀ:

• ਬਾਰ-ਬਾਰ ਆਊਟੇਜ ਜਾਂ ਇਕੋ ਜਿਹਾ ਬੱਗ ਹਰ ਦਿਨ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ
• ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ (ਕੁੰਜੀਆਂ ਖੁਲੀਆਂ, ਢਿੱਲਾ auth, ਬਿਨਾਂ ਸਮੀਖਿਆ ਦੇ permissions)
• ਰਿਲੀਜ਼ ਰੁੱਕ ਰਹੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੋਡ ਬਦਲਣ ਲਈ ਬਹੁਤ ਨਾਜ਼ੁਕ ਹੈ
• ਗਾਹਕ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦੇ performance regressions ਜੋ ਵਾਪਰ ਰਹੇ ਹਨ
• ਹੱਥ-ਕੰਮਾਂ ਦੀ ਇਕ ਵਧਦੀ ਗਿਣਤੀ ਜੋ ਸਿਰਫ ਇਕ ਵਿਅਕਤੀ ਜਾਣਦਾ ਹੈ

“ਰੁਕ ਕੇ ਠੀਕ ਕਰੋ” ਵਸ ਮੁਕਾਬਲਾ ਕੀਟਾ vs “ਚਲਦੇ ਰਹੋ”

ਇੱਕ ਉਪਯੋਗੀ ਨਿਯਮ: ਜਦੋਂ ਮੌਜੂਦਾ ਗੜਬੜ ਅਗਲੇ ਬਦਲਾਅ ਨੂੰ ਅਨਿਸ਼ਚਿਤ ਕਰ ਦੇਵੇ ਤਾਂ ਰੁਕੋ ਅਤੇ ਠੀਕ ਕਰੋ।

ਰੁਕ ਕੇ ਠੀਕ ਕਰਨ ਦੇ ਪਲ:

• ਇੱਕ ਬੱਗ ਡੇਟਾ ਲੋਸ, ਗੋਪਨੀਯਤਾ ਮਸਲੇ, ਜਾਂ ਗਲਤ ਬਿੱਲਿੰਗ ਕਰ ਸਕਦਾ ਹੈ
• ਤੁਸੀਂ ਕਿਸੇ ਚੇਜ਼ ਨੂੰ ਪ੍ਰੋਡ 'ਚ ਟੈਸਟ ਕੀਤੇ ਬਿਨਾਂ ਜਾਂਚ ਨਹੀਂ ਸਕਦੇ
• ਇੱਕ ਛੋਟੀ ਸਹੀ ਕਰਨ ਲਈ 5 ਅਲੱਗ ਫਾਈਲਾਂ ਛੇੜਨੀਆਂ ਪੈਂਦੀਆਂ ਅਤੇ ਹਮੇਸ਼ਾ ਕੁਝ ਟੁੱਟ ਜਾਂਦਾ

ਚਲਦੇ ਰਹਿਣ ਦੇ ਪਲ:

• ਮੁੱਦਾ ਸਿਰਫ਼ ਨਜ਼ਾਰਾ ਹੈ ਜਾਂ ਅੰਦਰੂਨੀ ਟੂਲ ਲਈ ਹੈ ਜਿਸਦਾ ਇੱਕ ਸਪਸ਼ਟ ਵਰਕਅਰਾਊਂਡ ਹੈ
• ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਅਸਥਾਈ ਹੈਕ ਹੈ ਜੋ ਸੰਗ੍ਰਹਿਤ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਹਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ
• ਖਤਰਾ ਸਮਝਿਆ ਹੋਇਆ, ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਸਮੇਂ-ਬੱਧ ਹੈ

ਕਿੱਸ ਤਰ੍ਹਾਂ ਇਹ ਟਰੇਡਆਫ਼ ਸਾਂਝਾ ਕਰੋ

ਖਰਚ, ਜੋਖਮ, ਅਤੇ ਲਾਭ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਵੋ। “ਸਾਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ” ਕਹਿਣ ਦੀ ਥਾਂ, ਕਹੋ:

• ਹੁਣ ਕੀ ਹੋ ਰਿਹਾ (ਉਦਾਹਰਨ: “migrations ਕਰਕੇ deploy ਹਰ ਹਫ਼ਤੇ fail ਹੋ ਰਹੇ ਹਨ”)
• ਪ੍ਰਭਾਵ (ਖੋਇਆ ਸਮਾਂ, ਯੂਜ਼ਰ ਨੁਕਸਾਨ, ਰੇਵਨਿਊ ਰਿਸ਼ਕ)
• ਸਭ ਤੋਂ ਛੋਟਾ ਸਾਫ-ਅਪ ਜੋ ਰੁਝਾਨ ਬਦਲ ਦੇਵੇ (1–3 ਵਿਸ਼ੇਸ਼ ਟਾਸਕ)
• ਤੁਸੀਂ ਕੀ ਰੋਕ ਰਹੇ ਹੋ ਤੇ ਕਿਉਂ (ਅਤੇ ਕਿਉਂ ਇਹ ਲਾਭਕਾਰੀ ਹੈ)

ਅੰਤ 'ਤੇ ਇਕ ਸਧਾਰਣ ਮਨੋਭਾਵ ਸਰੰਸ਼: ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ, ਅਕਸਰ ਠੀਕ ਕਰੋ—ਪਹਿਲਾਂ ਪ੍ਰਯੋਗ ਸ਼ਿਪ ਕਰੋ, ਫਿਰ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂਂ ਘਟਾਓ ਤਾਂ ਜੋ ਉਹ ਸੰਕਲਿਤ ਨਾ ਹੋਵੇ।