Rocksoft

Dokąd z tym monolitem

Dokąd z tym monolitem

Long story short – przejeliśmy aplikację o architekturze monolitycznej i wraz z nią odziedziczyliśmy dług techniczny, niosący ze sobą problemy na każdym kroku jej rozwoju. To dość powszechna sytuacja i oklepany temat w świecie IT, ale pomyślałem, że napiszę kilka słów o tym, jak my do tego podeszliśmy, nie mając dużo doświadczenia z takimi projektami.

Kilkunastuletni projekt, który pamięta jeszcze WinForms’y i wszystkie wersje MVC, przestarzałego .NET Framework’a, Knockoutjs czy bibliotekę jQuery. Zaintrygowany? Zapraszam do lektury, podczas której zabiorę Cię, drogi Czytelniku, na przygodę, której byłeś, jesteś lub będziesz częścią (oczywiście jeśli wybrałeś tę ekscytującą ścieżkę jako programista). Dla oszczędzenia Twojego czasu wyszczególnię punkty, które będę chciał szerzej omówić:

1. Projekt brownfield’owy – czyli dlaczego, według mnie, lepiej zacząć od tego typu projektu.

2. Ścięgno achillesa w odziedziczonej aplikacji. W zasadzie będzie ich kilka.

3. Inkrementacyjny refaktoring – czyli jak zrobić rewolucję w architekturze, zmniejszając ryzyko niepowodzenia.

1. Projekt brownfield’owy. W punkcie pierwszym chciałbym poruszyć jeden aspekt, który jest często niedoceniany w tego typu projektach – są to dane historyczne. W przeciwieństwie do wielce pożądanych i wymarzonych projektów greenfield’owych tutaj mamy zaletę tego, że posiadamy informacje na temat tego, jak użytkownicy korzystają z naszej aplikacji. Daje nam to ogromną wiedzę, którą możemy wykorzystywać w przebudowie i optymalizacji procesów zachodzących w systemie. Drugą zaletą jest to, że aplikacja „wygrzana” na produkcji jest dojrzałym produktem, który był opracowywany z biznesem przez długie lata. Wiedza biznesowa, albo wymagania biznesowe nie są zawsze jasne na początku powstawania aplikacji lub nowych funkcjonalności. W zależności od typu projektu, musimy podjąć odpowiednią taktykę. W naszym przypadku mieliśmy dobry start, ponieważ posiadaliśmy informacje historyczne, które pomogły nam nakierować aplikację na właściwe tory. Dla młodych zespołów jest to świetna okazja, żeby nauczyć się podstaw programowania oraz sztuki zbierania i przetwarzania danych. Znając konkretne przypadki użycia, łatwiej podjąć decyzję architektoniczną. Może będzie jeszcze kiedyś okazja, żeby napisać kilka słów odnośnie drugiego typu projektów – projektów greenfield’owych i podejściu Lean Startup.

2. Ścięgno achillesa. Nasza aplikacja miała kilka niewybaczalnych grzechów, jeżeli chodzi o szeroko pojętą inżynierię dobrego oprogramowania i nowoczesnych trendów cloud native. Jednym z nich była wszechobecna i wszechwiedząca sesja oraz cache. Moja rada? Jeśli widzisz zaimplementowaną sesję oraz API, które komunikuje się z front-endem i nic z tym nie możesz zrobić: Uciekaj! Pół żartem, pół serio. Cache i sesja przysporzyły nam sporo problemów i często prowadziły do konieczności głębokiego debugowania. Są i plusy – nauczyliśmy się debugować i dobrze poznaliśmy nasze środowisko – Ridera. Jak wyjść z takiej sytuacji, nie zamykając się w piwnicy na kilka lat, by przepisać aplikację? Naszym podejściem było systematycznie persystowanie „sesji” do bazy danych. Na koniec tego punktu doradzę, byś zainwestował w poszerzenie wiedzy o Design-driven developmencie, a w szczególności tematu bounded contextów. Nasz spadek zawierał w sobie dwie aplikacje, które z biznesowego punktu nie miały nic ze sobą wspólnego, albo bardzo niewiele. Taki skrót dwóch aplikacji w jednej solucji świadczy albo o lenistwie programistów, braku kompetencji lub krótkich terminach. Podsumowywując – jeśli chcesz dostarczać oprogramowanie dobrej jakości, to potrzebujesz na to czasu.

3. Inkrementacyjny refaktorking. Osobiście nie jestem zwolennikiem przepisywania aplikacji od zera. W naszym wypadku było to niemożliwe z racji tego, że aplikacja była używana oraz mieliśmy ograniczone zasoby. Natomiast wierzę w zwinne programowanie, dzięki któremu w relatywnie krótkim czasie można dostarczyć coś, co przyniesie wartość dla biznesu. Zaczęliśmy od analizy systemu i nazwania długu technicznego po imieniu. Oszacowaliśmy, że w pesymistycznym przypadku wyprowadzenie tej aplikacji na właściwe tory zajmie nam około roku. Jak dla mnie – „no go”. Zainpirowani książką Lean startup zdecydowaliśmy się na MVP najszczęściej używanych funkcji przez użytkowników. W 3 miesiące oddaliśmy aplikację SPA napisaną w Reactcie. Oczywiście musieliśmy zaciągnąć dług techniczny, który wiązał się z nieoptymalnymi zapytaniami (problem N+1), zastowowaniem „anti corruption layer” oraz kilku dodatkowych „work-aroundów”. Świadomi posiadanego długu, systematycznie spłacaliśmy go w każdej możliwej iteracji.

Nasza podróż się jeszcze nie skończyła, ale konsekwentnie dążymy do celu. Krótko, ale mam nadzieję, że zainspirowałem Ciebie, drogi Czytelniku, żebyś nie tracił motywacji, jeśli odziedziczysz aplikację, która okazuje się „Big ball of mud”. W jaki sposób podejdziesz do tego typu projektów, będzie świadczyć o Twojej dojrzałości jako programisty.

Piotr Czyż
@_piotr