blog.testowka.pl

Spłata długów

opublikowany przez 08, Sie, 2011, w kategoriach Agile, Testowanie, Zarządzanie

Poprzednio pisałem o długu technologicznym. Skończyłem na tym, że dług technologiczny tak jak każde inne zadłużenie trzeba prędzej czy później spłacić.

W przypadku tego długu odsetki rosną dosyć szybko, więc wydawało by się, że ze spłatą nie należy zwlekać. Niemniej jednak czasem okazuje się, że pomimo wysokiego długu i rosnących odsetek nadal opłaca się dodawać nowe funkcjonalności i rozwijać system bez dbania o jakość – przeważnie wynika to z wysokiego popytu na oferowane przez nasz system usługi – jeśli popyt jest wystarczająco duży to nasi klienci są w stanie wybaczyć niską jakość, a inwestorów nie będzie ona wcale obchodziła póki da się jeszcze coś dodać do naszego systemu tak by koszty/czas wytwarzania tej funkcjonalności nie przewyższyły zysków.

Z czasem każda aplikacja/system wytwarzane w ten sposób osiągają pewną masę krytyczną, w której nawet najmniejsza zmiana może spowodować nieodwracalne straty. Wtedy właśnie inwestorzy decydują się na spłatę zaciągniętego długu technologicznego (lub sprzedają cały biznes komuś innemu, kto od teraz będzie musiał powyższe problemy samemu rozwiązać – taki ktoś przeważnie zacznie od zatrudnienia sztabów QAów).

Nie zrozumcie mnie źle – nie krytykuję startupów za to, że pierwsze ich wersje były kaszaną programistyczną – wręcz przeciwnie, z perspektywy biznesowej takie rozwiązania są wręcz genialne – tworzymy niskim kosztem coś co zaczyna zarabiać – lub nie – i właśnie jeśli okaże się, że nasza idea nie chwyciła i nie zaczyna zarabiać to tracimy znacznie mniej, niż gdybyśmy od początku inwestowali w wysoką jakość. A jeśli nasz pomysł okaże się strzałem w dziesiątkę i zacznie zarabiać pokaźne sumy to przestają nas obchodzić koszty jakości i możemy sobie pozwolić nawet na przepisanie całego systemu od nowa, czy podwojenie liczby zatrudnionych developerów.

„Naturalną” drogą obieraną przez wiele firm podczas zaciągania długu technologicznego jest zatrudnianie coraz większej ilości programistów, których ilość ma rekompensować spadek prędkości rozwijania aplikacji. Niestety samo zwiększenie liczby pracowników nie spowoduje spłaty zaciągniętego długu, mało tego często brak dodatkowych starań w kierunku zapewniania jakości i odpowiedniej presji w tym kierunku może spowodować jeszcze większy wzrost zadłużenia – więcej osób oznacza więcej kodu słabej jakości czyli szybszy przyrost zadłużenia.

Jeśli przez długi czas żyło się na kredyt to aby spłacić zadłużenie trzeba czasem zacisnąć pasa – spłacanie długu spowoduje drastyczne spowolnienie rozwoju naszego biznesu. Wynika to z tego, że teraz dostępne zasoby będziemy przeznaczać na poprawę jakości zamiast na rozwijanie nowych ficzerów. „Poprawa jakości” czegoś co nigdy znamion tejże jakości nie nosiło często oznacza napisanie tego od nowa. Przepisywanie funkcjonalności od nowa nie jest proste. By dobrze to zrobić należy najpierw dokładnie zdefiniować to co napisana wcześniej funkcjonalność tak naprawdę miała robić, jakie były co do niej wymagania i założenia – w przypadku braku dbania o jakość o jakiejkolwiek dokumentacji wymagań przeważnie można tylko pomarzyć.

Jednym ze sposobów na rozwiązanie tego problemów jest pisanie testów funkcjonalnych typu „black box” – tworzymy testy automatyczne, które traktują daną funkcjonalność jak czarną skrzynkę – podają wartości wejściowe i sprawdzają stan na wyjściu nie wnikając w to co dzieje się w środku. Takie testy piszemy na starym systemie (przed przepisaniem) traktując go jak wyrocznie testową – zakładamy, że system działa poprawnie i zwraca prawidłowe wartości – wyrocznia prawdę ci powie. Po napisaniu tego typu testów i maksymalnym pokryciu nimi przepisywanej funkcjonalności możemy przystąpić do przepisywanie czy refaktoryzacji tejże funkcjonalności nie martwiąc się o to, że coś zepsujemy. Oczywiście jest to dosyć naiwne stwierdzenie. Niemniej jednak jest to jedno z najbardziej optymalnych rozwiązań w przypadku wcześniejszego braku jakichkolwiek testów automatycznych czy dokumentacji wymagań. Należy także pamiętać o tym by pisząc nową funkcjonalność od razu zapewniać jej wysoką jakość stosując dobre praktyki programistyczne takie jak np. TDD.

Nawet jeśli uda się uniknąć przepisywania całej aplikacji to koszty „wdrażania jakości” są wielokrotnie wyższe niż gdyby od początku tworzono software wysokiej jakości, co nie oznacza, że w skrajnych przypadkach jest to nawet bardziej opłacalne.


Skomentuj