W zeszłą sobotę miałem przyjemność wziąć udział w konferencji IT pod nazwą Click. W tym roku była to III edycja tego programu i miała ona formę online - Click2020. Dwie wcześniejsze odbyły się w Lublinie. Click przeznaczony jest głównie dla specjalistów branży IT chcących posłuchać o najnowszych technologiach oraz biznesie.
Wszystkie wykłady odbywały się w wirtualnych salach. Wystarczyło wejść na podany link do YouTube czy Facebook’a i cieszyć się prelekcją. Dodatkowo w przerwach dostępne były wirtualne stoiska firm umożliwiające rozmowę z konsultantem. Do wyboru możliwe były 4 ścieżki technologiczne:
- Java
- Web
- Mobile (Android / iOS)
- Python / Cloud / Machine Learning / AI / Data Science / Salesforce
Oczywiście ja udałem się do sali żółtej, w której obywały się wykłady dotyczące Javy ☕ (no może poza jednym). Agenda wyglądała następująco:
- 10:00-11:00 Bartłomiej Słota - Live refactoring towards solid code
- 11:00-11:30 Przerwa na kontakt z Wystawcami
- 11:30-12:30 Grzegorz Piwowarek - Fantastic Frameworks and How to Avoid Them
- 12:30-13:00 Przerwa na kontakt z Wystawcami
- 13:00-14:00 Andrzej Dyjak - DevSecOps: Bohater, którego potrzebujemy!
- 14:00-15:00 Długa przerwa na kontakt z wystawcami
- 15:00-16:00 Sławomir Sobótka - Poznaj swoje granice - o odkrywaniu granic obiektów i modułów
- 16:00-16:30 Przerwa na kontakt z Wystawcami
- 16:30-17:30 Przemysław Bykowski - Architektura heksagonalna i droga do eliminowania komplikacji konstrukcyjnych w oprogramowaniu
- 17:45 Zakończenie i podsumowanie konferencji.
Muszę przyznać, że jestem zadowolony z tego jak spędziłem sobotę. Mogłem spojrzeć na niektóre problemy z w ogóle innej perspektywy. Pokrótce chciałem przedstawić o czym były wyżej przedstawione wykłady.
Bartłomiej Słota - Live refactoring towards solid code
Akurat się tak zdarzyło, że byłem już na dokładnie tej prezentacji Bartka podczas meetupu Applause Poland Meetup Group, który odbył się 12 grudnia 2019. Sesja odbywała się w formacie live refactoring. Pokazywany był sposób w jaki ulepszać nasz kod w sposób bezpieczny (nie zmieniając jego działania).
Refactoring cannot change the external behaviour of the existing code
Byłem pod ogromnym wrażeniem sprawności Bartka w sposobie poruszania się po IntelliJ. Za pomocą wielu skrótów klawiszowych potrafił szybko ulepszać kod. Sprawiło to, że sam zacząłem się ich uczyć, aby ułatwić sobie pracę. Przechodząc do głównego wątku w prezentacji ujęty był problem pracy z kodem legacy. Zaproponowano sposób w jaki można zabrać się do refaktoryzacji kodu.
Na samym początku warto pogrupować linie kodu, o podobnej odpowiedzialności, do osobnych, mniejszych metod uzyskując bardziej przejrzysty obraz. Następnie ważne jest, aby dopisać testy jednostkowe do istniejącej logiki. W ten sposób zyskuje się pewność, że nie zmieni się sposobu działania programu. Zaczynając pisanie testów Bartek proponuje, aby zacząć testowanie najpłytszej gałęzi (w przeciwieństwie do ogólnie przyjętego happy path). Wskazane jest korzystanie ze wzorców TestFixture i TestDataBuilder oraz rozdzielenie testów stanu (np. weryfikacja czy produkt zmienił stan na sprzedany) od testów interakcji (np. czy została wywołana metoda odpowiedzialna za aktualizację stanu produktu). Gdy już stworzymy porządną bazę testów to możemy przejść do refactoring’u. Tutaj zalecanym podejściem jest zaczęcie od najgłębszej gałęzi. Łatwiej “rozplątuje się” wtedy całą funkcjonalność.
Nie będę zdradzał więcej zagadnień z prezentacji. Jeśli jesteś zainteresowany tą tematyką to obejrzyj sobie koniecznie nagranie z soboty - Bartłomiej Słota - Live refactoring towards solid code.
Grzegorz Piwowarek - Fantastic Frameworks and How To Avoid Them
Trener Javy w Bottega IT Minds oraz starszy inżynier w Hazelcast. Ta prezentacja naprawdę mnie pozytywnie zaskoczyła. Mocno ostudza głowę jeśli chodzi o uleganie najnowszym trendom. Grzegorz zaznacza, że trzeba naprawdę mocno przemyśleć plusy i minusy danego framework’a. Im bardziej uzależnimy się od jakiegoś rozwiązania tym trudniej nam będzie przenieść się na inne. Zgadzam się z tym twierdzeniem, jedna adnotacja może nam oszczędzić 3 linijki kodu, ale zaciągniemy duży dług technologiczny. Najlepszym rozwiązaniem jest korzystanie z “czystej” Javy i do niej doklejanie konfiguracji framework’a. Nie możemy uzależnić się od magii 🌈!
Porównanie biblioteki z framework’iem
Warto również nie uzależniać się od wielu dependencji. Można się łatwo wpędzić w Dependency Hell. Jednak trzeba to także wyważyć, bo z drugiej strony czeka na nas syndrom Not invented here syndrome. Spodobało mi się przedstawienie zagadnienia framework’a w życiu biznesowym na przykładzie franczyzy. Decydując się na taki zabieg zapewniamy sobie szybki start, ale jesteśmy uzależnieni od danej konwencji (np. nie możemy zmodyfikować loga firmy). Wartościowa była dla mnie nauka jak ograniczyć adnotacje Spring’a w kodzie Javy. Zamiast tworzyć klasę oznaczoną przez @Component możemy utworzyć metodę @Bean tworzącą konfigurację danego obiektu. Uzyskujemy w ten sposób niezależność od technologii.
Koniecznie obejrzyj to nagranie Grzegorza Piwowarka. Podaje on ciekawe przykłady produkcyjne związane z niedziałającymi framework’ami oraz możliwości odcięcia się od nich - Grzegorz Piwowarek - Fantastic Frameworks and How To Avoid Them.
Andrzej Dyjak - DevSecOps: Bohater, którego potrzebujemy!
Następnym prelegentem był Andrzej Dyjak, specjalista od cyberbezpieczeństwa. Przedstawił on zagadnienie DevSecOps czyli połączenia zespołów rozwoju oprogramowania (Dev) z jego utrzymaniem (Ops) i działem bezpieczeństwa (Sec). Po krótkiej historii rozwoju bezpieczeństwa w aplikacjach Andrzej przeszedł do przykładów prezentujących nagrody uzyskane poprzez BugBounty. Naprawdę można zarobić na tym bajeczne sumy 💰. W kolejnym kroku zaprezentowane zostały działania mające na celu ochronę naszych wrażliwych kodów (np. ApiKey) przed przypadkowym wyciekiem np. do repozytorium Gita, które może stać się publiczne w przyszłości.
Zainteresowało mnie zagadnienie związane z nieuprawnionym dostępem do naszej aplikacji poprzez zaciągnięte zależności. Jest to naprawdę bardzo pomysłowy atak na dane. Typowymi atakami są:
- Account Takeovers (ATO) - przykładowe przejęcie konta poprzez brute force bądź brak 2FA
- Malicious Takeovers - przejęcie pakietu poprzez zyskanie zaufania i dołączenie do kręgu właścicieli
- TypoSquatting - zrobienie literówki podczas wpisywania nazwy zależności
Na koniec chciałbym jeszcze przytoczyć dyskusję o różnicy między testami penetracyjnymi a oceną podatności. Przy penetracji korzystamy z black-box na włączonej aplikacji ze wszystkimi zabezpieczeniami. Musimy obmyślić łańcuch ataku, jak złamać schematy w systemie. Penetracji dokonujemy na produkcji. Natomiast oceny podatności dokonuje się na white-box’ie. Szukamy luk bezpieczeństwa lokalnie albo na środowisku testowym. Przez to, że mamy dostęp do kodu źródłowego to wiemy dokładnie gdzie szukać. Taka ocena powinna być wykonywana jak najwcześniej. Po więcej detali zapraszam do obejrzenia prezentacji Andrzeja Dyjaka. Nie jest to do końca tematyka, która mnie zachwyca, ale naprawdę dobrze się słuchało - Andrzej Dyjak - DevSecOps: Bohater, którego potrzebujemy!.
Sławomir Sobótka - Poznaj swoje granice - o odkrywaniu granic obiektów i modułów
Początek prezentacji był naprawdę niespodziewany. Powiedziałbym, że w stylu Sławka 😉. Jak obejrzysz to sam zrozumiesz o co chodzi. Ta krótka historyjka dobrze nakreśla tematykę wykładu. Przechodząc do głównego celu wykładu otrzymujemy wymagania stawiane przed przykładową aplikacją. Ich implementacja została zawarta w tzw. GodClass. Przy okazji Sławek w jasny sposób wyjaśnia zagadnienie kohezji. Chodzi w niej o to, że nie wszystkie pola klasy są używane w każdej z metod. Jest to wskazówka, że pewnie taka klasa jest zrostkiem kilku innych klas (ma za dużo odpowiedzialności).
Kolejnym krokiem wykładu było przedstawienie problemu związanego z lokalnym refaktoringiem. W przypadku źle wykonanej analizy biznesowej niskopoziomowe porządki nie są trywialnym zadaniem. Zmiana w jednym module wprowadza chaos w innych. Należy wyjść poziom wyżej i jeszcze raz zastanowić się nad logiką biznesową. Co tak naprawdę jest naszym sercem aplikacji. Trzeba naprawdę dobrze przemyśleć model biznesowy. Zastanowić się czego wymagamy od systemu. Efektem ubocznym tych działań będzie porządek w kodzie. Nasz lokalny refactoring wykona się za nas. Sławek na koniec zostawia nas ze zdaniem:
5 lat kodowania pozwoli nam zaoszczędzić aż kwadrans analizy
Tomasz Nurkiewicz
Polecam przesłuchać z uwagą tą prezentację. Naprawdę daje dużo do myślenia i pokazuje jakie działania można podjąć, aby uzyskać czystą architekturę. Nie jest to łatwe zadanie, ale podkreśla po raz kolejny współpracę na linii deweloperzy-biznes. Zamieszczam tutaj link do wykładu - Sławomir Sobótka - Poznaj swoje granice - o odkrywaniu granic obiektów i modułów.
Przemysław Bykowski - Architektura heksagonalna i droga do eliminowania komplikacji konstrukcyjnych w oprogramowaniu
Przemek jest konsultantem i trenerem programowania. Jego wykład miał na celu przybliżenie architektury heksagonalnej. Alternatywną nazwą są Porty i Adaptery (Ports & Adapters). Nie ma to żadnego związku z 6 bokami heksagonu. Jest to tylko nazwa z racji tego, że ta architektura jest bardzo elastyczna. Główna logika aplikacji komunikuje się z adapterami poprzez wystawione przez siebie porty. Natomiast adaptery łączą się ze światem zewnętrznym (np. bazami danych, protokołem http). Dodatkowym atutem jest możliwość połączenia się także z inną aplikacją. Przemek napomina, że ta architektura ma dużo wspólnego z DDD.
Schemat architektury heksagonalnej
Na Ports & Adapters składają się 3 warstwy: framework (komunikacja oraz transformacja danych na obiekty naszej aplikacji), aplikację (przetwarza dane, łączy framework z domeną) i domenę (serce programu, obiekty domenowe). Porty są interfejsami, a adaptery je implementują. Ważne jest, aby dobrze postawić granice w logice aplikacji (Bounded Context). W prezentacji zaprezentowany został przykład w Javie, z którym polecam się zapoznać.
Dla mnie świat architektury IT jest bardzo ciekawym zagadnieniem, więc wciąż poszukuję nowych informacji. Temat architektury heksagonalnej w tej prezentacji jest tylko początkiem - Przemysław Bykowski - Architektura heksagonalna i droga do eliminowania komplikacji konstrukcyjnych w oprogramowaniu.
Podsumowanie
Cieszę się, że mogłem uczestniczyć w tym wydarzeniu. Mimo, że konferencja była darmowa to materiały były wysokiej jakości. Tutaj ukłon w stronę organizatorów. Dla tych, którzy nie mogli uczestniczyć w sobotnim wydarzeniu zachęcam do zapoznania się z linkami umieszczonymi w artykule. Jestem zadowolony z wiedzy jaką stąd wyniosłem. Czy Ty także uczestniczyłeś w tej konferencji? Jakie są Twoje odczucia? Może masz do polecenia jakieś inne wydarzenie? Podziel się tym w komentarzu lub napisz do mnie maila 📧.