Kent Beck ਅਤੇ Extreme Programming: TDD, ਇਟਰੇਸ਼ਨ, ਫੀਡਬੈਕ

ਕਿਉਂ Kent Beck ਅਤੇ XP ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹਨ

Kent Beck ਦੀ Extreme Programming (XP) ਨੂੰ ਕਈ ਵਾਰੀ ਸ਼ੁਰੂਆਤੀ ਵੈੱਬ ਯੁੱਗ ਦੀ ਕੋਈ ਚੀਜ਼ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ: ਦਿਲਚਸਪ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ, ਪਰ ਥੋੜ੍ਹਾ ਪੁਰਾਣਾ ਤੇ। ਪਰ ਉਹ ਆਦਤਾਂ ਜੋ ਆਧੁਨਿਕ ਸਾਫਟਵੇਅਰ ਟੀਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ালী ਬਣਾਉਂਦੀਆਂ ਹਨ — ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਰਿਲੀਜ਼ ਕਰਨਾ, ਯੂਜ਼ਰਾਂ ਤੋਂ ਤੇਜ਼ ਸੁਨੇਹੇ ਲੈਣਾ, ਅਤੇ ਕੋਡ ਨੂੰ ਬਦਲਣਯੋਗ ਰੱਖਣਾ — ਇਹ ਸਿੱਧੇ XP ਦੇ ਮੁੱਖ ਵਿਚਾਰਾਂ ਨਾਲ ਜੁੜਦੀਆਂ ਹਨ।

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

ਤਿੰਨ ਮੁੜ-ਮੁੜ ਆਉਣ ਵਾਲੇ ਥੀਮ

XP ਅਭਿਆਸਾਂ ਦਾ ਇੱਕ ਸੰਕਲਨ ਹੈ, ਪਰ ਤਿੰਨ ਮੁੱਖ ਥੀਮ ਬਾਰ-ਬਾਰ ਉभरਦੀਆਂ ਹਨ:

• TDD (Test-Driven Development): ਟੈਸਟਾਂ ਨੂੰ ਕੇਵਲ ਬਗ ਰੋਕਣ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਡਿਜ਼ਾਇਨ ਨੂੰ ਰੂਪ ਦੇਣ ਲਈ ਵਰਤਣਾ—ਇਹ ਤਲਾਸ਼ ਕਰਦਾ ਹੈ ਕਿ ਕੋਡ ਨਿਰਧਾਰਤ ਤਰੀਕੇ ਨਾਲ ਕੀ ਕਰੇਗਾ।
• ਇਟਰੇਸ਼ਨ: ਕੰਮ ਨੂੰ ਛੋਟੇ, ਆਮ ਤੌਰ ਤੇ ਮੁੜ-ਮੁੜ ਦੇਣਯੋਗ ਹਿੱਸਿਆਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਨਾ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਸیکھੋਂ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦਾ ਅਣ-ਪੜਤਾਲ ਕੰਮ ਨਾ ਕਰੋ।
• ਫੀਡਬੈਕ ਲੂਪ: "ਕੋਸ਼ਿਸ਼ → ਦੇਖੋ → ਸੋਧੋ" ਦੀ ਛੋਟੀ ਚੱਕਰਵੱਤ ਪ੍ਰਕਿਰਿਆ ਬਣਾ ਕੇ ਟੈਸਟ, ਜੋੜੀ-ਕਾਮ, ਇਨਟੀਗਰੇਸ਼ਨ ਅਤੇ ਅਸਲ ਯੂਜ਼ਰ ਨਤੀਜਿਆਂ ਰਾਹੀਂ ਤੇਜ਼ ਸਿੱਖਣਾ।

ਇਹ ਕਿਸ ਲਈ ਹੈ

ਜੇ ਤੁਸੀਂ ਇੰਜੀਨੀਅਰ, ਟੈਕ ਲੀਡ, ਇੰਜੀਨੀਅਰਿੰਗ ਮੈਨੇਜਰ, ਜਾਂ ਪ੍ਰੋਡਕਟ-ਮਨਸੂਬੇ ਵਾਲੇ ਪਾਠਕ ਹੋ ਜੋ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਨੇੜੇ ਮਿਲ ਕੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਤਾਂ XP ਓਹੋ ਹੀ ਸ਼ਬਦਾਵਲੀ ਦਿੰਦਾ ਹੈ ਜੋ "ਤੇਜ਼ ਅੱਗੇ ਵਧਣਾ ਬਿਨਾਂ ਸਭ ਕੁਝ ਤੋੜੇ" ਨੂੰ ਵਿਹਾਰਕ ਰੂਪ ਵਿੱਚ ਸਮਝਾਉਂਦੀ ਹੈ।

ਤੁਸੀਂ ਕੀ ਸਿੱਖੋਗੇ

ਅਖੀਰ 'ਤੇ, ਤੁਸੀਂ ਸਮਰੱਥ ਹੋਉਗੇ:

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

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

Kent Beck ਦਾ ਸੰਦਰਭ: XP ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਿਹਾ ਸੀ?

Kent Beck ਨੂੰ ਅਕਸਰ XP ਨਾਂ ਦੇਣ ਵਾਲਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ Agile ਲਹਿਰ ਨੂੰ ਰੂਪ ਦੇਣ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲਾ ਵਿਆਖਿਆਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।ਪਰ XP ਸਿਧਾਂਤਿਕ ਕਸਰਤੀ ਨਹੀਂ ਸੀ; ਇਹ ਇੱਕ ਕਾਰਗਰ ਜਵਾਬ ਸੀ ਉਹਦੀਆਂ ਖਾਸ ਪ੍ਰੇਸ਼ਾਨੀਆਂ ਲਈ: ਜਿੱਥੇ ਮੰਗਾਂ ਬਦਲਦੀਆਂ ਰਹਿੰਦੀਆਂ, ਸਾਫਟਵੇਅਰ ਟੁੱਟਦਾ ਰਹਿੰਦਾ, ਅਤੇ ਟੀਮਾਂ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਬਹੁਤ ਦੇਰ ਨਾਲ ਸਮਝਦੀਆਂ।

ਉਹ ਪ੍ਰੋਜੈਕਟ ਦਾ ਦਬਾਅ ਜਿਸਨੇ XP ਨੂੰ ਜਨਮ ਦਿੱਤਾ

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

XP ਕਿਸ ਚੀਜ਼ ਦਾ ਵਿਰੋਧ ਕਰ ਰਿਹਾ ਸੀ

XP ਦਾ ਮੁੱਖ ਦੁਸ਼ਮਣ ਸਧਾਰਨ ਤੌਰ 'ਤੇ "ਡਾਕੂਮੈਂਟੇਸ਼ਨ" ਜਾਂ "ਪ੍ਰਕਿਰਿਆ" ਨਹੀਂ ਸੀ—ਇਹ ਦੇਰੀ ਵਾਲਾ ਫੀਡਬੈਕ ਸੀ।

ਭਾਰੀ, ਫੇਜ਼-ਗੇਟ ਕੀਤੀਆਂ ਵਿਧੀਆਂ ਸਿੱਖਣ ਨੂੰ ਦੇਰੀ ਨਾਲ ਮਿਲਦੀਆਂ:

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

XP ਨੇ ਆਰਡਰ ਨੂੰ ਉਲਟ ਦਿੱਤਾ: ਕਾਰਵਾਈ ਅਤੇ ਜਾਣਕਾਰੀ ਦਰਮਿਆਨ ਦਾ ਸਮਾਂ ਘਟਾ ਦੋ।ਇਸੇ ਕਰਕੇ TDD, continuous integration, refactoring, ਅਤੇ pair programming ਵਰਗੇ ਅਭਿਆਸ ਇਕੱਠੇ ਫਿੱਟ ਹੋ ਜਾਂਦੇ—ਸਭ ਫੀਡਬੈਕ ਲੂਪ ਹਨ।

XP ਕੇਵਲ "ਤੇਜ਼ ਚਲੋ" ਨਹੀਂ ਹੈ

"Extreme" ਕਹਿਣ ਦਾ ਮਕਸਦ ਚੰਗੀਆਂ ਵਿਚਾਰਧਾਰਾਵਾਂ ਨੂੰ ਹੋਰ ਅੱਗੇ ਧਕਣਾ ਸੀ: ਪਹਿਲਾਂ ਟੈਸਟ ਕਰੋ, ਜ਼ਿਆਦਾ ਅਕਸਰ ਇਨਟੀਗਰੇਟ ਕਰੋ, ਲਗਾਤਾਰ ਗੱਲ-ਬਾਤ ਕਰੋ, ਅਤੇ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ डਿਜ਼ਾਈਨ ਨੂੰ ਸੁਧਾਰੋ।XP ਉਹਨਾਂ ਮੁੱਲਾਂ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ (ਜਿਵੇਂ ਕਿ ਸੰਚਾਰ ਅਤੇ ਸਾਦਗੀ), ਨਾ ਕਿ ਕੋਰਟ-ਕੱਟ ਛੂਟ।ਲਕੜੀਮੰਤਵ ਹੈ ਸਥਿਰ ਗਤੀ: ਸਹੀ ਚੀਜ਼ ਬਣਾਉ ਅਤੇ ਬਦਲਾਅ ਜਾਰੀ ਰਹਿਣ ਦੌਰਾਨ ਉਹ ਕੰਮ ਕਰਦੀ ਰਹੇ।

ਅਭਿਆਸਾਂ ਦੇ ਪਿੱਛੇ ਮੁੱਲ

XP ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਚਾਲਾਕੀਆਂ ਦਾ ਸંગ્રਹ ਨਹੀਂ।Kent Beck ਨੇ ਇਸਨੂੰ ਮੁੱਲਾਂ ਦੇ ਇੱਕ ਸੈੱਟ ਵਜੋਂ ਰੱਖਿਆ ਜੋ ਫੈਸਲੇਾਂ ਨੂੰ ਰਾਹ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਕੋਡਬੇਸ ਰੋਜ਼ਾਨਾ ਬਦਲ ਰਿਹਾ ਹੋਵੇ।ਅਭਿਆਸਾਂ—TDD, pair programming, refactoring, continuous integration—ਉਸ ਸਮੇਂ ਤੇ ਜ਼ਿਆਦਾ ਸਮਝਦਾਰ ਬਣਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਉਹ ਕਿਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਦੀ ਰੱਖਿਆ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਨ।

ਪੰਜ XP ਮੁੱਲ (ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ)

Communication (ਸੰਚਾਰ) ਦਾ ਮਤਲਬ ਹੈ "ਜਾਣਕਾਰੀ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਮਨ ਵਿੱਚ ਫਸੇ ਨਾ ਰਹਿਣੇ"।ਇਸ ਲਈ XP pair programming, ਸਾਂਝੀ ਕੋਡ ਮਲਕੀਅਤ, ਅਤੇ ਛੋਟੇ-ਛੋਟੇ ਚੈਕ-ਇਨ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ।ਜੇ ਕੋਈ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਮਹੱਤਵਪੂਰਕ ਹੈ ਤਾਂ ਉਹ ਗੱਲ-ਬਾਤ ਅਤੇ ਕੋਡ ਵਿੱਚ ਦਿਖਾਈ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ—ਨ ਕਿ ਖਾਸ ਤਰੀਕੇ ਨਾਲ ਰੱਖੇ ਗਏ ਮਾਨਸਿਕ ਮਾਡਲ ਵਿੱਚ।

Simplicity (ਸਾਦਗੀ) ਦਾ ਮਤਲਬ ਹੈ "ਅੱਜ ਲਈ ਸਭ ਤੋਂ ਸਧਾਰਨ ਚੀਜ਼ ਕਰੋ ਜੋ ਕੰਮ ਕਰਦੀ ਹੈ"।ਇਹ small releases ਅਤੇ refactoring ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ: ਜੋ ਤੁਹਾਨੂੰ ਹੁਣ ਚਾਹੀਦਾ ਹੈ ਉਸਨੂੰ ਬਣਾਓ, ਸਾਫ਼ ਰੱਖੋ, ਅਤੇ ਅਗਲੇ ਕਦਮ ਲਈ ਅਸਲ ਵਰਤੋਂ ਨਿਰਧਾਰਿਤ ਹੋਣ ਦਿਓ।

Feedback (ਫੀਡਬੈਕ) ਦਾ ਮਤਲਬ ਹੈ "ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖੋ"।XP TDD (ਤੁਰੰਤ ਸਹੀਪਣ ਅਤੇ ਡਿਜ਼ਾਈਨ ਤੇ ਫੀਡਬੈਕ), continuous integration (ਇਨਟੀਗਰੇਸ਼ਨ ਰਿਸਕ 'ਤੇ ਤੇਜ਼ ਸੂਚਨਾ), ਅਤੇ ਨਿਯਮਤ ਗਾਹਕ/ਟੀਮ ਰਿਵਿਊ ਦੁਆਰਾ ਫੀਡਬੈਕ ਨੂੰ ਰੋਜ਼ਾਨਾ ਅਭਿਆਸ ਬਣਾਉਂਦਾ ਹੈ।

Courage (ਹਿੰਮਤ) ਦਾ ਮਤਲਬ ਹੈ "ਸਿਸਟਮ ਨੂੰ ਸੁਧਾਰਨ ਵਾਲਾ ਬਦਲਾਅ ਕਰੋ, ਭਾਵੇਂ ਉਹ ਅਸੁਖਾਦ ਹੋ"।ਹਿੰਮਤ ਹੀ refactoring ਅਤੇ ਮਰੇ ਹੋਏ ਕੋਡ ਨੂੰ ਮਿਟਾਉਣਾ ਆਮ ਬਣਾਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਡਰਾਉਣਾ।ਚੰਗੇ ਟੈਸਟ ਅਤੇ CI ਉਸ ਹਿੰਮਤ ਨੂੰ ਤਰਕਸੰਗਤ ਬਣਾਉਂਦੇ ਨੇ।

Respect (ਆਦਰ) ਦਾ ਮਤਲਬ ਹੈ "ਲੋਕਾਂ ਲਈ ਐਸਾ ਕੰਮ ਕਰੋ ਜੋ ਟਿਕੇ"।ਇਹ pairing (ਸਹਿਯੋਗ), ਵਾਜਿਬ ਗਤਿਤੀ, ਅਤੇ ਕੋਡ ਗੁਣਵੱਤਾ ਨੂੰ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਮੰਨਣ ਵਰਗੇ ਅਭਿਆਸਾਂ ਦੇ ਪਿੱਛੇ ਹੈ।

ਮੁੱਲਾਂ ਕਿਵੇਂ ਹਕੀਕਤੀ ਤਰ੍ਹਾਂ ਵਪਾਰੀਆਂ ਫੈਸਲਿਆਂ ਨੂੰ ਰਾਹ ਦਿਖਾਉਂਦੇ ਹਨ

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

TDD ਦੀ ਉਦਭਵ ਕਹਾਣੀ: ਟੈਸਟ ਤੋਂ ਡਿਜ਼ਾਈਨ ਫੀਡਬੈਕ ਤੱਕ

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

"ਬाद ਵਿੱਚ ਟੈਸਟ" ਤੋਂ ਪਹਿਲਾਂ-ਟੈਸਟ ਅਦਤ ਤੱਕ

Kent Beck ਦੀ TDD ਨਾਲ ਅਗਵਾਈ ਇੱਕ ਸਧਾਰਨ ਪਰ ਵਿੱਕਟ ਆਦਤ ਸੀ: ਪਹਿਲਾਂ ਇੱਕ ਟੈਸਟ ਲਿਖੋ, ਉਸਨੂੰ ਫੈਲ ਹੋਣ ਦਿਖੋ, ਫਿਰ ਉਸਨੂੰ ਪਾਸ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਛੋਟਾ ਬਦਲਾਅ ਕਰੋ।ਉਹ "ਫੈਲਿੰਗ ਟੈਸਟ ਪਹਿਲਾਂ" ਨਿਯਮ ਥੀਏਟਰ ਨਹੀਂ—ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਸਾਫ਼ ਕਰਨਾ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੋਡ ਤੋਂ ਕੀ ਚਾਹੁੰਦੇ ਹੋ ਪਹਿਲਾਂ, ਫਿਰ ਤੁਸੀਂ ਫੈਸਲਾ ਕਰੋ ਕਿਵੇਂ ਕਰਨਾ ਹੈ।

Red–Green–Refactor ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ

TDD通常 Red–Green–Refactor ਵਜੋਂ ਸੰਖੇਪ ਹੁੰਦਾ ਹੈ:

• Red: ਇੱਕ ਛੋਟਾ ਬਿਹੇਵਿਯਰ ਲਈ ਟੈਸਟ ਲਿਖੋ।ਉਦਾਹਰਣ: "ਜਦੋਂ ਮੈਂ 5 ਅਤੇ 7 ਕੀਮਤ ਵਾਲੇ ਦੋ ਆਈਟਮ ਪੂਰਨ ਕਰਦਾ ਹਾਂ, ਕੁੱਲ 12 ਹੈ।" ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਫੈਲ ਦੇਖੋ।
• Green: ਉਹ ਸਧਾਰਨ ਕੋਡ ਲਿਖੋ ਜੋ ਟੈਸਟ ਪਾਸ ਕਰਾ ਦੇਵੇ (ਸ਼ਾਇਦ ਇੱਕ ਬੇਸਿਕ total() ਫੰਕਸ਼ਨ ਜੋ ਆਈਟਮਾਂ ਦੀ ਕੀਮਤ ਜੋੜਦਾ ਹੋਵੇ)।
• Refactor: ਵਿਹੇਵਿਯਰ ਨਾ ਬਦਲੇ ਬਿਨਾਂ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਕਰੋ—ਵੈਰੀਏਬਲਾਂ ਦੇ ਨਾਂ ਬਦਲੋ, ਨਕਲ ਹਟਾਓ, ਸਰਚਨਾ ਸੁਧਾਰੋ—ਫਿਰ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਕੇ ਪੱਕਾ ਕਰੋ।

ਇਹ ਸਿਰਫ "ਵਧੇਰੇ ਟੈਸਟ" ਨਹੀਂ ਸੀ

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

TDD ਨੇ ਰੋਜ਼ਾਨਾ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਕੀ ਬਦਲ ਦਿੱਤਾ

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

"ਚੰਗੇ" ਯੂਨਿਟ ਟੈਸਟ ਕਿਵੇਂ ਹੋਂਦੇ ਹਨ

ਉਹ ਯੂਨਿਟ ਟੈਸਟ ਜੋ TDD ਨੂੰ ਸਹਾਰਨ ਕਰਦੇ ਹਨ ਅਕਸਰ ਕੁਝ ਖਾਸ ਲੱਛਣਾ ਸਾਂਝੇ ਕਰਦੇ ਹਨ:

• ਤੇਜ਼: ਉਹ ਮਿਲੀਸੈਕੰਡਾਂ ਵਿੱਚ ਚੱਲਦੇ ਹਨ ਅਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ, ਹਰ ਕਮੇਟ ਤੋਂ ਪਹਿਲਾਂ ਆਸਾਨੀ ਨਾਲ ਚਲਾਏ ਜਾ ਸਕਦੇ ਹਨ।
• ਕੇਂਦਰਿਤ: ਹਰ ਟੈਸਟ ਇਕ ਵਿਹੇਵਿਯਰ ਦੀ ਜਾਂਚ ਕਰਦਾ; ਫੇਲਯਰ ਇੱਕ ਖਾਸ ਸਮੱਸਿਆ ਦੀ ਨੋਟਿਸ ਦਿੰਦਾ।
• ਪੜ੍ਹਨਯੋਗ: ਟੈਸਟ ਦਾ ਨਾਮ ਅਤੇ ਸੈਟਅਪ ਇਰਾਦਾ ("ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ") ਨੂੰ ਦੱਸਦੇ ਹਨ, ਨ ਕਿ ਸਿਰਫ ਤਰੀਕੇ।

ਇੱਕ ਮਦਦਗਾਰ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਇੱਕ ਟੈਸਟ ਕਿਸ ਲਈ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਉਹ ਜ਼ਿਆਦਾ ਵਜ਼ਨ ਨਹੀਂ ਢੋ ਰਿਹਾ।

TDD ਦਾ ਨਰਮ ਪ੍ਰਭਾਵ API ਡਿਜ਼ਾਈਨ 'ਤੇ

ਪਹਿਲਾਂ ਟੈਸਟ ਲਿਖਣ ਨਾਲ ਤੁਸੀਂ ਸਰਵਰ ਤੋਂ ਪਹਿਲਾਂ ਕਾਲਰ ਦੀ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੇ ਹੋ।ਇਸ ਨਾਲ ਅਕਸਰ Safa ਇੰਟਰਫੇਸ ਬਣਦੇ ਹਨ ਕਿਉਂਕਿ ਰੁਕਾਵਟ ਤੁਰੰਤ ਸਾਹਮਣੇ ਆ ਜਾਂਦੀ:

• ਹਰਾਨੀਜਨਕ constructors ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਪੈਰਾਮੀਟਰ ਜ਼ਾਹਰ ਹੋ ਜਾਂਦੇ।
• ਛੁਪੇ ਨਿਰਭਰਤਾਵਾਂ (globals, singletons, time, randomness) seams ਜੋੜਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੀਆਂ ਹਨ।
• ਤੁਸੀਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਛੋਟੇ, ਜੋੜ-ਯੋਗ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੀ ਪ੍ਰੀਖਿਆ ਆਸਾਨ ਹੁੰਦੀ ਹੈ।

ਅਮਲ ਵਿੱਚ, TDD ਟੀਮਾਂ ਨੂੰ ਐਸੇ APIs ਵੱਲ ਧਕੀਦਾ ਹੈ ਜੋ ਵਰਤਣ ਵਿੱਚ ਆਸਾਨ ਹੋਣ, ਸਿਰਫ ਬਣਾਉਣ ਵਿੱਚ ਨਹੀਂ।

ਆਮ ਗਲਤ ਫਹਿਮੀਆਂ

ਦੋ ਮਿਥ ਹਨ ਜੋ ਬਹੁਤ ਨਿਰਾਸ਼ਾ ਪੈਦਾ ਕਰਦੇ ਹਨ:

• "TDD ਦਾ ਮਤਲਬ ਸਭ ਕੁਝ ਟੈਸਟ ਕਰਨਾ ਹੈ." ਇਸਦਾ ਮਤਲਬ ਹੈ ਸਹੀ ਲੈਵਲ ਤੇ ਕੀਮਤੀ ਵਿਹੇਵਿਯਰਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ।ਕੁਝ ਕੋਡ ਲਈ ਇੰਟੀਗਰੇਸ਼ਨ ਟੈਸਟ ਜਾਂ ਸਧਾਰਨ ਅਸਰਸ਼ਨ ਵਧੀਆ ਹਨ।
• "ਜੇ ਅਸੀਂ TDD ਕਰਦੇ ਹਾਂ ਤਾਂ ਸਾਨੂੰ ਇੰਟੀਗਰੇਸ਼ਨ ਟੈਸਟ ਨਹੀਂ ਚਾਹੀਦੇ।" ਯੂਨਿਟ ਟੈਸਟ ਛੋਟੀ ਵਿਹੇਵਿਯਰ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ; ਇੰਟੀਗਰੇਸ਼ਨ ਟੈਸਟ ਵਾਇਰਿੰਗ, ਕੰਫਿਗਰੇਸ਼ਨ ਅਤੇ ਅਸਲੀ ਨਿਰਭਰਤਾਵਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ।

ਜਿੱਥੇ TDD ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਹੈ (ਅਤੇ ਬਦਲਣ ਲਈ ਕੀ ਕਰੋ)

TDD ਨੂੰ legacy ਕੋਡ (ਤੀਸਰਾ-ਪੱਖੀ ਨਿਰਭਰਤਾ, ਕੋਈ seams ਨਹੀਂ) ਅਤੇ UI-ਭਾਰੀ ਕੋਡ (ਇਵੈਂਟ-ਚਲਿਤ, ਰਾਜ-ਸੰਭਾਲ, framework glue) ਵਿੱਚ ਮੁਸ਼ਕਿਲ ਲੱਗ ਸਕਦੀ ਹੈ।ਇਸ ਨੂੰ ਜਬਰਦਸਤੀ ਕਰਨ ਦੇ ਬਜਾਏ:

• legacy ਕੋਡ ਲਈ, ਮੌਜੂਦਾ ਵਿਹੇਵਿਯਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ characterization tests ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਰਿਫੈਕਟਰ ਕਰੋ।
• UI-ਭਾਗਾਂ ਲਈ, ਲੋਜਿਕ ਨੂੰ ਟੈਸਟ ਕਰਨ ਯੋਗ ਯੂਨਿਟਾਂ ਵਿੱਚ ਧੱਕੋ, ਅਤੇ ਹੱਦਾਂ ਲਈ ਜ਼ਿਆਦਾ ਇੰਟੀਗਰੇਸ਼ਨ/ਐਕਸੈਪਟੈਂਸ ਟੈਸਟਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹੋ।

ਇਸ ਤਰੀਕੇ ਨਾਲ, TDD ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਡਿਜ਼ਾਈਨ ਫੀਡਬੈਕ ਟੂਲ ਬਣ ਜਾਂਦਾ—ਨ ਕਿ ਕੋਈ ਪਵਿੱਤਰਤਾ ਪ੍ਰੀਖਿਆ।

ਇਟਰੇਸ਼ਨ: ਛੋਟੇ ਬੈਚਾਂ ਵਿੱਚ ਸ਼ਿਪ ਕਰਨਾ

XP ਵਿੱਚ ਇਟਰੇਸ਼ਨ ਦਾ ਮਤਲਬ ਹੈ ਕੰਮ ਨੂੰ ਛੋਟੇ, ਸਮੇਂ-ਬੱਧ ਹਿੱਸਿਆਂ ਵਿੱਚ ਦੇਣਾ—ਇਹ ਐਸੇ ਬੈਚ ਹੁੰਦੇ ਹਨ ਜੋ ਖਤਮ, ਸਮੀਖਿਆ ਅਤੇ ਸਿੱਖੇ ਜਾ ਸਕਣ।ਇੱਕ ਵੱਡੀ ਰਿਲੀਜ਼ ਨੂੰ ਕਦਰਦੇ ਹੋਏ XP ਡਿਲਿਵਰੀ ਨੂੰ ਅਕਸਰ ਦੀ ਜਾਂਚ ਵਜੋਂ ਲੈਂਦਾ: ਕੁਝ ਛੋਟਾ ਬਣਾਓ, ਇਹ ਸਾਬਤ ਕਰੋ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ ਅਗਲਾ ਫੈਸਲਾ ਕਰੋ।

ਛੋਟੀ ਚੱਕਰਵੱਤ ਕਿਵੇਂ ਖਤਰੇ ਘਟਾਉਂਦੀ ਹੈ

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

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

ਲਘੂ ਯੋਜਨਾ: ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ + ਗ੍ਰਹਿਣਯੋਗਤਾ ਮਾਪਦੰਡ

XP ਇਟਰੇਸ਼ਨ ਯੋਜਨਾ ਜ਼ਿਆਦਾ ਸਧਾਰਨ ਹੁੰਦੀ ਹੈ।ਟੀਮਾਂ ਅਕਸਰ ਯੂਜ਼ਰ ਸਟੋਰੀਜ਼ ਵਰਤੀਆਂ ਕਰਦੀਆਂ ਹਨ—ਯੂਜ਼ਰ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਮੁੱਲ ਦੀ ਛੋਟੀ ਵਰਣਨਾ—ਅਤੇ "ਡਨ" ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ acceptance criteria ਜੋੜਦੇ ਹਨ।

ਇੱਕ ਚੰਗੀ ਸਟੋਰੀ ਇਹ ਦੱਸਦੀ ਹੈ: ਕੌਣ ਕੀ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਿਉਂ?Acceptance criteria ਵੇਖਣਯੋਗ ਵਿਹੇਵਿਯਰ ("ਜਦ ਮੈਂ X ਕਰਦਾ ਹਾਂ, ਸਿਸਟਮ Y ਕਰਦਾ ਹੈ") ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਜੋ ਬਿਨਾਂ ਵੱਡੀ ਵਿਸ਼ੇਸ਼ਤਾ ਲਿਖਣ ਦੇ ਸਭ ਨੂੰ ਇਕੱਠੇ ਲਿਆਉਂਦੀਆਂ ਹਨ।

ਕਾਰਗਰ ਤਾਲਮੇਲ ਉਦਾਹਰਨ (ਅਤੇ ਕੀ ਸਮੀਖਿਆ ਕਰਨੀ ਹੈ)

ਆਮ XP ਕੈਡੰਸ ਹਫਤਾਵਾਰੀ ਜਾਂ ਦੁ-ਹਫਤਾਵਾਰੀ ਹੁੰਦੀ ਹੈ:

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

ਹਰ ਇਟਰੇਸ਼ਨ ਦੇ ਅੰਤ 'ਤੇ, ਟੀਮ ਆਮ ਤੌਰ 'ਤੇ ਸਮੀਖਿਆ ਕਰਦੀ ਹੈ:

• ਕੀ ਸ਼ਿਪ ਕੀਤਾ (ਕੰਮ ਕਰ ਰਹੀ ਯਕੀਨੀ ਸੋਫਟਵੇਅਰ ਦਾ ਡੈਮੋ)
• ਕੀ acceptance criteria ਪੂਰੇ ਹੋਏ
• ਕਿਹੜਾ ਫੀਡਬੈਕ ਪ੍ਰਾਇਰਿਟੀ ਬਦਲਿਆ
• ਕੀ ਟੀਮ ਨੂੰ ਅਹਿਸਾਸ ਕਰਵਾਇਆ ਕਿ ਧੀਮੇ ਕਰ ਰਿਹਾ ਸੀ (ਇੱਕ ਛੋਟੀ ਰੇਟਰੋ ਜਿਸ ਵਿੱਚ ਇੱਕ ਜਾਂ ਦੋ ਵਾਜ਼ਹ ਸੁਧਾਰ)

ਮਕਸਦ ਪਰਕਿਰਿਆ ਨਹੀਂ—ਇਹ ਇੱਕ ਸਥਿਰ ਰਿਦਮ ਹੈ ਜੋ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਜਾਣਕਾਰੀ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਫੀਡਬੈਕ ਲੂਪ: XP ਦੀ ਇੰਜਣ

XP ਅਕਸਰ ਆਪਣੀਆਂ ਪ੍ਰਥਾਵਾਂ—ਟੈਸਟ, ਜੋੜੀ, CI—ਰਾਹੀਂ ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹਦਾ ਇਕੱਠਾ ਵਿਚਾਰ ਹੋਰ ਸਧਾਰਨ ਹੈ: ਬਦਲਾਅ ਕਰਨ ਅਤੇ ਇਹ ਜਾਣਨ ਦਰਮਿਆਨ ਦਾ ਸਮਾਂ ਘਟਾਓ ਕਿ ਉਹ ਚੰਗਾ ਸੀ ਜਾਂ ਨਹੀਂ।

ਫੀਡਬੈਕ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਆਉਂਦਾ ਹੈ

XP ਕਈ ਫੀਡਬੈਕ ਚੈਨਲ ਇਕੱਠੇ ਜੋੜਦਾ ਤਾਂ ਕਿ ਤੁਸੀਂ ਕਦੇ ਵੀ ਬਹੁਤ ਦੇਰ ਨਾ ਕਰੋ:

• ਟੈਸਟ (ਖਾਸ ਕਰਕੇ ਯੂਨਿਟ ਟੈਸਟ): ਵਿਹੇਵਿਯਰ ਹਜੇ ਵੀ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਦਾ ਤੁਰੰਤ ਸੰਕੇਤ।
• ਕੋਡ ਰਿਵਿਊ / ਪੇਅਰਿੰਗ: ਦੂਜੀ ਨਜ਼ਰ ਮਹਿੰਗੀ ਨਾ ਹੋਣ ਵਾਲੀ ਗਲਤ ਫਰਮੀ ਨੂੰ ਸਸਤੇ ਵਿੱਚ ਫੜ ਲੈਂਦੀ ਹੈ।
• CI ਬਿਲਡ: ਟੀਮ ਨੂੰ ਜਲਦੀ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇਨਟੀਗਰੇਸ਼ਨ ਟੁੱਟੀ ਹੈ, ਨਾ ਕਿ ਦਿਨਾਂ ਬਾਅਦ।
• ਗਾਹਕ ਡੈਮੋਜ਼ (ਜਾਂ ਸਟੇਕਹੋਲਡਰ ਚੈਕ-ਇਨ): ਇਹ ਪਛਾਣਾਂ ਕਰਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਸਹੀ ਚੀਜ਼ ਬਣਾਈ ਹੈ, ਸਿਰਫ ਇਹ ਨਹੀਂ ਕਿ ਇਹ "ਚੱਲਦੀ" ਹੈ।

ਤੇਜ਼ ਫੀਡਬੈਕ ਕਿਵੇਂ ਪੂਰਨ ਭਵਿੱਖਬਾਣੀ ਨਾਲ ਬਿਹਤਰ ਹੈ

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

ਤੇਜ਼ ਚੱਕਰ ਅਣਿਸ਼ਚਿਤਤਾ ਨੂੰ ਡੇਟਾ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।ਧੀਮਾ ਚੱਕਰ ਤਰਕ-ਵਾਦ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ।

Idea → Code → Test → Learn → Adjust → (repeat)

ਧੀਮੇ ਫੀਡਬੈਕ ਦੀ ਕੀਮਤ

ਜਦੋਂ ਫੀਡਬੈਕ ਦਿਨਾਂ ਜਾਂ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਲੈਂਦਾ ਹੈ, ਸਮੱਸਿਆਵਾਂ ਬਹੁਤ ਵਧ ਜਾਂਦੀਆਂ ਹਨ:

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

XP ਦੀ "ਇੰਜਣ" ਕੋਈ ਇਕਲ ਅਭਿਆਸ ਨਹੀਂ—ਇਹ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਵਿਚ ਇਹ ਲੂਪ ਆਪਸ ਵਿੱਚ ਇਕ ਦੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ ਤਾਂ ਜੋ ਕੰਮ ਮਿਲਦਾ-ਜੁਲਦਾ ਰਹੇ, ਗੁਣਵੱਤਾ ਉੱਚੀ ਰਹੇ, ਅਤੇ ਹੇਰਾਨੀਆਂ ਛੋਟੀਆਂ ਰਹਿਣ।

ਪੇਅਰ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ: ਰੀਅਲ-ਟਾਈਮ ਕਵਾਲਿਟੀ ਕੰٹرول

Pair programming ਨੂੰ ਅਕਸਰ "ਦੋ ਲੋਕ, ਇੱਕ ਕੀਬੋਰਡ" ਵਜੋਂ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ XP ਵਿੱਚ ਅਸਲ ਵਿਚਾਰ ਨਿਰੰਤਰ ਸਮੀਖਿਆ ਹੈ।pull request ਦੀ ਉਡੀਕ ਕਰਨ ਦੇ ਬਜਾਏ, ਫੀਡਬੈਕ ਹਰ ਮਿੰਟ ਹੁੰਦਾ: ਨਾਂ, ਕੋਨਿਆਂ, ਆਰਕੀਟੈਕਚਰ ਚੋਣਾਂ, ਅਤੇ ਇਸ ਤੋਂ ਵੀ ਕਿ ਕੀ ਬਦਲਾਅ ਕਰਨ ਵਾਲਾ ਹੈ।

ਨਿਰੰਤਰ ਰਿਵਿਊ + ਸਾਂਝਾ ਸੰਦਰਭ

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

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

ਫੀਡਬੈਕ ਲਾਭ ਜੋ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹੋ

ਕਿਉਂਕਿ ਫੀਡਬੈਕ ਲੂਪ ਤੁਰੰਤ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ ਦੇਰ ਨਾਲ ਬਾਹਰ ਨਿਕਲ ਰਹੇ ਦੋਸ਼ ਘੱਟ ਦੇਖਦੀਆਂ ਹਨ।ਡਿਜ਼ਾਈਨ ਵੀ ਸੁਧਰਦਾ ਹੈ: ਉਹ ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਲ ਤਰੀਕੇ ਨੂੰ ਵਾਜਬ ਠਹਿਰਾਉਣਾ ਔਖਾ ਬਣ ਜਾਂਦਾ ਜਦੋਂ ਤੁਹਾਨੂੰ ਉਸ ਨੂੰ ਜ਼ਬਾਨ ਨਾਲ ਵਿਆਖਿਆ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।ਫੈਸਲੇ ਬਿਆਨ ਕਰਨ ਦੀ ਕਾਰਵਾਈ ਆਮ तौर 'ਤੇ ਸਰਲ ਡਿਜ਼ਾਈਨ, ਛੋਟੇ ਫੰਕਸ਼ਨ, ਅਤੇ ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੀ ਹੈ।

ਆਮ ਚਿੰਤਾਵਾਂ (ਅਤੇ XP ਟੀਮਾਂ ਕਿਵੇਂ ਨਿਪਟਦੀਆਂ ਹਨ)

• "ਕੀ ਇਹ ਦੋ ਗੁਣਾ ਖਰਚ ਨਹੀਂ ਹੈ?" ਜੇ ਇਹ ਰੀ-ਵਰਕ, ਲੰਮੇ ਰਿਵਿਊਜ਼, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਰੋਕਦਾ ਹੈ ਤਾਂ ਨਹੀਂ।ਤੁਸੀਂ ਬਾਅਦ ਦੀ ਸਫਾਈ ਲਈ ਪਹਿਲਾਂ ਦੀ ਸਪੱਸ਼ਟਤਾ ਚੁਕਾ ਰਹੇ ਹੋ।
• ਥਕਾਵਟ: ਸਾਰੀ ਦਿਨ pairing ਕਰਨ ਨਾਲ ਥਕਾਵਟ ਹੋ ਸਕਦੀ ਹੈ।ਕਈ ਟੀਮ ਚੁਣਿੰਦਗੀ ਨਾਲ ਜੋੜਦੀ ਹੈ (ਨਵੇਂ ਫੀਚਰ, ਮੁਸ਼ਕਲ ਰਿਫੈਕਟ) ਅਤੇ ਰੁਟੀਨ ਕੰਮ ਲਈ ਇਕੱਲੇ ਸਮਾਂ ਛੱਡਦੀ ਹੈ।
• ਅਸਮਾਨ ਦਖਲਦਾਰੀ ਸਤਰ: ਇਹ ਆਮ ਹੈ।ਠੀਕ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਇਹ ਮੈਨਟੋਰਿੰਗ ਵਾਂਗ ਹੁੰਦਾ ਹੈ—ਬਿਨਾਂ ਫ਼ਾਰਮਲ ਮੀਟਿੰਗ ਦੇ—ਫਿਰ ਵੀ ਸ਼ਿਪ ਹੁੰਦਾ ਹੈ।

ਕਾਰਗਰ pairing ਰੁਟੀਆਂ

Driver/Navigator: ਇੱਕ ਕੋਡ ਲਿਖਦਾ, ਦੂਜਾ ਰਿਵਿਊ ਕਰਦਾ, ਅੱਗੇ ਸੋਚਦਾ, ਅਤੇ ਸਵਾਲ ਪੁੱਛਦਾ।ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਭੂਮਿਕਾਵਾਂ ਬਦਲੋ।

Rotating pairs: ਹਰ ਦਿਨ ਜਾਂ ਹਰ ਸਟੋਰੀ ਲਈ ਸਾਥੀ ਬਦਲੋ ਤਾਂ ਕਿ ਗਿਆਨ ਇਕੱਠਾ ਨਾ ਹੋਵੇ।

Time-boxed sessions: 60–90 ਮਿੰਟ ਲਈ ਜੋੜੀ ਕਰੋ, ਫਿਰ ਬ੍ਰੇਕ ਲਵੋ ਜਾਂ ਕੰਮ ਬਦਲੋ।ਇਸ ਨਾਲ ਧਿਆਨ ਉੱਚਾ ਰਹਿੰਦਾ ਅਤੇ ਬਰਨਾਉਟ ਘੱਟ ਹੁੰਦਾ ਹੈ।

ਰਿਫੈਕਟਰਨਿੰਗ: ਕੋਡ ਨੂੰ ਤੰਦਰੁਸਤ ਰੱਖਣਾ

Refactoring ਦਾ ਮਤਲਬ ਹੈ ਕੋਡ ਦੀ ਅੰਦਰੂਨੀ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਣਾ ਬਿਨਾਂ ਸੌਫਟਵੇਅਰ ਦੇ ਵਿਹੇਵਿਯਰ ਨੂੰ ਬਦਲਣ ਤੋਂ।XP ਵਿੱਚ ਇਹ ਇੱਕ ਕਦੇ-ਕਦੇ ਦੀ ਸਫਾਈ ਦਿਨ ਨਹੀਂ ਸੀ—ਇਹ ਰੋਜ਼ਾਨਾ ਕੰਮ ਦਾ ਹਿੱਸਾ ਸੀ, ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ, ਫੀਚਰ ਵਿਕਾਸ ਦੇ ਨਾਲ ਸਹਿ।

XP ਨੇ ਰਿਫੈਕਟਰਨਿੰਗ ਨੂੰ ਆਦਤ ਕਿਉਂ ਬਣਾਇਆ

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

TDD ਰਿਫੈਕਟਰਨਿੰਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਿਵੇਂ ਬਣਾਉਂਦਾ ਹੈ

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

ਆਮ ਰਿਫੈਕਟਰਨਿੰਗ ਲਕੜੀ ਦਰਸ਼

ਰਿਫੈਕਟਰਨਿੰਗ ਚਤੁਰਾਈ ਨਹੀਂ—ਇਹ ਸਪਸ਼ਟਤਾ ਅਤੇ ਲਚਕੀਲਾਪਣ ਲਈ ਹੁੰਦੀ ਹੈ:

• ਪੜ੍ਹਨਯੋਗਤਾ: ਵਧੀਆ ਨਾਂ, ਛੋਟੇ ਫੰਕਸ਼ਨ, ਸਾਫ਼ ਜੋੜ।
• ਨਕਲ ਹਟਾਉਣਾ: ਇਕ ਚੰਗੇ ਨਾਮ ਵਾਲੀ ਲੋジਿਕ ਇੱਕ ਥਾਂ ਤੇ।
• ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ: ਜਿੰਨ੍ਹਾਂ ਨਾਲ ਬਦਲਾਅ ਹਰ ਜਗ੍ਹਾ ਨਹੀਂ ਫੈਲਦੇ (ਜਿਵੇਂ ਕਿ ਬਿਜ਼ਨਸ ਨਿਯਮਾਂ ਨੂੰ ਡੈਟਾਬੇਸ ਜਾਂ UI ਕੋਡ ਤੋਂ ਵੱਖ ਕਰਨਾ)।

ਟਾਲੀ-ਚੇਤਾਵਨੀਆਂ

ਦੋ ਗਲਤੀਆਂ ਬਹੁਤ ਆਮ ਹਨ:

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

Continuous Integration: ਮੁਸ਼ਕਿਲਾਂ ਨੂੰ ਛੋਟਾ ਹੋਣ ਤੇ ਫੜੋ

Continuous Integration (CI) XP ਦਾ ਇੱਕ ਆਈਡੀਅਾ ਹੈ ਜਿਸਦਾ ਸਧਾਰਨ ਮਕਸਦ ਹੈ: **ਕੰਮ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਮਰਜ ਕਰੋ taa ਕਿ ਸਮੱਸਿਆਵਾਂ ਛੋਟੀਆਂ ਹੋਣ 'ਤੇ ਪੜਚੋਲਿਆ ਜਾ ਸਕੇ।**ਹਰ ਕੋਈ ਆਪਣੀਆਂ ਫੀਚਰਾਂ ਨੂੰ ਕਈ ਦਫਾ ਦਿਨ ਵਿੱਚ ਇਨਸੋਲੇਟ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮ ਧੀਰ-ਧੀਰ ਸਾਫ਼ਟਵੇਅਰ ਨੂੰ ਉਸ ਸਥਿਤੀ ਵਿੱਚ ਰੱਖਦੀ ਹੈ ਜਿਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜੋੜਿਆ ਜਾ ਸਕੇ।

XP ਸ਼ਬਦਾਂ ਵਿੱਚ CI: ਅਕਸਰ ਇਨਟੀਗਰੇਟ ਕਰੋ

XP ਇਨਟੀਗਰੇਸ਼ਨ ਨੂੰ ਫੀਡਬੈਕ ਦੀ ਇੱਕ ਫਾਰਮ ਵਜੋਂ ਵੇਖਦਾ ਹੈ।ਹਰੇਕ ਮਰਜ ਪ੍ਰਾਇਕਟਿਕ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ: *ਕੀ ਅਸੀਂ ਅਕਸਮੀਤ ਤੌਰ 'ਤੇ ਕੁਝ ਤੋੜ ਦਿੱਤਾ ਹੈ? ਕੀ ਸਾਡੇ ਬਦਲਾਵ ਹੋਰਾਂ ਦੇ ਬਦਲਾਵਾਂ ਨਾਲ ਅਜੇ ਵੀ ਕੰਮ ਕਰ ਰਹੇ ਹਨ?*ਜਦੋਂ ਜਵਾਬ "ਨਹੀਂ" ਹੋਵੇ, ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਪਤਾ ਲੱਗੇ, ਨਾ ਕਿ ਇਟਰੇਸ਼ਨ ਦੇ ਅੰਤ 'ਤੇ।

ਪਾਈਪਲਾਈਨ ਕੀ ਕਰਦਾ ਹੈ (ਜਰਗਨ ਤੋਂ ਬਿਨਾਂ)

ਬਿਲਡ ਪਾਈਪਲਾਈਨ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਇੱਕ ਦੁਹਰਾਉਣਯੋਗ ਚੈਕਲਿਸਟ ਹੈ ਜੋ ਕੋਡ ਬਦਲਣ 'ਤੇ ਚਲਦੀ ਹੈ:

• ਇਹ ਉਤਪਾਦ ਨੂੰ ਅਸੈਂਬਲ ਕਰਦੀ ਹੈ (ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਾਣੋ ਕਿ ਇਹ ਅਜੇ ਵੀ "ਬਿਲਡ" ਹੁੰਦਾ ਹੈ)।
• ਇਹ ਆਟੋਮੇਟਿਡ ਚੈੱਕ ਚਲਾਉਂਦੀ (ਤਾਂ ਜੋ ਤੁਸੀਂ ਜਾਣੋ ਕਿ ਮੁੱਖ ਵਿਹੇਵਿਯਰ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ)।
• ਇਹ ਨਤੀਜੇ ਤੇਜ਼ੀ ਨਾਲ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ (ਤਾਂ ਜੋ ਤੁਸੀਂ ਸੰਦੇਸ਼ ਦੌਰਾਨ ਹੀ ਸੁਧਾਰ ਕਰੋ)।

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

ਇਹ ਇਟਰੇਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਤੇਜ਼ ਕਰਦਾ ਹੈ

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

ਆਧੁਨਿਕ ਜੋੜ-ਜੁੜਾਅ (ਕੋਈ ਧਾਰਨਾ ਨਹੀਂ)

ਅੱਜਕਲ CI ਵਿੱਚ ਅਕਸਰ ਹੋਰ ਆਟੋਮੇਟਿਡ ਚੈੱਕ (ਸੁਰੱਖਿਆ ਸਕੈਨ, ਕੋਡ ਸਟਾਈਲ ਚੈਕ, ਪਰਫਾਰਮੈਂਸ smoke tests) ਅਤੇ workflow ਹਨ ਜਿਵੇਂ trunk-based development, ਜਿੱਥੇ ਬਦਲਾਅ ਛੋਟੇ ਰੱਖੇ ਜਾਂਦੇ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਨਟੀਗਰੇਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।ਮਕਸਦ ਕਿਸੇ ਇੱਕ "ਸਹੀ" ਫਾਰਮੈਟ ਨੂੰ ਫਾਲੋ ਕਰਨਾ ਨਹੀਂ—ਇਹ ਫੀਡਬੈਕ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਇਨਟੀਗਰੇਸ਼ਨ ਨੂੰ ਰੋਜ਼ਮਰ੍ਹਾ ਬਣਾਉਣਾ ਹੈ।

ਟਿਕਾਣੇ, ਗਲਤ ਵਰਤੋਂ, ਅਤੇ ਕਦੋਂ XP ਨੂੰ ਅਨੁਕੂਲ ਕਰਨਾ

XP ਨਿਖਰ ਤੇ ਸਕੱਤਰ ਵਿਚਾਰ ਲਿਆਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਨੁਸ਼ਾਸਨ ਬਾਰੇ ਅਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ।ਇਸੇ ਕਰਕੇ ਇਹ ਆਸਾਨੀ ਨਾਲ ਗਲਤ ਸਮਝਿਆ ਵੀ ਜਾ ਸਕਦਾ ਹੈ।

ਆਮ ਟਿਕਾਣਾ (ਅਤੇ ਇਸ ਵਿੱਚ ਕੀ ਸੱਚ ਹੈ)

ਤੁਸੀਂ ਅਕਸਰ ਸੁਣੋਗੇ: "XP ਬਹੁਤ ਸਖਤ ਹੈ" ਜਾਂ "TDD ਸਾਨੂੰ ਸਲੋ ਕਰ ਦਿੰਦਾ ਹੈ"।ਦੋਹਾਂ ਸੱਚ ਹੋ ਸਕਦੇ ਹਨ—ਛੋਟੀ ਦੇਰੀ ਦੀ।

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

XP ਕਿੱਥੇ ਠੀਕ ਬੈਠਦਾ ਹੈ—ਅਤੇ ਕਦੋਂ ਅਨੁਕੂਲ ਕਰਨਾ

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

ਤੁਹਾਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੰਮ ਵੱਧ ਕੰਟਰੋਲ ਵੱਲ ਹੋ: ਨਿਯਮਤ ਪਰਿਵੇਸ਼, ਭਾਰੀ ਨਿਰਭਰਤਾਵਾਂ, ਜਾਂ ਬਹੁਤ ਸਾਰੇ ਵਿਸ਼ੇਸ਼ਜ्ञ ਟੀਮ ਮੈਂਬਰ।XP ਪਵਿੱਤ੍ਰਤਾ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ।ਇਹ ਇਮਾਨਦਾਰੀ ਮੰਗਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਫੀਡਬੈਕ ਦਿੰਦਾ ਹੈ—ਅਤੇ ਕੀ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਢੱਕਦਾ ਹੈ।

ਆਮ ਅਸਫਲਤਾ ਮੋਡ

ਸਭ ਤੋਂ ਵੱਡੀਆਂ ਅਸਫਲਤਾਵਾਂ ਇਹ ਨਹੀਂ ਕਿ "XP ਕਾਰਗਰ ਨਹੀਂ ਸੀ", ਪਰ:

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

ਛੋਟੇ-ਸ਼ੁਰੂਆਤੀ ਕਦਮ

ਇੱਕ ਲੂਪ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਮਜ਼ਬੂਤ ਕਰੋ:

• ਜੇ ਗੁਣਵੱਤਾ ਦੰਦਬਥੇ: ਸਭ ਤੋਂ ਬਦਲਣ-ਯੋਗ ਕੋਡ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਟੈਸਟਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
• ਜੇ ਦਿਸ਼ਾ ਖ਼राब ਹੈ: ਇਟਰੇਸ਼ਨ ਸਾਈਕਲ ਛੋਟੇ ਕਰੋ ਅਤੇ ਅਸਲ ਸਮੀਖਿਆ/ਡੈਮੋ ਪਲਸ ਸ਼ਾਮਿਲ ਕਰੋ।

ਜਦੋਂ ਇੱਕ ਲੂਪ ਭਰੋਸੇਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਗਲਾ ਜੋੜੋ।XP ਇੱਕ ਪ੍ਰਣਾਲੀ ਹੈ, ਪਰ ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ ਸਭ ਨਹੀਂ ਅਪਣਾਉਣੀ ਪੈਂਦੀ।

ਅਖੀਰੀ ਸੱਭਿਆਚਾਰਕ ਪ੍ਰਭਾਵ: ਆਧੁਨਿਕ ਟੀਮਾਂ 'ਚ XP ਦੇ ਵਿਚਾਰ

XP ਨੂੰ ਅਕਸਰ ਵਿਸ਼ੇਸ਼ ਅਭਿਆਸਾਂ ਲਈ ਯਾਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (pairing, TDD, refactoring), ਪਰ ਇਸਦੀ ਵੱਡੀ ਵਿਰਾਸਤ ਸੱਭਿਆਚਾਰਕ ਹੈ: ਇੱਕ ਟੀਮ ਜੋ ਗੁਣਵੱਤਾ ਅਤੇ ਸਿੱਖਣ ਨੂੰ ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਜੋਂ ਮੰਨਦੀ ਹੈ, ਨਾ ਕਿ ਅੰਤ-ਦੇ-ਵਿਚ ਫੇਜ਼।

XP ਨੇ ਆਧੁਨਿਕ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਕਿਵੇਂ ਨਿੱਘੇ ਪ੍ਰਭਾਵਤ ਕੀਤੇ

ਕਈ ਗੱਲਾਂ ਜੋ ਹੁਣ ਟੀਮਾਂ Agile, DevOps, continuous delivery, ਅਤੇ ਇੱਕ ਹੱਦ ਤੱਕ product discovery ਕਹਿੰਦੀਆਂ ਹਨ, ਉਹ XP ਦੇ ਮੁੱਖ ਕਦਮਾਂ ਦੀ ਆਵਾਜ਼ ਹਨ:

• ਬੈਚ ਘਟਾਓ: ਛੋਟੇ ਬਦਲਾਅ ਬਾਰੇ ਜ਼ਿਆਦਾ ਅਕਸਮਾਤ ਰਿਸਕ ਘਟਾਉਣ ਲਈ।
• ਫੀਡਬੈਕ ਤੰਗ ਕਰੋ: ਟੈਸਟਾਂ, ਸਹਿਯੋਗੀਆਂ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਸੰਕੇਤ ਜਲਦੀ ਲਵੋ।
• ਕੰਮ ਦੇਖਣ ਯੋਗ ਬਣਾਓ: "ਪੂਰੀ" ਭਵਿੱਖਬਾਣੀ ਦੀ ਥਾਂ ਸਧਾਰਨ ਯੋਜਨਾਵਾਂ ਤੇ ਧਿਆਨ ਦਿਓ ਜਿਹਨਾਂ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਜਾ ਸਕੇ।

ਜਦੋਂ ਟੀਮਾਂ ਇਸਨੂੰ "XP" ਨਹੀਂ ਕਹਿੰਦੀਆਂ, ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਪੈਟਰਨ trunk-based development, CI ਪਾਈਪਲਾਈਨ, ਫੀਚਰ ਫਲੈਗ, ਲਘੂ ਪ੍ਰਯੋਗ, ਅਤੇ ਅਕਸਰ ਗਾਹਕ ਸਪਰਸ਼ਾਂ ਵਿੱਚ ਵੇਖੋਗੇ।

AI-ਸਹਾਇਤ ਨਿਰਮਾਣ ਦੇ ਯੁੱਗ ਵਿੱਚ XP

ਇੱਕ ਕਾਰਨ ਕਿ XP ਅਜੇ ਵੀ ਤਾਜ਼ਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਇਸਦੇ "ਸਿੱਖਣ ਵਾਲੇ ਲੂਪ" ਆਧੁਨਿਕ ਟੂਲਿੰਗ ਦੇ ਨਾਲ ਵੀ ਵਰਤੋਂਯੋਗ ਹਨ।ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਉਤਪਾਦ ਵਿਚਾਰ 'ਤੇ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਉਪਕਰਨ ਜਿਵੇਂ Koder.ai ਇਟਰੇਸ਼ਨ ਚੱਕਰ ਨੂੰ ਹੋਰ ਘੱਟ ਕਰ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ ਇੱਕ ਫੀਚਰ ਚੈਟ ਵਿੱਚ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹੋ, ਇੱਕ ਕੰਮ ਕਰਦੀ ਵੈੱਬ ਐਪ (React) ਜਾਂ ਬੈਕਐਂਡ ਸੇਵਾ (Go + PostgreSQL) उत्पन्न ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਅਸਲ ਵਰਤੋਂ ਨਾਲ ਅਗਲੀ ਕਹਾਣੀ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।

XP-ਫੇਵਰਡ ਹਿੱਸਾ "ਜਾਦੂਈ ਕੋਡ ਜਨਰੇਸ਼ਨ" ਨਹੀਂ—ਇਹ ਛੋਟੇ ਅਤੇ ਵਾਪਸੀਯੋਗ ਬੈਚ ਰੱਖਣ ਦੀ ਸਮਰੱਥਾ ਹੈ।ਉਦਾਹਰਨ ਵਜੋਂ, Koder.ai ਦਾ planning mode ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਇਰਾਦਾ ਸਪੱਸ਼ਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ (ਇਹ acceptance criteria ਲਿਖਣ ਵਰਗ) ਅਤੇ snapshots/rollback ਰਿਫੈਕਟਰਨਿੰਗ ਜਾਂ ਖਤਰਨਾਕ ਬਦਲਾਅ ਕਰਨ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ।

ਕੁਝ ਟਿਕ ਰਹਿਣ ਵਾਲੇ ਸੱਭਿਆਚਾਰਕ ਪ੍ਰਭਾਵ

XP ਟੀਮਾਂ ਨੂੰ ਇਸ तरफ ਧੱਕਦਾ ਹੈ:

• ਸਾਂਝੀ ਮਲਕੀਅਤ: ਕੋਡ ਟੀਮ ਦੀ ਸੰਪਤੀ ਹੈ, ਇਸ ਲਈ ਸੁਧਾਰ "ਉਸ ਇੱਕ ਵਿਅਕਤੀ" 'ਤੇ انتظار ਨਹੀਂ ਰੱਖਦੇ।
• ਸਿੱਖਣ ਦਿਸ਼ਾ: ਗਲਤੀਆਂ ਜਾਣਕਾਰੀ ਹਨ; ਸਿਸਟਮ ਐਸਾ ਬਦਲਦਾ ਹੈ ਕਿ ਉਹ ਗਲਤੀ ਮੁੜ ਕਰਨਾ ਔਖਾ ਹੋ ਜਾਵੇ।
• ਗੁਣਵੱਤਾ ਆਦਤ ਬਣ ਜਾਂਦੀ ਹੈ: ਟੈਸਟ, refactoring, ਅਤੇ ਰਿਵਿਊ "ਐਕਸਟ੍ਰਾ" ਨਹੀਂ; ਇਹ ਕੰਮ ਕਰਨ ਦਾ ਤਰੀਕਾ ਹੈ।

ਇੱਕ ਕਾਰਗਰ ਛੋਟੀ-ਚੈੱਕਲਿਸਟ (ਇਸ ਹਫ਼ਤੇ ਵਰਤੋ)

• ਕੀ ਤੁਸੀਂ ਟੈਸਟ ਜਾਂ ਬਿਲਡ ਨਤੀਜਾ ਮਿੰਟਾਂ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ, ਘੰਟਿਆਂ ਵਿੱਚ ਨਹੀਂ?
• ਕੀ ਤੁਸੀਂ ਘੰਟਿਆਂ/ਦਿਨਾਂ ਵਿੱਚ ਡਿਲਿਵਰ ਕਰ ਸਕਦੇ ਹੋ, ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਨਹੀਂ?
• ਕੀ ਤੁਸੀਂ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਰਿਫੈਕਟਰ ਕਰਦੇ ਹੋ ਜਿਵੇਂ ਸਧਾਰਨ ਕੰਮ ਦਾ ਹਿੱਸਾ?
• ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਅਹਿਸਾਸੀ ਫੀਡਬੈਕ ਰਸਮ ਹੈ (pairing, review, ਜਾਂ mobbing) ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਤੇ?
• ਕੀ CI ਫਾਸਟ ਫੇਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਟੀਮ ਲਾਲ ਬਿਲਡ ਨੂੰ ਤਤਕਾਲ ਮਾਣਦੀ ਹੈ?

ਜੇ ਤੁਸੀਂ ਹੋਰ ਖੋਜ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਬਲੌਗ ਵਿੱਚ ਹੋਰ ਲੇਖ ਪੜ੍ਹੋ, ਜਾਂ ਦੇਖੋ ਕਿ ਹਲਕੀ-ਫਰਮਾਈਸ਼ੀ ਅਪਣਾਉਣ ਯੋਜਨਾ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀ ਲੱਗ ਸਕਦੀ ਹੈ ਪ੍ਰਾਈਸਿੰਗ ਪੇਜ 'ਤੇ।