22
06-06-27
R01-03.doc
INNE SPOJRZENIA NA ARCHITEKTURĘ OPROGRAMOWANIA
23
Projektowanie podsystemów a poczucie całości
Niewielu programistów chciałoby specjalizacji sprowadzającej ich pracę do jednego rodzaju działań — analizy, projektowania, pisania kodu czy poprawiania błędów. Dużo bardziej typowe jest dążenie do zaangażowania w pełen zakres czynności programisty: omawianie wymagań z klientem lub menedżerem produktu, opracowywanie i realizowanie artefaktów analizy i projektu, poprawianie błędów, optymalizowanie wydajności itd. Uważam, że jest to wyraz stosunkowo silnego dążenia do poczucia „kompletności” wykonywanej pracy. Dążenie to ma głębokie implikacje. Dobra decyzja projektowa to często decyzja, która pozwala je zaspokoić.
Pojęcie „kompletności” wykonywanej pracy jest różnie rozumiane przez różne osoby.
Kierownictwo musi być dobrze zorientowane w tym, jak jest postrzegane przez dany zespół.
W pewnej aplikacji typu klient-serwer rozważaliśmy kilka różnych konstrukcji klienta. Przytoczę tutaj dwie z nich, aby zilustrować naszą interpretację kompletności pracy i to, jak wpłynęła na podjęty wybór.
W pierwszej wersji jeden zespół odpowiadał za zagadnienia „związane z klientem”, a drugi za „infrastrukturę”. W drugiej wersji projektu każdy zespół przyjmował odpowiedzialność za komponenty z obu tych obszarów.
O ile pierwszy projekt mógł wydawać się nieco bardziej przejrzysty na papierze, zdecydowanie psuł morale zespołu infrastruktury, który skłaniał się ku opinii, że pozbawiłoby to ich peł-
nego uczestnictwa w procesie przygotowywania kolejnych wersji. Mówiąc ściślej, zespół ten tracił wówczas okazję do bezpośredniej pracy z osobami odpowiedzialnymi za kierowanie produktem, publikacjami technicznymi i potencjalnymi klientami. Należało to do jego obowiązków wcześniej i wszyscy chcieli, żeby tak zostało. W efekcie wybraliśmy drugą wersję architektury, ponieważ tylko ona pozwalała obu zespołom zachować to samo poczucie kompletności wykonywanej pracy, tak bardzo ważne dla programistów. Dla nich oznaczało ono, między innymi, kontakt z osobami kierującymi rozwojem produktu i udział w procesie przygotowywania kolejnych wersji.
Poddawanie się dobrej architekturze
Używam czasownika „poddawać się”, gdy architekt lub zespół programistów odsuwa od siebie, tak daleko jak to możliwe, własne doświadczenia i wyobrażenia o tym, co jest poprawne i właściwe, pozwalając, aby ich pracą nad architekturą kierowały siły właściwe dziedzinie problemu. Niektórzy twierdzą, że nie jest to problemem i że oni lub ich zespół zawsze tworzą architekturą opartą wyłącznie na obiektywnej analizie problemu klienta i najlepszych metodach prowadzących do jego rozwiązania.
Słowo-klucz to oczywiście najlepsze. Zdanie Czytelnika o tym, co jest najlepsze, może różnić się od mojego. Różnice tego rodzaju biorą się przede wszystkim z posiadanego zasobu doświadczeń. Nie wynikają bezpośrednio z dziedziny problemu (z wyjątkiem sytuacji, kiedy zdobywamy doświadczenia w obrębie danej dziedziny). Jednym z aspektów „poddawania się” dobrej architekturze jest ciągłe wery-fikowanie, czy podejmowane decyzje mają na uwadze przede wszystkim potrzeby klienta, i zgoda na zmienianie tych decyzji, jeżeli weryfikacja taka będzie miała skutek negatywny.
R01-03.doc
06-06-27
23
24
WIĘCEJ NIŻ ARCHITEKTURA OPROGRAMOWANIA
Nie to ładne, co ładne, ale co się komu podoba!
Wszyscy możemy podać po kilka definicji udanych architektur oprogramowania. Podczas gdy firma może uważać, że system jest udany, bo wspiera produkcję lub sprzedaż dochodowego produktu, doglą-
dający go programiści mogą w tym samym czasie załamywać ręce nad archaicznymi rozwiązaniami technicznymi. Analogicznie, wiele zgrabnych i eleganckich rozwiązań technicznych kończy jako mniejsze lub większe niepowodzenia. Co więcej, elegancja techniczna rozwiązań to pojęcie subiek-tywne. Dwóch najlepszych programistów mojego zespołu miało skrajne różnie podejścia do stosowania procedur przechowywanych w bazach danych. Jestem pewien, że każdy z nich potrafiłby stworzyć dobre rozwiązanie praktycznie każdego problemu związanego z bazami danych. Jestem równie pewien, że ich aplikacje byłyby różne, a każdy z nich potrafiłby uzasadnić podjęte decyzje, przedsta-wiając zarazem poprawną krytykę architektury zastosowanej przez drugiego. Niewielu programistów potrafi wyjść poza ograniczenia narzucane im przez własne rozumienie estetyki architektury.
Znaczenie architektury oprogramowania
Architektura oprogramowania jest ważna, ponieważ, gdy jest dobra, staje się czynnikiem decydującym o przyszłym powodzeniu projektu. Architektura wpływa na sukces przedsięwzięcia w różny sposób.
Nie każdy z tych wpływów jest równie ważny, ale wszystkie mają swój początek w architekturze.
Trwałość