sobota, 23 kwietnia 2011

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).

wtorek, 19 kwietnia 2011

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...

piątek, 15 kwietnia 2011

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:)))