Refactoring - Jak pozostać przy zdrowych zmysłach, redukując dług
0 likes44 views
Pracowałem przy wielu projektach, które to miały specyfikę totalnie zadłużonych. W prezentacji podzielę się 14 latami moich doświadczeń i zmagań z długiem technicznym w projektach small & medium business. Odpowiem jak my sami się godzimy na wprowadzenie długu technicznego do projektu. Opowiem jak go trzymać w ryzach i monitorować. Dam przykłady narzędzi do monitorowania miejsc w kodzie, które są potencjalnymi nosicielami długu technicznego. Podam gotowy przepis jak wprowadzić do work-flow walkę z długiem technicznym.
Refactoring - Jak pozostać przy zdrowych zmysłach, redukując dług
- 1. Wyobraź sobie, że masz na imię Mirek i kupujesz pięknego Passata B5
- 2. Prestiż, blichtr i splendor.
- 4. Turbo i wtryski do wymiany, ale może pojeździ. Potem się będę martwić
- 5. Mirek nagle musi spłacić dług, który zaciągnęli poprzedni właściciele jego samochodu.
- 6. Cześć! Ja jestem Max i Opowiem wam dzisiaj o: długu technicznym
- 7. Refactoring. Jak pozostać przy zdrowych zmysłach, redukując dług? Max Małecki - PHPers Summit 2022
- 9. 9 Czy do grzebania w serwisie napisanym przez Grześka zakładasz latexowe rękawiczki?
- 10. 10 Ile razy P.O. obciął ci czas na funkcjonalność bez redukcji zakresu?
- 11. 11 Czy twoje estymacje zawsze są zbyt optymistyczne?
- 12. 12 To znak, że twój projekt może być Zadłużony. Zadłużony technicznie.
- 13. 13 Czym jest dług techniczny?
- 14. 14 Czym jest ten dług? Dla Mirka? Dla programisty? Dla projektu? Dla firmy? Kosztem remontu silnika. Stratą czasu, frustracją. Kolejnymi opóźnieniami. Stratą pieniędzy.
- 15. 15 Dług zawsze rośnie wraz z rozrostem złożoności code-base projektu.
- 17. 17 To wynik odwiecznego kompromisu między jakością a delivery
- 18. 18 Wynika to z praw Prawa ewolucji oprogramowania M. Lehmana ● Continuing Change A program that is used and that as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful. ● Increasing Complexity As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it. M. Lehman: „Programs, Life Cycles, and Laws of Software Evolution”. PROCEEDINGS OF THE IEEE, VOL. 68, NO. 9 , SEPTEMBER 1980
- 19. 19 Proces powstawania oprogramowania długu. ● Dług można zaciągnąć na każdym z sześciu etapów, ● Od złego planowania, ● Poprzez kiepską analizę, ● Z której to wynika zły design, ● Źle zaprojektowane rozwiązanie, nie może być dobrze zakodowane ● Testy możemy zrobić później, ● A utrzymując system łatamy tylko objawy nie szukając źródła problemu.
- 20. 20 Czym grozi niepanowanie nad długiem? ● Więcej bugów – rosną koszty utrzymania aplikacji. ● Trudniej dodać nowe funkcjonalności, żeby nie rozsypać produkcji – rosną koszty wdrożenia nowych funkcjonalności. ● Estymacje nie pokrywają się z rzeczywistością. ● Spada uptime aplikacji – klient nie zarabia, a Ty po nocach usuwasz awarie bo SLA i kary umowne! ● Osiągniecie Masy Krytycznej Długu. „Projekt zaorać. Przepisujemy go w nowej technologii x”
- 21. 21 Aż w końcu:
- 23. 23 Można przedstawić skalę długu jako liczbę godzin/lat potrzebną na zlikwidowanie go. Tak.
- 24. 24 Ale bez kontekstu fakt, że masz 1000 godzin długu do spłaty nie znaczy zupełnie Nic.
- 27. 27 Ale co właściwie refaktoryzować?! O tym za chwilę.
- 28. 28 Do refaktoringu należy zaplanować fragmenty kodu które:
- 29. 29 Low Cohesion Zajmują się wieloma rzeczami naraz.
- 30. 30 KISS Są niezrozumiałe lub nazbyt zawiłe.
- 31. 31 Risky Code Często pojawiaja się w nich bugi
- 32. 32 CODE SMELLS – np. naruszające SOLID
- 33. 33 Code Smells The Bloaters The Object- Orientation Abusers The Change Preventers The Dispensables The Couplers Large method Refused bequest Code scattering Duplicated code Inappropriate intimacy Large class Parallel Hierarchy Lazy class Feature envy Long parameters list Dead code
- 34. 34 Cyclomatic Complexity Najtrudniejsze w zrozumieniu, gdzie dług kosztuje najwięcej
- 35. 35 High Coupling Jeżeli nie da się napisać testu do fragmentu kodu. Wiedz że coś się dzieje.
- 37. 37 Ekstra lista potencjalnych dłużników: ● Braki w dokumentacji ● Braki w testach ● Nieaktualne vendory ● Trzymanie się kurczowo niewspieranych już vendorów ● Hotfixy późną nocą – bez planu na zrobienie tego dobrze
- 38. 38 Nie da się tego jakoś zautomatyzować?
- 39. 39 Pewnie, że się da. ● Darmowe: – SonarQube – PHPMD - PHP Mess Detector – j6s/phparch – PHP_CodeSniffer – PHP CS Fixer – PHPStan – Psalm – PHPUnit – CRAP mode ● Płatne – Scrutinizer – SymfonyInsight
- 40. 40 Ale biznes nie da mi budżetu na ogarnięcie całego długu!
- 41. 41
- 43. 43 Walcz z długiem tam, gdzie on kosztuje najwięcej.
- 44. 44 Ale jak policzyć co kosztuje najwięcej?
- 45. 45 Znajdź hotspoty w kodzie Hotspot to fragment kodu, który: ● jest najczęściej zmieniany (zwłaszcza przez wielu autorów) ● oraz ma najwyższą złożoność cyklometryczną. Adam Thornhill: „Prioritizing Technical Debt as if Time and Money Matters” Goto; conference 2020
- 46. 46 Wielu developerów musiało stracić masę czasu żeby zrozumieć, o co biega w złożonym kodzie.
- 47. 47 Liczba zmian może być spowodowana fixowaniem bugów, które się tam pojawiły
- 48. 48 Czerwona flaga. Idealny kandydat do refactoringu
- 49. 49 Narzędzia do lokalizacji hotspotów ● codescene.io – Płatny Kombajn do analizy repozytoriów
- 50. 50 Narzędzia do lokalizacji hotspotów ● https://github.com/ adamtornhill/code-maat ● Można odpalić prosto z .jar ● Analizuje commit log z repozytorium ● Wyznacza najczęściej edytowane pliki ● Generuje raport ● Licencja GNU
- 51. 51 Odważna teza: „Dług w stabilnym kodzie jest dopuszczalny, gdyż nie wpływa on bezpośrednio na podniesienie kosztu wprowadzania nowych funkcjolanlości w projekcie.” Work smart, not hard.
- 52. 52 Kod niezmieniany od roku, można spokojnie traktować jako kod stabilny. Dług zawarty w nim nie wpływu na koszt utrzymania projektu Adam Tornhill „Software Design X-Rays - Fix Technical Debt with Behavioral Code Analysis”
- 53. 53 Wygaszanie jedynie hotspotów, realnie wpływa na obniżenie kosztu utrzymania projektu przez refaktoring.
- 55. 55
- 57. 57
- 58. 58 Jak wygląda u Ciebie pokrycie testami? To pytanie jest Kluczowe. Ale najpierw jedno zajebiście ważne pytanie:
- 59. 59 Użyjmy Code coverage jako punktu odniesienia do podjęcia decyzji, którą strategię testową wybrać ● Sprawdzamy pokrycie testami całego systemu ● Sprawdzamy pokrycie funkcjonalności, którą będziemy refaktoryzować ● Na poziomie: ● Unit Tests ● Integration Tests ● Functional Tests ● End2End Tests ● Contract Tests
- 60. 60 Scenariusz 1. Nie ma testów! – Opcja Minimum Effort Maximum Value: 1) Wybieramy najgorętszy hotspot, 2) Tworzymy Test Charakteryzujący (Characterization Test) 3) Refaktoryzujemy wyłącznie pokryty testem fragment. 4) Testy przechodzą? 5) Commit & Push 6) Następny hotspot Approves!
- 61. 61 Scenariusz 2: Jakieś tam testy ale im nie ufam ● Patrz scenariusz: Nie ma testów.
- 62. 62 Scenariusz 3: Są jakieś testy CC <50% ● Wybierz hotspot, ● Zrób analizę testów, czy pokrywają ścieżki krytyczne. ● Zepsuj coś celowo, zobacz czy testy są wiarygodne. ● Jak już masz jakieś tam zaufanie do testów. ● Napisz własny test do funkcjonalności, którą zamierzasz refaktoryzować. Jeżeli już są testy napisz je od nowa. ● Refaktoryzuj
- 63. 63 Scenariusz 4: Ufam testom pokrycie >75%
- 66. 66 Masz test charakteryzujący. Odpal go z włączonym profilerem.
- 67. 67 Benchmark ● Punkt odniesienia wydajności fragmentu kodu. ● Sprawdzenie czy nasz refactor nie zepsuje wydajności aplikacji. ● Pozwoli na wykrycie przedwczesnej optymalizacji. ● Gwarantuje lepsze zrozumienie kodu i celowości jego wcześniejszej optymalizacji.
- 68. 68 Reasumując. 1. 2. 3. 4. 5. 6. Test Benchmark Refactor Re-Test Benchmark Success!
- 69. 69 Czy to już?
- 71. 71 Jak refaktoryzować już wiecie. Przynajmniej Ci co byli u Leszka i Szymona wczoraj na warsztatach
- 72. 72 Jak utrzymać dług pod kontrolą? Zmień proces Krzysiu.
- 73. 73 Dodaj do procesu CI/CD analizę statyczną
- 74. 74 Dodaj do pocesu CI/CD benchmark wydajności
- 75. 75 Dodaj krok z analizą ich wyników do Code Review
- 76. 76 Cyklicznie analizuj hotspoty. Twórz tickety. Priorytetyzuj.
- 77. 77 Zaplanuj refactor. Konsekwentnie go realizuj.
- 78. 78 Refaktoryzuj tylko tam gdzie to konieczne i praktyczne
- 79. 79 Zakładaj tickety jak napotkasz miejsca w kodzie, które proszą się o refactor i eskaluj na planowaniu.
- 80. 80 Dziel zadania na max jeden dzień roboczy
- 81. 81 Zrozum kod!
- 82. 82 Testuj jednosktowo zawsze, integracyjnie i e2e przy releasie
- 83. 83 Jeżeli robisz hotfix na produkcji nocą. Dodaj ticket by naprawić przyczynę.
- 84. 84 Skup się przy Code Review, nie akceptuj wszystkiego jak leci
- 85. 85 Skup się na jednym. Skończ, a potem wydaj
- 86. 86 Nie ma negocjacji przy estymacji czasowej („biznesy” chcą szybciej to muszą dostać mniej).
- 87. 87 A co powiedzieć mojemu P.M / P.O?
- 88. 88 Dodaj Epic w Jirze żeby śledzić postępy walki z długiem.
- 89. 89 Zadania z tego Epic’a traktuj jak normalne zadania projektowe (analiza, dekompozycja, estymacja)
- 90. 90 Dodaj timebox w cyklu by systematycznie walczyć z długiem.
- 91. 91 Zmieniaj jego rozmiar w zależności od potrzeb i możliwości
- 92. 92 Dług jest w każdym projekcie, panuj nad nim, a Cię nie ugryzie.
- 93. 93 A twoi developerzy nie będą myśleli, że pracują przy wywozie szamba.
- 94. 94 A co z Mirkiem?
- 95. 95 Dzisiaj Mirek dowiedział się, że: ● w chwili zakupu jego auto było warte jakieś -20 tyś zł ● a dług eksploatacyjny sam się nie rozwiąże.
- 96. 96 Nie bądź jak Mirek. Zapanuj nad długiem technicznym
- 97. 97 Pytania?