Kilka lat temu Martin Fowler przedstawił coś takiego jak technical debt quadrant (możecie o tym przeczytać tutaj).
Ten wykres jest wynikiem jego rozmyślań nad długiem technicznym – jakie nasze działania doprowadzają do jego powstania i co możemy zrobić, aby był on spłacalny.
Tworząc oprogramowanie może to robić na dwa sposoby:
– lekkomyślnie, gdy w ogóle nie dbając o jakość kodu, robimy funkcjonalności 'byle do przodu’;
– rozważnie, gdy postępujemy profesjonalnie, robimy wszystko jak należy, stosujemy odpowiednie wzorce projektowe i piszemy testy.
Nieważne na który ze sposobów się zdecydujemy, to w obu przypadkach możemy doprowadzić do powstania długu technicznego. Jednakże możemy to zrobić w sposób celowy, gdy doskonale wiemy, że ten dług powstaje lub nieumyślny, kiedy dopiero po czasie orientujemy się, że dług został zaciągnięty.
I te cztery możliwości sumują się do całokształtu:
Przyjrzyjmy się bliżej jakie działania doprowadzają do powstania długu w poszczególnych ćwiartkach.
1. Lekkomyślnie i nieumyślnie
Taki dług powstaje z reguły wtedy, gdy w zespole są same niedoświadczone osoby. Nie wiedzą one czym są wzorce projektowe, ani jak wielką rolę przy tworzeniu oprogramowania odgrywają testy. Nie słyszały o code-review albo słyszały, ale nie wiedzą na co należy zwracać uwagę. W tej sytuacji bardzo często zespół nawet nie wie, że zaciąga dług i że z każdym dniem się on powiększa.
2. Lekkomyślnie i celowo
Taki dług powstaje w dwóch sytuacjach.
Pierwsza, to gdy osobom z zespołu nie chce się stosować dobrych praktyk. Wiedzą, że one istnieją, umieją ich używać, ale nie mają już motywacji, nie mają chęci, więc po prostu klepią kod i do domu.
Druga, to gdy osoby z zespołu chcą stosować dobre praktyki, ale tego nie robią, bo wydaje im się, że nie ma na to czasu. Nie rozumieją, że pracując tak przez długi okres, w pewnym momencie przekroczą 'termin spłaty długu’ i dodawanie nowych funkcjonalności będzie niezwykle czasochłonne.
3. Rozważnie i celowo
Zespół zdaje sobie sprawę z tego, że nieważne co zrobi, to prawdopodobnie powstanie dług techniczny. Co prawda programiści piszą testy, stosują wzorce projektowe, ale nie porywają się z motyką na pole. Nie starają się wytworzyć od razu wielkiej funkcjonalności. Na początek tworzą najmniejszą rzecz, która realizuje minimalne potrzeby biznesowe. Dopiero gdy to wypali, gdy klienci będą zadowoleni, biorą się za rozszerzanie tej funkcjonalności i jej refaktoryzację. Świadomie zaciągają dług, ale robią to, aby ograniczyć koszty i nie narazić się na dług nieumyślny.
4. Rozważnie i nieumyślnie
A jak to się dzieje, że zespół pomimo działania rozważnie, zaciągnął dług techniczny i nawet nie był o tym świadomy? O dziwo to sytuacja, w której znalazł się prawdopodobnie już nie raz każdy z nas. To jest sytuacja kiedy mówimy 'aaa… teraz to już wiem jak należało to zrobić’. To jest rodzaj długu, kiedy dopiero po czasie orientujemy się, że został on zaciągnięty. Pomimo tego, że zespół pisał testy, stosował odpowiednie wzorce projektowe, a kod był czysty, to doprowadził do powstania długu.
Podsumowanie
Łatwo jest powiedzieć, że lekkomyślne działanie jest złe, a rozważne dobre. Niestety, ale tylko rozważne i celowe zaciąganie długu technicznego może doprowadzić do tego, że będzie on spłacalny. W pozostałych przypadkach koszt jego spłaty prawdopodobnie okaże się tak duży, że nie będzie się już opłacało tego robić.
Pingback: dotnetomaniak.pl
Możliwość komentowania została wyłączona.