ਤੁਸੀਂ ਟੈਕਨੀਕਲ ਕਰਜ਼ੇ ਨੂੰ ਕਿਵੇਂ ਪਛਾਣਦੇ, ਤਰਜੀਹ ਦਿੰਦੇ ਅਤੇ ਚੁਕਾ ਦਿੰਦੇ ਹੋ?

Technical debt ਕੋਡ ਦੀ ਵਰਤਮਾਨ ਸਥਿਤੀ ਅਤੇ ਜਿਸ ਤਰ੍ਹਾਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਵਿਚਕਾਰ ਅੰਤਰ ਹੈ, ਜਿਸ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਬੜ੍ਹਨ ਲਈ (ਜਾਣ-ਬੁੱਝ ਕੇ ਜਾਂ ਨਹੀਂ) ਲਿਆ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਕਰਜ਼ਾ ਠੀਕ ਹੈ; ਕਾਜ ਇਸ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨਾ ਹੈ, ਭਾਵ ਇਸ ਨੂੰ ਖਤਮ ਕਰਨਾ ਨਹੀਂ। ਮੁੱਖ ਗੱਲ ਇਸ ਕਰਜ਼ੇ ਨੂੰ ਤਰਜੀਹ ਦੇਣਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ।

ਪਰੇਸ਼ਾਨੀ ਨਹੀਂ, ਪ੍ਰਭਾਵ ਦੁਆਰਾ ਤਰਜੀਹ ਦਿਓ

For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it

ਇੱਕ ਸਮੂਰਤਾ ਵਾਲੀ ਉਦਾਹਰਣ

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