Czasem można usłyszeć rozmowy na temat tego czy warto pisać kod dobrej jakości. To nie jest tak, że są osoby, które uważają, że jakość jest nieważna. Zazwyczaj mówią one coś w stylu: „obecnie pędzimy z funkcjonalnościami, aby wyrobić się w czasie, więc piszemy oprogramowanie gorszej jakości”.
Istnieje jakoby przeświadczenie, że jakość można wymienić na szybkość. Gdyby brak jakości oznaczał większą szybkość, to na pewno byłbym tego zwolennikiem. Myślę nawet, że większość osób byłaby za tym. Tylko pojawia się pytanie – czy aby na pewno zaniedbywanie jakości w celu przyśpieszenia prac jest zawsze dobrym pomysłem?
Jakość się nie liczy
Wyobraźmy sobie zespół, który pędzi z dodawaniem nowych funkcjonalności i nie przejmuje się dobrymi praktykami. Na początku wszystko idzie bardzo szybko, ale z czasem zaczynają oni dostarczać coraz wolniej (albo coraz mniej). Jest to spowodowane tym, że kod ulega pogorszeniu i jest trudniejszy w modyfikacji. Efektem czego jest spadek produktywności. Wykres dostarczonej łącznej funkcjonalności (ilość zaimplementowanych funkcji w naszym systemie) od czasu wyglądałby w takiej sytuacji następująco:
Idealny scenariusz
A jak wyglądałby „idealny” wykres? W „idealnej” sytuacji wzrost czasu nie miałby wpływu na dostarczane funkcjonalności, stary kod by nie przeszkadzał, a nowe rzeczy pojawiałyby się w takim samym czasie.
Termin spłaty długu technicznego
Jak nałożymy te dwa wykresy na siebie, to punkt ich przecięcia nazywamy terminem spłaty długu technicznego.
Co on oznacza? Przekroczenie tego punktu może skutkować tym, że projekt przestanie być utrzymywalny, ponieważ dodanie nowej funkcjonalności będzie niezwykle czasochłonne lub wręcz niemożliwe.
Jak odnaleźć swój projekt na wykresie?
Warto jest mierzyć to, jak szybko dostarczamy nowe funkcjonalności. Wtedy może nam być łatwiej określić, czy poruszamy się bardziej po linii zielonej, czy po czerwonej. Jeśli w każdym kolejnym odstępie czasu dowozimy tyle samo, może warto poświęcić trochę jakości, aby się upewnić, czy nie jesteśmy pod zieloną linią. Z drugiej strony, gdy zaobserwujemy, że zaczynamy dostarczać coraz mniej albo że stary kod zaczyna nam przeszkadzać, to warto popracować nad jakością. Jednakże tutaj trzeba być czujnym, ponieważ z każdym kolejnym tygodniem może być coraz trudniej wytłumaczyć biznesowi, że od teraz nowe funkcjonalności będą dodawane dużo wolniej.
Słowo na koniec
Moim zdaniem nie warto przedkładać szybkości nad jakość, ponieważ w dłuższej perspektywie to właśnie jakość pozwala nam dostarczać nowe funkcjonalności szybciej. Albo może nie szybciej, ale stale w mniej więcej tym samym czasie. Dzięki temu biznes wie czego może się po nas spodziewać i łatwiej im planować kolejne wersje. Jednak trzeba uważać, aby z dbaniem o jakość nie przedobrzyć w drugą stronę.
Post inspirowany twórczością Martina Fowlera.
Pingback: dotnetomaniak.pl