Si e identifikon, i përparëson dhe paguajtë borxhin teknik?

Question

Accepted Answer

**Technical debt** është hendesa midis asaj se si është kodi dhe si duhet të jetë, i marrë (qëllimisht ose jo) për të lëvizur më shpejt. Disa borxh janë në rregull; puna është ta menaxhojmë atë, jo ta elimináojmë atë. Çelësi është përparësia e borxhit që vërtet *dëmton*.

## Përparësia sipas ndiksimit, jo sipas bezdijesje

```text
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
```

## Një shembull konkret

Një modul i brishtë që thyhet në çdo lëshim dhe bllokon ekipin çdo javë ia vlen të rregullohet. Një utility e shëmtuar, por e qëndrueshme që asnjë nuk prek, *nuk ia vlen*, edhe nëse të ofendon. Refaktorimi është zene, jo vlerë.

## Si të financohet puna

"Sprint borxhi" të pastër rrezja marrin miratim. Taktika më të mira:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Pse është e rëndësishme

Borxhi i pamenaxhuar përpunon: shpejtësia bien në heshtje derisa ekipa pothuajse nuk mund të dërgojë asgjë.

Por ndjekja e çdo papërsosmërie humbet kohë në borxh që nuk ka rëndësi.

Vlera e një TL është të dijë ndryshimin dhe të kërkojë rasti te drejtimi në terma *biznesi*, jo vetëm inxhinierike.