Cukierki, radosny chaos i takie tam, czyli Przemkowe rojenia ;-)

Nigdy nie marzyłem o tym by zostać architektem oprogramowania. Nie chodzi tylko o to, że to nudna robota jest (dla mnie, są osoby które się w tym realizują i mają świetne wyniki. Ale stanowią mniejszość), chodzi też o to, że jest to często robota bez sensu.

Bo opiera się na założeniu, że w przypadku oprogramowania da się projektować "od góry". Że można zbudować projekt oprogramowania i go zrealizować.
Nie można.

Ogólną koncepcję można, z zaznaczeniem, że się może zmieniać, ale całego softu nie.

Nie ma ludzi z tak dużymi głowami by byli w stanie zobaczyć wszystkie możliwe zależności bez zobaczenia prototypu.

Bo cukierki widać głównie od dołu ;-)

Cukierek to ułatwiajka gdy chodzi o interfejs użytkownika, albo sprytny pomysł, który załatwia za nas większość roboty.

Tak, część cukierków jest na poziomie architektury, ale giną tam w tłoku masy wymagań.

Kiedyś pisałem narzędzie które miało tworzyć pewną strukturę w bazie danych, dokładniej miało i nadal to robi i będzie robić przez kolejne lata ;-) tworzyć te pewne struktury często. W jednej bazie miało się znaleźć kilka tysięcy rekordów, które tworzą zamkniętą całość, a między tymi rekordami istnieją wzajemne powiązania, polegające na tym, że niektóre z nich są kluczami obcymi w innych tabelach.
Klasycznie trzeba by było stworzyć jakiś schemat tych zależności i zakodować go.
Ja zrobiłem inaczej. Dałem programowi wszystkie rekordy które ma włożyć [dla ułatwienia w postaci zrzutu z bazy jako serię INSERT INTO] i wstawiłem do niego zgadywajkę, która na podstawie nazwy pola zgaduje czy ma do czynienia z kluczem głównym czy obcym, czy może z danymi nie będącymi akurat kluczem ;-). Akurat w tej bazie było to proste.
Aha, zmiany w bazie odpadały.
I teraz program działa tak, że najpierw na szybko w pamięci buduje sobie mapę tabel, a w każdej z nich trzyma listę rekordów do włożenia. Bierze pierwszą tabelę z brzegu i próbuje ją włożyć do bazy, robiąc to sprawdza czy aby nie ma tam kluczy obcych, jak są to po prostu rekurencyjnie próbuje włożyć wszystkie rekordy tabeli z kluczami obcymi, jak tam są inne klucze obce to idzie dalej, aż dociera do tabeli, które nie mają kluczy obcych. Wkładając je do bazy zapamiętuje jakie mają teraz numery (tak, dodatkowe utrudnienie to constraints UNIQUE na numerach rekordów) i w razie gdzieś używany jest klucz obcy to prosta funkcja zwraca jego nowy numer.
De facto program robi sortowanie topologiczne i łazi po grafie zależności między tabelami, ale nie zna ich przed uruchomieniem ;-)
Cały engine powstał w 2-3 dni i działa od prawie 3 lat bez zbytnich modyfikacji.
Taki cukierek :-)

Gdyby projektować to od góry to byłoby tak z pół tony wzorców użyte, kodowanie byłoby nudne i smutne, a wszystko trwałoby kilka tygodni. Gdyby trafić na ambitnego architekta to skończyłoby się na użyciu specjalnego języka tylko do opisu zależności ;-)

Programy komputerowe się wyłaniają. Puki ich nie stworzysz nie wiesz do końca gdzie pójdą.

Ale jak się wszyscy upierają przed projektowaniem z góry to później nagle w trakcie kodowania okazuje się, że są sprzeczności, że trzeba je jakoś obejść.

Choć taki radosny chaos jaki ja lubię ma tę wadę, że nie wszyscy go lubią. Nawet większość go nie lubi ;-)
Wg. mnie lepiej się sprawdza, bo pozwala szybciej reagować, nie wymaga miesięcy przygotowań, które i tak idą często na marne w trakcie implementacji, bo się okazuje, że jednak się czegoś nie da, albo (co rzadziej, ale szczęśliwiej ;-)) da się prościej no i jest zabawniejszy.
No i trudno powiedzieć czy radosny chaos sprawdza się w dużych systemach.
Choć tu też jest to, że jak mi się wydaje lepsze są duże systemy, które powstają z masy małych programów i programików, niż takie które powstają w ramach WIELKIEGO NIESTETY WYSŁOWIONEGO PLANU.
Koszty naprawy czy nawet przepisania małego fragmentu SYSTEMU są niskie, koszty zmiany w kodzie SYSTEMU są wysokie. Bo jak coś spapramy w małym narzędziu to zawsze można szybko wrócić do starszej wersji, a cały system trudniej zmienić ;-)

O! Protokoły (albo protokóły ;-)) są ważne. Wg. mnie im prostsze tym lepsze.

Na koniec zastrzeżenia ;-) Prawdziwego [w mojej ocenie] architekta spotkałem raz, takich różnych tytularnych wielu. Ci lepsi nie decydowali o tym jak ma wyglądać aplikacja, a jedynie wytyczali ogólny kierunek implementację zostawiając developerom. W końcu developerzy to nie jest banda kretynów, a ludzie którzy znajdują się w wąsie krzywej Gaussa i różnica między nawet najmniej inteligentnym developerem, a architektem jest dużo mniejsza niż między nimi, a przeciętnymi ludźmi. W skrócie to zdolne bestie są.
Poznałem też "architektów", którzy nie powinni mieć nawet prawa zbliżania się do komputerów ;-)
Z obserwacji tych drugich jest więcej, na szczęście zwykle poza firmami gdzie ja pracuję :-) [z niechlubnym wyjątkiem poprzedniej, która upadła jakieś pół roku po tym jak z niej odszedłem :-)]

To wyżej może się zmienić, akurat dziś jestem w takim nastroju, jutro mogę uważać, że wszystko trzeba projektować i planować ;-) bo wszystko zależy od Eli, eli dane podejście będzie działało, eli nie będzie ;-)
Tu nie ma prawd objawionych ;-)


Podobne posty^beta
U mechanika... czyli nudne pisanie o niczym dla zabicia nudy
Świat disco polo...
Ingress - to wciąga ;-)
Złudne poczucie bezpieczeństwa...
Branche i Scrum to taki security blanket dla programistów