05 ਅਗ 2025·8 ਮਿੰਟ
Ward Cunningham, ਵਿਕੀਆਂ ਅਤੇ ਸਮੇਂ ਨਾਲ ਤਕਨੀਕੀ ਕਰਜ਼ਾ
ਵੇਖੋ ਕਿ Ward Cunningham ਦੀ ਵਿਕੀ ਅਤੇ “technical debt” ਮੈਟਾਫ਼ਰ ਨੇ ਸਹਿਯੋਗ, ਰੀਫੈਕਟੋਰਿੰਗ ਆਦਤਾਂ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਕੋਡ ਪਰਬੰਧਨ ਫੈਸਲਿਆਂ ਨੂੰ ਕਿਵੇਂ ਬਦਲਿਆ।
ਵੇਖੋ ਕਿ Ward Cunningham ਦੀ ਵਿਕੀ ਅਤੇ “technical debt” ਮੈਟਾਫ਼ਰ ਨੇ ਸਹਿਯੋਗ, ਰੀਫੈਕਟੋਰਿੰਗ ਆਦਤਾਂ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਕੋਡ ਪਰਬੰਧਨ ਫੈਸਲਿਆਂ ਨੂੰ ਕਿਵੇਂ ਬਦਲਿਆ।
Ward Cunningham ਦੋ ਐਸੀਆਂ ਸ਼ਬਦਾਵਲੀਆਂ ਲਈ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਸ਼ਹੂਰ ਹੈ ਜੋ ਆਪਣੇ ਮੂਲ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਆ ਕੇ ਰੋਜ਼ਮਰਾ ਦੇ ਸੰਦ ਬਣ ਗਈਆਂ: “wiki” ਅਤੇ “technical debt.” ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਦੋਹਾਂ ਵਿਚਾਰ ਕਿਸੇ ਬ੍ਰਾਂਡਿੰਗ ਮੁਹਿੰਮ ਦੇ ਤੌਰ ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਏ ਸਨ। ਦੋਹਾਂ ਸਮੂਹ ਸਮੱਸਿਆਵਾਂ ਦੇ ਪ੍ਰਯੋਗਿਕ ਜਵਾਬ ਸਨ।
Cunningham ਪੈਟਰਨ ਅਤੇ ਐਜਾਈਲ ਚਰਚਾਵਾਂ ਵਿੱਚ ਸਰਗਰਮ ਸੀ, ਜਿੱਥੇ ਆਧੁਨਿਕ ਸੌਫਟਵੇਅਰ ਟੀਮ ਵਰਕ ਸ਼ੇਪ ਹੋ ਰਿਹਾ ਸੀ। ਉਨ੍ਹਾਂ ਨੇ ਪਹਿਲੀ ਵਿਕੀ ਬਣਾਈ, ਟੂਲ ਤਿਆਰ ਕੀਤੇ, ਅਤੇ ਐਸੀਆਂ ਪ੍ਰਥਾਵਾਂ ਉਤੇ ਪ੍ਰਭਾਵ ਕੀਤਾ ਜੋ ਫੀਡਬੈਕ, ਸਿੱਖਣ ਅਤੇ ਸਾਦਗੀ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦੀਆਂ ਸਨ।
ਉਹ ਵਿਸ਼ਾਲ ਸਿਧਾਂਤਾਂ ਨਾਲੋਂ ਵੱਧ ਇਸ ਗੱਲ ਲਈ ਜਾਣੇ ਗਏ ਕਿ ਉਹ ਛੋਟੇ, ਕੰਮ ਕਰਨ ਵਾਲੇ ਹੱਲ ਸ਼ਿਪ ਕਰਦੇ ਜੋ ਲੋਕ ਨਕਲ ਕਰ ਸਕਦੇ ਸਨ।
ਪ੍ਰੋਜੈਕਟਾਂ 'ਤੇ, Cunningham ਨੇ ਉਹੀ ਘਣਘੋਰੀ ਰੁਕਾਵਟ ਵੇਖੀਆਂ: ਈਮੇਲ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਫਸਿਆ ਗਿਆ ਗਿਆਨ, ਮੀਟਿੰਗਾਂ ਤੋਂ ਬਾਅਦ ਖੋਇਆ ਫੈਸਲਾ, ਅਤੇ ਕੋਡਬੇਸ ਜਿਹੜਾ ਮਹੀਨਿਆਂ ਵਿੱਚ ਬਦਲਣ ਲਈ ਔਖਾ ਹੋ ਜਾਂਦਾ।
ਟੀਮਾਂ ਨੂੰ ਸਿਰਫ਼ “ਬਿਹਤਰ ਦਸਤਾਵੇਜ਼” ਜਾਂ “ਬਿਹਤਰ ਆਰਕੀਟੈਕਚਰ” ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਉਹਨਾਂ ਨੂੰ ਸਾਂਝੀ ਸਮਝ ਨੂੰ ਮੌਜੂਦਾ ਰੱਖਣ ਦੇ ਤਰੀਕੇ ਚਾਹੀਦੇ ਸਨ—ਅਤੇ ਜਦੋਂ ਅੱਜ ਦੀ ਰਫ਼ਤਾਰ ਕੱਲ੍ਹ ਦੀ ਲਾਗਤ ਪੈਦਾ ਕਰਦੀ ਹੈ ਤਾਂ ਟਰੇਡ‑ਆਫ਼ ਵਰਗੀਆਂ ਗੱਲਾਂ ਨੂੰ ਦਰਸਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਸੀ।
ਵਿਕੀ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਸੀ ਕਿ ਇਸ ਨਾਲ ਯੋਗਦਾਨ ਅਤੇ ਸੁਧਾਰ ਕਰਨ ਦੀ ਰੁਕਾਵਟ ਘੱਟ ਹੋ ਗਈ। ਡੈਬਟ ਮੈਟਾਫ਼ਰ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਇਜ਼ਜ਼ਤਦਾਰ ਢੰਗ ਦਿੱਤਾ ਕਿ ਭਵਿੱਖ ਦੀ ਲਾਗਤ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਜਾ ਸਕੇ ਬਿਨਾ ਕਿਸੇ ਵਿਅਕਤੀ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਣ ਦੇ।
ਦੋਹਾਂ ਆਰਗੈਨਿਕ ਤੌਰ 'ਤੇ ਫੈਲੇ: ਕਿਸੇ ਨੇ ਇਸਨੂੰ ਅਜ਼ਮਾਇਆ, ਇਹ ਮਦਦਗਾਰ ਸਾਬਿਤ ਹੋਇਆ, ਅਤੇ ਹੋਰ ਲੋਕਾਂ ਨੇ ਇਸਨੂੰ ਅਪਨਾਇਆ।
Cunningham ਦੀ ਸਿੱਧੀ ਰੇਖਾ ਸਧਾਰਨ ਹੈ: ਸਾਂਝੀ ਸਮਝ ਅਤੇ ਟਿਕਾਊ ਬਦਲਾਅ ਲਈ ਅਨੁਕੂਲਤਾ ਕਰੋ। ਜਦੋਂ ਟੂਲ ਅਤੇ ਮੈਟਾਫ਼ਰ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖਣ, ਜਲਦੀ ਸੰਰੇਖਣ ਅਤੇ ਕੋਡਬੇਸ ਨੂੰ ਹਕੀਕਤੀ ਡੈਡਲਾਈਨਾਂ ਹੇਠਾਂ ਲਚਕੀਲਾ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਹੀ ਉਹ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੋਂਦੀਆਂ ਹਨ।
ਇੱਕ ਵਿਕੀ ਵੈੱਬ ਪੇਜ਼ਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜੋ ਕਿਸੇ ਗਰੁੱਪ ਵਿੱਚ ਕਿੱਸੇ ਵੀ ਵਿਅਕਤੀ ਦੁਆਰਾ ਬਰਾਊਜ਼ਰ ਨਾਲ ਬਣਾਈ ਅਤੇ ਸੋਧੀ ਜਾ ਸਕਦੀ ਹੈ। ਦਸਤਾਵੇਜ਼ ਨੂੰ ਮਨਜ਼ੂਰੀ ਲਈ ਰਾਉਂਡ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਪੇਜ਼ ਨੂੰ ਹੀ ਬਦਲਦੇ ਹੋ—ਅਤੇ ਪੇਜ਼ ਤੁਰੰਤ ਸਾਰਿਆਂ ਲਈ ਅਪਡੇਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਉਹ ਸਾਦਾ ਵਿਚਾਰ ਅਸਲ ਨਵੀਨਤਾ ਸੀ। ਵਿਕੀਆਂ ਤੋਂ ਪਹਿਲਾਂ, “ਸਾਂਝਾ ਗਿਆਨ” ਅਕਸਰ ਤਿੰਨ ਵਿੱਚੋਂ ਇੱਕ ਹੁੰਦਾ ਸੀ:
ਇੱਕ ਵਿਕੀ ਨੇ ਉਸ ਮਾਡਲ ਨੂੰ ਉਲਟ ਦਿੱਤਾ। ਇਹ ਗਿਆਨ ਨੂੰ ਉਸ ਚੀਜ਼ ਵਜੋਂ ਦੇਖਦਾ ਸੀ ਜੋ ਟੀਮ ਇੱਕਠੇ ਰੱਖਦੀ ਹੈ, ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ। ਜੇ ਤੁਸੀਂ ਕੋਈ ਗਲਤੀ ਵੇਖਦੇ, ਤਾਂ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਫਿਕਸ ਕਰਨ ਲਈ ਟਿਕਟ ਨਹੀਂ ਬਣਾਉਂਦੇ—ਤੁਸੀਂ ਉਸਨੂੰ ਸਿੱਧਾ ਠੀਕ ਕਰਦੇ।
Ward Cunningham ਨੇ ਮਿੱਡ‑1990s ਵਿੱਚ ਪਹਿਲੀ ਵਿਕੀ, WikiWikiWeb, ਬਣਾਈ ਤਾਂ ਜੋ ਸੌਫਟਵੇਅਰ ਅਭਿਆਸਕਰਤਾ ਪੈਟਰਨ, ਵਿਚਾਰ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਤਰੀਕੇ ਸਾਂਝੇ ਕਰ ਸਕਣ। ਉਨ੍ਹਾਂ ਦਾ ਮਕਸਦ ਕੋਈ ਪੋਲੀਸ਼ਡ ਪਬਲਿਸ਼ਿੰਗ ਪਲੈਟਫਾਰਮ ਬਣਾਉਣਾ ਨਹੀਂ ਸੀ। ਉਹ ਇੱਕ “ਗੱਲ‑ਬਾਤ” ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਸਨ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਸੁਧਰ ਸਕੇ, ਜਿੱਥੇ ਛੋਟੀਆਂ ਸੁਧਾਰਾਂ ਇਕਠੇ ਹੋ ਕੇ ਕੁਝ ਹੇਰਾਨ ਕਰਨ ਵਾਲਾ ਉਪਯੋਗੀ ਬਣ ਜਾਂਦੇ।
ਸ਼ੁਰੂਆਤੀ ਉਪਯੋਗ ਕੇਸ ਪ੍ਰਾਗਟਿਕ ਸਨ: ਆਮ ਹੱਲ ਕੈਪਚਰ ਕਰਨਾ, ਸ਼ਬਦਾਵਲੀ ਸਪਸ਼ਟ ਕਰਨਾ, ਉਦਾਹਰਨ ਦਰਜ ਕਰਨਾ, ਅਤੇ ਸੰਬੰਧਤ ਵਿਸ਼ਿਆਂ ਨੂੰ ਲਿੰਕ ਕਰਨਾ ਤਾਂ ਜੋ ਪਾਠਕ ਫੋਲਡਰਾਂ ਵਿਚ ਖੋਜ ਕਰਨ ਦੇ ਥਾਂ ਖੋਜ ਸਕਣ।
ਰਵਾਇਤੀ ਡੌਕਯੂਮੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਖਤਮ ਹੋਣ ਅਤੇ ਅਧਿਕਾਰਕ ਹੋਣ ਦਾ ਉਦੇਸ਼ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਵਿਕੀ ਅਧੂਰਾ ਰਹਿਣ ਵਿੱਚ ਆਰਾਮਦਾਇਕ ਹੁੰਦੀ ਹੈ—ਜਦ ਤੱਕ ਇਹ ਅਜੇ ਵੀ ਮਦਦਗਾਰ ਹੋ।
ਈਮੇਲ ਕ੍ਰਮਿਕ ਹੁੰਦੇ ਹਨ; ਵਿਕੀ ਵਿਧਾਨਬੱਧ। ਮੀਟਿੰਗਾਂ ਅਸਥਾਈ ਹੁੰਦੀਆਂ ਹਨ; ਵਿਕੀਆਂ ਇੱਕ ਟਰੇਲ ਛੱਡਦੀਆਂ ਹਨ ਜਿਸਨੂੰ ਨਵੇਂ ਆਏ ਲੋਕ ਬਿਨਾਂ ਕਿਸੇ ਨੂੰ ਮਿਲਾ ਕੇ ਸਿੱਖ ਸਕਦੇ ਹਨ।
ਉਹ ਮਿਲਾਪ—ਘੱਟ ਘਰੜਾ ਸੋਧ, ਤੇਜ਼ ਲਿੰਕਿੰਗ, ਅਤੇ ਸਾਂਝੀ ਮਾਲਕੀ—ਵਿਕੀਆਂ ਨੂੰ “ਦਸਤਾਵੇਜ਼” ਦੇ ਬਜਾਏ ਟੀਮਵਰਕ ਲਿਖਿਆ ਹੋਇਆ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ।
ਆਰੰਭਿਕ ਵਿਕੀ ਸੋਚ ਸਿਰਫ਼ “ਕਿਸੇ ਵੈੱਬਸਾਈਟ ਨੂੰ ਜੋ ਕੋਈ ਵੀ ਸੋਧ ਸਕਦਾ” ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਸਧਾਰਣ ਤਰਕੀਬ ਸੀ ਜੋ ਲੋਕਾਂ ਦੀ ਔਕਤ ਜਾਣਕਾਰੀ ਨੂੰ ਉਸ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦੇਂਦੀ ਜੋ ਪੂਰੀ ਟੀਮ ਵਰਤ ਸਕੇ।
ਇਹ ਬਦਲਾਅ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਰੁਕਾਵਟਾਂ ਟਾਈਪਿੰਗ ਦੀ ਰਫ਼ਤਾਰ ਤੋਂ ਨਹੀਂ ਆندੀਆਂ—ਉਹ ਉਡੀਕ ਕਰਨ ਤੋਂ ਆਂਦੀਆਂ ਹਨ: ਉਸ ਇਕ ਵਿਅਕਤੀ ਦੀ ਉਡੀਕ ਜੋ ਡਿਪਲੋਏਮੈਂਟ ਕਦਮ ਯਾਦ ਰੱਖਦਾ ਹੈ, ਉਸ ਇਕ ਵਿਅਕਤੀ ਦੀ ਉਡੀਕ ਜੋ ਇੱਕ ਐਜ‑ਕੇਸ ਸਮਝਦਾ ਹੈ, ਉਸ ਇਕ ਵਿਅਕਤੀ ਦੀ ਉਡੀਕ ਜੋ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਫੈਸਲਾ ਕਿਉਂ ਲਿਆ ਗਿਆ।
ਵਧੀਆ ਟੀਮ ਵਿਕੀ ਛੋਟੀ, ਪ੍ਰਯੋਗਿਕ ਜਾਣਕਾਰੀਆਂ ਕੈਪਚਰ ਕਰਦੀ ਹੈ ਜਦ ਉਹ ਹਾਲੇ ਤਾਜ਼ਾ ਹੁੰਦੀਆਂ ਹਨ: ਉਹ ਐਰਰ ਮੈੱਸੇਜ ਜੋ ਤੁਸੀਂ ਵੇਖਿਆ, ਉਹ ਵਰਕਅਰਾਊਂਡ ਜੋ ਚੱਲਿਆ, ਉਹ ਗਾਹਕ ਦੀ ਪਾਬੰਦੀ ਜੋ ਮੁੜ‑ਮੁੜ ਆਉਂਦੀ।
ਜਦ ਇਹ ਨੋਟ ਇਕ ਥਾਂ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਸਿੱਖਣ ਹਰ ਕਿਸੇ ਲਈ ਤੇਜ਼ ਹੁੰਦਾ—ਖਾਸ ਕਰਕੇ ਨਵੇਂ ਜੁੜਨ ਵਾਲਿਆਂ ਲਈ ਜੋ ਖੁਦ‑ਸੇਵਾ ਕਰ ਸਕਦੇ ਹਨ ਬਦਲੇ ਵਿੱਚ ਲਗਾਤਾਰ “ਕੀ ਤੁਸੀਂ ਦੱਸ ਸਕਦੇ ਹੋ…” ਮੀਟਿੰਗਾਂ ਸੈਟ ਕਰਨ ਦੇ।
ਵਿਕੀਆਂ ਅਚ্ছে ਤੌਰ 'ਤੇ ਭਾਰਹੀਣ ਰਹਿੰਦੀਆਂ ਹਨ: ਸੰਖੇਪ ਪੇਜ਼, ਤੇਜ਼ ਸੋਧ, ਸਾਫ਼ ਜ਼ਿੰਮੇਵਾਰੀ, ਅਤੇ “ਛੇਤੀ ਚੰਗੀ” ਲਿਖਾਈ। ਲਕਸ਼ ਪਰਫੈਕਸ਼ਨ ਨਹੀਂ; ਲਕਸ਼ ਸੰਰੇਖਣ ਹੈ।
ਇੱਕ ਦੋ‑ਪੈਰਾ ਪੇਜ਼ ਜੋ ਇਕ ਮੁੜ ਮੁੜੀ ਸਮਝ ਗਲਤੀ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਉਹ ਇੱਕ ਸੋਧਿਆ ਹੋਇਆ ਦਸਤਾਵੇਜ਼ ਜਿਸਨੂੰ ਕੋਈ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦਾ, ਉਸ ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ।
ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਿੱਚ ਸਿਲੋ ਘਟਾਉਣ ਵਾਲੇ ਆਮ ਵਿਕੀ ਪੇਜ਼:
ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਪੇਜ਼ ਟੀਮ ਯਾਦਦਾਸ਼ਤ ਬਣ ਜਾਂਦੇ ਹਨ। ਉਹ ਗੱਲ‑ਬਾਤ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈਂਦੇ—ਉਹ ਗੱਲਾਂ ਛੋਟੀ, ਨਿਸ਼ਚਿਤ ਅਤੇ ਕਾਰਵਾਈਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
Ward Cunningham ਨੇ “technical debt” ਨੂੰ ਇੱਕ ਗਾਲੀ ਵਾਂਗ ਨਹੀਂ ਰੱਖਿਆ। ਉਹ ਇਸਨੂੰ ਇੱਕ ਜਾਣ‑ਬੁਝ ਕੇ ਕੀਤਾ ਗਿਆ ਟਰੇਡ‑ਆਫ ਵਜੋਂ ਵਰਤਦਾ ਸੀ: ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਰਸਤਾ ਲੈਂਦੇ ਹੋ ਤਾਂ ਕਿ ਜ਼ਿਆਦਾ ਤੇਜ਼ੀ ਨਾਲ ਸਿੱਖ ਸਕੋ ਜਾਂ ਜਲਦੀ ਸ਼ਿਪ ਕਰੋ, ਇਹ ਜਾਣਦੇ ਹੋਏ ਕਿ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਕੰਮ ਕਰਨਾ ਪਏਗਾ।
Cunningham ਦੇ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ, ਕਾਰਜ਼ ਅਕਸਰ ਈਰਾਦੇ ਨਾਲ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਡਿਜ਼ਾਇਨ ਚੁਣ ਸਕਦੇ ਹੋ ਤਾਂ ਜੋ ਅਸਲ ਯੂਜ਼ਰ ਫੀਡਬੈਕ ਮਿਲੇ, ਜਾਂ ਸੁੰਦਰ ਅਬਸਟ੍ਰੈਕਸ਼ਨ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ ਜਦ ਤੱਕ ਤੁਸੀਂ ਸਮੱਸਿਆ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝ ਨਹੀਂ ਲੈਂਦੇ।
ਚਾਬੀ ਇਹ ਹੈ ਕਿ ਉਹ ਛੋਟਾ ਰਸਤਾ ਇੱਕ ਭਵਿੱਖੀ ਜ਼ਿੰਮੇਵਾਰੀ ਪੈਦਾ ਕਰਦਾ ਹੈ—ਨ ਕਿ ਇਸ ਲਈ ਕਿ ਟੀਮ ਲਾਪਰਵਾਹ ਸੀ, ਪਰ ਇਸ ਲਈ ਕਿ ਅੱਜ ਸਪੀਡ ਅਤੇ ਸਿੱਖਣ ਮਹੱਤਵਪੂਰਨ ਸਨ।
ਕਰਜ਼ਾ ਤਾਕਤਵਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇਕੱਠੇ ਦੋ ਚੀਜ਼ਾਂ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:
ਉਹ “ਵਿਆਜ” ਨੈਤਕ ਅਸਫਲਤਾ ਨਹੀਂ ਹੈ; ਇਹ ਉਸ ਆਮ ਲਾਗਤ ਹੈ ਜੋ ਇਕ ਕੋਡਬੇਸ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਸਥਿਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਹੁਣ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਉਸ ਨਾਲ ਨਹੀਂ ਮਿਲਦੀ।
ਭੁਗਤਾਨ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਰੀਫੈਕਟਰਿੰਗ, ਟੈਸਟ ਸੁਧਾਰ, ਅਤੇ ਓਹਨਾਂ ਹਿੱਸਿਆਂ ਦਾ ਮੁੜ ਡਿਜ਼ਾਇਨ ਕਰਨ ਨਾਲ ਹੁੰਦਾ ਹੈ ਜੋ ਸਮੇਂ ਨਾਲ ਕੇਂਦਰੀ ਬਣ ਗਏ। ਤੁਸੀਂ ਸਭ ਕੁਝ ਮੁੜ ਲਿਖ ਕੇ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰਦੇ—ਤੁਸੀਂ ਕਾਰਵਾਈ ਘਟਾਉਣ ਦੇ ਰਸਤੇ ਹਟਾ ਕੇ ਭਵਿੱਖੀ ਕੰਮ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਾਉਂਦੇ ਹੋ।
Cunningham ਦਾ ਵਿਚਾਰ ਯੋਜਨਾ ਬੱਧ ਕਰਜ਼ੇ ਨਾਲ ਸਭ ਤੋਂ ਮਿਲਦਾ ਜੁਲਦਾ ਹੈ: ਸੋਚ ਸਮਝ ਕੇ, ਦਸਤਾਵੇਜ਼ਬੱਧ ਅਤੇ ਸਮੇਂ ਸਮੇਂ ਉੱਤੇ ਮੁੜ ਦੇਖਿਆ ਜਾਣ ਵਾਲਾ।
ਆਕਸੀਡੈਂਟਲ ਗੜਬੜ ਵੱਖਰੀ ਹੈ: ਅਸਪਸ਼ਟ ਮਾਲਕੀ, ਟੈਸਟਾਂ ਦੀ ਘਾਟ, ਜ਼ੁਰ੍ਰੰਤ ਮਿਲਾਪ, ਅਤੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਡਿਜ਼ਾਇਨ। ਸਭ ਕੁਝ “ਕਰਜ਼ਾ” ਕਹਿਣ ਨਾਲ ਅਸਲ ਮਸਲਾ—ਫੈਸਲਾ ਨਾ ਹੋਣਾ ਅਤੇ ਫਾਲੋ‑ਥਰੂ ਦੀ ਘਾਟ—ਢੱਕ ਜਾਂਦਾ ਹੈ।
Ward Cunningham ਦੀ “technical debt” ਮੈਟਾਫ਼ਰ ਇਸ ਲਈ ਫੈਲੀ ਕਿਉਂਕਿ ਇਹ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਅਸਲ ਅਹਿਸਾਸ ਸਮਝਾਉਂਦੀ ਹੈ: ਤੁਸੀਂ ਅੱਜ ਕੁਝ ਤੇਜ਼ੀ ਨਾਲ ਭੇਜ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਇਸਦਾ ਭੁਗਤਾਨ ਕੱਲ੍ਹ ਨੂੰ ਭੁਗਤਾਣਾ ਪਾ ਸਕਦਾ ਹੈ।
ਵਿੱਤੀ ਕਰਜ਼ੇ ਵਾਂਗ, technical debt ਦਾ ਵਿਆਜ ਹੁੰਦਾ ਹੈ। ਤੇਜ਼ ਫਿਕਸ, ਘੱਟ ਟੈਸਟ, ਜਾਂ ਅਸਪਸ਼ਟ ਡਿਜ਼ਾਇਨ ਆਮ ਤੌਰ 'ਤੇ ਤੁਰੰਤ ਨੁਕਸਾਨ ਨਹੀਂ ਪਹੁੰਚਾਉਂਦੇ—ਪਰ ਉਹ ਹਰ ਅਗਲੇ ਬਦਲਾਅ ਨੂੰ ਹੌਲਾ, ਖਤਰਨਾਕ ਅਤੇ ਜ਼ਿਆਦਾ ਤਣਾਅਭਰ ਬਣਾਉਂਦੇ ਹਨ।
ਇਹ ਟਰੇਡ‑ਆਫ ਅਤੇ ਸਮੇਂ ਦੇ ਮੁੱਦੇ ਨੂੰ ਵੀ ਉਜਾੜਦਾ ਹੈ। ਕਦੀ‑ਕਦੀ ਕਰਜ਼ਾ ਲੈਣਾ ਵਾਜਿਬ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਅਸਥਾਈ ਵਿਕਲਪ ਡੈਡਲਾਈਨ ਨੂੰ ਮੀਟ ਕਰਨ ਲਈ, ਇੱਕ ਵਿਚਾਰ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ, ਜਾਂ ਗਾਹਕ ਨੂੰ ਅਨਲੌਕ ਕਰਨ ਲਈ। ਮੁੱਖ ਗੱਲ ਇਹ ਜਾਣਣਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਚੋਣ ਸੀ, “ਹੋ ਗਿਆ” ਨਹੀਂ।
ਅਤੇ ਇਹ ਟੀਮਾਂ ਨੂੰ ਭੁਗਤਾਨ ਬਾਰੇ ਗੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਰੀਫੈਕਟੋਰਿੰਗ, ਟੈਸਟ ਜੋੜਨਾ, ਡਿਪੈਂਡੈਂਸੀ ਸਧਾਰਨਾ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਸੁਧਾਰ—ਇਹ ਸਾਰੇ ਤਰੀਕੇ ਹਨ ਜਿਹੜੇ ਵਿਆਜ ਘਟਾਉਂਦੇ ਹਨ ਤਾਂ ਜੋ ਭਵਿੱਖੀ ਕੰਮ ਸਸਤਾ ਹੋ ਜਾਵੇ।
ਮੈਟਾਫ਼ਰ ਸ਼ੱਕੀ ਤੌਰ 'ਤੇ ਨੈਤਿਕਤਾ ਵਾਲੀ ਗੱਲ ਬਣ ਸਕਦੀ ਹੈ: “ਕਰਜ਼ਾ” ਕੰਮ ਨੂੰ ਗਲਤ ਜਿਵੇਂ ਲਗਾਉਂਦਾ ਹੈ, ਜੋ ਇਲਜ਼ਾਮ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ (“ਇਹ ਕਿਸਨੇ ਕੀਤਾ?”) ਇਸਦੀ ਬਜਾਏ ਸਿੱਖਣ ('ਇੱਥੇ ਕਿਹੜਾ ਦਬਾਅ ਸੀ?') ਨੂੰ ਤਰਜੀਹ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇਹ ਅਤਿ ਸਧਾਰਨ ਵੀ ਕਰ ਸਕਦਾ ਹੈ। ਸਭ ਗੜਬੜ ਇਕ ਹੀ ਤਰ੍ਹਾਂ ਦੇ ਵਿਆਜ ਨਹੀਂ ਦਿਖਾਉਂਦੀ। ਕੁਝ ਸਮੱਸਿਆਵਾਂ “ਅਣਜਾਣ ਖਤਰੇ”, “ਜਟਿਲਤਾ”, ਜਾਂ “ਉਤਪਾਦ ਨਿਰਣਾ ਨਹੀਂ” ਦੇ ਨੇੜੇ ਹੁੰਦੀਆਂ ਹਨ। ਹਰ ਚੀਜ਼ ਨੂੰ debt ਕਹਿ ਦੇਣਾ ਗਲਤ ਯਕੀਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ “debt” ਲੇਬਲ ਕਰਦੇ, ਕਮਰੇ ਵਿੱਚ ਲੋਕ ਸੁਣ ਸਕਦੇ ਹਨ “ਇੰਜੀਨੀਅਰਿੰਗ cleanup sprint ਚਾਹੁੰਦੀ ਹੈ।” ਜਦੋਂ ਤੁਸੀਂ ** ਪ੍ਰਭਾਵ ** ਦਾ ਵਰਣਨ ਕਰਦੇ—ਧੀਮੀ ਰਿਲੀਜ਼, ਵੱਧ ਆਉਟੇਜ, ਮੁਸ਼ਕਲ onboarding—ਲੋਕ ਇਸਨੂੰ ਹੋਰ ਵਪਾਰਕ ਲਕਸ਼ਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹਨ।
ਮੈਟਾਫ਼ਰ ਨੂੰ ਵਰਤੋ ਚੋਣਾਂ ਨੂੰ ਸਪਸ਼ਟ ਕਰਨ ਲਈ: ਅਸੀਂ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਕੀ ਲਾਗਤ ਆਏਗੀ, ਅਤੇ ਅਸੀਂ ਕਦੋਂ ਭੁਗਤਾਨ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਾਂ? ਪਿਛਲੇ ਫੈਸਲਿਆਂ 'ਤੇ ਲੋਕਾਂ ਨੂੰ ਸ਼ੇਰ ਕਰਨ ਲਈ ਇਹ ਇਸਤੇਮਾਲ ਨਾ ਕਰੋ।
Technical debt ਤਦ ਹੀ ਲਾਭਕਾਰੀ ਹੈ ਜਦੋਂ ਇਹ ਤੁਹਾਡੇ ਸੋਮਵਾਰ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਬਦਲ ਦੇਵੇ। Cunningham ਦਾ ਮੰਤਵ ਨਹੀਂ ਸੀ “ਤੁਹਾਡਾ ਕੋਡ ਖਰਾਬ ਹੈ,” ਬਲਕਿ “ਤੁਸੀਂ ਹੁਣ ਗਤੀ ਵਾਪਸ ਲੈ ਸਕਦੇ ਹੋ—ਜੇ ਤੁਸੀਂ जानबूਝ कर ਫੇਰ ਤੋਂ ਅਦਾ ਕਰੋਂਗੇ।” ਭੁਗਤਾਨ ਦਾ ਨਾਮ ਹੈ: ਰੀਫੈਕਟੋਰਿੰਗ।
Debt ਉਸ ਵੇਲੇ ਵਧਦਾ ਹੈ ਜਦੋਂ ਤਬਦੀਲੀਆਂ ਰਰਿਕਤ ਅਤੇ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇੱਕ ਟੀਮ ਜੋ “ਕਲਿਨਅਪ ਸਪ੍ਰਿੰਟ” ਦੀ ਉਡੀਕ ਕਰਦੀ ਹੈ ਅਕਸਰ ਪاتا ਲੱਗਦਾ ਹੈ ਕਿ ਕੋਡਬੇਸ ਹੇਠਾਂ ਤੋਂ ਬਦਲ ਗਿਆ ਹੈ, ਜਿਸ ਨਾਲ ਕਲਿਨਅਪ ਮਹਿੰਗਾ ਅਤੇ ਰਾਜਨੀਤਿਕ ਤੌਰ 'ਤੇ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।
ਛੋਟੇ, ਅਕਸਰ ਰੀਫੈਕਟਰ—ਫੀਚਰ ਕੰਮ ਦੇ ਨਾਲ ਕੀਤੇ—ਤਬਦੀਲ ਕਰਨ ਦੀ ਲਾਗਤ ਘੱਟ ਰੱਖਦੇ ਹਨ। ਤੁਸੀਂ ਲਗਾਤਾਰ ਥੋੜ੍ਹਾ ਵਿਆਜ ਦੈ ਰਹੇ ਹੋ ਨ ਕਿ ਇਸਨੂੰ ਸਮੇਤਣ ਦਿੰਦੇ ਹੋ ਕਿ ਇਹ ਚਰੰਗ ਹੋ ਜਾਏ।
ਰੀਫੈਕਟੋਰਿੰਗ “ਮੂਲ ਭੁਗਤਾਨ” ਹੈ: ਵਿਹਾਰ ਬਦਲੇ ਬਿਨਾ ਢਾਂਚਾ ਸੁਧਾਰਣਾ। ਫਸ ਹੈ ਵਿਸ਼ਵਾਸ ਦੀ।
ਆਟੋਮੇਟਡ ਟੈਸਟ ਰਿਸਕ ਕੰਟਰੋਲ ਵਾਂਗ ਹਨ: ਉਹ ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਯੋਜਨਾ ਦੇ ਦੌਰਾਨ ਉਤਪਾਦ ਵਿੱਚ ਤੂਟਣ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਖੇਤਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਰੀਫੈਕਟਰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਪਹਿਲਾਂ ਉਸ ਵਿਹਾਰ ਦੇ ਆਸ‑ਪਾਸ ਇਕ ਪਤਲਾ ਟੈਸਟ ਲੇਅਰ ਬਣਾਓ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਨਿਰਭਰ ਹੋ।
ਇਟਰੇਸ਼ਨ ਸਿਰਫ਼ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਬਾਰੇ ਨਹੀਂ ਹੈ; ਇਹ ਜਲਦੀ ਸਿੱਖਣ ਬਾਰੇ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਡਿਲਿਵਰ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਜਦ ਤਕ ਤਬਦੀਲੀਆਂ ਸਸਤੀ ਹਨ। ਇਹ ਗਲਤ ਡਿਜ਼ਾਇਨਾਂ ਦੇ ਪ੍ਰੀਮੈਚਰ “ਹਾਰਡਨ” ਹੋਣ ਨੂੰ ਰੋਕਦਾ ਹੈ।
ਰੋਜ਼ਾਨਾ ਕੰਮ ਵਿੱਚ ਇਹ debt ਸੰਕੇਤ ਵੇਖੋ:
ਜਦੋਂ ਇਹ ਨਜ਼ਰ ਆਉਣ, ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਟੈਸਟ ਕਵਰੇਜ ਨੂੰ ਯੋਜਿਤ ਕੰਮ ਵਜੋਂ ਸਮਝੋ—ਹੁਨਰਮੰਦ ਪਾਸੇ 'ਤੇ ਜਾਣ ਵਾਲੇ ਸਾਈਡ‑ਕੰਮ ਨਹੀਂ।
ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਨਾਟਕੀ “ਗਲਤ ਆਰਕੀਟੈਕਚਰ ਚੁਣੇ” ਪਲ ਨਾਲ ਨਹੀਂ ਆਉਂਦਾ। ਇਹ ਛੋਟੇ ਟਰੇਡ‑ਆਫਾਂ ਵਜੋਂ ਆਉਂਦਾ ਹੈ ਜੋ ਅਸਲ ਦਬਾਅ ਹੇਠ ਕੀਤੇ ਜਾਂਦੇ ਹਨ—ਫਿਰ ਸ਼ਾਂਤ ਢੰਗ ਨਾਲ ਇਕੱਤਰ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦ ਤਕ ਟੀਮ ਧੀਮੀ, ਘੱਟ ਭਰੋਸੇਯੋਗ ਅਤੇ ਜ਼ਿਆਦਾ ਪ੍ਰਤਿਕਿਰਿਆਸ਼ੀਲ ਮਹਿਸੂਸ ਨਾ ਕਰਨ ਲੱਗੇ।
ਇੱਕ ਆਮ ਸਰੋਤ ਤੇਜ਼ ਰਿਲੀਜ਼ ਹੁੰਦੀ ਹੈ: ਡੈਡਲਾਈਨ ਇੱਕ “ਹੁਣ ਲਈ ਚੋੰਗਾ” ਹੱਲ ਤੱਕ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਪਰ “ਹੁਣ” ਮਹੀਨਿਆਂ ਵਿੱਚ ਫੈਲ ਜਾਂਦਾ ਹੈ।
ਦੂਜਾ ਸਰੋਤ ਅਸਪਸ਼ਟ ਜ਼ਰੂਰਤਾਂ ਹਨ। ਜਦੋਂ ਲਕੜੀ ਮੁਲ ਹੁੰਦੀ ਰਹਿੰਦੀ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ ਲਚਕੀਲੇ ਵਰਕਅਰਾਊਂਡ ਬਣਾਉਂਦੀਆਂ ਹਨ ਬਜਾਏ ਸੁਥਰੇ ਹੱਲ ਦੇ—ਕਿਉਂਕਿ ਵਾਰ ਵਾਰ ਮੁੜ ਬਣਾਉਣਾ ਬੇਕਾਰ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਪੁਰਾਣੀਆਂ ਡਿਪੈਂਡੈਂਸੀਆਂ ਵੀ ਪ੍ਰਯੋਗਿਕ ਕਾਰਕ ਹਨ। ਲਾਈਬਰੇਰੀਆਂ, ਫਰੇਮਵਰਕ ਅਤੇ ਸੇਵਾਵਾਂ ਵਿਕਸਤ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਅਪ‑ਟੂ‑ਡੇਟ ਰਹਿਣ ਲਈ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਛੱਡ ਦਿੱਤੀਆਂ ਚੀਜ਼ਾਂ ਅਰਥਪੂਰਨ ਸਮੇਂ ਵਿੱਚ ਵਾਜਿਬ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਹ ਭਵਿੱਖੀ ਲਾਗਤ ਵਧਾਉਂਦੀਆਂ ਹਨ: ਸੁਰੱਖਿਆ ਅਪਡੇਟ ਮੁਸ਼ਕਲ ਹੁੰਦੇ ਹਨ, ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਟੁੱਟ ਸਕਦੇ ਹਨ, ਅਤੇ ਭਰਤੀ ਔਖੀ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਸਟੈਕ ਫਸਿਆ ਹੋਇਆ ਮਹਿਸੂਸ ਹੋਵੇ।
ਜਹੀਦੇ ਤਰੀਕੇ ਨਾਲ ਬਣੇ ਸਿਸਟਮ ਵੀ ਡ੍ਰਿਫਟ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਛੋਟਾ ਪੈਚ ਇੱਕ ਐਜ‑ਕੇਸ ਹਾਬੇ ਲਈ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰੈਸੀਡੈਂਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਹੋਰ ਪੈਚ ਉਸ 'ਤੇ ਲੇਅਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਸਮੇਂ ਦੇ ਨਾਲ, “ਅਸਲ” ਡਿਜ਼ਾਇਨ ਉਹ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਚ ਰਹਿ ਗਈ—not ਜੋ ਕਿਸੇ ਨੇ ਇੰਤਜ਼ਾਮ ਕੀਤਾ ਸੀ।
ਇਸ ਲਈ ਟੀਮਾਂ ਕਦੇ ਕਹਿਣਦੀ ਹਨ, “ਕੋਈ ਵੀ ਇਸ ਮੋਡੀਊਲ ਨੂੰ ਨਹੀਂ ਸਮਝਦਾ।” ਇਹ ਨੈਤਿਕ ਅਸਫਲਤਾ ਨਹੀਂ—ਇਹ ਡ੍ਰਿਫਟ ਹੈ।
ਸਭ ਕਰਜ਼ਾ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ।
ਗਿਆਨ ਕਰਜ਼ਾ ਉਸ ਵੇਲੇ ਬਣਦਾ ਹੈ ਜਦੋਂ ਫੈਸਲੇ ਕੈਪਚਰ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ: ਕਿਉਂ ਛੋਟਾ ਰਸਤਾ ਲਿਆ ਗਿਆ, ਕਿਹੜੇ ਖਤਰੇ ਸਵੀਕਾਰ ਕੀਤੇ, ਕਿਹੜੇ ਵਿਕਲਪ ਰੱਦ ਕੀਤੇ ਗਏ। ਅਗਲਾ ਵਿਅਕਤੀ ਉਹ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ ਉਹ ਵੇਖ ਨਹੀਂ ਸਕਦਾ।
ਟੂਲਿੰਗ ਕਰਜ਼ਾ ਵੀ ਬਰਾਬਰ ਹਕੀਕਤ ਹੈ: ਹੌਲੀ ਬਿਲਡ, ਫਲੇਕੀ ਟੈਸਟ, ਨਾਜੁਕ CI ਪਾਇਪਲਾਈਨ, ਅਤੇ ਅਸੰਗਤ ਵਿਕਾਸ ਦਾ ਵਾਤਾਵਰਣ। ਇਹ ਰੋਜ਼ਾਨਾ ਘਰੜਾ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਹੋਰ ਛੋਟੇ ਰਸਤੇ ਲੈਣ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ—ਇਹ ਚੱਕਰ ਨੂੰ ਪੋਸ਼ਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕਰਜ਼ਾ ਜਲਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਦੁਹਰਾਏ ਕੰਮ, ਵੱਧਦੇ “ਡਰ ਰੀਫੈਕਟੋਰ” ਅਤੇ ਟੂਲਾਂ ਨਾਲ ਸਮਾਂ ਖਪਾਉਣ ਉੱਤੇ ਧਿਆਨ ਦਿਓ—ਬਨਾਉਣ ਦੀ ਥਾਂ।
ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਇਕ ਇਕਲੌਤਾ “ਕਲਿਨਅਪ ਸਪ੍ਰਿੰਟ” ਨਹੀਂ ਹੈ। ਇਹ ਟਰੇਡ‑ਆਫਾਂ ਦੀ ਇੱਕ ਲੜੀ ਹੈ। ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਕਿਹੜੇ ਟਰੇਡ‑ਆਫਾਂ ਨੂੰ ਵਾਪਸ ਕਰਨਾ—ਬਿਨਾਂ ਡਿਲਿਵਰੀ ਰੋਕੇ ਜਾਂ ਗੰਦگي ਵੱਧਣ ਦੇ।
ਉਸ ਕਰਜ਼ੇ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਦਿਨ‑ਪ੍ਰਤੀ ਦਿਨ ਕੰਮ ਨੂੰ ਹੌਲਾ ਜਾਂ ਖਤਰਨਾਕ ਬਣਾ ਰਿਹਾ ਹੈ:
ਇੱਕ ਸਰਲ ਪਰਖ: ਜੇ ਕੋਈ ਕਰਜ਼ਾ ਹਫਤੇ ਦੇ ਹਰ ਰੋਜ਼ ਯੂਜ਼ਰ‑ਸਮਮੁੱਖ ਮੁੱਲ ਪਹੁੰਚਾਉਣ ਦਾ ਸਮਾਂ ਵਧਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਉੱਚ‑ਬਿਆਜ ਵਾਲਾ ਲੋਨ ਹੈ।
“ਫੀਚਰ ਬਨਾਮ ਰੀਫੈਕਟਰ” ਦੇ ਬਹਿਸ ਦੀ ਬਜਾਏ, ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜੋ:
ਇਸ ਨਾਲ ਅੰਦਰੂਨੀ ਕੰਮ ਯੂਜ਼ਰ ਪ੍ਰਭਾਵ ਨਾਲ ਜੁੜੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ “ਨਵਾਂ ਫੀਚਰ” ਕੰਮ ਹੋਰ ਖਰਾਬੀ ਨਾ ਵਧਾਉਂਦਾ।
ਟੀਮ ਉਹੀ ਚੀਜ਼ ਅਹੰਕਾਰ ਨਾਲ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿੰਦੀ ਜੋ ਉਹ ਦੇਖ ਸਕਦੀ ਹੈ। ਸਧਾਰਨ ਰੱਖੋ:
debt, risk, slow-build, hard-to-test ਵਰਗੇ ਟੈਗਦਿੱਖ ਬਣਾਉਣ ਨਾਲ ਧੁੰਦਲੇ ਸ਼ਿਕਾਇਤਾਂ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਵਿਕਲਪ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਕਈ ਵਾਰ ਤੁਸੀਂ ਜਾਨ‑ਬੁਝ ਕੇ ਕਰਜ਼ਾ ਲਵੋਗੇ (ਡੈਡਲਾਈਨ ਹੁੰਦੇ ਹਨ)। ਇਹ ਇੱਕ ਨਿਯੰਤਰਿਤ ਫੈਸਲਾ ਬਣਾਓ:
ਇਸ ਨਾਲ “ਅਸਥਾਈ” ਛੋਟੇ ਰਸਤੇ ਸਥਾਈ ਆਰਕੀਟੈਕਚਰ ਬਣਨ ਤੋਂ ਰੁੱਕਦੇ ਹਨ।
ਇੱਕ ਵੱਡਾ ਕਾਰਣ ਭੁਗਤਾਨ ਦੁਬਾਰਾ ਆਉਣ ਦਾ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਭੁੱਲ ਜਾਂਦੀਆਂ ਹਨ ਕਿ ਕਿਉਂ ਇੱਕ ਫੈਸਲਾ ਲਿਆ ਗਿਆ ਸੀ।
ਇੱਕ ਵਿਕੀ ਕੋਡਬੇਸ ਦੀ “ਯਾਦ” ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ: ਨਾ ਸਿਰਫ਼ ਕੀ ਸਿਸਟਮ ਕਰਦਾ ਹੈ, ਪਰ ਕਿਹੜੇ ਟਰੇਡ‑ਆਫ ਮਨਜ਼ੂਰ ਕੀتے ਗਏ, ਕੀ ਮੁਆਵਜ਼ਾ ਅਸਥਾਈ ਰੱਖਿਆ ਗਿਆ, ਅਤੇ ਕਿਹੜੀਆਂ ਧਾਰਨਾਵਾਂ ਅਗਲੇ ਸਮੇਂ ਵਿੱਚ ਟੁੱਟ ਸਕਦੀਆਂ ਹਨ।
ਜਦੋਂ ਨਵੇਂ ਲੋਕ ਜੁੜਦੇ ਹਨ—ਜਾਂ ਟੀਮ ਮਹੀਨਿਆਂ ਬਾਅਦ ਕਿਸੇ ਮੋਡੀਊਲ ਨੂੰ ਮੁੜ ਵੇਖਦੀ ਹੈ—ਇੱਕ ਵਿਕੀ ਉਨ੍ਹਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਸੰਦਰਭ ਦਿੰਦੀ ਹੈ। ਉਹ ਸੰਦਰਭ ਟੀਮਾਂ ਨੂੰ ਇੱਕਸਾਰ ਚੋਣਾਂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਮੁੜ‑ਮੁੜੀ ਸਿੱਖ ਵਿੱਚ ਵਿਆਜ ਦੇ ਕੇ ਸਮਾਂ ਖਰਚ ਨਾ ਕਰੋ।
ਚਾਬੀ ਉਹਨਾਂ ਪਲਾਂ ਨਾਲ ਗਿਆਨ ਲਿੰਕ ਕਰਨਾ ਹੈ ਜਿਥੇ ਫੈਸਲੇ ਲਏ ਗਏ: ਰਿਲੀਜ਼, ਘਟਨਾਵਾਂ, ਮਾਈਗਰੇਸ਼ਨ, ਅਤੇ ਮੁੱਖ ਰੀਫੈਕਟੋਰ।
ਵਿਕੀ ਸਭ ਤੋਂ ਚੰਗਾ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦ ਪੇਜ਼ ਕੁਝ ਹਲਕੇ ਟੈਮਪਲੇਟਿਸ ਨੂੰ ਅਨੁਸਰਦੇ ਹਨ:
ਹਰ ਪੇਜ਼ ਛੋਟਾ ਰੱਖੋ। ਜੇ ਸਮਝਣ ਲਈ ਮੀਟਿੰਗ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਇਹ ਬਹੁਤ ਲੰਮਾ ਹੈ।
ਦਸਤਾਵੇਜ਼ ਸੱਚਾਈ ਨਾ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨਦਾਇਕ ਬਣ ਜਾਂਦੇ ਹਨ। ਛੋਟੀਆਂ ਆਦਤਾਂ ਇਸਨੂੰ ਰੋਕਦੀਆਂ ਹਨ:
ਜਦ ਵੀ ਤੁਸੀਂ “refactor X” ਜਾਂ “clean up Y” ਲਈ ਟਿਕਟ ਖੋਲ੍ਹਦੇ ਹੋ, ਉਸਨੂੰ ਸੰਬੰਧਿਤ ADR, ਇੰਸਿਡੈਂਟ ਰਿਵਿਊ, ਜਾਂ ਡੈਬਟ‑ਲੌਗ ਐਂਟਰੀ ਨਾਲ ਲਿੰਕ ਕਰੋ।
ਫਿਰ, ਜਦ ਕੋਈ ਪੁੱਛਦਾ “ਅਸੀਂ ਇਸ 'ਤੇ ਸਮਾਂ ਕਿਉਂ ਬਚਾ ਰਹੇ ਹਾਂ?”, ਜਵਾਬ ਇਕ ਕਲਿੱਕ ਦੁਰੀ 'ਤੇ ਹੋਵੇਗਾ—ਅਤੇ ਭਵਿੱਖੀ ਤਬਦੀਲੀਆਂ ਆਸਾਨ ਹੋ ਜ਼ਾਵਣਗੀਆਂ ਕਿਉਂਕਿ ਇਰਾਦਾ ਸਪਸ਼ਟ ਹੈ।
ਤਕਨੀਕੀ ਕਰਜ਼ਾ ਤਦ ਹੀ ਫੰਡ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦ ਲੋਕ ਪ੍ਰਭਾਵ ਨੂੰ ਸਮਝਦੇ ਹਨ, ਨ ਕਿ ਜਦ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ “debt points” ਵਾਲੀ ਸਪ੍ਰੈੱਡਸ਼ੀਟ ਦਿਖਾਉਂਦੇ ਹੋ। Cunningham ਦੀ ਮੈਟਾਫ਼ਰ ਕੰਪਨੀ ਗੱਲਬਾਤ ਵਿੱਚ ਇੰਜੀਨੀਅਰਿੰਗ ਟਰੇਡ‑ਆਫ ਨੂੰ ਤਬਦੀਲ ਕਰਦੀ—ਇਸ ਲਈ ਸੁਨੇਹਾ ਸਧਾਰਨ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਨਤੀਜਿਆਂ 'ਤੇ ਅਧਾਰਤ ਰੱਖੋ।
“ਸਾਡੇ ਕੋਲ 37% debt ਹੈ” ਜਾਂ “ਇਹ ਮਾਡਿਊਲ 12 ਦਿਨ ਪਿੱਛੇ ਹੈ” ਵਰਗੀਆਂ ਦਾਅਵਿਆਂ ਤੋਂ ਬਚੋ। ਇਸ ਦੀ ਥਾਂ ਵਰਣਨ ਕਰੋ ਕਿ ਕਰਜ਼ੇ ਕਾਰਨ ਟੀਮ ਕੀ ਨਹੀਂ ਕਰ ਸਕਦੀ—ਜਾਂ ਫ਼ਿਲਹਾਲ ਕਿਹੜੀ ਕੰਮ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਰਨ ਵਿੱਚ ਰੁਕਾਵਟ ਆ ਰਹੀ ਹੈ।
ਉਦਾਹਰਣ:
ਮੈਟ੍ਰਿਕਸ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਕੇਵਲ ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੰਡਿਕੇਟਰ ਵਜੋਂ ਵਰਤਦੇ ਹੋ, ਨ ਕਿ ਸਬੂਤ ਵਜੋਂ।
ਬਿਹਤਰ ਚੋਣਾਂ ਜੋ ਬਹੁਤ ਟੀਮਾਂ ਬਿਨਾਂ ਭਾਰੀ ਟੂਲਿੰਗ ਦੇ ਮਾਪ ਸਕਦੀਆਂ ਹਨ:
ਵਿਆਜ ਉਹ ਵਾਧੂ ਲਾਗਤ ਹੈ ਜੋ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਉਸ ਖੇਤਰ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਭੁਗਤਦੇ ਹੋ। ਅਕਸਰ ਕਹੋ: “ਹਰ ਚੇਂਜ ਵਿੱਚ 2–3 ਘੰਟਿਆਂ ਦਾ ਵਾਧੂ ਸਮਾਂ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ ਰੀਵਰਕ, ਕੋਆਰਡੀਨੇਸ਼ਨ, ਜਾਂ ਮੈਨੂਅਲ ਟੈਸਟਿੰਗ ਲਈ। ਇਸ ਕਰਜ਼ੇ ਨੂੰ ਘਟਾਉਣ ਨਾਲ ਉਹ ਲਗਾਤਾਰ ਲਾਗਤ ਘਟਦੀ ਹੈ।”
ਇੱਕ ਛੋਟੀ ਉਦਾਹਰਨ (ਕੀ ਸਭਕਾਰੀ ਰੁਕਾਵਟ ਆਈ, ਕੀ ਰਿਸਕ ਵੱਧਿਆ) ਇੱਕ ਸਹੀ ਮੈਟ੍ਰਿਕ ਨਾਲ ਜੋੜੋ। ਕਹਾਣੀਆਂ ਸਪਸ਼ਟਤਾ ਬਣਾਉਂਦੀਆਂ ਹਨ; ਮੈਟ੍ਰਿਕ ਭਰੋਸੇਯੋਗਤਾ ਵਧਾਉਂਦੇ ਹਨ—ਬਿਨਾਂ ਇਹ ਦਾਅਵਾ ਕੀਤੇ ਕਿ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਨਜ਼ੈਕ ਹੀ ਮਾਪ ਸਕਦੇ ਹੋ।
Ward Cunningham ਦੀਆਂ ਦੋ ਵੱਡੀਆਂ ਸੋਚਾਂ ਤੋਂ ਲਾਭ ਪਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਕੰਪਨੀ ਪੱਧਰ ਦੀ ਪਹਿਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਇੱਕ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਇੱਕ ਛੋਟਾ, ਦੁਹਰਾਏ ਯੋਗ ਲੂਪ ਚਲਾਓ: ਇੱਕ ਵਿਕੀ ਪੇਜ਼ ਨੂੰ ਸਾਂਝੀ ਯਾਦਦਾਸ਼ਤ ਵਜੋਂ ਵਰਤੋ, ਅਤੇ ਤਕਨੀਕੀ ਕਰਜ਼ੇ ਨੂੰ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਟਰੇਡ‑ਆਫ ਮੰਨੋ ਜਿਸਦਾ ਭੁਗਤਾਨ ਕੀਤਾ ਜਾ ਸਕੇ।
ਇੱਕ ਇੱਕਲ ਪੇਜ਼ ਬਣਾਓ: “Project X: Debt & Learning Log.” ਇਕ ਛੋਟੀ ਮੀਟਿੰਗ ਵਿੱਚ, ਉਹ ਹਾਟਸਪਾਟ ਲਿਸਟ ਕਰੋ ਜਿੱਥੇ ਟੀਮ ਲਈ ਮੁੜ ਮੁੜ ਰੁਕਾਵਟ ਆ ਰਹੀ ਹੈ।
ਰੋਜ਼ਾਨਾ ਦਰਦ ਉੱਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰੋ, ਨਾ ਕਿ abstract ਕੋਡ ਗੁਣਵੱਤਾ:
ਹਰ ਆਈਟਮ ਲਈ ਦੋ ਟਿੱਪਣੀਆਂ ਜੋੜੋ: “ਟੁੱਟਣ 'ਤੇ ਕੀ ਹੁੰਦਾ?” ਅਤੇ “ਕਿਹੜਾ ਕੰਮ ਵਿਚਰਿਆ ਜਾਂਦਾ ਹੈ?” ਇਹ ਗੱਲ‑ਬਾਤ ਨੂੰ ਨਤੀਜਿਆਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖਦਾ ਹੈ।
ਸਿਰਫ 1–3 ਆਈਟਮ ਚੁਣੋ। ਹਰ ਇੱਕ ਲਈ ਲਿਖੋ:
ਰੂਲ: ਉਹ ਕਰਜ਼ਾ ਚੁਣੋ ਜੋ ਅਗਲੇ ਹਫ਼ਤੇ ਦੇ ਕੰਮ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਸੁਧਾਰ ਲਿਆਵੇ।
ਇਸਨੂੰ ਫੀਚਰ ਕੰਮ ਵਾਂਗ ਹੀ ਮਾਨੋ: ਛੋਟੇ ਕਮਿਟ, ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਟੈਸਟ, ਅਤੇ ਵਿਕੀ 'ਤੇ ਇਕ ਛੋਟੀ ਨੋਟ ਕਿ ਕੀ ਬਦਲਿਆ ਅਤੇ ਕਿਉਂ।
ਛੋਟੀ “ਸਿੱਖਿਆ” ਸੈਕਸ਼ਨ ਜੋੜੋ: ਕੀ ਹੈਰਾਨ ਕੀਤਾ, ਕੀ ਲੰਮਾ ਲੱਗਿਆ, ਅਤੇ ਅਗਲੇ ਵਾਰੀ ਤੁਸੀਂ ਕੀ ਵੱਖਰਾ ਕਰੋਗੇ। ਫਿਰ ਆਪਣੀ ਲਿਸਟ ਅਪਡੇਟ ਕਰੋ ਅਤੇ ਹਫ਼ਤੇ ਜਾਂ ਦੋ ਹਫ਼ਤੇ ਵਿੱਚ ਲੂਪ ਦੌਰਾਓ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਨਵੀਂ ਅੰਦਰੂਨੀ ਟੂਲਾਂ ਜਾਂ ਪ੍ਰੋਟੋਟਾਈਪਲਾ ਬਣਾ ਰਹੀ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਇਸ ਵਰਕਫਲੋ ਨਾਲ ਚੰਗੇ ਢੰਗ ਨਾਲ ਟਿਕ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ ਉਸਦੀ ਖ਼ੁਲ੍ਹੀ ਚੈਟ‑ਅਧਾਰਤ planning mode ਵਰਤ ਕੇ ਅਗੇਸ਼ਨ ਅਤੇ ਫੈਸਲਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਕੈਪਚਰ ਕਰ ਸਕਦੇ ਹੋ, ਇਕ React/Go/PostgreSQL (ਜਾਂ Flutter) ਦਾ ਕੰਮ ਕਰਨ ਵਾਲਾ ਸਲਾਈਸ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸਨੇਪਸ਼ਾਟ ਤੇ ਰੋਲਬੈਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਯੋਗ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ, ਅਣਚਾਹੇ ਕਰਜ਼ੇ ਵਿੱਚ ਪਰਿਵਰਤਿਤ ਹੋਣ ਤੋਂ ਰੋਕ ਸਕਦੇ ਹੋ। ਜਦ ਲੋੜ ਹੋਵੇ, ਤੁਸੀਂ ਸੋਰਸ ਕੋਡ ایکਸਪੋਰਟ ਕਰਕੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਆਪਣੀ ਆਦਤ ਦੀ ਰੇਪੋ ਅਤੇ ਰਿਵਿਊ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਲੈ ਜਾ ਸਕਦੇ ਹੋ।
“Technical debt” ਇੱਕ ਲਾਭਦਾਇਕ ਮੈਟਾਫ਼ਰ ਹੈ—ਜਦ ਤੱਕ ਇਹ ਸਭ ਕੁਝ ਫ੍ਰਸਟਲ ਮਾਨ ਲੈਣ ਲਈ ਇੱਕ catch‑all ਲੇਬਲ ਨਾ ਬਣ ਜਾਏ। ਜਦ ਇਹ ਹੋ ਜਾਂਦਾ, ਟੀਮਾਂ ਸਪਸ਼ਟ ਟਰੇਡ‑ਆਫ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਖੋ ਬੈਠਦੀਆਂ ਹਨ।
ਹਰ ਗੰਦੇ ਕੋਡ ਨੂੰ debt ਨਹੀਂ ਕਹਿਨਾ ਚਾਹੀਦਾ। debt ਉਹ ਛੋਟਾ ਰਸਤਾ ਹੈ ਜੋ ਹੁਣ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਣ ਲਈ ਸੋਚ‑ਸਮਝ ਕੇ ਲਿਆ ਗਿਆ ਸੀ, ਜਿਸਦੀ ਭੁਗਤਾਨ ਯੋਜਨਾ ਹੈ।
ਚੰਗੇ ਵਿਕਲਪ:
“ਸਭ ਕੁਝ ਇੱਕ ਵਾਰੀ ਸਾਫ਼ ਕਰ ਦੇਵੋ” ਵਾਲੇ ਸਪ੍ਰਿੰਟ ਅਕਸਰ fail ਕਰ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਅਗਲੇ ਹਫ਼ਤੇ ਨਵਾਂ ਕਰਜ਼ਾ ਬਣ ਜਾਂਦਾ ਹੈ। Cunningham ਦੀ ਸੋਚ ਇੱਕ ਆਦਤ ਵਜੋਂ ਬਿਹਤਰ ਮੈਚ ਕਰਦੀ ਹੈ: ਜਾਣ‑ਬੁਝ ਕੇ ਕਰਜ਼ਾ ਲਓ, ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚੁਕਾਉ।
ਬਿਹਤਰ ਵਿਕਲਪ: ਇੱਕ ਲਗਾਤਾਰ ਰੀਫੈਕਟੋਰਿੰਗ ਬਜਟ ਬਣਾਓ (ਛੋਟੇ, ਅਕਸਰ ਠੀਕ) ਜਿਹੜੇ ਅਸਲ ਕੰਮ ਨਾਲ ਜੁੜੇ ਹੋਣ।
ਕਰਜ਼ਾ ਕਦਾਚਿਤ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਗ਼ਲਤੀ ਹੁੰਦਾ ਹੈ। ਡੈਡਲਾਈਨ, ਅਸਪਸ਼ਟ ਮੰਗਾਂ, ਟੈਸਟ ਦੀ ਘਾਟ, ਅਤੇ ਹੇਡਓਫ਼ ਹਨ ਉਹ ਹਾਲਾਤ ਜੋ ਸੰਖੇਪ ਰਸਤੇ ਤਰਕਸੰਗਤ ਬਣਾਉਂਦੇ ਹਨ।
ਬਿਹਤਰ ਵਿਕਲਪ: ਪ੍ਰਣਾਲੀਕ ਬਾੱਧਾ ਵੇਰਵਾ ਕਰੋ (“ਟੈਸਟ ਵਾਤਾਵਰਣ ਨਹੀਂ”, “ਅਸਪਸ਼ਟ ਮਾਲਕੀ”, “ਤੁਰੰਤ ਰਿਲੀਜ਼”) ਅਤੇ ਪਹਿਲਾਂ ਉਸਨੂੰ ਠੀਕ ਕਰੋ।
ਇੱਕ ਪੁਰਾਣੀ ਵਿਕੀ ਨ ਹੋਣ ਨਾਲੋਂ ਵਧੀਅਾ ਹੈ: ਇਹ ਗਲਤ ਧਾਰਨਾਵਾਂ ਫੈਲਾਉਂਦੀ ਹੈ।
ਬਿਹਤਰ ਵਿਕਲਪ: ਵਿਕੀ ਪੇਜ਼ ਛੋਟੇ, ਮਾਲਕੀ ਵਾਲੇ, ਅਤੇ ਰੀਵਿਊਯੋਗ ਰੱਖੋ—“last verified” ਨੋਟ ਸ਼ਾਮਿਲ ਕਰੋ, ਸੂਤਰ‑ਟਿਕਟਾਂ ਨਾਲ ਲਿੰਕੋ, ਅਤੇ ਉਹ ਪੇਜ਼ ਡਿਲੀਟ ਕਰੋ ਜੋ maintain ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦੇ।
ਤੁਹਾਨੂੰ Cunningham ਦੀ “ਵਿਕੀ + ਕਰਜ਼ਾ” ਸੋਚ ਤੋਂ ਲਾਭ ਲਈ ਕਿਸੇ ਰੀਆਰਗ ਜਾਂ ਨਵੇਂ ਟੂਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਕੁਝ ਹਲਕੀ ਆਦਤਾਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਟਰੇਡ‑ਆਫਾਂ ਨੂੰ ਦਿੱਖਯੋਗ ਅਤੇ ਦੁਹਰਾਏ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਆਪਣੀ ਟੀਮ ਵਿਕੀ ਵਿੱਚ Debt Log ਨਾਮ ਦਾ ਇੱਕ ਸਿਰਫ਼ ਇੱਕ ਪੇਜ਼ ਬਣਾਓ। ਇਸਨੂੰ ਛੋਟਾ ਅਤੇ ਤਾਜ਼ਾ ਰੱਖੋ।
ਹਰ ਐਂਟਰੀ ਲਈ:
ਸਪ੍ਰਿੰਟ/ਸਪੱਤਾਹਿਕ ਯੋਜਨਾ ਵਿੱਚ ਇੱਕ ਨਿਯਮਤ ਬਜਟ ਸ਼ਾਮਿਲ ਕਰੋ (ਛੋਟਾ): ਉਦਾਹਰਨ ਵਜੋਂ 10–20% ਸਮਰਥਾ ਜਾਂ ਹਰ ਫੀਚਰ ਲਈ ਇੱਕ ਰੀਫੈਕਟਰ ਕਹਾਣੀ।
ਇਸਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ: “ਅਸੀਂ ਹਰ ਹਫ਼ਤੇ ਵਿਆਜ ਭੁਗਤਦੇ ਹਾਂ; ਇਹ ਇੱਕ ਨਿਯਤ ਭੁਗਤਾਨ ਹੈ।” ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ ਰੀਫੈਕਟਰਿੰਗ ਟਾਸਕ ਨੂੰ ਯੂਜ਼ਰ‑ਦਿੱਖ ਵਾਲੇ ਲਕਸ਼ ਨਾਲ ਜੋੜੋ (ਤੇਜ਼ ਤਬਦੀਲੀਆਂ, ਘੱਟ ਘਟਨਾਵਾਂ, ਆਸਾਨ ਟੈਸਟਿੰਗ)।
ਸਥਿਰਤਾ ਵਿਸਥਾਰ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸ਼ੁਰੂ ਕਰੋ:
ਵਿਕੀ 'ਤੇ ਇੱਕ ਛੋਟਾ “Definition of Debt” ਲਿਖੋ: ਕੀ ਗਿਣਦਾ ਹੈ, ਕੌਣ ਇਸਨੂੰ ਲੇਬਲ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਭੁਗਤਾਨ ਕਿਵੇਂ ਮਨਜ਼ੂਰ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਥੋੜ੍ਹੀ ਸਫਲ ਨਿਯਮ: Debt ਇੱਕ ਜਾਣ‑ਬੁਝ ਕੇ ਟਰੇਡ‑ਆਫ ਹੈ ਜਿਸਦੀ ਭੁਗਤਾਨ ਯੋਜਨਾ ਹੁੰਦੀ ਹੈ। ਜੇ ਇਹ ਸਿਰਫ਼ ਅਸਪਸ਼ਟ ਹੈ, ਤਾਂ ਇਸਨੂੰ “unknown”, “bug”, ਜਾਂ “design risk” ਕਹੋ।
Ward Cunningham ਦੋ ਪ੍ਰਯੋਗਿਕ ਵਿਚਾਰਾਂ ਲਈ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਮਸ਼ਹੂਰ ਹੈ ਜਿਹੜੇ ਆਪਣੇ ਮੂਲ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਜਾਂਦੇ ਹੋਏ ਹਰ ਰੋਜ਼ ਦੇ ਸੰਦ ਬਣ ਗਏ: ਪਹਿਲੀ ਵਿਕੀ (WikiWikiWeb) ਅਤੇ “technical debt” ਮੈਟਾਫ਼ਰ।
ਦੋਹਾਂ ਹੀ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮੰਤਵ ਬ੍ਰਾਂਡਿੰਗ ਨਹੀਂ ਸੀ—ਇਹ ਮੁੜ ਮੁੜ ਆਉਂਦੇ ਟੀਮ ਮਸਲਿਆਂ ਦੇ ਹਲ ਸੀ, ਜਿਵੇਂ ਕਿ ਗੁੰਮ ਹੋਈ ਸੰਦਰਭ ਜਾਣਕਾਰੀ, ਧੀਮੀ ਗਿਆਨ ਸਾਂਝੇਦਾਰੀ ਅਤੇ ਉਹਨਾਂ ਵਪਾਰਕ ਫੈਸਲਿਆਂ ਦੀ ਗੁਪਤਤਾ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਕੋਡ ਵੱਲੋਂ ਬਦਲ ਜਾਣਾ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੰਦੇ ਹਨ।
Cunningham ਨੇ 1990 ਦੇ ਵਿਚਕਾਰ ਪਹਿਲੀ ਵਿਕੀ ਬਣਾਈ ਤਾਂ ਜੋ ਸੌਫਟਵੇਅਰ ਅਭਿਆਸਕਰਤਾਂ ਪੈਟਰਨ ਅਤੇ ਵਿਚਾਰ ਸਾਂਝੇ ਕਰ ਸਕਣ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਮਿਲ ਕੇ ਸੁਧਾਰ ਕਰ ਸਕਣ।
ਮਕਸਦ ਇੱਕ ਜੀਵੰਤ ਗੱਲਬਾਤ ਬਣਾਉਣ ਦਾ ਸੀ: ਛੋਟੀਆਂ ਸੋਧਾਂ, ਤੇਜ਼ ਲਿੰਕਿੰਗ ਅਤੇ ਸਾਂਝੀ ਮਾਲਕੀ—ਤਾਂ ਜੋ ਗਿਆਨ ਕميਨਿਟੀ ਦੇ ਸਿੱਖਣ ਦੇ ਨਾਲ ਵਿਕਸਤ ਹੋ ਸਕੇ।
ਇੱਕ ਵਿਕੀ ਨੂੰ ਥਾਂ 'ਤੇ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਪੇਜ਼ ਨੂੰ ਹੀ ਸੋਧਦੇ ਹੋ ਅਤੇ ਹਰ ਕੋਈ ਤੁਰੰਤ ਅਪਡੇਟ ਵੇਖਦਾ ਹੈ।
ਤੁਲਨਾ ਵਿੱਚ:
ਵਿਕੀ ਤੇਜ਼ ਸਹੀ ਕਰਨ ਅਤੇ ਸਾਂਝੀ, ਕਰੰਟ ਸਮਝ ਲਈ ਅਨੁਕੂਲ ਹੈ।
ਉਹ ਪੇਜ਼ ਬਣਾੋ ਜੋ ਰੋਜ਼ਾਨਾ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ—ਨ ਕਿ ਇਕ ਵੱਡੇ ਦਸਤਾਵੇਜ਼ੇ ਪ੍ਰਯਾਸ
ਇੱਕ ਪ੍ਰਾਇਗਟਿਕ ਸਟਾਰਟਰ ਸੈਟ:
ਹਰ ਪੇਜ਼ ਛੋਟਾ ਅਤੇ ਅੱਜ ਲਈ ਉਪਯੋਗੀ ਰੱਖੋ; ਬਾਅਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦੇ ਹੋ।
ਕੁਝ ਸਥਿਰ ਟੈਮਪਲੇਟ ਵਰਤੋ ਤਾਂ ਜੋ ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖ ਸਕਣ ਅਤੇ ਪਾਠਕ ਆਸਾਨੀ ਨਾਲ ਸਕੈਨ ਕਰ ਸਕਣ।
ਵਧੀਆ ਹਲਕੇ ਟੈਮਪਲੇਟ:
ਟੈਮਪਲੇਟ friction ਘਟਾਉਣ ਲਈ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਪੂਰਨਤਾ ਥੋੜ੍ਹੀ ਨਹੀਂ ਲਗਾਉਣੇ।
ਬੁਜ਼ੁਰਗੀ ਨੂੰ ਮੁੱਖ ਅਸਫਲਤਾ ਮੋਡ ਮਨੋ ਅਤੇ ਛੋਟੀਆਂ ਆਦਤਾਂ ਜੋ ਇਹ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਜੋਗਵਾਰ ਕਰੋ।
ਵਹੀ ਪ੍ਰਯੋਗਿਕ ਸੁਰੱਖਿਆ:
ਇੱਕ ਛੋਟੀ, ਭਰੋਸੇਯੋਗ ਵਿਕੀ ਵੱਡੀ, ਬੇਕਦ੍ਰ ਵਿਕੀ ਨਾਲੋਂ ਵਧੀਆ ਹੈ।
Cunningham ਦੇ ਮੁਲ ਸੰਦਰਭ ਵਿੱਚ, technical debt ਇੱਕ ਜਾਣ‑ਬੁਝ ਕੇ ਕੀਤਾ ਹੋਇਆ ਟਰੇਡ‑ਆਫ ਹੈ: ਤੁਸੀਂ ਹੁਣ ਸਿੱਧਾ ਜਾਂ ਤੇਜ਼ ਰਸਤਾ ਚੁਣਦੇ ਹੋ ਤਾਂ ਜੋ ਤੇਜ਼ ਸਿੱਖਿਆ ਜਾਂ ਤੁਰੰਤ ਰਿਲੀਜ਼ ਮਿਲ ਸਕੇ, ਪਰ ਇਹ ਮਣਦਾ ਹੈ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਕੰਮ ਰਹਿ ਜਾਵੇਗਾ।
ਇਹ ਆਪਣੀ ਥਾਂ 'ਤੇ ਬੁਰਾ ਕੋਡ ਨਹੀਂ ਸੀ; ਇਹ ਸਮਾਂ ਣ ਲੈਣ ਵਰਗਾ ਹੈ ਜਿਸਦਾ ਮੁਕਾਬਲਾ ਰੀਫੈਕਟੋਰਿੰਗ, ਟੈਸਟਿੰਗ ਜਾਂ ਡਿਜ਼ਾਇਨ ਮੁੜ ਕਰਨ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਯੋਜਨਾ ਬੱਧ ਕਰਜ਼ਾ ਇੱਕ ਹੋਸ਼ੀਅਾਰ ਛੋਟ ਹੈ ਜਿਸਦੇ ਸੰਦਰਭ ਅਤੇ ਭੁਗਤਾਨ ਯੋਜਨਾ ਹੁੰਦੀ ਹੈ; ਐਕਸੀਡੇਂਟਲ ਗੜਬੜ ਅਣਪਛਾਤੀ ਜਟਿਲਤਾ ਹੈ ਜਿਸ ਵਿੱਚ ਸਪਸ਼ਟ ਮਾਲਕੀ ਜਾਂ ਫਾਲੋ‑ਥਰੂ ਨਹੀਂ ਹੁੰਦਾ।
ਫਰਕ ਦੇ ਤਰੀਕੇ:
ਸਭ ਕੁਝ “debt” ਕਹਿਣ ਨਾਲ ਅਸਲੀ ਮਸਲਾ ਛੁਪ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਭਰੋਸੇਯੋਗਤਾ ਖਤਰਾ, ਅਸਪਸ਼ਟ ਮੰਗਾਂ ਜਾਂ ਮਾਲਕੀ ਦੀ ਘਾਟ।
ਪਹਿਲਾਂ ਉਹ ਕਰਜ਼ਾ ਚੁਣੋ ਜੋ ਤਬਦੀਲੀ ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ (ਉਹ ਜੋ ਸਿਰਫ਼ ਬਦਸੂਰਤ ਹੈ ਨਹੀਂ)
ਅਮਲ ਵਾਲੇ ਫੈਸਲੇ:
ਸਧਾਰਨ ਪਰਖ: ਜੇ ਕੋਈ ਕਰਜ਼ਾ ਹਫਤੇ ਦਰ ਹਫਤੇ ਯੂਜ਼ਰ‑ਸਮਮੁੱਖ ਮੁੱਲ ਦੇ ਦਿੱਤੀ ਸਮਾਂ ਵਧਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਉੱਚ‑ਬਿਆਜ ਵਾਲਾ ਕਰਜ਼ਾ ਹੈ।
ਟ੍ਰੇਡ‑ਆਫ ਨੂੰ ਵਪਾਰਕ ਗੱਲਬਾਤ ਵਿੱਚ ਤਰਜਮਾ ਕਰੋ—ਅੰਕੜੇ ਦੇ ਨਾਲ ਨਾਹ, ਪਰ ਪ੍ਰਭਾਵ ਨਾਲ।
ਸ਼ੁਰੂ ਵਿੱਚ ਪ੍ਰਭਾਵ ਬਿਆਨ ਕਰੋ (ਨਪਾਇਦਾਰ ਸਹੀਤਾ ਨਹੀਂ):
ਇੱਕ ਛੋਟੀ ਗੱਲ ਅਤੇ ਇੱਕ ਮਾਪਦੰਡ ਨਾਲ ਰਿਪੋਰਟ ਕਰੋ: ਕਹਾਣੀ ਸਪਸ਼ਟਤਾ ਦੇਂਦੀ ਹੈ; ਮੈਟ੍ਰਿਕ ਭਰੋਸਾ ਵਧਾਉਂਦੇ ਹਨ—ਬਿਨਾ ਇਹ ਦਿਖਾਏ ਕਿ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਅੰਦਾਜ਼ੇ ਨਾਲ ਮਾਪ ਸਕਦੇ ਹੋ।