fbpx

Z patologii w patologę

Opublikowane przez Jerzy Wickowski w dniu

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.



Czy to był wartościowy artykuł? Zapisz się, a wyślę Ci dwa ebooki o czystym kodzie oraz będę informował Cię o nowych postach
Kategorie: Code

0 Komentarzy

Dodaj komentarz

Twój adres email nie zostanie opublikowany.

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.


    Zapisz się

    Wyślę Ci dwa dokumenty mówiące o jakości kodu. Dodatkowo będę Cię informował o nowych postach i nowościach.