Code Review vs Pair Programming

Oczywiście w idealnym świecie najlepiej byłoby mieć zarówno Code Review (CR) jak i Pair Programming (PP).
Jednak w brutalnej rzeczywistości zwykle nie ma to czasu, ponieważ ich wykonywanie wiąże się ze złudzeniem tracenia czasu.

Na szczęście w dojrzałych organizacjach znajdujemy czas na tego typu "zbytki" rozumiejąc ich potrzebę - szczególnie w przypadku ekspansji zespołu o "młodych, zdolnych, dobrze zapowiadających się".
Wówczas zwykle defultowo wybór pada na CR.

Co takiego możemy sprawdzić podczas CR?
Na pewno:
- dużą część zasad Clean Code
- poziom sensowności testów
- bardzo ogólnie zgodność z założonym stylem architektonicznym
- przy większym zaangażowaniu być może część reguł GRASP lub SOLID.

<dygresja>
Co do podstawowych zasad Clean Code to wydawać by się mogło, że są intuicyjne. Że każdy podczas pierwszego roku nauki programowania (czy to w podstawówce czy to na studiach) zrozumiał, że krótkie metody i samoopisujące się identyfikatory - GOOD, odwrotnie - BAD.

Okazuje się, że jednak niekoniecznie. W wolnej chwili przyjrzycie się sobie i kolegom z teamu pod kątem dominacji jednego z dwóch typów inteligencji: werbalnej i algorytmicznej.

Polecam Doskonały artykuł Andrzeja Szczodraka: "O programiście-pisarzu i programiście-konstruktorze..."
Dobitnie mówi o tym również Greg Young "gdzieś" w swoim 6.5 godzinnym video.

Ogólny morał jest taki: ważne aby odpowiednio przypisywać programistów o naturalnych zdolnościach do odpowiednich części systemu.

Generalnie różnica polega na tym, że programiści o dominującej inteligencji werbalnej dbają o formę wyrazu. Ich nastawienie - a wręcz predyspozycje - determinują elegancki styl, czytelność i prostotę (prostotę w rozumieniu werbalnym). A Możliwość eleganckiego i prostego wyrażenia intencji jest dla nich narzędziem weryfikacji poprawności pomysłu (weryfikacji nie formalnej ale bardziej intuicyjnej). Algorytmy nie są ich mocną stroną, raczej wzorce, ogólne zasady i formy, architektury, archetypy. Mają niestety chorobliwą tendencję do tworzenia frameworków, aby nadać ramy myślom.

Z kolei programiści o dominującej inteligencji algorytmicznej doskonale czują się w złożonej gmatwaninie obostrzeń nie dbając o styl i formę - te są dla nich pomijalne. Na poziomie algorytmu liczy się wydajność. Ich mocną stroną są raczej biblioteki niż frameworki.
Dodatkowo kilkanaście lat stukania młotkiem w głowę na lekcjach/zajęciach z matematyki gdzie dobra nazwa funkcji to f albo g, dobra nazwa zmiennej to x, y, k, l, m, n a najlepsze zadania to te bez kontekstu i bez treści - umacniają naturalne nawyki.
</dygresja>

Mam nadzieję, że szczypta psychologii rzuci nieco nowego światła na podstawowe zasady Clean Code - z którymi jako entuzjasta dobrych modeli werbalnych osobiście zgadzam się w zupełności. Jednak innych ludzi trzeba również zrozumieć i nie można być zawsze Clean-Nazi.

Poza tym wiele z podstawowych zasad czystego kodu można sprawdzić automatycznie.


Jak jednak sprawdzić design? Jak sprawdzić sensowność koncepcji rozwiązania? Jak sprawdzić model biznesowy?

//Pomijamy tutaj organizacje, gdzie takowe artefakty przychodzą "z góry" do wklepania.

Zakładam też, że sprawdzanie designu metrykami z automatu to jak ocenianie obrazu poprzez histogram;)

Zatem aby sprawdzić tej klasy problemy podczas CR, weryfikujący musi niemal powielić całą pracę umysłową osoby, która weryfikowany kod spłodziła. Czyli innymi słowy mamy podwójny wysiłek mentalny!

Co jeżeli rzeczywiście go poniesiemy (czyli sprawdzimy coś więcej niż nazwy zmiennych i długość metod) i okaże się, że cała koncepcja rozwiązania jest błędna i należało by ją przepisać?

Czy przepisujemy, czy może kończymy CR stwierdzeniem: "następnym razem postaraj się bardziej"?


Skoro już inwestujemy czas drugiej osoby (zwykle tej "mocniejszej") w powstanie kodu, to może warto zrobić to na początku. Tak aby ta osoba brała udział w powstawaniu koncepcji rozwiązania a nie tylko sprawdzała długość metod;)

Jest wówczas duża szansa na:
- wyklucie się lepszego rozwiązania, modelu, koncepcji
- eliminację potrzeby przepisania
- czysty kod będzie niejako produktem ubocznym - ekspert zwykle nie potrafi pisać inaczej niż czysto - syf po prostu go spowalnia lub wręcz uniemożliwia myślenie

Dlatego lepiej zawczasu uprawiać Pair Programming (model kierowcy i pilota) aniżeli poniewczasie liczyć linijki w metodach i sprawdzać czy zmienne nazywają się tak podpowiada zdrowy rozsądek;P
Innymi słowy: mając ograniczone man-hoursy do zainwestowania, lepszy zwrot uzyskamy z PP.

Mam nadzieję, że archaiczne wyrazy użyte w ostatnim akapicie nadały temu postowi poniosły, świąteczny charakter;)

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

W psychologii uczenia się, mentoring uznaje się za najbardziej efektywną technikę uczenia. Po prostu my, ludzie w ogromnej większości uczymy się przez naśladownictwo - przynajmniej na pierwszych poziomach kompetencji (vide model Dreyfus).

TCP vs UDP

Dziś będzie o komunikacji...

Najpierw nieco teorii:
- protokół TCP - komunikacja klient-serwer, w której klient potwierdza otrzymanie pakietu
- protokół UDP - wysyłanie danych bez kontroli przepływu i retransmisji; szybszy od TCP z uwagi na pominięcie "ceregieli" związanych z tym czy klient otrzymał i "zrozumiał".

Nawiązując do poprzedniego, refleksyjnego posta:
podczas jednej z ostatnich konferencji, bardzo dobry znajomy - o pseudonimie artystycznym lburdz - wyświadczył mi nieocenioną przysługę udzielając następującego fidbeku:
Podczas prezentacji nie chodzi o najszybsze opróżnianie (właściwie to lepszym w tym kontekście słowem będzie wypróżnianie) buforów na strumień UDP. Trzeba traktować ludzi (publiczność) jak drugi koniec strumienia TCP.

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

Niby proste, ale jak dla mnie przełomowe! Może jeszcze komuś się przyda...

Pocztówka z wakacji

Mam za sobą 10-dniowe "wakacje", z których to wrażeniami chciałbym się podzielić.
Ostatnie 10 dni upłynęło mi na:
- konferencji 4 developers
- konferencji 33rd Degree
- szkoleniu na temat Distributed DDD i CqRS prowadzonemu przez Grega Younga


Podczas obu doskonałych konferencji obserwować można było wyraźnie pewne trendy.

Mimo, że konferencje mają charakter techniczny, to dużym powodzeniem cieszą się tematy miękkie. Pisał o tym już Martin Fowler w swoim artykule w akapicie na temat trendów konferencyjnych.

Generalne głosy ze świata są takie, że szczegóły techniczne można sobie zgłębiać w domu, a podczas konferencji mamy dostęp do wiedzy niedostępnej w literaturze z naszej branży. Cieszy fakt, że nadążamy za najnowszymi trendami - ciekawy jestem Waszych opinii na ten temat.

Kolejna obserwacja to wyraźny trend amerykanów - doskonała forma ale treść merytoryczna tak prosta, że miejscami ocierająca się o prostactwo (np. odpustowe sztuczki w aplikacjach klasy hello world;).

Podczas 33rd degree prowadziliśmy wraz z kolegami z ssepp panel dyskusyjny na temat profesji w naszej branży. Jako grupa zawodowa wciąż jednak zbytnio skupiamy się na rozgoryczeniu zamiast na działaniu w kierunku krystalizacji profesji.




Jednak trzydniowe szkolenie Grega było jeszcze bardziej intensywne pod względem mentalnym (towarzyskim również - wynajęliśmy na 5 dni wspólnie z Gregiem apartament:)

Greg przedstawił wiele szczegółów technicznych związanych z jego podejściem do architektury CqRS i modelowania DDD. Poszerzył nam również horyzonty przedstawiając architektury systemów, które obsługują setki tysięcy transakcji na sekundę!
Wniosek jest jeden: świat relacyjnych baz danych, popularnych frameworków i platform oraz standardowych warstw jest mocno ograniczający. Aby podejść do problemu o skali rzędu tysięcy na sekundę trzeba zaprzeczyć wszystko co stanowi naszą bazę wiedzy!

Klimat panujący na szkoleniu był nie do opisania. Ponad trzydzieści osób z kraju i zagranicy operujących wspólnym poziomie abstrakcji, fechtujących technikami inżynierii oprogramowania z mistrzowską gracją. Bez kompromisów jakościowych - po prostu przy tej klasie problemu nie da się inaczej...

Do tego doskonały prowadzący z szerokim wachlarzem kompetencji. Począwszy od szczegółów kompilatora poprzez paradygmaty programowania, wzorce projektowe i architektoniczne, znajomość całej klasyki oraz najnowszych zdobyczy inżynierii oprogramowania, metodyk prowadzenia projektów, kreowania wizerunku architektury jako produktu, technik negocjacji po ogólną erudycję sięgającą sieci neuronowych, algorytmów genetycznych, polityki itd itp.

Kudos Greg.

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

Nazywam ten czas wakacjami, ponieważ jestem typem obserwatora (perceiving), poszukiwacza. Dlatego cenię sobie stałą stymulację nowymi pomysłami oraz dyskusje z ludźmi wnoszącymi coś do sprawy, ponad leżenie na plaży.

Patrząc z boku ciężko uwierzyć jak ktoś kto siedzi kilka godzin na konferencji/szkoleniu w bezruchu może przezywać ultra-intensywne doznania poznawcze:)))

Dyskusje panelowe

Podczas 4Developers będę prowadził dyskusję na temat braków w Javie (na różnym poziomie) i sposobach, narzędziach oraz podejściach na ich uzupełnianie.

Podczas 33rd Degree będziemy (wraz z kolegami z SSEPP) prowadzić dyskusję na temat kompetencji, profesji i profesjonalizmu w naszej branży.


Formuła zakłada, że to Wy wnosicie wiedzę i doświadczenie oraz pytania i wątpliwości. To Wy nadajecie kierunek dyskusji w stronę, która Was interesuje.

4Developers

tytuł: Java - czego nam brakuje, co warto dodać?
temat przewodni:
Po pewnym czasie pracy z niektórymi narzędziami zaczynamy zauważać ich
braki - szczególnie gdy spróbujemy użyć narzędzi z innego zestawu.
Wszyscy mamy zapewne przemyślenia na temat pewnych braków w
technologii, której używamy.
Część z nas ma inspirujące doświadczenia z innymi technologiami i podejściami.
Podczas dyskusji chcemy zastanowić się nad sposobami uzupełnienia
naszego warsztatu na poziomie: składni, struktury, narzędzi, podejść,
itd.
Uzupełnienia poprzez: biblioteki, frameworki, pluginy, nowe best practices.

33rd Degree

tytuł: Dokąd zmierza Software Craftsmanship
temat przewodni:
Ruch Software Craftsmanship jest odpowiedzią na pojawiające się potrzeby problemy.

Jest to jednak ogólna idea. Warto jednak zastanowić się nad konkretami:

• jakimi cechami powinien charakteryzować się profesjonalista
  
• jaki zakres bazowych kompetencji powinien posiadać profesjonalista
  
• ew. jakie poziomy kompetencji możemy próbować określać
  
• być może zależy to od klasy problemów
  
• czy nadszedł już czas na krystalizację profesji - czy mamy właściwą ilość doświadczeń
  
• czy i kiedy warto mówić o profesjonalizmie - kiedy jest on potrzeby i kiedy wnosi wartość
  

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

Jeżeli macie jakieś sugestie odnośnie prezentacji lub dyskusji to zapraszam do pisania komentarzy lub na prv.

Tydzień segregacji

Zbliżający się tydzień to dwie konferencje:
- 4 Developers
- 33rd Degree

Przygotowałem dla Was prezentację na temat Command-query Responsibility Segregation, którą przedstawię na obu konferencjach.


Poniżej wersja alfa.

Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw on Prezi

Prezentacja zgodnie z najnowszymi trendami nie zawiera zbyt wiele tekstu - całość wymaga akompaniamentu paszczowego.

W świecie Javy mamy ostatnio stagnację (frameworki webowe już nie wychodzą co tydzień, a skoro najnowsze wersja Java EE wyszła rok temu to mamy kilka lat spokoju;). Jest to zatem dobry moment na ostrzenie piły - np zastanowienie się nad podstawami.

Ogólne przesłanie prezentacji: wybór narzędzia i podejścia powinien zależeć od klasy problemu.

W świecie Javy mamy z jednej strony platformę korporacyjną, która była pomyślana jako produkt dla klientów (wytwórców oprogramowania) wielkiej skali. Po nasyceniu tego rynku mamy widoczną zmianę strategii marketingowej i atakowanie małych softwarehousów. Z drugiej strony mamy mnogość rozwiązań typu generator jednowarstwowej aplikacji, którymi próbuje się kusić każdego - nawet duże softwarehousy.

W prezentacji przedstawię rozwiązania architektoniczne podpatrzone w świecie .NET. Nie są one specyficzne dla .NET ale w tej społeczności są mocniej rozwijane i dyskutowane niż w naszej.

Warto podkreślić, że koncepcja architektoniczna CqRS została wypracowana w ciągu kilku ostatnich lat przez community. Nie jest to zatem objawienie zesłane przez anonimowych pracowników jakiejś firmy, lecz wynik dyskusji i eksperymentów nad rzeczywistymi problemami. Jest to zatem owoc pracy ludzi żywo zaangażowanych w sprawę - stąd wartość.


Mottem dla mojej prezentacji będzie ewolucja architektury, czyli jej rozbudowa wraz ze wzrostem skali (komplikacji i wielkości) systemu. Wychodzę z założenia, że nie każde podejście może ewoluować.


Dla zainteresowanych prezentacją mam sugestię: warto wcześniej zapoznać się z moją prezentacją na temat Domain Driven Design. Nie jest to konieczne, ale jeżeli to zrobicie, to całość ułoży się w sumie w spójne rozwiązanie.
Link tutaj.



Tydzień segregacji właściwie zostanie wydłużony...

W kolejnym tygodniu Greg Young będzie prowadził otwarty wykład i 3-dniowe szkolenie na temat DDD i CqRS w Krakowie (szczegóły).

Nieczęsto zdarza się możliwość uczenia od mistrza, tak więc polecam:)




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

Jeżeli ktoś ma uwagi/sugestie odnośnie prezentacji (treść, zakres) to piszcie w komentarzach lub na prv.
Będę bardzo wdzięczny za feedback:)

Greg Young w Polsce! (UWAGA KONKURS)

Mamy już kompletną agendę konferencji 4Developers, zatem mogę oficjalnie powiedzieć, że Greg Young, którego udało się nam zaprosić do Polski, przedstawi dwie prezentacje:

1. Zapomnij o szczegółach, liczy się efekt! - jest to nowa, jeszcze nie publikowana prezentacja, którą Greg przygotował specjalnie dla nas na 4Dev
   
2. Uwolnij swoją domenę! - przekrojowa prezentacja, która udowadnia, że możemy skonstruować wysokowydajny, skalowalny system, zachowując nieautystyczny model domeny biznesowej. Czyli jak połączyć Domain Driven Design, Commmand-query Responsibility Segregation, Event Sourcing oraz kilka innych najnowszych zdobyczy inżynierii oprogramowania.
   

Od siebie dodam, że Greg należy do mojej ścisłej czołówki guru współczesnej inżynierii oprogramowania. Posiada tytuł Most Valuable Person Microsoftu, jest głównych twórcą koncpecji architektonicznej CqRS oraz wniósł duży wkład w rozwój Domain Driven Design. Dodatkowo potrafi z pasją opowiadać historie o zaawansowanych koncepcyjnie technikach, w taki sposób, że doznajemy efektu "I know Kung Fu".



btw: czy ktoś z Was odważyłby się wystąpić ze slajdami w TAKIM stylu: 7 Reasons DDD Projects #FAIL



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

KONKURS

Rejestracja na 4Dev będzie trwać już tylko do końca marca, a dla czytelników bloga mamy niespodziankę w postaci darmowej wejściówki.

Zasady są proste: wygrywa osoba o największej ilości komentarzy pod postami na moim blogasku. Chodzi oczywiście o posty wystawione przed ogłoszeniem konkursu:0 Zgłoszenia wraz z linkami do komentowanych postów przysyłajcie na maila podanego w sekcji "o mnie".

Proszę o udział tylko tych z Was, których potencjalne szanse na przybycie na konferencję wynoszą 99% (obecność sprawdzę osobiście;)

DDD we Wrocławiu

Dzięki uprzejmości Pawła Szulca na vimeo pojawiła się moja prezentacja na temat Domain Driven Design (i kilku tematów dodatkowych), którą przedstawiłem podczas spotkania Wrocławskiego JUG.
część 1
część 2

Dziękuję wszystkim za aktywne uczestnictwo:)

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

Nawiązanie do community .NET jako przodującego w poszukiwaniu nowych (a może klasycznych?) i lepszych metod modelowania jest zabiegiem celowym, mającym na celu zdopingowanie Was do działania.