Tutaj nie przejmujemy się stopami procentowymi ale refaktoringiem.
Dług ekonomiczny
Dług to zobowiązanie, zgodnie z którym jedna strona, dłużnik, powinna zapłacić pieniądze lub spełnić inne świadczenie drugiej stronie – wierzycielowi. Tyle prawo. Dalej jest ekonomia, a dokładniej powiedzenie autorstwa Ray’a Dalio:
Produktywność ma znaczenie na dłuższą metę. Kredyt ma znaczenie na krótką metę.
Kredyt pozwala nam przyspieszyć i przejąć konkurencję. Jeśli pomyślimy o tym na prawdziwym, żywym przykładzie: kupno mieszkania. Chcesz je kupić za gotówkę cena na rynku rośnie szybciej niż oszczędzasz. Więc bierzesz kredyt hipoteczny – zamrażasz cenę, za którą chcesz kupić, a teraz będziesz płacić odsetki swojemu bankowi za to, że pozwolił Ci to zrobić.
Refaktoryzacja
Ta analogia do długu ekonomicznego pozwala lepiej zastanowić się nad długiem technicznym. Dług techniczny zawsze rośnie. Może rosnąć szybciej lub wolniej, ale rośnie, dopóki nie wykonamy refaktoringu. To modne słowo wśród programistów. Refaktoryzacja to punkt zwrotny w kierunku czystości kodu. To jak dzień sprzątania mieszkania w sobotę lub światowy Dzień Ziemi i Sprzątanie Świata (przypominamy: 22 kwietnia). Gdybyśmy tego nie zrobili, utonęlibyśmy w bałaganie.
Dlaczego nie zrobić tego dobrze za pierwszym razem?Ale jak to zrobić w tak krótkim czasie jaki mamy na napisanie ogromu funkcji w aplikacji? Wszystko wymaga to czasu. To tak, jakbyś chciał przygotować dwa posiłki. Możesz przygotować jeden, wyczyścić stół, a następnie przygotować drugi, lub możesz też przygotować oba i wyczyścić później. Zatem refaktoryzacja oznacza czyszczenie.
Skuwamy beton
Czasami wymagania zmieniają się podczas pracy nad daną funkcją. Powinniśmy być świadomi tego, jak daleko zaszliśmy ze zmianą. Pomyśl o tym tak - kopiesz dziurę, a inwestor podchodzi do Ciebie i mówi Chcę mieć większą dziurę. W porządku bo i tak ją kopiesz, niewiele to zmienia w zastanej sytuacji. Jest jednak inaczej, gdy już wylałeś na nią wilgotny beton. Nie możesz nic zrobić. Musisz pozwolić mu wyschnąć, rozbić go i wyjąć - dług - a wtedy możesz wykopać głębszą dziurę. Pomyśl o tym następnym razem, gdy będziesz pracować nad jakimś nowym zadaniem.
Zespół produktowy
Zespół produktowy koncentruje się na biznesowej części aplikacji - to Ty jako deweloper jesteś technologiem. Tak jak ty nie rozumiesz ich pracy, oni niekoniecznie rozumieją twoją. Musisz sprzedać tym gościowym od sprzedaży, dlaczego od czasu do czasu wymagany jest sprint zadłużenia technicznego. Może uda Ci się przekonać zespół produktowy do regularnego poświęcania czasu na spłacanie swoich długów, które tak rozsądnie zaciągałeś przez ostatnie dni, tygodnie… miesiące?
Właściwa architektura
Nie da się przecenić roli architektury w aplikacji. Są tacy co uważają, że należy zacząć od proof-of-concept, zrezygnować z testów, bo nikt nie chce za nie płacić itd. To może się sprawdzić w firmach usługowych, gdzie przygotowujesz aplikacje dla klientów, oni ją odbierają, płacą i nigdy ich już nie widzisz.
Zasadniczo jednak niezwykle ważne jest aby zacząć od warstwy domeny i sensownych testów. To pozwala na uniknięcie sytuacji, w której pracujesz ciurkiem tylko nad błędami albo nad regresją. A nawet jeśli testerzy lub klienci znajdą błąd, po prostu tworzysz test obejmujący ten przypadek i działasz dalej.
A co z architekturą? Ważne jest, aby mieć taką, narysowaną np. na draw.io, aby każdy mógł zobaczyć jak to ma wyglądać. Pomaga w refaktoryzacji bo z łatwością dostrzeżesz miejsca, do których warto wrócić i je przemyśleć na nowo. Jest taka linia (możliwe, że jest cienka i czerwona), że jeśli za nią zajdziesz, dług technologiczny nie będzie mógł zostać spłacony i wtedy zbankrutujesz.
