Jak ważna jest architektura oprogramowania?

Architektura aplikacji? Ale o co chodzi?

O powyższym niby każdy słyszał, niby każdy wie, co to. Ba! Każdy programista ochoczo pokiwa głową i zrobi mądrą minę na dźwięk tych słów. Ale starczy ledwie spytać o detale, wystarczy niewinnie zagaić "A jakiej architektury WY używacie?", a już mamy problem.

Bo nagle nasz - było nie było profesjonalny - rozmówca zaczyna się niespokojnie wiercić, kręcić i dopytywać o pogodę (jakby za oknem nie było widać ulewnego deszczu).

Fakt faktem, że niewiele firm (szczególnie tych mniejszych i w Polsce) przykłada jakąkolwiek wagę do kwestii tzw. architektury aplikacji. Bo o ile rzecz brzmi bardzo fachowo, naukowo i szumnie, a tym samym jezzy, o tyle konkretnej definicji ciężko się dokopać. Czym bowiem jest architektura systemu?

Zaznaczmy od razu - nie jest nią MVC, nie jest nią MVP, ani też PCMEF. Tudzież - jest, ale nie o takiej architekturze tutaj mówimy. Wymienione, nazwijmy je, wzorce są bowiem zdecydowanie zbyt nisko poziomowe, zbyt "techniczne". My natomiast mówimy o czymś nabudowanym na to, o kolejnej, wyższej warstwie logiki, o kolejnej płaszczyźnie zasad.

Architektura to to, na czym opiera się cała aplikacja. To to, jaka jest jej najbardziej podstawowa zasada działania. To jej prawa fizyki.

Mało precyzyjnie? Przykro mi, lepiej się nie da.

Architektura systemu słowno-wokalnie

Bez wątpienia mamy w branży specjalistów najwyższej klasy, którzy będąc architektami systemów z wieloletnim doświadczeniem potrafią podać tę czy inną podręcznikową definicję tego terminu. Nie będzie to jednak - moim skromnym zdaniem - nigdy definicja wystarczająca (pomijając już, że zazwyczaj wysoce nieciekawa).

A szkoda, ogromna szkoda, bo doprawdy ciężko dokopać się w IT do czegoś ciekawszego niż właśnie architektura systemowa.
Dlaczego? Ależ proszę bardzo:

1. dobra architektura to dobra aplikacja. Zła architektura to, cóż... zmarnowane pieniądze
2. jeśli zepsujemy szkielet aplikacji, możemy pomarzyć o czymś takim jakim rozszerzalność
3. jeśli nie mamy architektury, nasza aplikacja zazwyczaj będzie wolna, brzydka i nie do zmiany
4. brak architektury to horror dla słabszych programistów i spore wyzwanie dla lepszych
5. wreszcie - brak architektury świadczy o krótkowzroczności danej firmy

Oczywiście powodów przemawiających za przemyślanym projektowaniem modelu informatycznego naszego oprogramowania jest dużo, dużo więcej, ale już powyższych kilka punktów jest na tyle ważkich, na tyle kluczowych, by nie musieć ich wymieniać. Co nie znaczy, że są one uznawane - ku mojemu wielkiemu ubolewaniu - przez każdego.

Diagnoza a'la doktor House

Nie okłamujmy się - to, o czym piszę dla większości jest sporą abstrakcją. Co gorsza, zdaję sobie sprawę - dzięki doświadczeniu zebranemu zarówno w iOculus, jak i w innych firmach - że moje wywody są miejscami mgliste i nie zawierają konkretów, tak ważnych w naszej branży. OK, racja. Ale powód do takiego a nie innego przedstawienia sprawy mam i to ważny - nie da się tego tak prosto wytłumaczyć. Czasami zastanawiamy się w szerszym gronie, czy da się ten temat wytłumaczyć w ogóle.

Bo z architekturą aplikacji jest jak z talentem - albo się go posiada, albo nie. Dlatego też architekci systemowi zarabiają krocie, a znalezienie naprawdę dobrego graniczy z cudem. Jednak duże firmy wiedzą, że jeden świetny architekt, w pojedynkę potrafi zadecydować o tym, czy projekt się powiedzie, czy też nie.

Jeśli ów nie wskaże programistom CO mają zrobić (bo JAK zazwyczaj wiedzą doskonale), projekt stanie się pięknym, interesującym i zarazem absolutnie nieprzydatnym przykładem zastosowania chaosu w biznesowej praktyce.

J