Bo w życiu trzeba... być Agile:)

Od dzieciństwa słyszmy ze strony różnych "dobrych wujków" co jest "w życiu ważne". Niestety rzadko zdarza się usłyszeć o adaptacyjności czyli życiowej zwinności (w sensie agilności).

Jadnak jakimś cudem w IT wszyscy są Agile - jakiś czas temu robiłem mały research, podczas którego z trudem znalazłem jedną firmę, w Indiach, która otwarcie mówi, że nie jest Agile;)

Gdy jednak przyjrzeć się bliżej, to z tym Agile jest jak z seksem u nastolatków - każdy o tym mówi ale niewielu tak na prawdę to robi (a przynajmniej tak było kilkanaście lat temu w klasach mat-inf;)
Mówi się, że Agile jest trudny ponieważ z pozoru wydaje się łatwy - tak łatwy, że wszystkim wydaje się, że zrozumieli.

W niniejszym poście nie będę pisał o problemach z metodykami (przy okazji: metodologia to nauka o metodykach). Skupimy się na materii miękkiej, czyli problemach z ludźmi.

Jak często napotykacie niemal faszystowskie, anty-adaptacyjne postawy typu:

- nie pisz komentarzy, pisz samo-komentujący się kod (ale samo-komentujący z czyjego punktu widzenia?)
- dobry kod powinien mieć 70% komentarzy tak aby dało się go odtworzyć czytając je (ale po co?)



- Stories są lepsze/gorsze niż Use Case (na jakim poziomie?)


- YAGNI i KISS (nawet jeżeli mam intuicję, że się przyda?)


- Java rules/.NET rules (ale czym to się różni?)

- zawsze używajmy IoC i ORM (ale dlaczego i po co?)
- ORM to badziewie, tylko SQL w procedurach (ale jakim kosztem?)

- jak baza to tylko Oracle/Postgres/...  (ale do każdego projektu?)
- jak baza to tylko noSQL (bo jest sexi?)

 - zawsze pisz testy - "you are not allowed to write a single line of production code without test first" - grzmiał jakiś czas temu Uncle (nomen omen;) Bob
- powinieneś mieć co najmniej 80% pokrycia testami (a dlaczego nie 85%? settery też?)
- nie pisz testów nigdy (nigdy?!?)

- metody powinny mieć 5 linijek (za 6 pójdę do więzienia?)
- metody powinny być tak długie, że powinno dać się je zrozumieć w 5 minut (ale zrozumieć przez kogo)

- zawsze używaj Mavena (nawet w jednomodułowym projekcie z 10 libami?)

- statyczne języki są lepsze (lepsze do czego?)
- dynamiczne języki są lepsze (szczególnie jak do klasy String dokleję sobie 150 metod


- przeglądarka/system/IDE X jest lepsze (lepsze do czego? mówisz to aby pomóc czy aby się podroczyć?)

Można by tak mnożyć w nieskończoność...

Nie wiem czy jest to przypadłość jedynie naszej branży, ale tym co hamuje Agile w procesie jest Autorytaryzm w ludziach. Być może autorytaryzm jest ogólnym memem "odziedziczonym" po wspomnianych w pierwszych zdaniu wujaszkach. Być może jest on wbudowany w nasze ścisłe umysły jako ich integralny ficzer - taki koprocesor poszukiwania jednego, naiwnie prostego równania na wszystko.


O ile mamy coraz więcej KNOW HOW to często brakuje KNOW WHEN.


Można ująć to inaczej: w równaniu

Mądrość = Wiedza + Kontekst

najważniejszy jest kontekst. Kontekst jest tym co odróżnia teorię od praktyki. Kontekst pozwalający zaadaptować wiedzę. Kontekst, który w Modelu Kompetencji Braci Dreyfus pojawia się z czasem, z doświadczeniem. A doświadczenie to refleksja. Refleksja jest konieczna do adaptacji podejścia.


//=================================

W większości cywilizacji konsekwencja jest cnotą. Zwrot "nie jesteś konsekwentny w swym postępowaniu" ma mocno pejoratywny wydźwięk.

Ale bardziej Agile jest inne podejście - podejście adaptacyjne: "Konsekwencja jest fortecą głupców". Konsekwencja zwalnia z obserwowania, myślenia i dostosowania się (nie należy mylić konsekwencji z wytrwałością).

Nie chodzi o to aby zafiksować się na czymś, spuścić głowę i konsekwentnie ryć niczym świnia za truflami. Co jakiś czas warto ją podnieść sprawdzić czy cel jest jeszcze wciąż na wprost - a może na horyzoncie pojawił się inny, lepszy cel i warto się zaadaptować?

Wspinaczka do profesjonalizmu

Wreszcie po ponad miesięcznej przerwie znalazłem chwilę czasu na napisanie posta:)
Brak czasu na pisanie wynika głównie z nawału nowych obowiązków związanych z opieką nad 3-tygodniową córką:]

Dlatego też dziś odsyłam do artykułu mojego autorstwa, który ukazał się w lutowym wydaniu SDJ pt:
"Wspinaczka do profesjonalizmu
Modelowa ścieżka rozwoju kompetencji – podejście pragmatyczne"

Artykuł traktuje o rozwoju kompetencji developerskich w kontekście Modelu Kompetencji Braci Dreyfus, o którym już pisałem.

W tekście zachowano znaczniki specyficzne dla wydawnictwa, ponieważ są czytelne dla "ludzi z branży" a jednocześnie nadają mu strukturę. Tekst zawiera kilkanaście stron, ale podobno szybko i lekko się go czyta;)

Zapraszam do lektury artykułu i być może nawet całego numeru poświęconego programowaniu gier - zawsze to ciekawa odmiana od enterprajz;)

//========================

W ciągu najbliższego tygodnia noworodek powinien przepoczwarzyć się w mniej zasobożerne niemowlę a co za tym idzie pojawi się kilka nowych postów. Będą poświęcone zagadnieniom z zakresu Craftsmanship, m. in. projektowaniu systemu pod kątem usability (na podstawie moich ostatnich doświadczeń z paroma autystycznymi koszmarkami) .

Ktoś sprzątać musi aby bałaganić mógł ktoś

Wszyscy zapewne pamiętamy burzliwą dyskusją Joela Spolskyego z Uncle Bobem (skrót na infoq)

Odbiła się ona szerokim echem dyskusji na ogólny temat: rzemiosło, profesja, jakość czy moźe lepiej byle jak, byle szybko, byle jako tako zadowolić klienta?

Kto ma rację?

Oczywiście ideałem byłoby dobrze i tanio. Ale jak intuicyjnie czujemy - tak to można tylko w mordę dostać;)

Prawda jak zwykle leży gdzieś po środku.

/*
 * W rozważaniach pomijam specyficzne przypadki typu
 * "firma nieustannie na dorobku"
 * albo specyficzny rodzaj dostawcy
 *
 * Zakładam, że bawimy się w projektach perspektywicznych
 * i jesteśmy świadomi zaciąganego kredytu bałaganu
 */


Ciekawą analizę tego zjawiska oraz racjonalne i pragmatyczne podejście do problemu przedstawił ostatnio w swojej genialnej (i jak zwykle niemiłosiernie ospałej) prezentacji sam guru DDD: Errrrrric Evaaaaans: Strategic Design - Responsibility Traps.

Poruszana tematyka zaczyna być omawiana od 30. minuty, ale gorąco wszystkich zachęcam do obejrzenia całości. Evans po mistrzowsku (i z typowym dla siebie poczuciem humoru) buduje od początku kontekst aby w 30. minucie wygarnąć nam co o nas myśli.
Wcześniej dowiecie się min. jakich strategicznych błędów nie popełniać podczas modernizacji systemu. Okazuje się, że standardowe 3 podejścia są z góry skazane na porażkę.

Prezentacja jest wg. mnie tak dobra, że w moim rankingu zajmuje miejsce 2. - zmieniając tym samym ostatnie notowania.


ZAŁOŻENIA (SAD BUT TRUE)
System jako całość nie może być dobrze przemyślany i zaprojektowany. KROPKA.
Nigdy nie będzie dostatecznie dużo: czasu, pieniędzy, wiedzy biznesowej, ludzi z odpowiednimi kwalifikacjami, czasu, pieniędzy, czasu, pieniędzy, czasu, pieniędzy,...

CO Z TEGO WYNIKA
Mamy 2 możliwości:
a) Wszystko zrobić "byle jak"
b) Pewną część zrobić porządnie i zgodnie z zasadami sztuki (oczywiście kosztem tego, że pozostała część będzie jakości mniejszej niż w punkcie a). W którą część i dlaczego warto zainwestować wysiłek - dowiemy się już za chwilę.

PROBLEM
Evans wytyka często spotykany problem. Ja nazwałbym go "złym rozłożeniem potencjału".
Evans opisuje taki oto często powtarzający się wzorzec: najlepsi (w sensie doświadczenia, intuicji, smaku a nie np certyfikatów) programiści/projektanci/architekci zajmują się tworzeniem tak zwanej "platformy". W zależności od systemu może to być wewnętrzny framework, główne biblioteki - ogólnie najczęściej są to jakieś zawiłości techniczne.

Natomiast reszta teamu - radośni hakierzy odpowiadają zwykle za dostarczanie corowych ficzerów biznesowych budowanych na bazie tejże tworzonej przez lokalnych guru platformy. Oczywiście ficzerów okraszonych zaokrąglonymi rogami w GUI - zgodnie z najnowszą modą żadna kanciasta forma nie jest dozwolona;)

Dostarczają oni funkcjonalności nazwanych przez Evansa sexy capabilities. Robią to tak jak potrafią, czyli byle jak byle szybko:)

Klient jest oczywiście zachwycony nowymi seksownymi możliwościami i nie zważa na marudzenie "nudziarzy od platformy", którzy narzekają, że znowu muszą sprzątać. Zresztą... po co sprzątać skoro działa?
Hero of the day to ten, kto zrobił zaokrąglony guzik zwiększający obroty o 1%;)

Oczywiście przyrost bałaganu jest większy niż możliwości jego sprzątania i mamy problem...

ROZWIĄZANIE: DESTYLACJA
Kto jak kto, ale my Słowianie mamy doświadczenie w destylacji więc mógłbym sobie odpuścić ten rozdział;)




Pomysł Evansa polega na wydestylowaniu domeny corowej. Zacznijmy od tego, że Evans wyróżnia 3 klasy domen:

- Core Domain - są to te specyficzne aspekty biznesu, będące powodem dla którego w ogóle warto tworzyć system. Przykładowo to one warunkują przewagę klienta nad konkurencją, lub odróżniają go od innych. To właśnie w tym miejscu mieszkają "sexy capabilities".

I to właśnie w ten kawałek (a powinien być relatywnie mały) inwestujemy największy wysiłek umysłowy.

To tutaj jest miejsce dla całej artylerii sprawdzonych technik naszego rzemiosła: szczegółowa analiza, archetypy biznesowe, wzorce projektowe, narzut na hermetyzację domeny, narzut na otwartość na rozbudowę, narzut na testability...

Core powinien być dobrze uniezależniony od pozostałych domen, które z definicji są w jakimś sensie "mniej godne zaufania" (bo np niestabilne).

- Supporting Domain - dodatkowe ficzery, bez których jednak można się obyć. Ten kawałek systemu może nawet np outsourceować. Jego jakość z założenia może być niska.

- Generic Domain - specyficzne domeny typu podsystem fakturowania lub biblioteka do operowania na grafach. Najlepiej kupić/uzyć gotowe rozwiązanie. Pamiętając o unikaniu zależności ze strony Core Domain.


Dobrym przykładem ilustrującym relatywizm tego pojęcia w zależności do biznesu jest system komentarzy użytkowników wystawianych kontrahentom.
W ebay jest to corowa funkcja (bez niej nikt nie kupiłby niczego od nieznajomej osoby). Dla amazona to po prostu jakiś poboczny ficzer (supportig domain) - ludzie i tak kupią jeżeli czegoś potrzebują lub po prostu mają ochotę.

Pamiętajmy, że developerzy nie są w stanie (ba, nie powinni) określić co należy a co nie do Core Domain w konkretnym przypadku danego klienta. Określenie Core Domain to jedna z głównych rzeczy, którą trzeba z niego wydusić;)




Chyba już domyślacie się jakie rozwiązanie sugeruje Evans...
Core Team zajmuje się Core Domain.
Najważniejsza część systemu ma szansę być zrobiona zgodnie ze sztuką a członkowie tego teamu zyskują uznanie jako dostawcy "sexy capabilities":)


Mam nadzieję, że moja recenzja/streszczenie zachęci Was (a szczególnie managerów) do poświęcenia godziny cennego czasu na prezentację Evansa.
Ciekaw jestem co sądzicie na temat tego podejścia - liczę na dyskusję równie owocną jak ta z przedostatniego posta:)

//==============================

Prowokacyjnie dodam, że Joel Spolsky stosuje jednak strategię "klasyczną". Flagowe oprogramowanie w ofercie firmy Joela: Copilot (soft dla helpdesku pozwalający na zdalną pracę na maszynie "petenta") to nic innego jak nakładka na OpenSourceowy projekt na licencji GPL ;PPP

Czyli ni mniej ni więcej: ktoś zrobił platformę a partacze Joela dodali "sexy capabilities" - a biznes chyba się kręci:)



I jeszcze druga myśl, która mi się nasunęła: Nierzadko występują takie przypadki, gdy naprawdę doświadczony developer w ogóle nie interesuje się pewną domeną biznesową. Po prostu uważamy (niebezpodstawnie) za interesują mniej więcej w takim samym stopniu jak zeszłoroczny śnieg. Wolimy zamiast tego skupić się na rozwoju w kierunku technicznym z uwagi na jego ogólność wynikającą z abstrakcyjności. Nic na siłę, każdy powinien znaleźć sobie optymalne zainteresowania...

Ile Ci to zajmie? (różnice w postrzeganiu czasu)

Niektóre filozofie zakładają, że czas nie istnieje. Jest tylko tu i teraz, upływ czasu to złudzenie. Inni z kolei chcą go wyginać i zaginać.

Ale zejdźmy na ziemię. W biznesie czas to tylko pieniądz. Stąd też najczęściej pojawiającym się pytaniem w komercyjnym procesie tworzenia softu jest nasze ulubione:

ILE CI TO ZAJMIE?

Managerowie uwielbiają zadręczać tym pytaniem swoich/swoje zasoby. Irytują się, gdy developerzy nie są w stanie odpowiedzieć na tak elementarne pytanie. Przecież jeżeli robi się coś od kilku lat to powinno dać się niemal co do godziny określić ilość potrzebnego czasu. Co za durnie, siedzą w tym po uszy i nie potrafią nawet zarządzać sobą, swoimi zadaniami i swoim czasem. Przecież programowanie jest prawie jak budowanie. Macie nawet te swoje wzorce pokrakowe (czy jakieś tam) oparte na latach doświadczeń budowlańców. Muszę mieć harmonogram i się z niego wywiązać. Budżet Panowie! Budżet!

Developerom z drugiej strony ciśnie się na usta "Nie wiem! Nigdy wcześniej tego nie robiłem!" - heh ale tylko Ci o mocnej pozycji w plemieniu mogą sobie pozwolić na zwerbalizowanie swoich myśli. Czy on nie rozumie, ze praca badawczo-rozwojowa (a taką właściwie jest każdy nowy projekt z uwagi na nowe narzędzia) nie jest liniowa a eksponencjalna. Stając w kopalni z kilofem w ręku, kilometr pod ziemią i fedrując na przodku nigdy nie wiadomo kiedy trafimy na skałę, ile będzie trwać stagnacja i kiedy pojawi się nagły wybuch ruszający wszystko do przodu. Programowanie to nie murowanie muru z cegieł (1 cegła na minutę = > mur z 1000 cegieł to 16.7 godziny) - to tak nie działa.

Jedni i drudzy mamroczą pod nosem: co za durnie!



Zagadnienie szacowania czasu, metodyki szacowania to temat na osobna bajkę, dziś będzie o postrzeganiu czasu.

Ale zanim przejdziemy do corowej warstwy posta, zatrzymajmy się na chwilę aby pokazać sceptykom, że postrzeganie czasu rzeczywiście jest względne i każdy doświadcza tego niemal codziennie (proszę nie uciekać od ekranów - względne w sensie poznawczym a nie w sensie teorii względności).

Pomijając filozoficzną i fizyczną naturę czasu, Twój mózg jest po prostu tak skonstruowany, że postrzega upływ czasu. Mamy wbudowane 2 "koprocesory czasu" - zegary dobowy i bieżący. Zegar bieżący opiera się na mechanizmie taktowania (tysiące neuronów) i próbkowania (neurony gwiaździste i piramidalne). Co ciekawe i istotne dla nas, hormony stresu zmieniają stężenie neuroprzekaźników w naszym "koprocesorze" czasu bieżącego co powoduje zmiany w "tykaniu" a co za tym idzie próbkowaniu bodźców ze świata.

Wszyscy znamy uczucie dłużenia się czasu lub odwrotne do niego - szybki upływ czasu. Jak się okazuje niem tu żadnej magii - wszystko zależy od poziomu hormonów stresu. Dzięki temu np w stresowej sytuacji na drodze mamy "gęste" próbkowanie świata, wchłaniamy więcej danych w jednostce czasu i mamy więcej "cykli" na podejmowanie działań związanym z uniknięciem zderzenia z jakimś durniem.


Przejdźmy do meritum, czyli czasu w kontekście IT.
W tym celu zostawmy poziom "techniczny" czyli neurony i przyjrzyjmy się ogólnym strategiom przeżywania czasu: Spontaniczny plan dnia.
Wynika z niego, że dysonans w podejściu do czasu i planowania jaki obserwujemy na różnych stanowiskach może wynikać z różnych sposobów myślenia o czasie. Tak, tak, wg tego modelu różnimy się wewnętrznymi reprezentacjami czasu!

Mamy zatem ludzi żyjących:
- W czasie (In time) - żyją chwilą, odczuwają każdy moment, bez planu i kontroli czasu, skupiają się na aktualnym działaniu
- Pomiędzy Czasem (Between Time) - w pozycji zdystansowanej do czasu, mają na niego ogólny ogląd, widzą możliwości działania, ale nie przypisują im czasu trwania, dowolnie przestawiają zadania
- Poprzez Czas (Through Time) - również z dystansem, ale mając ścisły chronologiczny plan, każde zdarzenie ma czas rozpoczęcia i czas trwania, czas jest linią o ograniczonej pojemności (w sumie logiczne;)

Autorzy artykułu zachęcają nas do trenowania różnych sposobów przeżywania czasu i dobierania najlepszego do danej sytuacji. Powodzenia.

Zastanawiam się czy można w ogóle być dobrym managerem nie żyjąc Poprzez Czas - widząc dokładny plan, zależności czasowe i być przez to cel-oriented?

Czy można w ogóle prowadzić jakąkolwiek kreatywną działalność (mam na myśli sensowną działalność a nie np malarstwo współczesne) nie żyjąc Pomiędzy Czasem - dostrzegając możliwości i potencjał.

A żyjąc chwilą W czasie lepiej chyba nie męczyć się z IT, rzucić to wszystko i rozpocząć karierę w biznesie porno;)

Każdy powinien zająć się tym w czym jest dobry. A szacunek to podstawa.

//==============================

"Ty masz zegarek, ja mam czas"
...Usłyszał w odpowiedzi na nerwowe pokazywanie na cyferblat podróżnik, gdy usiłował ponaglić swego przewodnika na postoju, pod­czas wędrówki gdzieś, na andyjskim bezludziu.

Stare Chińskie przysłowie: Jest czas na pracę i jest czas na zbieranie ryżu

Podobno to Hindusi odkryli system dziesiętny - Arabowie jedynie go rozpowszechnili (mając silne argumenty w dłoniach;).
Nieco mniej chlubnym osiągnięciem indyjskiej myśli jest na przykład biblioteka tagów JSP do integracji z JPA, na którą to niedawno przypadkiem się natknąłem. Zdaje się, że przyświeca jej motto "because we can!"

Stereotyp programisty Hindusa, który "nakłada gacie przez głowę" jest dosyć mocno rozpowszechniony i zakorzeniony ale wystrzegajmy się pychy.

Ciekawe studium hinduskiej mentalności znajdziemy w interesującej, lekkiej ale bardzo pouczającej książce Moja Praca Emigruje do Indii - A wszystko, co dostałem, to ta marna książka. Ale to tylko jeden z aspektów. Poznamy przede wszystkim globalne mechanizmy korporacyjne mające wpływ na niemal każdego z branży IT.

Chad Fowler zabiera nas w egotyczną podróż do Bangladuru, gdzie spędził 1.5 roku tworząc Software House dla jednej z amerykańskich korporacji.

Poznamy szereg kuriozów:
- na ogłoszenie o pracę odpowiada średnio kilkanaście tysięcy chętnych
- a mimo niemałego budżetu nie można sobie pozwolić na tych doświadczonych
- taksówkarz zna 5 języków
- a programista nie ma własnego komputera w domu

Każdy z 52 zgrabnych i wyważonych rozdziałów niesie w sobie pewien morał. Lokalny folklor jest jedynie pretekstem do przekazania metafory lub przesłania. Dostajemy zestaw gotowych strategii, uwag, ostrzeżeń i porad z zakresu szeroko pojętego samorozwoju i autopromocji. Kto się nie rozwija ten się cofa a zmiany są nieuniknione.

//=========================

Wymowa książki w naszym lokalnym kontekście nabiera jednak drugiego dna. Nie musimy obawiać się emigracji naszej pracy do Indii. Być może jesteśmy Indiami Europy:P

W co się bawić?

"W co się bawić? W co się bawić..." śpiewał (a właściwie - nie oszukujmy się - mówił przy akompaniamencie muzyki) Wojciech Młynarski - pierwszy polski raper.

Jest to pytanie, które często sobie zadajemy - a przynajmniej instynkt samozachowawczy powinien je nam podsuwać co jakiś czas.

Zakładając, że programujesz w Javie oraz celujesz w systemy "korporacyjne" (jednocześnie pomijając dyskusję nad tym wyborem) masz do wyboru szereg kombinacji elementów typu: JEE, Spring, Swing, SWT, JPA, Hibernate, Seam, JSF, Tapestry, Wicket, GWT, Flex... (samych frameworków webowych będzie kilkanaście - nie licząc wynalazków typu krzak). Do tego dochodzi cała masa bibliotek - po kilka na każdy problem (xml, javascript, ajax, security,..). Nie zapominajmy o narzędziach, serwerach i najlepszym pretekście do toczenia świętych wojen - IDE.

Mało tego, nie ograniczajmy się tylko do Javy - książki typu "Pragmatyczny programista" zalecają przecież aby co najmniej raz w roku uczyć się nowego języka:)


Oczywiście, wiedzy nigdy za wiele. Teoretycznie każde nowe skojarzenie może potencjalnie poszerzyć horyzont, otworzyć gdzieś tam w zakamarkach mózgu nową furtkę, odblokować nowy sposób myślenia i zaowocować olśnieniem. Ale podejdźmy do problemu racjonalnie. Zakładając jednak, że czas na research mamy ograniczony musimy dokonywać wyboru - czym się zająć, co zgłębić, co przejrzeć a co pominąć. Tu pojawia się niestety paradoks wyboru grożący zawieszeniem niczym ten przysłowiowy osioł, któremu w żłoby dano.


Spróbujmy jednak spojrzeć z innej strony - poprzez analogię do władania językami obcymi: co jest ważniejsze, to ile znasz języków; a może raczej to czy chociaż w jednym z nich masz coś mądrego do powiedzenia? Albo od innej strony: czy poliglota władającymi 5 językami jest w stanie stworzyć sonet choćby w jednym z nich?

Nieustanne miotanie się pomiędzy kolejnymi dostawami świeżego mięcha (nowe frameworki i biblioteki) może powodować ciągłe dryfowanie na drugim (z pięciu) poziomie kompetencji. Permanentne przebywanie na poziomie advanced begginer zwykle kończy się paskudnym schorzeniem - onanizmem technicznym. Zjawisko to po raz pierwszy zaobserwowano na osobnikach z branży fotograficznej, którym to wydaje się, jakoby odpowiednio duża ilość megapikseli gwarantowała wykonanie dobrego zdjęcia.


Wracając do naszego kontekstu: czy biegła znajomość API 15 frameworków GUI ma wpływ na jego estetykę, ergonomię, usability, intuicyjność i poziom autystyczności?

Dlatego na pytanie "W co się bawić?" odpowiadam zawsze, że najważniejsze są pewne koncepcje, które można sobie zrealizować przy pomocy dowolnych narzędzi. Ważniejsze od platformy technologicznej są: rzetelna analiza (np oparta o archetypy analityczne), giętka architektura, sensowny projekt (np oparty o DDD i wzorce).

Zastanówcie się czy Wasza nowa zabawka na prawdę rozwiązuje jakieś problemy - poza tymi, które sama stwarza.

//=====================

W wolnych chwilach szperam w poszukiwaniu materiałów na temat Domain Driven Design i niestety zauważyłem pewną niepokojącą prawidłowość. Przeważająca większość z nich pochodzi ze świata .NET!

Aby było ciekawej pamiętajmy, że książka Erica Evansa zawierała przykłady w Javie;P
Zwróćcie też uwagę, że nowe teksty Martina Fowlera są poparte przykładami w C#!

Zastanawiam się, czy nie jest przypadkiem tak, ze środowisko Javowe jest cały czas na etapie onanizmu technicznego spowodowanego zalewem mniej lub bardziej udanych narzędzi, bibliotek i frameworków, które po prostu rozpraszają uwagę od kwestii na prawdę istotnych.

W środowisku .NET natomiast wybór jest zdecydowanie uboższy, ale może dzięki temu można szybko skompletować skrzynkę z narzędziami i przejść na kolejne poziomy kompetencji. Pozwala to szybciej dojrzeć do na prawdę istotnych aspektów wytwarzania softu i wreszcie oddać się radosnemu filozofowaniu na przykład na tematy DDD:)

Po czym poznac, że jesteś zbyt stary na SCJP?

Skończyłem właśnie czytać miłą książeczkę SCJP Sun Certified Programmer i chciałem się podzielić przemyśleniami (bo tak se czasem lubię trochę pomyśleć).

Optymistycznie nastroił mnie do niej fakt iż jej autorzy są współautorami lekkiej i przyjemniej (jednocześnie bardzo pouczającej) książeczki Head First Design Patterns - którą to na marginesie szczerze polecam. Jej komiksowa forma i humor osadzony w latach '50 może wydawać się dziecinna ale po przeczytaniu wstępu wszystko stanie się jasne - jeden z autorów zajmuje się neuropsychologią i kognitywistyką więc dobrze wiej jak powinno się uczyć dorosłych ludzi.

Z dorosłymi idzie ciężej niż z dziećmi bo zazwyczaj myślą samodzielnie - a czasem nawet krytycznie.


No ale wracając do SCJP... Do samej książki nic nie mam - autorzy starali się jak mogli aby czerstwy temat przedstawić w miarę przystępny sposób. Pozytywne są komentarze typu: "my jako autorzy mamy na ten temat inne zdanie, ale na potrzeby egzaminu musisz robić tak i tak". Każdy z 10 rozdziałów obejmuje pewne zagadnienie - na dosyć podstawowym poziomie, ale mimo tego czasem można dowiedzieć się czegoś nowego. Na zakończenie każdego z rozdziałów mamy pytania sprawdzające, które z założenia odpowiadają tym z właściwego egzaminu. Utrzymane są głównie w konwencji: masz tu kawałek "super-profesjonalnego" kodu, skompiluj w jednej półkuli mózgu i ew. uruchom w drugiej; możesz też jęknąć w razie wyjątku. Problem merytoryczny jest zwykle banalny a wręcz wypaczony, natomiast cały ciężar trudności leży po stronie składni upstrzonej kuriozalnymi identyfikatorami i perfidnych zagrywek służących odwróceniu uwagi.

Zacząłem się zastanawiać dla kogo i po co jest ten egzamin... Doszedłem do wniosku, że możesz być na niego zbyt stary gdy masz niektóre z poniższych objawów:

• Zastanawiasz się gdzie są pogrubienia slow kluczowych - a nie ma...:P będziemy bawić się w sado-maso
  
• Zastanawiasz się gdzie jest cholerny kompilator i podkreślenia błędów?!? - a nie ma...:P i nie będzie...:P już wiesz na czym ma polegać cała ta żałosna zabawa...
  
• Zaczynasz się czuć jak student I roku na jakimś bezsensownym egzaminie z twierdzeń i ich dowodów
  
• #$%^& idę pograć sobie na PS3
  
• Zastanawiasz się gdzie jest dekiel który napisał ten kod? Tak się przecież nie programuje nawet w PHP w gimnazjum! Niech bym go tylko dostał w swoje ręce.
  
• Zwolnic go natychmiast i zanotować nazwisko na liście ludzi, z którymi nigdy nie chcesz współpracować
  
• Co to w ogóle za odpowiedź "G) Compilation fails"? To po cholerę komitujesz mi do poważnego testu niekompilujący się kod baranie jeden! W chyba każdej firmie dostałbyś po premii (a w pożądaj poleciałbyś na pysk) za choćby parę takich smrodków!
  
• Tijaaa znowu pytanie z serii "wlałeś benzynę przez rurę wydechową. Co się stanie? Samochód pojedzie ale skręci w drzewo. Samochód nie odpali. Samochód wybuchnie." Nie wydurniaj się człowieku. No wlej tą benzynę jak biały człowiek do baku i nie zawracaj mi głowy zgadywanką co się stanie jak dodatkowo założsysz gacie przez głowę.
  
• Zaczynasz rozumieć pojęcie "Code made in India"
  
• Gryzie Cię poczucie tracenia czasu
  
• Obawiasz się, ze jeszcze jeden rozdział i nabawisz się autyzmu
  
• Zaczynasz żałować, ze nie masz tego autyzmu - wspaniałego schorzenia, które pozwala skupiać się godzinami na nieistotnych pierdołach i ignorować szerszy kontekst
  
• Boisz się, ze nabyty autyzm mogą odziedziczyć Twoje dzieci (ku chwale wujka Suna)
  
• Motyla noga! Gdybym był wzrokowcem a nie słuchowcem to może przynajmniej widziałbym te brakujące średniczki i nawiasiki:/
  
• Dowiadujesz się, ze o wiele ważniejsze od projektowania i rozmyślania nad architekturą jest znajomość kolejności operatorów (nawiasy są dla cieniasów)
  
• Dowiadujesz się, że enkapsulacja to jednak prywatne pola i publiczne gettery/settery
  
• Dowiadujesz się, że w programowaniu współbieżnym najważniejsze jest kretyńskie zaprojektowanie wątków oraz to aby całość jakimś cudem się skompilowała. Teoria współbieżności jest dla dinozaurów programujących w ADA.
  
• Zastanawiasz się jak mogłeś przez 6 lat programować w języku, którego jak się okazuje w ogóle nie znasz
  

//=====================

Jest tez druga strona medalu: możesz być zbyt młody na SCJP... Jeżeli dopiero zaczynasz przygodę z Javą to olej certyfikaty ciepłym moczem parabolicznym. Ciesz się życiem i programowaniem. Programowanie wcale nie musi być nudnym zajęciem polegającym na wyszukiwaniu literówek i analizowaniu jakiegoś gównianego kodu (no dobra, czasem jest). W tej zabawie chodzi na prawdę o coś zupełnie innego!

A jeżeli chcesz zwiększyć swojego skilla to przeczytaj sobie dwie doskonale książki:
- Efektywne programowanie w języku Java autorstwa samego Joshua Bloch - projektanta i autora dużej części klas biblioteki standardowej Java; książka o której to sam James Gosling powiedział, ze gdyby została napisane wcześniej to inaczej zaprojektowałby Javę;)
- Java. Potrzaski zestaw 50 na prawdę realistycznych i ważnych haczyków na które należy uważać (nie ma tam syfu typu brak średnika)

Jeżeli jeszcze Ci mało, to proszę:
- More Java pitfalls - druga część potrzasków
- interesuje cię programowanie współbieżne? bardzo dobra pozycja: Java. Współbieżność dla praktyków

Ucz się z tych pozycji, ale powtarzam: nie trać czasu na certyfikat! To w żaden sposób nie zrobi z Ciebie lepszego człowieka (ani programisty).

Później przyjdzie czas na ważniejsze zagadnienia: projektowanie (wzorce projektowe), architektura, analiza itd... Nie zapominaj też o takich "szczegółach" jak dogadywanie się z ludźmi (koledzy z teamu, klient). A średniki poprawia Eclipse;P

The Unforgiven

Jak spożytkować godzinę czasu aby później jej nie żałować...?
Proponuję refleksję nad sobą, swą pracą, swym rozwojem i karierą: Developing Expertise: Herding Racehorses, Racing Sheep.
Godzina czasu spędzona przed "filmikem z netu" może wydawać się nudnym sposobem na spędzenie popołudnia, ale może warto wreszcie zrobić coś dla siebie po całym tygodniu robienia różnych rzeczy dla innych.

Dave mówi na tyle ogólnie, że aplikuje się to dla każdego , nie tylko dla programersów i jest adekwatne do wszystkich aspektów życia. I gwarantuję, że nie będziecie się nudzić - w razie czego w ramach rekompensaty stawiam każdemu kto się znudzi butelkę whisky:)


Dave (kurcze, tego faceta nie da się nie lubić) przedstawia pięciostopniową drogę rozwoju. Co prawda całość jest osadzona w kontekście IT, ale tak jak już wspomniałem treść jest uniwersalna - szczególnie, że Dave snuje paralele (trudne słowo) do nauki chodzenia, gotowania, ba nawet nauki pilotażu. Dave opisuje takie oto fazy kompetencji:

New blood joins this earth...

Novice - robisz coś po raz pierwszy, kompletnie nie wiesz o co chodzi. Nowy członek teamu jest nastawiony na szybką relizację prostego zadania. On po prostu potrzebuje małych sukcesów. Nie obchodzi go biger pikczer, po prostu chce zrobić coś co działa.

Advanced begginer - powoli zaczynasz rozumieć o co mniej więcej chodzi. Uczysz się. Twój mozg zaczyna zauważać powtarzalne wzorce - i jak zauważa Dave nie da się tego w żaden sposób wyłączyć - jest to jego naturalna cecha. Jednak w dalszym ciągu potrzebujesz kogoś, kto powie Ci co trzeba zrobić.

Competent - Mała larwa przepoczwarza się w samodzielnie myślącą bestię. Całkiem dobrze orientuje się w wyuczonej domenie a samodzielne myślenie pozwala mu na planowanie działań na przyszłość.

Proficient - Odkrył, że jest jeszcze coś więcej i zrozumiał, że tak na prawdę nic nie wie. Zaczyna syntetyzować wiedzę z innych dziedzin aby rozumieć więcej i lepiej. Upierdliwy typek. Zadaje pytania, filozofuje - z tego powodu jest pierwszy do zwolnienia;)

Expert (Wizard) - zasób wiedzy i skojarzeń jest tak ogromny, że mózg optymalizując procesy myślowe wykonuje je w nieświadomości (niższe warstwy kory nowej? może po prostu w skrócie intuicja). Wizard mówi (i zapewne rozumuje) w oparciu o metafory ponieważ nauczył się, że wszystko zależy od kontekstu. Ekspert stale jest głodny wiedzy dlatego nie pytaj go jakich frameworków użyć w nowym projekcie bo skonstruuje frankensteina (wiem, wiem, że Frankenstein był naukowcem, który to dopiero stworzył potwora, ale tak sie mówi) tylko po to aby sprawdzić jak to będzie ze sobą działać:)))


Na zakończenie dowiemy się, która grupa jest najbardziej liczna, dlaczego ludzie zatrzymują się na pewnym poziomie i dlaczego jest to wygodne zarówno z punktu widzenia firmy jak i większości pracowników oraz dlaczego jest to zgubne na dłuższą metę. Ale nie będę Wam robił spoilera;P

//============================
Sądzę, że model Davea jest dosyć mocno uproszczony. Nie uwzględnia np. typów osobowości o których pisałem i obiecałem napisać więcej. Zresztą, najlepiej poczytajcie sami, np tu. W skrócie: różne osobowości mają różne priorytety - w szczególności parcie na rozwój, poszerzanie kompetencji itp.

Innym pominiętym aspektem są metaprogramy. W szczególności różnice w podejściach Szczegółowe — Globalne (przewiń w dół do paragrafu "METAPROGRAM VI: SZCZEGÓŁOWE — GLOBALNE").

Jednak na podkreślenie zasługuje kilka ważnych myśli, które poruszył Dave...
Chyba nie znajdziecie lepszego ich rozwinięcia niż te proponowane przez Alexa:

Czy twoje 20 lat doświadczenia w ogóle coś znaczy, czy może możesz pochwalić jednym rokiem doświadczenia powtórzonym 20 razy???

oraz

Czy jesteś dojną/mięsną krową?