niedziela, maja 17

Symptoms of Rotting Design

solid czas rozpocząć;

Architecture and Dependencies
Aplikacja swoje życie rozpoczyna w umysłach programistów. Na początku posiada bardzo dobrą architekturę, prostotę, oraz zbudowana jest w oparciu o najlepsze wzorce programowania obiektowego.
Z systemem tak tworzonym zaczyna się coś dziać. Oprogramowanie zaczyna gnić. Początki nie są takie straszne, w jednym miejscu zastosuje się jakieś nie ładne rozwiązanie, w innym robi się jakiegoś sprytnego hacka, ale i tak nadal mówimy, że widać piękno pierwotnego projektu. Upływający czas powoduje, że ilość hacków w systemie wzrasta, a nasza prostota systemu zaczyna zanikać. System zaczyna posiadać coraz większy nieład w kodzie, a programiści uświadamiają sobie fakt, że zarządzanie kodem staje się coraz trudniejsze. Z każdą kolejną zmianą w kodzie trzeba zmieniać coraz więcej elementów systemu.


Symptoms of Rotting Design
Są cztery podstawowe symptomy po których można rozpoznać, że system zaczyna gnić. Nie są to zagadnienia przecinające się, ale powiązania między nimi są oczywiste. Podstawowe symptomy to rigidity (sztywność), fragility (kruchość), immobility (nie przenośność), viscosity (lepkość).

Ridigity (sztywność). System w którym jest bardzo trudno wprowadzać zmiany, nawet te łatwe. Każda zmiana pociąga za sobą dużą ilość zmian kaskadowych wynikających z zależności pomiędzy modułami. Zaczyna się to od tego, że zmiana które powinna zająć 2h, przeciąga się do 2 dni i powoduje zmiany w kilkunastu kalach w projekcie;
Kiedy system posiada takie symptomy programiści nie chętnie coś zmieniają i ograniczają się tylko do wprowadzania krytycznych zmian.

Fragility (kruchość). Blisko spokrewniona z sztywnością. Kruchość prowadzi do tego, że gdy dokonamy zmiany w jednym miejscu, system rozpada się w wielu miejscach. Często miejsca jakie ulegają uszkodzeniu nie mają bezpośredniego związku z miejscem zmiany. Sam problem nie pojawia się na etapie kompilacji, ale na etapie wykonania. Jeżeli problem ten zaczyna narastać to po pewnym czasie programistom towarzyszy strach. Wprowadzenie zmiany w jednym miejscu systemu może zepsuć każde inne bliżej nieokreślone miejsce. Jeżeli kruchość wzrasta może powodować wydłużanie się czasu wprowadzania zmian, ponieważ programiści zaczynają wykonywać nadmiarowe testy tylko, dlatego by uchronić się przed ewentualnymi problemami jakie zmiana mogła spowodować. Po pewnym czasie dbanie o system przestaje być opłacalne ponieważ nie wiadomo ile problemów może wprowadzić zmiana.

Immobility (nie przenośność)Immobility (nie przenośność). Pojawia się wtedy, gdy chce się wykorzystać projekt lub jego część w innym miejscu. Często zdarza się, że programista odkrywa to, że inni zrobili już coś podobnego i teraz można by wykorzystać gotowy kod. Ale gdy zaczyna się brać elementy które nas interesują okazuje się, że razem z nimi musimy wziąć bardzo dużo innych nie potrzebnych nam klas. Elementy dodatkowe nie są nam potrzebne, ale bez nich moduł nam potrzebny nie zadziała. Sytuacja ta powoduje, że dany fragment oprogramowania zamiast zostać użytym zostaje przepisany od nowa.

Viscosity (lepkość). Mówimy o lepkości projektu oraz systemu. Lepkość projektu pojawia się wtedy gdy zmianę można wykonać na więcej niż jedne sposób. Niektóre formy zmian są dłuższe, ale łamią pierwotnej architektury systemu, inne można nazwać potocznie hack. Jeżeli programiści wybierają dłuższe i leprze sposoby rozwiązywania problemu to nic strasznego się nie dzieje, ale może się tak zdarzyć, że presja klienta spowoduje zrobienie kacka. Oczywiście programista powtarza sobie, że zrobi hacks, puści release, a następnie rozwiązanie poprawi na porządne, tak się nigdy nie dzieje. Problemem w lepkości jest to, że zmiany łatwe które powinno się łatwo wprowadzać i nie powinny one łamać naszej pierwotnej architektury systemu, robią coś zupełnie przeciwnego.


Cztery symptomy o jakich napisałem są oznaką słabej architektury. Każda aplikacja posiadająca te oznaki zaczyna się psuć od środka. Ale co powoduje psucie się aplikacji, o tym napiszę w innym poście.