3 kroki do tyłu, 2 lata w przód

Czyli o architekcie co wrócił do programowania,
dołączył do projektu open-source PrestoSQL Trino i przeżył

Transcript

1. 3 kroki do tyłu, 2 lata w przód o architekcie co wrócił do programowania, dołączył do projektu open-source PrestoSQL Trino i przeżył Mateusz Gajewski 🤍 Confitura 2022
2. Kim jestem? • W IT spędziłem większą część życia 👴 • Byłem: • programistą, • incident managerem, • (chief) architektem, • tech leadem, • konsultantem, • szkoleniowcem, • @wendigo na Twitterze i Githubie 2
3. Agenda • Dlaczego wróciłem do programowania, • Czym jest open-source Trino i jak powstało, • 18 lekcji z 2 lat pracy w projekcie: • czego dowiedziałem się o sobie wracając do programowania, • jak wygląda praca w środowisku open-source, • jak programuje się w projekcie czysto technologicznym • Czy było warto i co dalej? • Q&A 3
4. Powrót do przyszłości • Po 15 latach w branży miałem dosyć: • powtarzalności problemów, • hype’u na technologie, • odkrywania koła na nowo, • procesów zamiast działającego oprogramowania, • nadmiaru komunikacji i polityki, • braku zauważalnych efektów swojej pracy. • Szukałem: • frajdy i satysfakcji z tworzenia, • rozwiązywania nietrywialnych problemów, • poczucia, że mam na coś wpływ, • merytoryki a nie retoryki. 4
5. 5 JPA Spring Hibernate Microservices Reactive Groovy
7. Trino (dawniej PrestoSQL) 7 Wysokowydajny silnik zapytań Federacja dostępu do danych Wsparcie dla dowolnej infrastruktury Szeroki zakres zastosowań Aktywne i różnorodne community Otwarty kod źródłowy
8. 2012 Powstaje PrestoDB 2013 Facebook opensourcuje PrestoDB 2014 Teradata oferuje wsparcie Presto 2017 Założenie Starburst Data 2018 Powstaje PrestoSQL 2019 Powstaje Presto Software Foundation 2020 Facebook zastrzega Presto 2021 Rebranding na Trino
9. Powrót do programowania jak przeżyć trudne początki 9
10. Lekcja nr 1 Nie potrafię programować :) 10
11. Nie potrafię programować • Każda nieużywana umiejętność zanika, • Każdy projekt ma inną specyfikę, • Różne segmenty IT wymagają innych umiejętności i wiedzy, • Teoria a praktyka to dwa różne światy. Rozwiązanie: być cierpliwym i otwartym na zweryfikowanie przyzwyczajeń, przekonań i doświadczeń. 11
12. Lekcja nr 2 Publiczne code review musi boleć 12
14. 14 5 — Polecam! ⭐ ⭐ ⭐ ⭐ ⭐ Mateusz Gajewski fakty praktyki know -how rady
15. Lekcja nr 3 Czytanie cudzego kodu jest super 15
16. Czytanie cudzego kodu 16 Pozwala poznać: • architekturę kodu, • sposób rozwiązywania problemów, • nazewnictwo, konwencje, niepisane reguły, • sposób i styl review maintainer-ów, • kierunek rozwoju projektu, • kto za co odpowiada. Pro hint: czytając cudzy kod nie musimy w całości rozumieć szczegółów implementacyjnych.
17. Lekcja nr 4 Praca zdalna/asynchroniczna jest trudna 17
18. Praca zdalna 18 • Różnorodne community —> różne style komunikacji i poziomy znajomości języka, • Wiele stref czasowych —> mniejsza dostępność, dłuższe code review, • Dłuższy onboarding —> poznanie projektu zajmuje więcej czasu, Dlatego: • Więcej cierpliwości i zrozumienia dla siebie i innych, • Warto pracować nad kilkoma zagadnieniami równocześnie, • Jasne komunikowanie oczekiwań podczas Code Review, np. w Trino: • nit (nitpicking): czepiam się, ale zrób jak uważasz, • change requested: uważam, że to powinno być zmienione, • AC (awaiting comments): zaadresowałem komentarze, czekam na kolejne.
19. Lekcja nr 5 asynchroniczne Programowanie piekielnie .trudne jest 19
20. Programowanie asynchroniczne 20 Wyzwania: • Współbieżny dostęp do pamięci, • Sekcje krytyczne, deadlocki, false sharing, • Poprawne propagowanie błędów, timeout’ów, przerwań wątków, • Współbieżne ładowanie klas i Thread.setContextClassLoader Co może pomóc: • Nazewnictwo threadów i odpowiednie logowanie, • Właściwe abstrakcje: maszyny stanowe, dobrodziejstwa java.util.concurrent, • Obsługa wyjątków jak InterruptedException, ExecutionException, TimeoutException itp, • Niemutowalne struktury danych, • Programowanie defensywne, • Choreografia zamiast orkiestracji.
21. Lekcja nr 6 Dokumentacji nie można ufać 21
22. Dokumentacji nie można ufać 22 Przyczyny: • Zależności i systemy z których korzystamy zawierają błędy, • Dokumentacja nie opisuje faktycznego działania kodu, • Istnieje sfera “niezdefiniowanych zachowań” o której dokumentacja milczy. Jak sobie z tym radzić: • Debuggowanie, • Techniki reverse engineeringu, • Weryfikowanie u źródła w kodzie bibliotek, • Duża doza sceptycyzmu (sprawdzam!).
23. Budowanie społeczności obowiązki w projekcie OSS 23
24. Lekcja nr 7 Zadbaj o niski próg wejścia 24
25. Niski próg wejścia 25 Cel: postawienie pierwszych kroków w projekcie nie wymaga doświadczenia. • README dla programisty zawierające: • wymagania, np. wersja Javy czy Dockera, • jak uruchomić aplikację i testy, • konwencje i zasady dla kontrybucji, • znane problemy i workaroundy dla nich, • Self-contained zależności i tooling (gradlew, mvnw), • Bezproblemowy import do IDE, • Szybka i powtarzalna kompilacja, • Raportowanie w CI
26. Lekcja nr 8 Wykorzystaj sprzężenie zwrotne 26
27. Sprzężenie zwrotne 27 Cel: Kiedy zmieniam kod, chcę widzieć natychmiastowy rezultat. Chcę: • Uruchomić projekt z IDE, • Testować i debuggować zmieniany kod, • Zmieniać konfigurację uruchomieniową, • Wchodzić w interakcję z systemem poprzez klienta/UI, • Móc zrobić “prawdziwe” demo, • Otrzymać feedback na code review, • Mieć satysfakcję z tego co zrobiłem :)
28. Lekcja nr 9 Sprzątaj przy każdej okazji 28
29. Housekeeping 29 Wiele nazw: • Refactor Mercilessly (XP), • Zasada skauta, • Syndrom wybitej szyby, • Spłacanie długu technicznego itp, W praktyce: • Sprzątaj kod przy każdej okazji, • Wydzielaj niezależne poprawki do osobnych PR, • Często podbijaj wersje zależności, • Rejestruj dług techniczny (@TODO)
30. Lekcja nr 10 Zarządzaj powierzchnią produktu 30
31. Powierzchnia produktu 31 Wszystko to, co jest publiczne i widoczne dla użytkownika: • API/SPI, • interfejs użytkownika UI, • biblioteki klienckie, • konfiguracja (flagi, argumenty do komend, pliki konfiguracyjne), • narzędzia klienckie, • artefakty (archiwa, instalatory, obrazy dockera, dokumentacja). Pułapki: • Zachowanie kompatybilności wstecznej, • Zwiększając powierzchnię produktu, zwiększamy koszt utrzymania i zmiany, • Usunąć/zmienić istniejącą funkcjonalność jest trudniej niż dodać nową.
32. Lekcja nr 11 Ewangelizuj społeczność 32
33. Wizja projektu 33 Krótkoterminowe cele taktyczne Długoterminowe cele strategiczne Wizja biznesowa Wizja technologiczna
34. Lekcja nr 12 Angażuj kontrybutorów 34
35. Różne zadania 35 “Good first issue” • bieżące utrzymanie projektu, • pozyskanie kontrybutorów, • onboarding i budowanie wiedzy “Enhancement”, “idea”, “bug” • rozwój projektu short-mid-term. • zaangażowanie kontrybutorów, • budowanie wiedzy eksperckiej “Roadmap” • rozwój projektu long-term, • budowanie fundamentów dla innych, • definiowanie wizji projektu Dla każdego, coś miłego :)
36. Programowanie w Trino jak ugryźć projekt technologiczny 36
37. Lekcja nr 13 Pilnuj granic 37
38. Pilnowanie granic 38 Cel: Spójność intencji z rzeczywistością. Pilnuj granic: • Commitów, • Pull requestów, • Pojęć i nazw, • Abstrakcji, • Kontraktów (SPI/API), • Modułów.
39. Lekcja nr 14 Programuj defensywnie 39
40. Programowanie defensywne 40 Cel: Nie unikniemy wszystkich błędów, ale istnieje szansa, że unikniemy tych najgroźniejszych (silent correctness issues). Stosujemy: • Zero zaufania dla danych wejściowych, • Sprawdzanie argumentów wywołań, • Testowanie inwariantów, • Sprawdzanie nullability, • Świadoma obsługa wyjątków, • Testowanie przypadków brzegowych, • Niemutowalne kopie danych
41. Lekcja nr 15 You Ain’t Gonna Need It 41
42. YAGNI 42 Cel: Im zmiana jest mniejsza, tym lepiej. Unikamy: • Zbędnych warstw abstrakcji, • Niepotrzebnych refaktoryzacji i uspójniania, • Interfejsów i klas abstrakcyjnych z jedną implementacją, • Nadmiarowych, nieużywanych extension pointów, • Zbędnych zależności, • Dependency hell. Rozsądek przede wszystkim.
43. Lekcja nr 16 Keep It Simple Synu 43
44. KISS 44 złożoność problemu złożoność implementacji WTF? może istnieje już rozwiązanie? serio? yeah! Cel: Optymalizujemy pod długoterminowy rozwój, utrzymanie i czytelność kodu. Preferujemy kod sprytny (ang. clever) niż mądry (ang. smart)
45. Lekcja nr 17 Przygotuj się na trudne zagadnienia 45
46. Trudne zagadnienia 46 W Trino to dopiero rozgrzewka: • Strony kodowe, np. UTF8/16/32, • Obsługa wielu stref czasowych, • Zarządzanie pamięcią i operacje bitowe na danych, • Wektoryzacja i batchowanie operacji, • Kryptografia i szyfrowanie danych, • System typów i typy parametryczne, • Kompresja, indeksowanie i kodowanie danych, • Generowanie i instrumentacja bytecode’u w locie.
47. Ostatnia lekcja “Miej odwagę, by odnaleźć swoje rozwiązanie” Mateusz Gajewski 47
48. Względne wszystko jest 48 To tylko początek drogi: • Nie bój się myśleć inaczej, • Korzystaj z doświadczenia innych, • Wytyczne i praktyki to nie reguły, • Coś co działało wczoraj, nie musi zadziałać dzisiaj, • Nie (de) optymalizuj przedwcześnie, • Nie przywiązuj się do tego co tworzysz, • Patrz daleko poza horyzont.
49. Było warto? 49
50. Najlepsza decyzja! 50
51. Co dalej? Frajda i chwała! 51 • Przejście na JDK 17, • Dynamiczne zarządzanie katalogami, • Wektorowe przetwarzanie danych, • HA przetwarzania wsadowego, • Zaawansowany SQL, • I trochę niespodzianek będących w R&D :)
52. 52 https://bit.ly/starburst-emea
53. Dziękuję! Mateusz Gajewski 🤍 Confitura 2022