Standardowy kłopot z refaktoryzacją: my chcemy, a z góry leci głośnie NIE! Łaj? W moim odczuciu są dwie główne przyczyny. Pierwsza wynika z definicji. Skoro refaktoryzacja, to "ulepszenie wewnętrznej struktury oprogramowania, bez zmiany jego funkcjonalności", to skoro nie dodaje funkcjonalności, a zatem nie dodaje wartości biznesowej, a zatem nie pozwala efektywniej zarabiać, a zatem nie warto jej wykonywać. Podsumowując - kasa.
Drugi problem jest związany z przekonaniem, że jak już refaktoryzować, to rewolucyjnie i musi to zająć mnóstwo czasu. Skoro czasu to i pieniędzy. Za drogo i nie warto tego robić. Znów kasa. Nie zbłądzę zbytnio, gdy stwierdzę, że tarcia o refaktoryzację obijają się o pieniądze.

Kłopot z metaforami

Aby zdobyć choć trochę posłuchu u biznesu community wykombinowało jak na razie dwie metafory: Długu technicznego oraz (najświeższa) Niezabezpiecznonej opcji typu call.
Gdy się w nie wczytać, to każda z nich mówi mniej więcej coś takiego: Pamiętaj biznes-ludku, że jak nie będziemy refaktoryzować, to stanie się COŚ strasznego!. Obie metafory odwołują się do rzeczy, która jak nam się zdaje, najlepiej do biznesu przemówi, czyli do pieniędzy.

Dług techniczny mówi: zabraniając refaktoryzacji zaciągasz duże zobowiązanie, w kolejnym wydaniu rollujesz ten dług kolejnym długiem, i kolejnym, i kolejnym. W końcu zbankrutujesz i klops.
Niezabezpieczona opcja call mówi: nie pozwoliłeś na refaktoryzację, nabyłeś najbardziej ryzykowny instrument finansowy we Wszechświecie. Jedyne co możesz robić, to się modlić.

Skoro te metafory tak dokładnie wyłuszczają konsekwencje zaniedbywania jakości kodu, to dlaczego nic się nie zmienia? Nieco światła rzuca na to psychologia społeczna, wg której bardziej preferujemy natychmiastową gratyfikację niż długoterminowe korzyści oraz bardziej obawiamy się nieprzyjemności bliższych i namacalnych niż odległych i nieco abstrakcyjnych.

Podsumowując, twierdzę, że obojętność na prorefaktoryzacyjne błagania ma następujące przyczyny
  • korzyść z refaktoryzacji jest zbyt odroczona w czasie
  • korzyść z refaktoryzacji bardzo trudno wykazać jest w pieniądzach
  • zaniedbanie refaktoryzacji ma negatywne skutki w bliżej nieokreślonym kiedyś; a dopóki programiści mogą ratować projekt, to go ratują; czasem bardzo długo
  • robienie tak, "aby działało" ma szybkie odczuwalne korzyści
Powyższe fakty sprawiają, że na refaktoryzację przychodzi zgoda, gdy już w zasadzie jest za późno. I wtedy to już na prawdę jest od cholery roboty.

Lokata długoterminowa

Dobitna metafora dla refaktoryzacji powinna charakteryzować się następującymi cechami:
  • korzyści można łatwo wyrazić w pieniądzach
  • korzyści finansowe są szybko odczuwalne, powiedzmy w perspektywie tego samego albo najbliższego wydania
Zauważmy, że jest to metafora pozytywna. Dług techniczny oraz opcja call były metaforami negatywnymi w takim sensie, że straszyły tym, co złego się wydarzy jeśli nie będziesz grzeczny. Nasza nowa metafora jest sformułowana pozytywnie, bo pokazuje korzyści jakie uzyskasz, gdy będziesz się dobrze sprawować.

Szukałem tego typu metafory również w świecie finansów (no, bo dlaczego nie?) i znalazłem ja w postaci lokaty długoterminowej. Korzystając z tej metafory można w stronę Biznesu perorować, że:
  • refaktoryzacja jest jak wpłata pieniędzy na lokatę, już po pierwszym okresie rozliczeniowym następuje kapitalizacja odsetek i otrzymujesz swój procent
  • im dłużej oszczędzasz tym więcej zyskujesz
  • żeby osiągnąć maksymalną korzyść musisz wpłacać regularnie
  • jeśli zerwiesz lokatę, właściwie tracisz większość zarobku
  • no i w przypadku refaktoryzacji nie ma podatku Belki:), same korzyści!

A jak pokazać korzyści finansowe?

Tu popuszczam trochę wodze fantazji. Można spokojnie założyć, że na refaktoryzacyjnej lokacie odsetki procentują razem z początkowym kapitałem. Weźmy sobie zatem wzorek:
gdzie: V - obecna wartość, V0 - początkowy kapitał, r - stopa procentowa, n - liczba okresów rozliczeniowych.

No, to teraz spróbujmy zinterpretować wzór w kontekście refaktoryzacji. Vx - liczmy dalej w pieniądzach, n - liczba iteracji, a r? Skoro finansowo odpowiada to zyskowności (potencjałowi wzrostu kapitału?), to co jest tego odpowiednikiem w projekcie? Mam feeling, że coś z jakością kodu, ale nie bardzo wiem co.

.