33degree – day 3

No dobra, czas kończyć bo ciągnie się to za długo.

Ostatni dzień był dla mnie głównie serią unconference Stefan Tilkov opowiadał o RESTcie w Javie (REST in Java). No cóż, o ile ciekawe, o  tyle mogłem wybrać coś innego ;) Failures Come in Flavors przedstawione przez Michaela Nygarda, przypuszczam, że dużo bardziej by pasowało do mojej obecnej sytuacji ;)

Nie zrozumcie mnie źle, Stefan jest ekspertem od RESTa, dowiedziałem się więcej o dostępnych bibliotekach w Javie by zaaplikować RESTową architekturę, ale mi to akurat teraz jest zbędne.

Następnie udałem się na najgorszą z wszystkich prelekcji: Marcin Kokott i Martin Chmelar w How to solve unsolvable problems in projects. Jak dla mnie to przyszli panowie, by zareklamować swoje usługi i przekonać nas by ich zatrudnić. Jak dla mnie porażka, nic więcej na ich temat nie napiszę.

Kolejna prezentacja, mimo iż o tematach wszystkim dobrze znanych, była jednym z najjaśniejszych punktów konferencji. Szczepan Faber i Bartosz Bańkowski opowiadali o głównych grzechach popełnianych przez programistów (Lost Chapters of Divine Code: 7 Deadly Sins). Zgadzam się z nimi w pełni i staram się przekonywać ludzi, z którymi pracuję, do idei zawartych w ich prezentacji. No może nie do wszystkich. Przejdźmy przez t o co powiedzieli:

1. Obiekt powinien nie mieć metod prywatnych, bądź mieć ich jak najmniej
2. Obiekty bezstanowe nie powinny mieć metod statycznych
3. Dziedziczenie komplikuje kod
4. Nie powinno się tworzyć finalnych klas / finalnych metod
5. Nie powinno się nazywać tej samej rzeczy na kilka sposobów
6. Nie powinno się budować frameworków na wyrost
7. static na polach prowadzi do stanu globalnego, który jest zły.

Ad 1. Ogółem to zgadzam się, że obiekty nie powinny być zbyt duże, ale przesada z ekstrakcją metod prywatnych i zamianą ich w metody publiczne, będzie prowadzić do biegunki klas, które są używane przez jeden obiekt jedynie.

Sam określiłbym to tak: jeśli wykorzystasz metodę prywatną w 2 obiektach, to wyekstrahuj ją do zewnętrznego obiektu by zachować zgodność z zasadą DRY.

Ad 2. Niemal w pełni zgoda. Słowo kluczowe static jest zakazane. Tworzyłem dla klienta niedawno standard kodowania w javie i był to jeden z pierwszych zapisanych przeze mnie  punktów: nie korzystać z statycznych utility classes. Nie jest to do kości złe, ale prowadzi do pokusy tworzenia aplikacji quasi proceduralnych, które niesamowicie ciężko jest testować i zmieniać.

Moja zasada: jeśli masz klasę, która posiada tylko statyczne metody, to jest ona uzasadniona jeśli może być wyekstrahowana do zewnętrznej biblioteki. Jako przykład podaję zawsze bibliotekę Apache Commons i klasę StringUtils. BTW jedna z bardziej użytecznych bibliotek.

Ad 3. Dziedziczenie uważam za złe. Widziałem proste obiekty, które był absolutnie niezrozumiałe z racji wielopoziomowej hierarchii klas. Dziedziczenie ma swoje miejsce, ale jeśli używa się go by ponownie wykorzystać kod, to bardzo łatwo złapać się w pułapkę, że coś nie działa i nie wiemy dlaczego, bądź koszt zmiany jest duży.

Dziedziczenie ma swoje miejsce i nie należy z niego całkowicie rezygnować, jednak w wielu przypadkach rozsądniej jest obiekt komponować, co prowadzi do bardziej elastycznej architektury.

Ad 4. Ogólnie zgoda. Odwołali się tu oni do Joshua Blocha, który stwierdził, że klasa powinna być abstrakcyjna albo finalna. Problem z takim podejściem pojawia się w trakcie pisania testów, bądź udostępnieniu kodu jako biblioteki dla klienta. Czasem musimy nadpisać jedną / kilka metod, bo mamy potrzebę inną niż autor przewidział.

Ad 5. W pełni zgoda. Borykają się z tym przeważnie projekty, które ciągną się na przestrzeni długiego czasu (a przynajmniej tak wynika z mojej obserwacji). Klient potrafi zmienić nazwę dla bytów co może przeniknąć szybko z dokumentów wymagań do kodu, a wtedy zaczyna się jazda, szczególnie jeśli zmienia się zespół programistów :)

Ad 6. Podsumowując: do powieszenia obrazka na ścianie potrzebny jest Ci gwóźdź i młotek. Nie buduj więc maszyny wbijającej gwoździe i wieszającej na nich obrazki, szczególnie gdy masz tylko jeden obrazek

Ad 7. Znów trudno się nie zgodzić. Stan globalny ciężko się zmienia i testuje. Hmm, może kompilator Javy powinien podczas kompilacji na każdym słowie static  wyrzucać prompta: “Czy jesteś pewien, że to chcesz zrobić?”. Może to by ich oduczyło?

Od chłopaków trafiłem do Neala Forda i  Abstraction Distractions. Opowiadał on o … trudno powiedzieć o czym, ale było ciekawie ;) Na poważnie, ciężko jest to wszystko zamknąć w kilku zdaniach by nie spłycić analizy jakiej dokonał Neal, dotyczącej tego jak myślimy, projektujemy, kodujemy, pracujemy, żyjemy. Wplatał w historie z życia wzięte zagadnienia związane z IT i szło mu to bardzo sprawnie.

Następnie wziąłem wolne  2.5 godziny i na korytarzu uczestniczyłem w licznych interesujących rozmowach. Jak na każdej konferencji: jeden z najlepszych momentów: możliwość pogadania z innymi devami.

Na sam koniec odwiedziłem jeszcze Teda Newarda i posłuchałem o … tym by nie słuchać nikogo i myśleć samemu za siebie (Rethinking “Enterprise”). Bardzo odprężający wykład na koniec.

Jeszcze tylko losowanie, w którym udało mi się dostać licencję na Intellij (jej, już nie muszę korzystać z  Idei u klienta i samemu klepać kodu w eclipsie :) ) i czekając na pociąg udałem się z Łukaszem Kuczerą na miasto.

Podsumowując: było rewelacyjnie. Już pod koniec day 1 wiedziałem że za rok na pewno tam jadę ponownie. Jak dla mnie najlepsza javowa (i nie tylko) konferencja w tej części europy. Świetni prelegenci, dużo uczestników (nie tylko z PL), znakomita organizacja, przystępna cena … a z resztą: w ankiecie na idealną konferencję tak opisałem tą moją wymarzoną, a Grzegorz ją zorganizował, za co bardzo mu dziękuję. Było rewelacyjnie i za rok postarajcie się, żeby was na niej nie zabrakło.

Co dalej na blogu? Kilka tematów, które przyszły do mnie na #33degree (teraz już technicznie stricte będzie). Pracuję też na screencastami, jak się uda i mnie technologia nie pokona (i brak czasu), to możecie się spodziewać kilku ciekawych, mam nadzieję, filmów o refactoringu i Tapestry. Tylko jeszcze w życiu osobistym posprzątam.

Do następnego