Tekninen velka (tunnetaan myös nimellä koodausvelka ) on metafora ohjelmistosuunnittelulle , joka viittaa ohjelmistokoodiin tai arkkitehtuuriin kertyneisiin ongelmiin , jotka liittyvät ohjelmistokehityksen laadun laiminlyöntiin ja aiheuttavat lisätyövoimakustannuksia tulevaisuudessa. Tekninen velka on yleensä näkymätön tuotteen loppukäyttäjille, mutta se liittyy puutteisiin ylläpidettävyyden , testattavuuden, ymmärrettävyyden, muunnettavuuden ja siirrettävyyden suhteen . Analogisesti rahoitusvelan kanssa , tekninen velka voi kasvaa " korolla " - mikä tekee kehityksen jatkamisesta vaikeampaa (tai jopa mahdotonta), mikä lisää aikaa, jonka kehittäjät käyttävät ohjelmistotuotteen vaihtamiseen, virheiden korjaamiseen, ylläpitoon jne. Tekninen velka on yleensä negatiivinen vaikuttaa projektin tulevaisuuteen, se voi olla myös tietoinen, olosuhteiden sanelema kompromissipäätös.
Huono koodi ei sinänsä ole aina teknistä velkaa, koska vahinko ("velan korko") johtuu tarpeesta vaihtaa koodia ajan myötä [1] .
Termiä tekninen velka käytetään ensisijaisesti ohjelmistokehityksen yhteydessä, mutta sitä voidaan soveltaa myös muuhun suunnitteluun.
Joskus termiä käytetään väärin, mikä tarkoittaa vanhaa koodia , jota ei enää tueta , joka on huonolaatuinen ja jonka on kirjoittanut joku muu [1] .
Teknisen velan yleisiä syitä (voi olla useita) [2] :
"Korkomaksut" näkyvät sekä paikallisen kehittämisen aikana että ilman teknistä tukea muilta projektikehittäjiltä. Projektin jatkuva kehittäminen saattaa nostaa "velan takaisinmaksun" kustannuksia tulevaisuudessa. Tekninen velka maksetaan takaisin tekemällä keskeneräiset työt.
Teknisen velan kasautuminen on merkittävä syy projektien viivästymiseen. On vaikea arvioida tarkasti, kuinka paljon työtä on tehtävä velan maksamiseksi. Jokaisella muutoksella projektiin lisätään määrittelemätön määrä keskeneräistä työtä. Määräajat "polttavat", kun projekti tulee ymmärtämään, että kesken on vielä paljon enemmän työtä (velkaa) kuin aikaa sen toteuttamiseen. Jotta julkaisuaikataulut olisivat ennakoitavissa, kehitystiimin on rajoitettava tehtävän työn määrä tasolle, joka minimoi keskeneräisen työn määrän (tekninen velka).
Vaikka Manny Lehmanin monimutkaisuuden lisääntymisen laki oli jo osoittanut, että ohjelmien jatkuva kehittäminen lisää niiden monimutkaisuutta ja huonontaa niiden suunnittelua niiden työstön aikana, Ward Cunningham teki ensimmäisen vertailun teknisen monimutkaisuuden ja velkaantumisen välillä vuoden 1992 raportissa:
Vuonna 2004 julkaistussa artikkelissaan "Refactoring with Patterns" Joshua Kerievsky puolustaa arkkitehtonisten väärinkäytösten korjaamisen kustannuksia, joita hän kuvailee "rakennevelaksi" [5] .
Toimintoja, jotka voivat viivästyä, ovat dokumentointi, testien kirjoittaminen, huomion kiinnittäminen "TODO"-merkinnöillä merkittyihin kommentteihin, kääntäjän taisteleminen ja varoitukset staattisesta koodianalyysistä . Muita teknisen velan tapauksia ovat tietopohja, jota ei jaeta organisaation sisällä, ja koodi, joka on liian monimutkainen helposti muutettavaksi.
Avoimen lähdekoodin ohjelmistoissa paikallisten muutosten viivyttäminen pääprojektiin on teknistä velkaa. .