Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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ł

7f1dfa02fd3771699d5bac40fc54a21c?s=128

Mateusz Gajewski

June 25, 2022
Tweet

More Decks by Mateusz Gajewski

Other Decks in Programming

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

  6. 6

  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

  13. 13

  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