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.

1. Wyobraź sobie, że masz na imię Mirek i
kupujesz pięknego Passata B5

2. Prestiż, blichtr i splendor.

3. Diesel musi dymić!
Jadęęę!

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

8. Szybkie
3 pytania
Gotowi?

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.

16. 16
Skąd pochodzi
dług?

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:

22. 22
Czy dług jest
policzalny?

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.

25. 25
Jak walczyć
z długiem?

26. 26
Refaktoryzować!

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.

36. 36
Co jeszcze śmierdzi
długiem?

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

42. 42
Ogarnąć cały dług?
O’RLY?

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.

54. 54
Refaktoryzować?!
Ja się boje!

55. 55

56. 56
Boisz?
Czy nie chcesz?

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%

64. 64
Mogę już
refaktoryzować?

65. 65
Nie!Stój!
Zapomniałeś o benchmarku.

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ż?

70. 70
Tak Śmiało!
Refaktoryzuj!

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?

98. 98
Twitter: @mgz
Github: @emgiezet