Recommandé
Recommandé
Contenu connexe
Similaire à Mity, które blokują Twoją karierę
Similaire à Mity, które blokują Twoją karierę (20)
Plus de Piotr Horzycki
Plus de Piotr Horzycki (9)
Mity, które blokują Twoją karierę
- 1. Mity, które blokują Twoją karierę Piotr Horzycki PHPCon Poland 2022
- 3. Agenda 01 Zły biznes, dobry development 02 Musimy mieć Scruma! 03 Spotkania to strata czasu 04 Pseudoelitarność 05 Wymyślna architektura 06 Wielkie przepisywanie 07 100% code coverage
- 4. Skup się na tym, co daje największe korzyści! Zasada Pareto: 20% czynności daje 80% rezultatów
- 5. Mit #1: Zły biznes, dobry development
- 6. Co myśli development: biznes nie wie, czego chce 🤦 biznes ciągle zmienia priorytety biznes nas nie rozumie Co często myśli biznes: ile to wszystko kosztuje! za rok odejdą i zostawią nas z tym nie rozumiemy, co oni gadają po co ten kolejny "refaktor"?
- 7. Przewidywalność: Sposób na pogodzenie dwóch światów
- 8. Jak pogodzić biznes i development w firmie
- 9. Jak pogodzić biznes i development tech i non-tech w firmie
- 10. Jak pogodzić tech i non-tech LUDZI w firmie development częścią biznesu wymiana informacji (priorytety, release plan) wspólne warsztaty usprawnienie developmentu dobry Product Owner
- 11. Krótki dokument o każdym zespole Cześć! Jesteśmy zespołem XYZ i odpowiadamy za... Pracujemy w cyklach 2-tygodniowych, zaczynamy planningiem w poniedziałki. Opisując zadania, użyj szablonu: ...
- 12. Mit #2: Musimy mieć Scruma!
- 13. Co deweloperzy myślą, że jest ważne story pointy, burndown charts 📉 niezmienne sprinty Scrum w CV
- 14. Co jest ważne? Sprawnie działający zespół!
- 16. 5 dysfunkcji pracy zespołowej Patrick Lencioni, "The Five Dysfunctions of a Team"
- 17. Empiryzm w Scrumie Transparencja ➡️inspekcja ➡️adaptacja CEREMONIE SCRUMOWE REALIZUJĄ TEN CYKL! Planning ➡️daily ➡️review ➡️retro
- 18. Kiedy estymować zadania? Estimation is valuable when it helps you make a significant decision. So whenever you're thinking of asking for an estimate, you should always clarify what decision that estimate is informing. martinfowler.com/bliki/PurposeOfEstimation.html
- 19. Mit #3: Spotkania to strata czasu
- 20. Frustracja spotkaniami "Ok, wracajmy do pracy" "Wystarczyło napisać maila" "Wczoraj nic nie zrobiłem, bo były spotkania"
- 21. Development to praca zespołowa Musicie pracować razem, ale też szanować nawzajem swój czas!
- 22. Sposoby na lepsze spotkania agenda przed spotkaniem czy wszyscy są potrzebni? prawo dwóch nóg moderacja, zmierzanie do celu timeboxing skupienie (np. wyłączamy Slacka) notatki, action points narzędzia (Google Docs, Miro, Notion itp.)
- 24. Przeciętne ogłoszenie o pracę Słynne "wiek 20 lat, 10 lat doświadczenia" Dużo modnych słów kluczowych ✅ "Młody, dynamiczny zespół" Rezultat: impostor syndrome
- 25. Jako kandydat Nie musisz znać wszystkich fancy technologii... ...ale kształć się i rozwijaj, znajdź swoje mocne strony! 💪 Jako rekruter Nie oczekuj od ludzi, że będą znali wszystkie fancy technologie
- 26. Zróżnicowany zespół Potrzebujemy ludzi dobrych w: architekturze zarządzaniu wydajności bezpieczeństwie skalowaniu testowaniu
- 27. Co to daje, gdy szukamy pracy? Większy wybór ofert Nowe możliwości Praca z lepszymi od siebie
- 28. Co to daje firmie? Większy wybór kandydatów Mocne, wszechstronne zespoły Wiele punktów widzenia Lepsze oprogramowanie Szybszy onboarding Niższe koszty
- 32. Problemy 😭 trudne utrzymanie wysokie koszty 💸 brak specjalistów porzucone frameworki joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you
- 33. Nie od razu wielkie systemy zbudowano John Gall Will Larson A complex system that works is invariably found to have evolved from a simple system that worked. Most implemented systems are designed to support one to two orders magnitude of growth from current load.
- 35. Historie nieudanego rewrite'u Martin Fowler, "Refactoring" “The old code had worked just fine. Yes, the design was a bit more "pure", and a bit more "clean." But the project had to ship code that worked, not code that would please an academic. (…) Six months later, the project failed.”
- 36. Strategie pracy z kodem legacy Testy automatyczne Refaktoring małymi krokami ♻️ Proof of Concept Event Storming Fasada Strangler Pattern Anti-Corruption Layer
- 37. Jak wybrać najkorzystniejsze działania? Działanie Koszt Spodziewany zysk Przepisanie koszyka XL M Refaktor rejestracji użytkownika L L Optymalizacja listy produktów M L
- 38. Jak wybrać najkorzystniejsze działania? Działanie Koszt Spodziewany zysk Przepisanie koszyka XL M Refaktor rejestracji użytkownika L L Optymalizacja listy produktów M L
- 39. Co nam to daje spełnienie deadline'ów ochrona istniejącego zachowania systemu efekty małych kroków są szybciej widoczne uniknięcie wypalenia więcej czasu na wartościowe rzeczy
- 40. Kiedy przepisanie systemu jest konieczne? śmierć technologii (np. Adobe Flash) nowy system daje kluczowe możliwości, których stary system nie może dać
- 41. Mit #7: 100% code coverage
- 42. Wybierz dobre metryki Line coverage to narzędzie do wyszukania kodu, który nie ma testów. Nie wystarcza to do oceny jakości testów.
- 44. Piramida testów E2E API integracyjne jednostkowe Jak bardzo ufamy naszym testom?
- 45. Jakość testów Line coverage: 100% 🎉 Branch coverage: 50% 😔 public function foo(bool $flag): void { if ($flag) { doThis(); } doOtherThing(); } public function testFoo(): void { foo(true); }
- 46. Strategia testowania unit testy są najszybsze; E2E wolniejsze i mniej stabilne jeśli nie mamy żadnych testów, to najlepiej zacząć od E2E happy path nie trzeba testować jednostkowo kontrolerów domena biznesowa powinna mieć najlepsze możliwe testy
- 47. Testy mutacyjne Mutation Score Index mówi, jak dokładne są testy / jak łatwo je oszukać infection.github.io
- 48. Podsumowanie Wymieniaj informacje z biznesem; buduj przewidywalność Buduj dobre relacje w zespole Dbaj o jakość spotkań Twórz zróżnicowane zespoły / nie bój się rekrutacji :) Projektuj rozsądną architekturę Refaktoryzuj małymi krokami, jeśli to możliwe Wprowadź jasną strategię testowania