Zawsze wydawało mi się, że Erik Meijer (@headinthebox) jest całkiem inteligentnym gościem. Prawda? Mam na myśli to, że koleś, który dał nam LINQ, nie może być idiotą, mam rację?
Ale ostatnio ... No cóż, ostatnio zdałem sobie sprawę, że dr Meijer jest po prostu niesamowicie genialny. To znaczy kreatywnie, kosmicznie, bohatersko genialny! A powód? POWÓD? POWÓD jest taki, że właśnie zrobił kawał stulecia!
Proszę, obejrzyj to. Po obejrzeniu tego Ron Jeffries zatweetował:
"no cóż, to było 45 minut, do których już nigdy nie wrócę"
Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.
Popatrz na dr Meijera grzmiącego, pieklącego się, dyszącego, pocącego się, szturmującego scenę, emitującego więcej szaleństwa niż normalny móżg jest w stanie znieść. Grzmi wśród płomieni piekielnych i oparów siarki. Jest jak słusznie oburzony kandydat do sejmu. Jest jak moralnie dotknięty aktywista na rzecz praw obywatelskich.
Poczuj entuzjazm i pasję tego człowieka kiedy nawołuje swoich słuchaczy (w czasie 30:00), aby unikali testowania ich kodu. Mówi:
"Jedyna słuszna droga tworzenia Twojego oprogramowania to wrzucenie tego na produkcję! Ponieważ to się zawali. I wtedy, jak tylko się zawali, cofasz to do poprzedniej wersji! ... Nie ma żadnego innego sposobu, w który mógłbyś wcześniej testować swoje oprogramowanie. Więc całe to TDD to gówno? Zapomnij o nim. Jeżeli Twoja firma robi TDD - co robisz? Zwalniasz się! Odchodzisz! Wypisujesz wypowiedzenie już dziś! ... Pisanie testów to marnotrawstwo. TDD jest dla ciot."
Ale nie wyłączaj tego video! Słuchaj dalej! Oglądaj dalej! Zobacz, jak dr Meijer pokazuje nam "jedyną architekturę jaką zna",
siedmiowarstwowe struktury OSI dla telekomunikacji. Nudziarstwo, mówisz? Ooo, nie! Na podstawie prostego przykładu architektury opartej na hierarchicznych warstwach, której w zasadzie nikt jeszcze nie zaimplementował, błyskotliwie argumentuje, że zespoły programistyczne powinny być zarządzane poprzez struktury ścisłego nadzoru i kontroli, jak w przypadku Kościoła Katolickiego, czy armii.
"Kościół istnieje od około 2000 lat. Żadne przedsiębiorstwo nie istnieje od 2000 lat. Dlaczego kościół potrafił przetrwać tak długo? Bo to architektura warstwowa!"
Oczywiście! Dlaczego nie wiedzieliśmy tego od samego początku! Kościół przetrwał, bo to wczesna implementacja stosu OSI!
W czasie 34:16 przedstawia obraz typowego programisty i twierdzi, że programiści to w zasadzie żołnierze, którym najlepiej służy wojskowa struktura, taka, jak armia. Mówi:
"Wszystkie nasze firmy powinny mieć kształt ściśle zhierarchizowanych struktur wojskowych."
Powołując się na paragraf w Podręczniku Marynarki Wojennej, Rozdział 1 : Działania Wojskowe mówi:
"Jeżeli zamienisz słowo 'wojna' na słowo 'oprogramowanie' to to po prostu pasuje! Ponieważ oprogramowanie jest jak walka na wojnie. A więc, koniec z tymi agilowymi bzdurami, spójrzmy na wojsko, jak robią to od tysięcy lat!"
I wtedy. I Wtedy. I WTEDY ...
"Czego nas może to nauczyć? Walka na wojnie nie jest dla starych ludzi! Starzy ludzie, jak ja, nie powinni być w tej branży."
Aby udowodnić swój punkt widzenia pokazuje wykres ze średnim wiekiem piłkarzy światowej klasy, który wynosi 27 lat +/- 1 rok. To ma oczywiste przełożenie na świat oprogramowania. To oczywiste, że twórcy oprogramowania są podobni, w każdy możliwy sposób, do piłkarzy światowej klasy. Te dwie branże są prawie identyczne w swoich celach i demografii. Prawda? Oczywiście.
"Chcę aby traktowano zespoły programistyczne jak zawodowe drużyny sportowe. Pomiędzy 22. a 32. rokiem życia, masz nie robić nic innego, tylko kodować! Koduj 24 godziny, 7 dni w tygodniu. Tak jak profesjonalny sportowiec."
O tak, oczywiście, to ma całkowicie sens. Programiści są wartościowi tylko w tym konkretnym przedziale wiekowym. Po osiągnięciu 32 lat ich ciało daje o sobie znać. Po osiągnięciu tego wieku wszyscy dostają
Zespołu Cieśni Kanału Nadgarstka i nie mogą już więcej programować! Oczywiście!
"Wy, programiści, powinniście myśleć tylko o kodzie. Powinniście śnić o kodzie, jeść i pić kod."
I wtedy, następuje ostateczny cios. Mistrzowskie uderzenie. Mem, który wieńczy dzieło:
"Ale to także oznacza, że powinniście zarabiać tyle ile profesjonalny gracz w piłkę. Dlaczego, do diaska, Messi (piłkarz światowej klasy) zarabia szesnaście milionów dolarów rocznie, a ty, który piszesz kod, będąc profesjonalnym koderem oprogramowania tak samo utalentowanym jak Messi, co dostajesz? Sześćdziesiąt tysięcy Euro? Coś koło tego? To śmieszne! A więc powinieneś ruszyć dupę w troki i przez te dziesięć lat zarobić całą tę kasę i wtedy przejść na emeryturę."
Cóż, dlaczego ktoś mógłby odpowiedzieć "nie" na coś takiego?
Geniusz
W prezentacji dr Meijera jest tego więcej. Dużo więcej. Dla przykładu, gdy gdzieś w środku prezentacji mówi o strukturze zespołu i jak gówniany jest Agile, przerywa, aby zaprezentować wstęp do
teorii sterowania i automatów
Mealy'ego.
Na początku, oglądając Jego szalone wybryki, możesz mieć wrażenie, że troszeczkę odleciał. Potem możesz pomyśleć, że oszalał. Potem zatopisz się w głębi połączonych ze sobą nielogiczności, sprzeczności i emocji. Ale, na końcu, jeśli jesteś bystry, zaczynasz zauważać, że ten człowiek jest absolutnie genialny.
Jest genialny w przeprowadzaniu perfekcyjnej mistyfikacji.
Posłuchaj tłumu. Posłuchaj jak akceptują wszystko, co do nich mówi. Posłuchaj jak ich słabe umysły bezkrytycznie wskakują do tego niekończącego się pociągu śmiesznych pomyłek i nonsensu. Oni to łykają!
Dr Meijer wypełnił te czterdzieści pięć minut kompletnymi bzdurami i wszystkim się to spodobało. A to wymaga geniuszu.
Jestem pewien, że schodząc ze sceny chichotał tak mocno, że zmoczył sobie spodnie.
Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :
Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.
Chwila, tutaj zadziało się coś dziwnego. Jeśli dobrze widzę, to Erik Meijer w 30:00 naśmiewa się z TDD, ale chwilę później w 30:25 wyjaśnia. Wyjaśnienie rozumiem jako "TDD służy do eliminowania błędów, które już znamy, ale twoja aplikacja ma być odporna na błędy których jeszcze nie znasz poprzez dobrą strukturę [tutaj: podział na niezależne warstwy]". Tyle wnioskuję z tego co jest na slajdach, ponieważ mój słuch nie pozwala na zbyt swobodne zrozumienie tego Pana. Jeżeli się mylę to proszę mnie oświecić :).
OdpowiedzUsuńTDD jest do sprawdzania, czy Twój software działa dobrze. Dzięki TDD nie boisz się robić zmian w kodzie. Dzięki TDD Twój kod jest lepiej zaprojektowany - bardziej przypomina interfejs API (jakoś musisz się do niego dobrać tymi testami).
OdpowiedzUsuńBardzo dobry wpis. Pozdrawiam serdecznie.
OdpowiedzUsuńRównież pozdrawiam :)
Usuń