Ścieżka od developera do architekta

Jak zdefiniować rozwój zawodowy? Rozwój zawodowy to proces zwiększania zakresu swojej wiedzy w czasie. Niby dobrze, ale jak to rozumieć? Może najprościej jak się da: każdego dnia uczymy się X nowych metod ( z danej klasy Frameworka etc.). I jeśli mówimy o początkach kariery zawodowej to jest to z pewnością prawda. Tylko, że jeśli z biegiem czasu dalej będziemy tak rozumieć rozwój to chyba coś z nami jest nie do końca w porządku. Chociaż to za dużo powiedziane. Może lepiej zabrzmi, że taka ścieżka rozwoju nie jest do końca optymalna (przynajmniej z mojego punktu widzenia). Kiedyś na blogu Scotta Hanselmana przeczytałem o dark matter developers i właśnie mam wrażenie, że osoby które pojmują rozwój tylko przez pryzmat nowych metod (klas, Frameworków), które poznały są takimi Dark Matter. Nie traktujmy tego jednak jako pejoratywnego określenia bądźmy świadomi że tak jak ciemna materia jest niezbędna do istnienia wszechświata takiego jaki znamy tak dark matter developers są konieczni to działania branży IT. Powiem więcej niektóre firmy wręcz preferują takich developerów ponieważ one po prostu nie potrzebują kogoś innego. Interesuje ich tylko maszyna do pisania kodu, którą można w każdej chwili wymienić jeśli nie będzie potrafiła dostosować się do nowych wymagań.

We Need To Go Deeper

Czemu posłużyłem się cytatem z Incepcji? Chyba każdy kto przeszedł ten etap zrozumie to bez problemu. Dla tych, którzy jeszcze nie osiągnęli “oświecenia” przedstawię przykład, który znam najlepiej czyli swój.
Gdy zaczynałem moją pracę najistotniejszym zadaniem było dla mnie zdobycie doświadczenia. Poznawałem kolejne metody, dopisywałem funkcjonalności (oczywiście w takim zakresie w jakim byłem w stanie). Gdy nie wiedziałem jak coś zrobić to miałem kilka opcji: poszukać podobnego przykładu w kodzie, sprawdzić w google albo spytać się kogoś z większym doświadczeniem (“To powinno być w tamtej klasie a jeśli nie to poszukaj w google”). I ogólnie było super ja się rozwijałem, umiałem coraz więcej ale czułem, że coś jest nie do końca dobrze. Czułem, że nie byłbym wstanie zbudować takiej aplikacji jaką rozwijałem w danym momencie. I gdy tylko taka myśl pojawiła się w mojej głowie nie dawała mi spokoju. Moja punkowa dusza zaczeła się buntować: “a dlaczego robimy tak a nie inaczej, a dlaczego użyliśmy czegoś takiego, jaki jest tego sens”.
Poczułem, że mój rozwój zawodowy znalazł się w tym momencie na właściwym torze (ale kiedy na niego skręcił nie wiem). Pamiętam jak dziś ten pierwszy moment w którym stwierdziłem “We Need To Go Deeper”. Z perspektywy czasu wydaje się to błahostką, ale wtedy dla mnie było to punkt przełomowy. Potrzebowałem połączyć kilka w stringów w jeden i o ile przed rozpoczęciem pracy używałem do tego konatacji stringów to już wtedy wiedziałem, że się tak nie robi (nie rozumiałem jeszcze dlaczego). Miałem więc do wyboru albo StringBuildera albo string.Format(). Tylko, które wybrać nie ma się kogo zapytać a w kodzie jest to używane na przemiennie. Mogłem odpuścić losowo wybrać jedno bądź drugie i przecież wynik będzie dobry… Tylko, że ja chciałem zrozumieć. Zrozumieć żeby móc wybrać. Wiedziałem (w sumie to nie wiem skąd) o takich narzędziach jak IL dasm, ILSpy, Reflector więc użyłem jednego z nich i nagle znalazłem się na niższym poziomie wiedziałem coś o czym reszta zespołu nie miała pojęcia. Podzieliłem się z nimi moim “odkryciem” a oni … nie podzielali mojego entuzjazmu, im wystarczało to co mieli w danym momencie. Byli jak Cypher na kolacji z Agentem Smithem. Fakt, że kod w głębi działa inaczej niż sądzili nie zrobił na nich wrażenia. Zrozumiałem wtedy, że ze mną jest coś nie tak, że jestem inny (w pozytywnym tego słowa znaczeniu). Nasze drogi coraz bardziej się oddalały niby robiliśmy to samo tylko nie do końca. To tak jak z modą. Dwie osoby mogą wybrać ten sam strój tylko, że jedna z nich zrobi to świadomie. I tu jest chyba klucz do wszystkiego. Uzyskanie świadomości.

Miej świadomość

Tym razem cytat z Kazika. Kolejnym etapem było stopniowe odłączenie się od googla. Tak jak pisałem wcześniej gdy czegoś nie wiedziałem miałem kilka opcji do wyboru. Z czasem odeszła opcja dopytania się bardziej doświadczonego deva gdyż odszedł on z firmy. W google zawsze znajdowałem odpowiedź a czasem nawet gotowy kod który trzeba tylko poprawić. Tylko, że mnie to drażniło. Co ze mnie za dev jeśli z każdym problemem lecę do googla? Chciałem podejść do problemów bardziej analitycznie zrozumieć co nie działa, następnie dlaczego nie działa a na końcu procesu rozwiązać problem. Jaki był tego efekt? Przy pierwszym problemie ktoś kto korzystał z googla zrobił to szybciej niż ja, tylko że ja zrozumiałem przyczynę i pisząc później kod wiedziałem gdzie są mielizny, na które trzeba uważać. Dodatkowo zauważyłem kolejny pozytyw. W miarę możliwości poprawiałem mój stary kod ponieważ widziałem jego braki (np. poprawiłem Count>0 na Any()), widziałem miejsca gdzie występują Code smell. Poczułem wtedy, że jest dobrze ponieważ rozwijam się.

Punkt przełomowy

Rozwój rozwojem, ale dalej nie czułem się na siłach napisać dużą aplikację od zera. Ponieważ spisywałem się nie najgorzej (autoreklama) i wykazywałem trochę więcej inicjatywy (znów autoreklama) to dostałem zadanie napisania czegoś od zera. Czegoś prostego. Czegoś co nie można zepsuć (a ja zepsułem). To znaczy działało tylko, że skorzystałem z technologii zaproponowanej przez innego programistę. Technologii, która jest naprawdę dobra pod warunkiem, że nic w aplikacji się nie zmienia (założenia początkowe są święte i program piszę się raz). A ja niestety musiałem kilka razy zmieniać coś na dość niskim poziomie. To wraz z doświadczeniem z dorabianiem nowych funkcjonalności do innej aplikacji (doświadczeniem, którego dodajmy tamten programista nie miał) spowodowały u mnie powstanie dość oczywistego przeświadczenia: Program musi być łatwy w rozbudowie.

With great power comes great responsibility

A teraz Spiderman. Kolejne samodzielne projekty realizowałem już inaczej (co nie znaczy, że optymalnie ale to przecież dobrze o mnie świadczy skoro teraz tak myśle). Robiłem je ewidentnie pod siebie tzn. pisałem kod tak aby potencjalne zmiany były jak najmniej uciążliwe. Spotykałem się z szyderstwem, że to co robię to jak strzelanie z armaty do muchy, że można szybciej, łatwiej. Może byłaby w tym racja gdyby nie fakt, że programy za które ja byłem odpowiedzialny działy a ich były w fazie produkcji. Małymi kroczkami wprowadzałem zmiany dokładałem pojedyncze biblioteki wcześniej nie używane. Wzorce projektowe wreszcie przestały być “akademicką ciekawostką”. I tak z biegiem czasu osiągałem cel za celem. W pewnym momencie gdy moja wiedza była dostateczna poczułem się pewnie. Byłem wstanie napisać coś dużego od podstaw lepiej niż to było zrobione dotychczas. (ogólnie w sprawie architektury polecam serie postów na blogu Basi Fusińskiej “Does great power come with great responsibility” z których to zaczerpnąłem tytuł akapitu albo filmik na youtube, który to podsumowuje)

Great Depression

Wreszcie dostałem tą swoją szansę. Mogłem pisać tak jak chciałem, z wykorzystaniem tych technologii, które chciałem. Reszta zespołu miała robić to samo bo programy muszą być spójne (łatwiej takie serwisować gdy każdy zna technologię). Więc dlaczego piszę o wielkim kryzysie? Pamiętacie jak pisałem na początku, że czułem się inny? Wtedy też to poczułem. Tylko, że poczułem negatywne znaczenie tego słowa. Zobaczyłem opór w pewnych sprawach. Niby wszyscy przyjęli bez zastrzeżeń zmiany w architekturze tylko, że dalej uważali że stare jest lepsze. Nie czuli sensu tych zmian bo nie rozumieli problemów, które te zmiany mają wyeliminować. Zgodzili się na zmiany, ale mam wrażenie że je sabotowali(sabotują nadal?).
Ponieważ czułem się odpowiedzialny (i w pewnym sensie byłem) za zmianę koncepcji to służyłem pomocną dłonią. Jest problem to praca stoi bo w tej chwili problem ten urasta do rangi góry lodowej. Odrywam się od bieżącego zadania analizuję problem wskazuję rozwiązanie … a później często i tak muszę napisać przykładowy kod do implementacji (to tak jak wspominałem na początku: Dark Matter puszą tylko to co już widzieli). Co gorsza muszę napisać przykład szczegółowo bo inaczej nie będzie jego poprawnej implementacji (np. samo powiedzenie aby rozszerzyć konstruktor bazowy o IEventAggregator nie wystarcza, tak samo jak mówienie o wyrejestrowaniu subskrypcji z EventAggregator na zamknięciu okna). W celach pomocy przesyłałem jakieś linki do materiałów, odpowiedzi na ciekawsze problemy, własne przemyślenia poparte przykładami. A później nie widziałem tego w kodzie albo widzę coś co nie ma prawa się tam znaleźć (to w gruncie rzeczy jedna z przyczyn powstania bloga).Fakt, że nie widziałem zainteresowania jak funkcjonuje kod z klas uruchamiających wszystkie nowe rzeczy pominę milczeniem(kod ten musiałem napisać samemu i z tego co widziałem to w żaden sposób nie był on zmieniany – choć w paru miejscach by się to przydało).
Najgorsze pozostawiłem jednak na koniec: obojętność. Nie znoszę letnich dań albo coś jest zimne albo gorące innej opcji nie trawię. A tutaj mieliśmy własnie taką letnią atmosferę. Żadnej dyskusji. Momentami odniosłem wrażenie, że reszta nie wie o czym mówię. Zaproponowałem Autofaca jako kontener IoC to nie słyszałem kontr propozycji (głosy niezadowolenia pojawiły się później). Nikt nie powiedział aby zamiast Caliburn.Micro użyć np. MVVM Light albo zostać przy gołym WPF (bądź nawet WindowsForms). Realizacja AOP to już kompletny kosmos więc nawet szkoda o tym mówić.
Poczułem się cholernie sfrustrowany i głęboko myślałem nad zmianą otoczenia. Więc dlaczego tego nie zrobiłem? Dlatego, że poczułem w pewnym momencie zainteresowanie (nie wszystkich ale zawsze). A to ktoś czyta książkę Marka Seemanna Dependency Injection in .NET. A to chęć aby w następnym projekcie użyć Ninjecta, albo samemu zbudować taką architekture od podstaw tylko żebym pomógł. A to co mnie utwierdziło w mojej decyzji to kłótnia (na argumenty, kontrargumenty, linki ,cytaty). Życie znów może być piękne (do następnej burzy).

7 thoughts on “Ścieżka od developera do architekta

  1. Pingback: dotnetomaniak.pl
  2. Ciekawy post. U nas w firmie było podobnie lecz z pewnymi różnicami. Na początku, kiedy zaproponowałem użycie kontenera IoC, to nie spotkało się to z wielkimi oklaskami czy nawet chęcią do używania. Pisząc aplikacje mobilne ciężko pisze się same testy dlatego dla reszty zespołu wprowadzenie takiego podejścia było bezużyteczne. Dziś wszyscy korzystają z kontenera bo poznali jego możliwości. Ciężko czasem przepchnąć w teamie takie zmiany lecz po czasie daje to dobry efekt.

    1. Ja właśnie liczę na ten efekt. Wiem, że nie będzie on natychmiastowy, ale może z czasem się pojawi.

  3. Jedna z cech dobrego architekta jest także umiejętność nie używania technik/praktyk jeżeli w danym projekcie nie ma konieczności używania tego rozwiązania. Może w danym projekcie nie ma potrzeby używania komend, może wystarczy warstwa serwisów aplikacyjnych, a może projekt jest na tyle mały i prosty że powinniśmy napisać wszystko w Code behind / akcjach kontrolera. Ja niestety jeszcze tej umiejętności nie zdobyłem.

    1. Zgadza się. Nie zawsze warto stosować bardziej zaawansowane techniki. W jednym z projektów z premedytacją zastosowałem np. Caliburn.Micro wraz z DI choć niewątpliwie był to przerost formy nad treścią. Tylko że miałem cel. Celem było zastosowanie wspomnianych wcześniej technik w bardziej zaawansowanym projekcie, w którym dodatkowo zastosowaliśmy kontener IoC. W małym projekcie zdobyliśmy doświadczenie które teraz procentuje.

  4. Trzeba jednak podkreślać że jest to inwestycja (zmniejszamy rentowność małego projektu żeby zarobić więcej albo nie utopić na dużym).
    Ja miałem na myśli przypadek powszechny pośród programistów w połowie rozwoju, którzy znają już wzorce i dobre praktyki i chcą je stosować zawsze i wszędzie w czasie gdy zazwyczaj nie jest to konieczne.
    Niestety nie mam żadnych wyników badań na poparcie mojej hipotezy ale sądzę że overengineering jest groźniejszy ponieważ zabija projekt zanim zostanie użyty przez użytkownika (czy to przez zamknięcie budżetu przez kadrę zarządzającą czy to przez koniec kasy/chęci u założycieli startupa), tymczasem underengineering jest kulą u nogi projektów które już zarabiają na siebie, jednak gdyby wcześniej byłyby lepiej doinwestowane dzisiaj zarabiałyby dużo lepiej (ewentualnie nie musiałyby być przepisywane od zera żeby utrzymać rentowność).

Comments are closed.