GeeCON – relacja subiektywna

Jeżeli przychodząc do mulitkina zamiast filmu widzisz na scenie brodatego gościa opowiadającego po angielsku o dziwnych rzeczach, a na widowni widzisz masę młodych ludzi z 95% przewagą płci męskiej – to znaczy, że jesteś w Poznaniu na GeeCONie.

Wszystkie wykłady z konferencji będą dostępne na stronie konferencji, dlatego nie ma sensu ich dokładnie streszczać – poniższy wpis jest subiektywnym zebraniem wrażeń i najciekawszych informacji z prezentacji.

 

Konferencję rozpoczął Bruce Eckel (tak, ten od Thinking in Java) wykładem „Power of Hybridization”.  Bruce zaczął od kilku ciekawych stwierdzeń: że dobrze jest angażować się w różne rodzaje aktywności, bo to rozszerza horyzonty; że tak jak samo programowanie trudne nie jest, tak proces nauki aby być dobrym programistą trwa całe życie; że najlepsi programiści nie tylko dobrze wykorzystują narzędzia, ale przez cały czas szukają lepszych i prostszych rozwiązań dla swoich problemów. Dalsza część wykładu prezentowała krótką historię rozwoju języków programowania , pokazywała że wszystkie języki mają swoje słabe strony i prezentowała przykłady, w których problemy trudno rozwiązywalne w jednym języku mają proste rozwiązane w innym.

Morał: nauka nowych języków programowania jest ważna – ale nie ze względu na naukę nowych składni czy konstrukcji, lecz ze względu na to, że otwiera umysł na nowe (i w wielu przypadkach prostsze!) sposoby rozwiązywania problemów.

A na marginesie: prezentacja Bruce’a była ilustrowana jego własnymi grafikami i malarstwem –bardzo ładny przykład tego, jak wielość zainteresowań może być użyteczna w praktyce.

 

Ivan Jacobson i prezentacja zatytułowana „Reneaissance in Lean Thinking”. Ivan twierdzi, że tak jak dziecko rozwija się nabierając stopniowo doświadczeń, tak samo systemy i aplikacje muszą rozwijać się powoli. Budując nowy, duży system nigdy nie mamy do czynienia z sytuacją, że potrafimy od razu zaprojektować i zaimplementować go poprawnie. Do rozwoju systemu potrzebujemy trzech rzeczy: podstawy (szkieletu systemu), planu lub wizji rozwoju oraz zasad i wartości – żeby rozwijać się we właściwym kierunku.

W teorii brzmi to prosto i oczywiście, ale Ivan podał rzeczywisty przykład firmy ubezpieczeniowej, która zatrudniała 600 architektów i 2000 deweloperów. Architekci tworzyli cudowne modele i diagramy, którymi tapetowane były pokoje – jedyny malutki problem polegał na tym, że tych diagramów nikt nie rozumiał (oprócz ich twórców, oczywiście) i że nie były one możliwe do zaimplementowania. Propozycja Ivana, żeby uzdrowić sytuację jest prosta: „find the kernel and enable the future”. Nie planuj wszystkiego z góry, lecz stwórz jądro systemu, rozwijaj je według planu i zgodnie z ustalonymi wcześniej zasadami – i pozwól ludziom znajdować i poprawiać słabe punkty i braki w systemie.

Ale odnalezienie czegoś, co możemy nazwać „kernel” czy „core business”, to dopiero początek. W procesie wytwarzania oprogramowania mamy do czynienia z ciągła refaktoryzacją – można założyć, że każdy produkt jest budowany od nowa lub gruntownie przebudowywany co 5-10 lat. Dlaczego? Dlatego że technologia się starzeje, dlatego że z biegiem czasu i przybywaniem poprawek systemy stają się coraz trudniejsze i bardziej kosztowne w utrzymaniu.

Jak budować duże systemy? Ivan postawił bardzo mocny postulat, że jądro systemu musi być działające i koniecznie związane z roadmapą architektoniczną. Architektura bez wykonywalnej wersji jest halucynacją. Wykonywalny kod bez architektury jest to [cytuję] shit [koniec cytatu]. Przykładem systemu, który rozwijał się w ten sposób, jest protokół WWW  stworzony przez Tima Bernersa Lee – wszystko zaczęło się od małej i działającej strony, blueprint’u opisującego dalszy rozwój oraz konkretnych i spisanych założeń architektonicznych.

A największym wyzwaniem dla świata rozwoju oprogramowania jest to, że w świecie w którym mamy już 20 milionów programistów i każdy z nich wie jak rozwijać własny system czy aplikacje – ale jako społeczność nie mamy wspólnych i powszechnie zaakceptowanych podstaw. Składa się na to wiele przyczyn: szybki rozwój i częsta zmiana technologii, brak teoretycznych podstaw (które są obecne np. w klasycznej inżynierii), wielość i różnorodność metodyk i idei rozwoju, brak wiarygodnych testów oraz potężny rozdźwięk pomiędzy praktyką w biznesie, a teoretycznymi pracami naukowymi.

Próbą uporządkowania i stworzenia wspólnego języka dla opisu świata tworzenia oprogramowania ma być SEMAT (www.semat.org). Czy ta próba się uda? Zobaczymy…

Morał: zacznij budowę swojego systemu od jego jądra i rozwijaj je według planu i zgodnie z ustalonymi wcześniej zasadami.

 

Gavin King przedstawiał projekt Ceylon. Ceylon jest nowym językiem programowania – ale założeniem projektu jest nie tylko zbudowanie nowego języka, ale również zbudowanie od podstaw całego SDK do niego. Interesującym celem projektu jest stworzenie języka dostosowanego do tworzenia dużych programów przez duże zespoły – czyli zwrócenie szczególnej uwagi na czytelność kodu (często więcej czasu spędzamy czytając kod niż tworząc go), przewidywalność kompilatora, prostotę rozwiązań i modularność. A reszta prezentacji dotyczyła prezentacji ciekawych cech Ceylonu i nieciekawych cech innych języków, ze szczególnym wskazaniem wad Javy.

Morał: hej, napiszmy jeszcze jeden język programowania, na pewno będzie lepszy niż wszystkie poprzednie!

 

W tym momencie zaczęły się wykłady w kilku równoległych sesjach. Z pierwszego zestawu prezentacji wybrałem Tomasza Kaczanowskiego, który mówił o testach automatycznych. Tomek rozpoczął sesję od prezentacji rzeczywistych testów, które niewiele wnoszą – wymagają ręcznego podawania danych, wymagają przeglądania logów systemu w poszukiwaniu błędów, testują gettery i settery (to rzeczywisty przykład!), nie podają szczegółów dotyczących miejsca wystąpienia błędu. Nie mniej gorsze są „flickering tests” – testy, które czasami zwracają rezultat pozytywny, a czasami negatywny.

Pojawia się pytanie: w jaki sposób pisać testy, które dadzą nam wartość dodaną i poprawią nam jakość? Tomasz podał kilka prostych zasad: pojedynczy test powinien testować tylko jedną rzecz (powinna być tylko jedna przyczyna niepowodzenia testu),  zadbaj o czytelność swoich testów (bo nie tylko ty będziesz je czytał i modyfikował), skup się na testowaniu tego co jest naprawdę ważne, zwróć uwagę na dobre nazwy testów (nazwa testu powinna opisywać, jaka funkcjonalność systemu nie zadziałała, a dużo lepszym przedrostkiem nazwy testu niż „test” jest „should”),  metody „assert” nie powinny zawierać wewnątrz skomplikowanej logiki, zadbaj o to, żeby test był krótki i podzielony na sekcje „given”, „when”, „then”. Nie mniej ważne jest dobre poznanie charakterystyki oraz właściwości narzędzi, którego używamy do testowania.

Często dużo problemów wynika z podejścia „test-last” czyli pisania testów już po zakończeniu implementacji. Powoduje to, że deweloperzy wykonują tylko „happy-testing” i odzwierciedlają w testach istniejącą implementację systemu.

Morał: jeżeli chcesz pisać testy, to rób to mądrze i z zaangażowaniem – albo nie rób tego wcale.

 

Prezentacja Sama Newmana była zatytułowana „Designing for Rapid Release”, a jej tematem prezentacji było pytanie, co możemy zrobić, żeby wydawać swoją aplikację częściej.

Przy projektowaniu aplikacji bierzemy z reguły pod uwagę wymagania, technologię, skalowalność, wydajność i masę innych rzeczy. Zapominamy o wzięciu pod uwagę jednej kwestii: jak często będziemy w stanie ją wydawać, czyli wrzucać na środowisko produkcyjne. A żeby wydawać aplikację często, trzeba zadbać o trzy rzeczy: zapewnić wprowadzania szybkich zmian w aplikacji, zapewnić możliwość szybkiego umieszczenia na środowisku produkcyjnym oraz minimalizować ryzyko wynikające z wydania. Podstawowym założeniem dla projektu systemu, który może być wydawany szybko, jest podzielenie go na małe fragmenty, które możemy testować i przenosić niezależnie od siebie. Ale sam podział to jeszcze nie wszystko – konieczne jest również zapewnienie, że poszczególne moduły nie są ze sobą statycznie połączone.

W praktyce jest sporo rzeczy, które utrudniają nam taki podział: musimy zadbać o integralność sesji po stronie serwera , musimy zadbać o poprawnie działanie systemu w momencie wymiany pewnych modułów na inne. Często bywa tak, że jedna zmiana funkcjonalna musi być zaimplementowana w wielu modułach. Podział na serwisy powinien być odzwierciedlony nie tylko w kodzie, ale również na poziomie baz danych – co jest proste w teorii, ale w praktyce pojawia się problem z danymi, które muszą współdzielone przez różne moduły.

Taki podział serwisu na niezależne moduły, które mogą pracować równolegle i można się między nimi dynamicznie przełączać ma jedną, wielką zaletę – jeżeli możemy przełączać się między jednocześnie pracującymi modułami, możemy rozdzielić moment wydania systemu od momentu włączenia lub pokazania zmienionych funkcjonalności klientom czy odbiorcom systemu.

Morał: jeżeli chcesz wydawać swój system często, zadbaj o dekompozycję systemu na niezależne elementy oraz luźne powiązania między nimi.

 

I na koniec dnia jeszcze raz Bruce Eckel z prezentacją „The Culture is The Company”. Prezentacją, podczas której opowiadał o swoim kwestionowaniu sposobu działania współczesnych organizacji i poszukiwaniu nowego i lepszego modelu dla działania organizacji biznesowych.

Dlaczego szukanie nowego modelu? Dlatego, że duże korporacje są mało produktywne. Dlatego że z reguły pasja jest odwrotnie proporcjonalna do wielkości organizacji. Dlatego że 10% organizacji każdego roku upada. Dlatego że menedżerowie organizacji, które odnoszą sukces, mają bardzo różne sposoby działania. Dlatego że w USA ponad połowa pracowników nienawidzi swojej pracy. Dlatego, że często duże korporacje nie są zdolne do innowacji i potrafią tylko optymalizować to, co już potrafią robić.

Czy można zatem stworzyć organizację, która będzie działała w oparciu o kreatywność, produktywność, zabawę i osobistą satysfakcję?

Bruce szuka odpowiedzi na to pytanie, przedstawił zarys manifestu takiej organizacji. Ale jednym z największych wyzwań we wprowadzeniu tej teorii w życie, jest to, że wiele rzeczywistych problemów wynika z hierarchii stanowisk w organizacjach – a propozycja spłaszczenia struktur spotyka się z naturalnym sprzeciwem menadżementu… Więcej informacji na ten temat jest na stronie Bruce’a.

Morał: być może do rewolucji technologicznych wkrótce dołączy również rewolucja w organizacji korporacji – i, co więcej, kluczowym czynnikiem wpływającym na sukces organizacji będzie jej kultura…

 

Tyle relacji z dnia pierwszego, ciąg dalszy nastąpi…