Słyszałeś o tym, że istnieje coś takiego jak wewnętrzna i zewnętrzna jakość?
Jakość zewnętrzna to wszystko to, co widzi użytkownik. To funkcje jakie spełnia aplikacja. Nie chodzi jedynie o usability i kwestie związane z wyglądem zewnętrznym. Też o jakość zaimplementowanych możliwości. Czy po kliknięciu drukuj pojawia się dialog drukowania, czy pdf do ściągnięcia, którego można wydrukować po otwarciu? Czy cały proces biznesowy jest obsługiwany, czy może o część elementów dbają użytkownicy? Czy elementy z zewnętrznych systemów importują się perfekcyjnie, czy w 10% potrzebna jest interwencja użytkownika lub nawet programisty?
Niższa jakość zewnętrzna nie zawsze oznacza, że jest źle. To jest decyzja, którą podejmuje właściciel produktu (product owner) pod warunkiem, że dysponuje pełną informacją o sytuacji. Jeśli wie, że perfekcyjny import opóźni wdrożenie o cały miesiąc, a “prawie dobry” oznacza wykorzystanie okazji biznesowej już teraz (relatywnie niewielkim nakładem pracy ludzi) – może wybrać opcję “prawie dobrą”. Oczywiście może poprosić o wersję idealną przy kolejnej iteracji.
Jakość wewnętrzna zkolei to coś, czego zrozumienie przychodzi ciężko czasem nawet programistom. To brak długu technicznego (przykład), podatność kodu na zmiany wymagań, niewrażliwość na regresję (wprowadzanie błędów wraz z nowym kodem, powracanie tych już naprawionych).
Jakość wewnętrzna aplikacji jest nienegocjowalna w zespołach Agile.
Gdy jest ona niska, nowe błędy są odkrywane przy każdym wdrożeniu, Twoja aplikacja choruje, a zespół traci czas na jej łatanie – wolniej implementuje nowe elementy. Sponsor/właściciel produktu nie wykorzystuje w pełni nadarzających się okazji na rynku. To wszystko trwa aż do dramatycznego momentu, kiedy okazuje się że nie da się już produktu rozwijać. Pomyśl tylko… zespół programistów dwa lata rozwijał aplikację i teraz musi zacząć od nowa. Aplikację, na którą wydałeś setki tysięcy złotych. I jedyne co masz, to doświadczenie Twoich programistów (o ile cały zespół nie wymienił się w tym czasie przynajmniej raz). Dla nich to świetne szkolenie, ale z Twojego punktu widzenia niezbyt opłacalne.
Znam trzy narzędzia, które dbają o wysoką jakość wewnętrzną.
Pierwszy (nietechniczny) już podałem: jakość wewnętrzna nie podlega negocjacji. Gdy product owner chce importu, ale nie ma czasu zaimplementować go perfekcyjnie – nie jest opcją zaimplementowanie go na szybko w technologii spagehetti code. Możesz negocjować zakres funkcji do zaimplementowania, nigdy jakość wewnętrzną. Klient nawet nie powinien znać opcji “super szybkiej”, z dwóch powodów:
- na pewno by ją wybrał, ponieważ…
- nie wie, że to zabije jego projekt
Posługując się analogią budowlaną: Klient chciałby mieć tańszy dom. Wykonawca proponuje zamiast wylania fundamentów (co trwa i kosztuje) wsypanie do wykopu śmieci, które ma z poprzedniej budowy. Klient oczywiście się nie zgadza, bo to śmiertelne zagrożenie dla jego rodziny. Oczywiście w naszym kraju to jest niemożliwe – kierownik budowy poszedłby do więzienia. IT nie ma nadzoru budowlanego – nieszczęście w szczęściu ;)
Pozostałe (techniczne): refaktoring kodu i testy. Refaktoring (czy refaktoryzacja) usuwa dług techniczny, który zawsze zaciągasz rozwijając aplikację. Aktywnie z nim walczy, stale przebudowując kod usuwając powtórzenia i poprawiając architekturę systemu.
Jednak refaktoring jest strasznie trudny. Nowe funkcje mogą wprowadzić nowe i przywrócić stare błędy. Zmiana kodu, która nie wprowadza nowych funkcji, ale wprowadza błędy w ogóle nie jest sexy. Dlatego potrzebujesz automatycznych testów.
Testy jednostowe, testy integracyjne i wszystkie inne jakie jesteś w stanie zautomatyzować mogą ochronić Cię przed regresją kodu. Dzięki nim programista nie boi się refaktoringu – zmienia, klika – widzi wielki zielony napis “OK” i jest szczęśliwy.
Takie podejście zwraca się w długim terminie. Życzę wszystkim, aby mieli okazję pracować którzy potrafią tak daleko patrzeć.
Nowy język, ciekawe podejście do tematu (nieco inne niż