Błażej Abel, Tomasz Ślązok - Czego się nauczyliśmy budując jeden produkt przez 11 lat 25.06.2022 - phpers summit - Poznań

1. Poznań, 25 Czerwca 2022
Czego się nauczyliśmy budując jeden
produkt przez 11 lat

2. Dawno, dawno temu…
2

3. Hello world (2011)
3

4. Bootstrapping
4

5. 5
Planujemy Legacy

6. 6
Dzida :)

7. 7
Tak, mamy inwestorów…

8. Killer feature
8

9. Generyczna domena
9

10. 10
Geopolityka

11. 11
Appsumo Deal

12. Cena popularności

13. Podążanie za trendami
13

14. Dzień dobry, z tej strony Jakub
Jaśkiewicz z mBanku..
Proszę Pana, na prawdę nie
potrzebuję żadnego kredytu.
Duzi klienci

15. Polska to trudny rynek
15

16. Polska to trudny rynek
16
Polska Świat

17. Aktualizacja vendorów
17
Przechodziliśmy przez migracje wielu frameworków. W zespole należy na stałe
zarezerwować czas na upgrade vendorów.
Decyzje które okazywały się dobre z perspektywy danego roku, po 10 latach nie zawsze
już takie są.

18. 18
Knowledge Base
Ludzie będą przychodzić i odchodzić. Zamiast
budować wiedzę ekspercką wśród kolegów
i koleżanek, należy ją zapisywać w projekcie
(git, wiki).
Nie tylko ułatwia to onboarding ale także powrót
i zrozumienie decyzji z wielu lat wstecz.

19. 19
Developer Productivity
-
DORA Metrics
Najważniejsze metryki to Lead Time oraz
Deployment Frequency
Deployment frequency to bicie serca zespołu
• Feature
fl
ags
• CD (w 100% automatyczny)
• Odpowiedni poziom testów automatycznych
• No-blame culture (fuckupy beda sie zdarzać)
Praktyki:

20. 20
Developer Productivity
-
Trunk Based Development
Tylko TBD zapewnia pełny Continuous Integration
• Commity do mastera minimum raz dziennie
• Code review (pair programming, stacked commits)
• PR to nie miejsce na dyskusje o designie
• Mindset Done better than perfect

21. 21
Developer Productivity
-
Monolit
-
Monorepo
Monolith jest najlepszym rozwiązaniem na
początku prac nad produktem, lepiej mieć źle
napisany jeden monolit niż dziesiątki złych
mikroserwisów.
Na późniejszym etapie monorepo (mikroserwisy)
jest bardzo dobrym rozwiązaniem.

22. 22
Developer Productivity
-
Deep Work
Należy optymalizować Deep Work w zespole bo
jest on bardzo kosztowny. Zbyt częste spotkania
niszczą produktywność w zespole.
Daily może być w formie asynchronicznej (praca
zdalna)

23. 23
Developer Productivity
-
KISS
Jeżeli zrealizowanie jakiegoś projektu jest
skomplikowane to należy pogadać z managerem
technicznym / architektem / cto aby uprościć
podejście bo pewnie osoba która zlecała nie
wiedziała o tych komplikacjach.

24. 24
Różna architektura do różnych projektów

25. 25
Why, Why, Why, Why, Why
Biznes często nie posiada gotowych odpowiedzi i
są to hipotezy jak coś może działać, dlatego trzeba
dopytywać o wszystko.
Jeżeli biznes zaczyna mówić o rozwiązaniach /
technikaliach zamiast problemie to wiedz że jesteś
w czarnej $^*&@

26. 26
Scrum or not to scrum
Scrum się sprawdza gdy zespół
Jeżeli tak zwany toil dochodzi do 50%
czasu to lepiej pomyśleć o Kanbanie
• ma jasny cel a nie roadmape
fi
czerów
• jest wstanie dostarczyć przyrost
biznesowy co każdy sprintu
• wymaga współpracy różnych osób
• rzadko zajmuje się wrzutkami

27. 27
Vendor Lockin
-
AWS
Nie taki straszny i pozwala na:
• zwiększenie skalowalności usług (Aurora)
• zwiększenie bezpieczeństwa
• uproszczenie stacku technologicznego
• skrócenie time to market

28. 28
Support Domain
>
Core Domain
(
?
)
Gdy sam produkt nie ma rozbudowanej logiki to
supportowe domeny bywają równie interesujące:
• DDoS protection
• Spam protection
• Abuse handling
• SSL provisioning
• Global Infrastructure