Getting Things Programmed
Download as PPTX, PDF1 like390 views
“Revert” to ostatnia faza rozpaczliwego kodowania pomysłu, który na początku wydawał się najgenialniejszym kawałkiem kodu, jaki kiedykolwiek powstał. Po zakończeniu mojej prezentacji z kilkoma konkretnymi technikami, które pomogą Ci “dokodować” swoje pomysły do końca. Przyjrzymy się między innymi: wyodrębnianiu i dekomponowaniu zadań programistycznych, planowaniu pracy, poszukiwaniu błędów w kodzie i umiejętności skupienia się.
Getting Things Programmed
- 2. @MichalBartyzel • ~500 dni szkoleniowych • 8 projektów doradczych • 80+ klientów • 40+ artykułów • 3+ książki • 3 dzieci
- 3. Co na wynos?
- 4. Co musi umieć developer?
- 8. # OKREŚL PIERWSZĄ CZYNNOŚĆ • Napisz test do CartService.findItem()? • Napisz metodę testową? • Przygotuj dane testowe? • Zamokuj zależności klasy CartSercvice ? • Sprawdź w dokumentacji, jak powinna działać usługa? • Wydrukuj dokumentację usług?
- 9. # Zapisz zanim zakodzisz public boolean peselIsValid(String pesel) { //Czy pesel ma poprawny format? //Oblicz sumę kontrolną peselu //Sprawdź warunek modulo algorytmu pesel } public boolean peselIsValid(String pesel) { if (!isNumber(pesel) || !hasValidLength(pesel)) { return false; } //Oblicz sumę kontrolną peselu //Sprawdź warunek modulo algorytmu pesel }
- 10. # narysuj zanim zaarchitekcisz HelloWorldInterjection interjection = new HelloWorldInterjection(); HelloWorldObject helloWorldObject = new HelloWorldObject(); HelloWorldMediator helloWorldMediator = new HelloWorldMediator(interjection, helloWorldObject); interjection.setHelloWorldMediator(helloWorldMediator); helloWorldObject.setHelloWorldMediator(helloWorldMediator); System.out.println(helloWorldObject.helloWorld());
- 11. # narysuj zanim zaarchitekcisz
- 12. # narysuj zanim zaarchitekcisz
- 13. # narysuj zanim zaarchitekcisz • Pattern-Oriented Software Architecture, Part 4 • Implementing Domain-Driven Desing • Pattern-Oriented Software Architecture, Part 1 • Pattern-Oriented Software Architecture, Part 2 • Pattern-Oriented Software Architecture, Part 3 • Patterns of Enterprise Application Architecture • Reactive Desing Patterns*
- 14. # nazywaj
- 15. # nazywaj
- 16. #Nazywaj LocationManager 26 752 NetworkItem 10 955 TransferOperations 6 871 CalculatorsManager 4 325 MonitorManager 1 514 VTViewInvoker 48 ContactService 47 Address 34 DataRange 21 LoggedUserDetailsModel 13
- 17. # izoluj
- 18. #Izoluj • Zacznij od testu jednego zachowania • Napisz test mniejszego zachowania • Przeczytaj Implementation Patterns
- 19. # pisz elegancko if (!r.IsDataRangeDoNull() && !r.IsDataRangeOdNull() && ((r.DataRangeOd.Day != yearRow.Miesiac.Day && r.DataRangeOd.Day != yearRow.Miesiac.AddMonths(1).Day) || (r.DataRangeDo.Day != yearRow.Miesiac.Day && r.DataRangeDo.Day != yearRow.Miesiac.AddMonths(1).Day))) { //... }
- 20. #ZNAJDUJ CZAS NA RZECZY WAŻNE
- 21. Pilność i ważność (wersja oryginalna) Getting Things Programmed Ważne Planuj Zarządzaj Zajmij się zanim staną się pilne Zajmij się natychmiast Najlepiej osobiście Jest to zadanie typu „pożar” Nieważne Unikaj Ponieważ mają niewielką wartość Deleguj Rutynowe zadania Niepilne Pilne
- 22. 0 m-c 3 m-ce 6 m-cy 9 m-cy Konsekwencje Pilne ? Ważne ? Dług tech. Działania Przykład – refaktoryzacja Getting Things Programmed
- 23. 0 m-c 3 m-ce 6 m-cy 9 m-cy Konsekwencje • Wzrasta metryka CC • Wzrasta metryka LoC • Testowanie jest uciążliwe • Młodsi programiści nabierają złych nawyków Pilne ? Nie Ważne ? Nie Dług tech. Niezauważalny Działania Nic nie robimy Przykład – refaktoryzacja Getting Things Programmed
- 24. 0 m-c 3 m-ce 6 m-cy 9 m-cy Konsekwencje • Wzrasta metryka CC • Wzrasta metryka LoC • Testowanie jest uciążliwe • Młodsi programiści nabierają złych nawyków • Pojawiają się Long Method, GodClass • Spada pokrycie kodu testami • Pojawiają się żarty na temat jakości kodu Pilne ? Nie Nie Ważne ? Nie Nie / Tak Dług tech. Niezauważalny Możliwy ukrycia Działania Nic nie robimy Nic nie robimy Przykład – refaktoryzacja Getting Things Programmed
- 25. 0 m-c 3 m-ce 6 m-cy 9 m-cy Konsekwencje • Wzrasta metryka CC • Wzrasta metryka LoC • Testowanie jest uciążliwe • Młodsi programiści nabierają złych nawyków • Pojawiają się Long Method, GodClass • Spada pokrycie kodu testami • Pojawiają się żarty na temat jakości kodu • Pojawia się BigBullofMud • Zauważane dryfowanie architektury • Pierwsze problemy wydajnościowe • Wzrasta ilość błędów na produkcji Pilne ? Nie Nie Nie Ważne ? Nie Nie / Tak Tak Dług tech. Niezauważalny Możliwy ukrycia Spłata wymaga świadomej inwestycji Działania Nic nie robimy Nic nie robimy Nic nie robimy Przykład – refaktoryzacja Getting Things Programmed
- 26. 0 m-c 3 m-ce 6 m-cy 9 m-cy Konsekwencje • Wzrasta metryka CC • Wzrasta metryka LoC • Testowanie jest uciążliwe • Młodsi programiści nabierają złych nawyków • Pojawiają się Long Method, GodClass • Spada pokrycie kodu testami • Pojawiają się żarty na temat jakości kodu • Pojawia się BigBallOfMud • Zauważane dryfowanie architektury • Pierwsze problemy wydajnościowe • Wzrasta ilość błędów na produkcji • Użytkownicy wyraźnie zauważają spadek wydajności oraz błędu systemu • Eskalacje ze strony biznesu • Konsekwencje finansowe dla sponsora Pilne ? Nie Nie Nie Tak Ważne ? Nie Nie / Tak Tak Tak Dług tech. Niezauważalny Możliwy ukrycia Spłata wymaga świadomej inwestycji Płacz i płać Działania Nic nie robimy Nic nie robimy Nic nie robimy Łatamy na szybko Przykład – refaktoryzacja Getting Things Programmed
- 27. Zajmuj się zadaniami ważnymi zanim staną się pilne Getting Things Programmed
- 28. Pilność i ważność (wersja dla programisty) Getting Things Programmed Ważne Planuj Zajmij się zanim staną się pilne Zajmij się natychmiast Najlepiej osobiście Nieważne Unikaj / Deleguj Krytycznie analizuj zadanie Usprawniaj środowisko pracy Niepilne Pilne
- 29. 8 technik na wynos 1. Kolejkuj zadania 2. Określ pierwszą czynność 3. Zapisz zanim zakodzisz 4. Narysuj zanim zaarchitekcisz 5. Nazywaj 6. Izoluj 7. Pisz elegancko 8. Znajduj czas na rzeczy ważne
- 30. Więcej Technik