... o których każdy programista
wiedzieć powinien.

Zawsze słuchaj ekspertów. Oni powiedzą ci, czego nie da się zrobić i dlaczego. A ty potem to zrób.
-- Robert Heinlein
Seb Rose

Postępuj rozważnie

Oryginalny tytuł: Act with Prudence

Autor: Seb Rose

Czegokolwiek się podejmujesz, działaj rozważnie i pamiętaj o konsekwencjach.
- Anonim

Choćby nie wiem jak bardzo bezpiecznie wyglądał harmonogram na początku iteracji, nigdy nie unikniesz działania pod presją w którymś jego momencie. Kiedy znajdujesz się w sytuacji wyboru między „zrobić to dobrze” a „zrobić to szybko” często atrakcyjne wydaje się „zrobić to szybko” i jednoczesne powzięcie zamiaru późniejszego powrotu do zagadnienia w celu wprowadzenia poprawek. W chwili kiedy składasz taką obietnicę samemu sobie, zespołowi lub klientom, rzeczywiście chcesz to zrobić. Niestety, zbyt często kolejna iteracja przynosi nowe problemy i to właśnie na nich musisz się skoncentrować. Tego typu opóźnianie pracy monżnaby nazwać zaciąganiem długu technicznego, który nie jest bynajmniej Twoim sprzymierzeńcem. W szczególności, Martin Fowler w swojej taksonomii tychże długów nazywa to uświadomionym długiem technicznym, co nie powinno być mylone z nieumyślnym długiem technicznym.

Dług techniczny jest jak pożyczka: w krótkim terminie jest korzystny, ale dopóki nie zostanie w całości uregulowany, musisz go spłacać wraz z odsetkami. Skróty w kodzie programów utrudniają dodawanie nowych funkcjonalności oraz refaktoryzację. Są doskonałą pożywką dla wszelkich defektów i kiepskich testów jednostkowych. Im dłużej je pozostawisz, tym bardziej dokuczliwe się staną. Zanim nadejdzie czas, gdy zechcesz naprawić jakiś problem, może się zebrać całkiem pokaźny zbiór nie do końca trafionych decyzji projektowych, które wpływają na rozważany problem i znacznie utrudniają refaktoryzację oraz proces poprawiania kodu. W zasadzie sprawy muszą iść naprawdę źle, żebyś musiał naprawić dany problem i rzeczywiście to zrobił. Choć wtedy często okazuje się, że naprawa jest na tyle trudna, że ze względu na czas lub ryzyko nie możesz sobie na nią pozwolić.

Są przypadki, kiedy musisz zaciągnąć dług techniczny, żeby dotrzymać deadline'u lub zaimplementować jakąś część danej funkcjonalności. Staraj się do takich sytuacji nie dopuszczać, chociaż jeżeli jest już taka konieczność, zrób to. Ale (i to jest ale przez duże A) musisz spłacić ten dług szybko, w innym przypadku wszystko pójdzie w złym kierunku. Kiedy zdecydujesz się na zawarcie kompromisu, opisz zadanie do wykonania na specjalnej kartce albo dodaj je do swojego systemu typu issue-tracker, aby być pewnym, że nie zostanie ono zapomniane.

Jeśli zaplanujesz spłatę długu na następną iterację, koszt będzie minimalny. Pozostawienie długu niespłaconego spowoduje przyrost odsetek, dlatego oprocentowanie powinno być obserwowane, aby koszt był dobrze widoczny. Spowoduje to uwypuklenie przełożenia długu technicznego na wartości biznesowe, co z kolei doprowadzi do właściwej priorytetyzacji spłaty. Podjęcie decyzji w jaki sposób kalkulować i monitorować stopę procentową będzie zależało od konkretnego projektu, ale takie monitorowanie jest konieczne.

Spłacaj długi techniczne najszybciej jak to możliwe. Nieroztropnym byłoby postępować inaczej.

Creative Commons Uznanie Autorstwa 3.0 Artykuł został opublikowany na licencji Creative Commons Uznanie Autorstwa 3.0.
Tłumaczenie: Mixer

Komentarze (0)

Dodaj komentarz

*
 
 
*
*