4Developers 2016 - relacja
Na konferencję 4developers 2016 wybrała się spora ekipa programistów ze Speednetu – to już swego rodzaju tradycja, że jeździmy na tego typu imprezy, by czerpać wiedzę z doświadczeń innych projektów.
Program
Zacząłem od prezentacji “2 years after the first event – The Saga Pattern”. Prelegent opowiedział o aplikacji która od dwóch lat działa w oparciu o zdarzenia emitowane przez poszczególne akcje projektu. Głównym tematem było podejmowanie decyzji które wymagają spełnienia paru asynchronicznych warunków – poszczególne zdarzenia mogą wystąpić w różnych momentach a dopiero ich wspólne wystąpienie może generować następny krok logiczny w aplikacji. Przyjęte rozwiązanie polegało na sprawdzaniu wystąpienia wszystkich wymaganych warunków w każdej z akcji biorących udział w podejmowaniu decyzji.
Następnie na wykładzie “Architecting your codebase” pokazano podstawy refactoringu kodu w IntelliJ Idea. Najciekawszym elementem prezentacji nie było jednak pokazanie narzędzia, a dokładne omówienie motywacji stojących za każdym krokiem refactoringu. Nie było to może nic odkrywczego, ale takie “wejście w proces myślowy” doświadczonych programistów jest dla mnie dobrym sposobem nauki i rozwoju.
Potem nadeszła pora na wyczekiwaną tego dnia prelekcję – “Nie koduj, pisz prozę!” Stanisława Sobótki. Przedstawiono w niej różne podejścia do wizualizacji projektów w głowach programistów i opisano problem komunikacji między tymi podejściami. Częstym problemem są zastane wyobrażenia i dotychczasowe doświadczenia osób, np. ktoś kto spędził wiele lat w Assemblerze będzie miał tendencje do mikro-optymalizacji zamiast skupić się na czytelności tworzonego kodu. Okazuje się, że w zespole problemy komunikacyjne mogą być dużo poważniejsze niż wyzwania technologiczne i to one mogą spowodować opóźnienie realizacji projektu.
Ostatnim wykładem przed przerwą obiadową, który wybrałem był “SOA zrobione (prawie) dobrze”. Autorzy opowiedzieli o przebudowie architektury serwisu pracuj.pl, w której odeszli od monolitu i zbudowali konstelację małych usług współpracujących ze sobą. To kolejna prezentacja, która nie skupiała się na teorii, ale operowała na konkretach. Najbardziej wartościowy był dla mnie sam koniec prezentacji, w której autorzy opowiadali o tym czego się nauczyli w procesie budowania kilkuset usług – choćby o tym, że przy kilkuset usługach ciężko zapanować nad odpowiedzialnością za rozwój i utrzymaniem spójności (żeby nie mieć kilku serwisów robiących to samo).
Po przerwie w pamięć szczególnie zapadła mi prezentacja związana z psychologią pt. “Nawyki kognitywne zwiększające efektywność i skuteczność programisty”, w której prowadzący dostosował poziom przekazywanej wiedzy do publiczności. Porównał nasze umysły do hardware, który ma olbrzymi bagaż, z całej ewolucji gatunku. Ciekawą częścią były pomysły jak wykorzystać nasze ewolucyjne ograniczenia by działały na naszą korzyść – choćby znana nam wszystkim metoda gumowej kaczuszki, w której dokładne opisanie problemu kaczuszce pomaga popatrzeć na problem z innej strony, często dostarczając od razu rozwiązanie. Okazało się też, że jeśli chcemy zmienić (lub wprowadzić) nowy nawyk trzeba znaleźć nagrodę, którą będziemy się warunkować – musi być ona atrakcyjna i natychmiastowa, by działanie przerodziło się w nawyk.
Ten dzień zakończyłem na prelekcji “Continuous Deployment – alternatywa dla żmudnego mergowania”, w której autor opisał projekt tworzony od kilku lat przez programistów z wielu krajów pracujących na jednej gałęzi. Przy czym każdy push (jeśli nie zepsuł testów) automatycznie idzie na produkcję. Jest to możliwe dzięki rozdzieleniu dwóch spraw – deployment (czyli nowy kod na serwerze) i release (kod dostępny dla użytkowników). To nie programiści odpowiadają za release funkcjonalności – to Product Owner wybiera moment w którym udostępni daną funkcjonalność użytkownikom. To Product Owner testuje czy wszystko działa jak trzeba i w razie błędów jednym kliknięciem wyłącza zepsute ficzery. Oczywiście tak szybkie wytwarzanie i wystawianie kodu na serwery wymaga dobrych, szybkich i sensownych testów, spełniania metryk jakości i wydajności kodu oraz badania metryk procesowych (np. liczba zamówień dzień po dniu).
Podsumowanie
W ciągu jednego dnia byłem na prezentacjach ze ścieżek Ruby, Java, PHP, Eksperci dla praktyków i Architektura aplikacji. Właśnie ta mnogość tematów na 4Developers jest wg mnie największą zaletą tej konferencji. Nie było problemu, że w którejś godzinie nie miałem na co iść, bywał problem odwrotny – chciałem zobaczyć kilka prezentacji odbywających się w tym samym czasie. W przyszłym roku na pewno znowu pojadę do Warszawy na kolejną konferencję 4Developers, na której wiele interesujących prezentacji mówiących o doświadczeniach, a nie teorii wraz z gigantycznymi możliwościami wyboru powodują, że ta konferencja jest jedną z najlepszych spotkań IT w Polsce.
