Przede wszystkim wielkie ukłony dla Grześka. Konferencja tej skali to z pewnością nie lada wyczyn. Dziękuję.
Kilka słów, na temat prezentacji, które szczególnie utkwiły mi w pamięci.
Don't code - create software!. Zapamiętałem ze względu na świetny sposób prowadzenia. Bardzo energicznie i przyjemnie.
Fractal TDD: Using tests to drive system design. Ech...naprawdę fajne koncepcje, naprawdę ciekawego człowieka, podane w nieco zagmatwany sposób (dopiero na drugi dzień doszedłem do tego o, co chodzi z tym "Fractal"). Po prezentacji, gdy kilku uczestników rozmawiało z p. Freemanem, widać było wyraźnie, że prowadzący zdecydowanie lepiej odnajduje się w małych grupach. Mimo tych niedogodności podobało mi się.
Git Going with a Distributed Version Control System ,
Monitoring 10 Critical Code Quality Metrics with Sonar. Merytorycznie raczej tutoriale do narzędzi, ale sposób prezentacji absolutnie rewelacyjny. Moim zdaniem najlepszy prelegent Konferencji.
Architecture and programming model for NOSQL web. Prezentację zapamiętałem, ze względu na to, że nic nie zapamiętałem:) Prowadzący założył pewną wiedzę u uczestników, ja jej nie miałem i się nie odnalazłem. Sąsiedzi twierdzili, że była ciekawa więc wierzę im na słowo. Przyszedł mi do głowy pewien pomysł. Być może na konferencjach powinno rozróżniać się prezentacje ogólne/przeglądowe od szczegółowych, na których zakłada się jakąś określoną wiedzę od uczestników. Prezentacja o NOSQL była raczej szczegółowa i jeśli ktoś przyszedł z konkretnym problemem, to pewnie znalazł rozwiązanie. Ja chciałem się zorientować o co chodzi i niestety nie skorzystałem.
BOF: Dokąd zmierza Software Craftsmanship W zamierzeniu miała być dyskusja o profesjonalizmie w IT. Skończyło się na zabawie, że jeden uczestnik wymyślał metaforę: programista jest jak: [szewc | budowniczy | architekt | lekarz], a cała sala ripostowała przypadkami szczególnymi, dla których metafora kuleje. Było dużo śmiechu, ale moje rozumienie profesjonalizmu raczej się nie poszerzyło. Miałem wrażenie, że wylewaliśmy swoje żale, mówiliśmy o własnych nieprzyjemnych doświadczeniach, które następnie uogólnialiśmy do nowotworu trawiącego całą branżę. Pomysł na dyskusję na pewno cenny, temat warto eksplorować.
Command-query Responsibility Segregation - nowe, bardziej racjonalne podejście do warstw. Obawiałem się konferencyjnej przeglądówki, ale było ok. Jasno konkretnie i po kolei wyłożone o co chodzi w temacie. Prezentacja a'la Matrix dodała kolorytu.
Lost Chapters of Divine Code: 7 Deadly Sins. Pierwsze wrażenie bardzo pozytywne. Świetny kontakt z publicznością, ważne rzeczy przedstawione w ciekawy i kreatywny sposób. Gdy wracałem do domu i myślałem o tej prezentacji, pojawiały mi się mieszane uczucia.
Pierwsza rzecz, to odniosłem wrażenie (z powodu komentarzy kierowanych w stronę słuchaczy), że prowadzący zaczęli prezentację z założeniem, że mają przed sobą bandę troglodytów, którzy do programowania używają dłuta i maczugi, a których oni właśnie oświecają. O czym mówili? O ile dobrze zapamiętałem to: nie używać metod prywatnych, nie używać konstrukcji statycznych, nie używać metod i klas final, preferować kompozycję ponad dziedziczenie. Nie są to więc sprawy, które nagle spłynęły z nieba, lecz tematy przewijające się w branży od czasów GoF i raczej większość programistów ma swoje zdanie na te tematy.
Z wieloma argumentami prowadzących można się zgodzić, ale podawane bez kontekstu tracą swoje znaczenia, a dogmatyczne przestrzeganie tych zaleceń zawsze i wszędzie doprowadzi bajzlu w kodzie równie szybko, co ich ignorowanie. Będzie to bajzel innej jakości, ale zawsze bajzel. Sądzę, że porady prowadzących były ciekawe, ale jak wszystko mają zakres swojej stosowalności. Myślę, że tworzenie boskiego kodu, to coś więcej niż mechaniczne przestrzeganie niskopoziomowych wytycznych.
Moje całościowe wrażenie odnośnie przesłania tej prezentacji jest bardzo pozytywne, potrzebujemy tego rodzaju ewangelistów. Jedna rzecz mnie zniesmaczyła. Prowadzący kolejno wyśmiewali: K.Becka, E.Gamma, S.Freemana, R.Martina i kogoś jeszcze, za to jakie błędy popełnili i co powiedzieli w przeszłości. Przypomniało mi to wiersz Asnyka Do młodych, którym napisał ale nie depczcie przeszłości ołtarzy, choć macie sami doskonalsze wznieść. Myślę, że gdyby nie ci wszyscy "giganci" inżynierii oprogramowania, Autorzy prezentacji z pewnością nie robiliby tego, co teraz robią, nie prezentowaliby siebie na konferencji, a i konferencji z pewnością by nie było. Autorzy prawdopodobnie rzeźbiliby paznokciami w rzadkim...kodzie i nie przychodziłoby im do głowy, że można inaczej. Myślę, że choć Autorom nie brakuje świetnych pomysłów, to jednocześnie przydałoby im się nieco pokory i szacunku do Becka, Gamma, Freemana, Martina i innych, gdyż między innymi dzięki ich błędom (i sukcesom, oczywiście), Autorzy są tam, gdzie są i robią to, co robią.
Podsumowując - niecierpliwie czekam na kolejną edycję Konferencji.
Tyle ode mnie.
agile
(41)
anti-patterns
(17)
architecture
(33)
books
(10)
buissness analysis
(1)
cases
(1)
code speaks 2u
(3)
communication
(1)
conferences
(13)
consulting
(1)
conversation patterns
(26)
customer collaboration
(14)
ddd
(5)
design patterns
(15)
desing
(1)
dialogi
(1)
dsl
(2)
effectiveness
(19)
embedded
(1)
events
(22)
gtp
(4)
info
(2)
infoq
(5)
kanban
(2)
lean
(2)
master
(1)
measuring
(1)
orm
(2)
pea
(2)
product humanisation
(1)
refactoring
(13)
requirements
(7)
retrospections
(1)
retrospective
(1)
scrum
(9)
scrumguide
(1)
sm
(1)
soft skills
(4)
software craftsmanship
(14)
tdd
(1)
team
(20)
time management
(3)
tutorial
(1)
uml
(1)
user stories
(1)
visions
(28)
Podobno nie ma głupich pytań, więc co złego jest w metodach prywatnych?
ReplyDeleteMyślę, że choć Autorom nie brakuje świetnych pomysłów, to jednocześnie przydałoby im się nieco pokory i szacunku (...)
ReplyDeleteSzkoda, ze tak to odczytales. Prezentacja miala miec dosc luzny charakter, co zreszta zauwazyles, a czesc nalezalo potraktowac z przymruzeniem oka i dystansem. Kazda z wymienionych przez Ciebie postaci traktuje z duzym szacunkiem za to co zrobili, a Robert Martin to moj guru :) Pozdrawiam.
Metody prywatne same z siebie "nie gryzą", a mają parę niewygodnych konsekwencji:
ReplyDelete* trudno je przetestować, bo nie ma do nich dostępu
* metody prywatne szybko stają się dość duże i skupia się w nich logika działania komponentu
* bywa, że klasa ma jedną lub dwie metody publiczne oraz całą masę prywatnych, co znów nie jest ani czytelne ani testowalne.
Metody prywatne są ok, ALE jako etap pośredni refaktoryzowania kodu. Jeśli wśród metod prywatnych zaczynamy widzieć pewną odpowiedzialność, to wygodnie jest wyodrębnić nowy obiekt.
Zerknij tu:
* http://msieraczkiewicz.blogspot.com/2011/02/naturalny-porzadek-refaktoryzacji-idea.html
* http://mbartyzel.blogspot.com/2011/02/paczkowanie-kodu.html
Podczas opinii Autorzy proponowali dogmatyczne zaprzestania używania metod prywatnych. Sądzę, że bez podania dużej ilości przykładów i rozważania różnych subtelnych kontekstów taka reguła jest trudna do przyjęcia i stosowania.
Możesz napisać do Autorów z prośbą do szerszy komentarz. Wkrótce ukaże się książka Divine Code, współautorstwa jednego z nich - być może nam znajdziesz więcej przesłanek prowadzących do w/w wniosków.
Inne godne polecenia lektury na ten temat to:
* Implementation Patterns,
* Clean Code
pozdr,
mb