Zauważyłem pewną cechę różnicującą projekty, w których kod woła o pomstę do nieba, od tych, które są bardzo przyzwoicie napisane. Różnicą, którą mam na myśli nie jest bynajmniej skala projektu, skomplikowanie domeny, język programowania, czy nawet wiek projektu. Zauważyłem, że w zespołach, w których kod jest dobrze utrzymany objawia się osoba, która nakręca cały ten pęd ku ciągłemu doskonaleniu. Nazwałem go Strażnikiem architektury.
Nie posługuję się nomenklaturą Scotta Amblera, który mówi o Właścicielu architektury, gdyż sądzę, że chodzi o nieco inną rolę. Mimo koncepcji Właściciela architektury, jako roli, a nie stanowiska (zapewne z inspiracji Product Ownerem) trudno uciec od skojarzeń, że właściciel coś posiada. Tego typu rola, bardzo szybko przekształca się w klasyczne stanowisko architekta, który jest wyrocznią w sprawie architektury, od czego Scott Ambler chciał uciec.
Strażnik architektury jest jednym z członków zespołu, który ma "parcie" na ciągłe doskonalenie projektu oraz ewangelizuje zespół w zakresie jakości tworzonego kodu. Zaobserwowałem, że zazwyczaj Strażnik architektury jest inicjatorem i koordynatorem następujących aktywności w zespole:
- wprowadzanie standardu kodowania
- zmiana/wprowadzanie systemu kontroli wersji/zmian
- wprowadzenie code review
- wprowadzenie procesu continuous integration
- wprowadzenie/zmiana podejścia tworzenia kodu np:. DDD
- wprowadzenie/zmiana technologii/frameworka
- tworzenie warstw abstrakcji na niektóre z używanych bibliotek, w celu uniezależnienia się od nich
- zmiana architektury w celu poprawienia wydajności (i nie chodzi tylko do dopisanie paru SQLi i założenie paru indeksów)
Zazwyczaj Strażnik architektury objawia się sam. Po prostu jest ktoś taki w zespole, od kto stopniowo staje się autorytetem dla innych. Uczy ich, prowokuje do wyjścia poza utarte schematy, stymuluje do rozwoju. Zazwyczaj pomaga rozstrzygnąć sporne kwestie dotyczące technicznej strony projektu. Doradza i nieformalnie akceptuje nowe pomysły albo je odrzuca (albo jak mawiają znajomi z pewnego sympatycznego zespołu "spsikuje" pomysły ;) )
Kilka punktów nt. zaobserwowanej charakterystyki Strażnika architektury.
- jest pasjonatem
- poświęca wolny czas na czytanie blogów, literatury, rozpoznawanie technologii
- testuje nowe rozwiązania (często projekcie, w którym uczestniczy)
- często staje się liderem z nadania (poprzez stanowisko) i bywa, że to go "zabija" bo tonie w papierkach, budżetach i spotkaniach
- mimo szeregowego stanowiska z jego zdaniem management się liczy i potrafi przelobbować praktycznie co tylko chce
- szybko wyciąga wnioski z pomyłek, ale się nie zraża
- jest motywowany głównie "na cel"
Pojawia się jednak pewne niebezpieczeństwo. Pęd Strażnika architektury do doskonalenia projektu jest niemal niepohamowany. Niepohamowany do tego stopnia, że może łatwo przekroczyć dopuszczalną tolerancję biznesu oraz wytrzymałość zespołu. Istnieje duże prawdopodobieństwo, że za przyczyną niekontrolowanego Strażnika architektury zespół będzie co miesiąc zmieniał frameworki, a co pół roku technologię.
Kontrolowanie Strażnika przez management bardzo szybko zachęci go do poszukania nowej pracy, gdzie będzie mógł realizować swoje pomysły. Rozwiązanie tej kwestii, podpowiedział mi układ personalny pojawiający się nieraz w zespołach. Otóż, w sprawnie funkcjonującym zespole, prócz Strażnika architektury pojawia się jeszcze jego przeciwwaga. Nazwijmy go Weryfikatorem. Charakterystyka Weryfikatora to:
- jest równie kompetentny technicznie co Strażnik architektury
- bardziej niż nowinki technologicznie ceni sobie bezpieczeństwo
- jest skrupulatny, metodyczny i niesamowicie cierpliwy
- potrafi długo dyskutować ze Strażnikiem architektury i obalać jego teorie jeśli uzna je za niewystarczająco dobrze uzasadnione
- jest motywowany głównie "od problemu"
Strażnik architektury oraz Weryfikator stanowią główną oś zespołu dzięki, dzięki któremu projektu ewoluują w równomiernym tempie. Żaden z nich nie jest nadmiernie, czy sztucznie kontrolowany. Raczej wspólnie wypracowują rozwiązania, czerpiąc jednocześnie wiele satysfakcji z pracy.
Podsumowując: jeśli chcesz mieć dobry zespół i dobrze napisany projekt, to proponuję następujący przepis:
- Zatrudnij Strażnika architektury oraz Weryfikatora o wskazanych wyżej cechach - ci muszą być rewelacyjni
- Zatrudnij pozostałych członków zespołu - ci powinni być dobrzy
- Pozwól im działać
Mnóstwo pytań nasuwa się w związku z tym pomysłem, chociażby: jako to zrobić?, skąd wziąć ludzi?, jak to zrobić najtaniej?. TODO.... :)
