W ogóle jestem ciekaw jak walczycie z długiem technicznym w waszych projektach? Macie jakieś fajne systematyczne rozwiązania na to?
Dotąd widziałem kilka nieudanych inicjatyw:
- każdy sprząta po sobie (scout rule) - działa tylko w małej skali i do powierzchownych rzeczy, ludzie unikają większego sprzątania
- superhero big bang refactoring - "ale poryty kod, przepiszę go w weekend", a po 3 miesiącach: "już prawie działa".
- "zaprojektujmy to porządnie" (waterfall?) - dwa tygodnie spotkań, brak konsensusu jak to powinno wyglądać, po czym nikt nie napisał ani linijki kodu przez kolejne lata....
W 2 firmach i 2 większych projektach (wieloletnie) zadziała metoda - nie pogarszamy, czasem lekko poprawiamy. Czyli boy scout rule. Jak już gdzies wchodzisz i dopisujesz ficzór to zobacz czy przy okazji nie możesz lekko nasprzątac dookoła (bez szału). Sporadycznie refaktoringi superhero na zasadzie, jak już widzimy jak zrobić lepiej perzystencje i mamy na to sposób sprawdzony w kilku przypadkach - to jakiś straceniec zamyka się na weekend i kosi projekt (to naprawdę sporadyczne wypadki -2-3 akcje na projekt, dokończenie pełzającego refaktoringu
, migracja na nową javę). W sumie to zaskakujaco szybko widać było efekty (głównie poprawa morale - nagle ktoś się orientuje, że standardowe narzekanie na kod wypadło z tematów przy kawie
).
Ważne, że musi być jakiś konsensus co to znaczy lepszy kod - to nie zawsze jest proste do ustalenia (jakaś wizja gdzie zmierzamy, biblioteki, practices itp).
W obu przypadkach projekt był naprawdę, naprawdę straszny( wizje szalonych architektów połączone z sabotażem w wykonaniu szeregowych koderów), ale generował dużo kasy, więc nie było problemów z budżetem, a biznes nerwowo reagował na hasła quick and dirty
, bo już zdążyli wielokrotnie za takie pomysły zapłacić.
Mam też kilka pomnijeszych projektów, w kórych ugrzęzłem w brudzie, bo albo się nie dogadałem z zespołem co jest dobre
(w dawnych czasach to częste było), albo uwierzyłem biznesowi, że projekt i tak zaraz będzie wyrzucony (daje się na to ciągle złapać - jak dziecko, nawet w ostatnim roku).
EDIT:
Dorabiałem też wizualizacje/ CI oparte o metryki, które pokazywały "czy nie pogarszamy". (Powiedzmy, że bardziej nachalne przezentowanie to co można wyciągnąć z sonara).
Robiłem to dla zabawy, w ramach manipulowania ludźmi i naciąganiu ich na głupawą grywalizację. Działa. Nawet rozdawanie medali działało :-) Nie będe narzekał, pomagało mi to i sam się na takie sztuczki też daję łapać. Chociaż bardzo możliwe, że ta grywalizacja nie odegrała istotnej roli, trudno mi ocenić - byłem autorem tych pomysłów i nie jestem obiektywny.
to generowanie długu technicznego i że albo przeniosą to do prywatnej części A, albo zostawia w ogólnych ale wtedy mają zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność, i dopóki to się nie stanie, to nie ma mergowania.
Jak ktoś zostaje architektem to o nagle doskaje jakiegoś świra na punkcie spójności-homogeniczności (mi tęż kiedyś się zdarzyło). Pamietam jak jeden człowiek w końcu zadał pytanie czy naprawdę chcemy mieć cały projekt zły, ale konsekwentnie - spójnie zły, czy może zrobimy jeden moduł inaczej, ale lepiej...
Wyobraź sobie, że każdy moduł zrobił sobie własną implementację listy łączonej która jest zrealizowana w miejscu użycia ad-hoc na wskaźnikach, tj. nie ma wydzielonego modułu, tylko te listy są takie ogólnie pomieszane z innym kodem - tj. logika biznesowa przepleciona z ustawianiem pointerow next i prev. Zero abstrakcji, 100% porytego kodu.
Czy to jest kod w C pisany przez mamuty? Gdzie się takie cuda jeszcze pisze?