Z patologii w patologę
Pisząc kolejną część cyklu o aplikacji do piłkarzyków chciałem nawiązać do błędów jakie popełniałem jak początkujący programista. Teraz z pewnością popełniam inne :). Przypomniałem sobie, że kiedyś napisałem post o tym jak łatwo popaść z patologi w patologię. Ten tekst był aktualny kilka lat temu. Natomiast teraz jest to miła retrospekcja, aby przeczytać i pomyśleć, że już tak nie robię. A oto on w lekko zmodyfikowanej formie.
Początek
Na samym początku mojej ścieżki programistycznej miałem przyjemność tworzyć programy bez żadnej przemyślanej architektury. Jakże, to było piękne! Wolność, szybkość, spagetti. Projekt posuwał się do przodu z każdym dniem było widać postęp, aż przyszedł czas zmian i łatania błędów. Z wiadomych przyczyn projekt padł. Na szczęście był w bardzo wszczesnym stadium produkcji.
Jakiś czas później, gdy nabrałem trochę doświadczenia. Postanowiłem zmienić pracę. Aplikację, którą tam pisaliśmy miała sprawdzoną, przemyślaną i uporządkowaną architekturą, która została zaprojektowana przez najbardziej doświadczonego architekta w firmie. Każdy członek projektu znał i wiedział, co i gdzie ma swoje miejsce. Jednak im dłużej projekt trwał tym częściej pojawiały się trudności w rozwoju. Dlaczego? Ponieważ architektura nie była zmieniana i przestawała pasować do aktualnego rozwiązania. Teraz zmieniałbym ją bez skrupułów. Jednak wtedy, byłem młody, jeszcze student, nie dyskutowałem. W każdym razie tępo dodawania nowych funkcjonalności spadało, a zmiany zaczęły powodować błędy w innych częściach systemu.
Architektura idelana ?
Zacząłem robić własny projekt, gdzie nikt mi nic nie narzucał. Mój projekt, moja architektura, moje pomysły. Dodatkowo zaczynałem przygodę z testami jednostkowymi. Usłyszałem, że są świetne i są lekarstwem na wiele problemów podczas wytwarzania oprogramowania. Testy jednak pociągają za sobą wiele rzeczy takich jak abstrakcja, interfejsy, IoC, Mocki itp…. Wszystko świetnie, ale projekt ten robiłem sam i nikt mi nie powiedział w odpowiednim momencie „Wickowski przesadzasz!”. Aż pewnego dnia, gdy zobaczyłem coś około 20 projektów, a funkcjonalności można policzyć na palcu jednej ręki, pomyślałem „w dupę jeża”. I porzuciłem projekt, ale co się nauczyłem to moje.
Wniosek
Architekturę oprogramowania, należy tworzyć, zmieniać i aktualizować, ale dopiero wtedy, gdy będą dowody, że jest to potrzebne.
0 Komentarzy