Refaktoryzacja to nic innego jak sposób i technika aby zachować równowagę. Ale jaką równowagę? Emocjonalną? Z pewnością także, bo przecież jest nam łatwiej kiedy kod który piszemy jest czytelny, testowalny, rozszerzalny i najprawdopodobniej działa zgodnie z wymaganiami biznesowymi.
Ale najważniejszą równowagą, jaką refaktoryzacja może umożliwić jest równowaga P/PC. LItera “P” z języka angielskiego symbolizuje słowo produkcja, czyli ilość pieniędzy którą DZISIAJ zarabiamy poprzez dostarczanie klientom wartości biznesowej. “PC” (production capability) symbolizuje zdolność produkcyjną, czy to czy JUTRO także będziemy w stanie dostarczać nową wartość biznesową, kiedy przyjdzie potrzeba dostarczenia nowych wymagań, zmiany istniejących oraz szybkiej poprawy błędów znalezionych w działającym oprogramowaniu.
Przyglądnijmy więc się bliżej co się dzieje kiedy powyższa równowaga nie jest zachowana.
To najczęstszy przypadek, z reguły będący pochodną wartości w firmie iż “najważniejszy jest klient”. Niestety bardzo często jest to powiązane z tworzeniem programowania jak najszybciej, na “wygórowane terminy” a więc i z niską jakością. Podejście to chwilowo pozwala zarabiać pieniądze ale dług techniczny zawsze rośnie nieubłaganie. Prędzej czy później (a z reguły dużo wcześniej niż się tego spodziewamy) będzie bardzo trudno dodawać nowe funkcjonalności, zmieniać te już istniejące oraz szybko poprawiać znalezione w oprogramowaniu błędy.
Z powodu pośpiechu stopień złożoności rozwiązań stanie się coraz większy, więc z czasem programiści zaczną szukać nowej pracy. Ci zatrudnieni na ich miejsce popracują chwilę (za prawdopodobnie już większe pieniądze) ale kiedy się zorientują jak wygląda proces tworzenia oprogramowania i stracą nadzieję także po chwili stwierdzą że szkoda ich nerwów. Ostatecznie konkurencyjne firmy które dbały także o jakość będą szybsze i bardziej skuteczne w dostarczaniu konkurencyjnego produktu.
Pisząc tego bloga chcę być uczciwy względem drugiej strony. Co się stanie kiedy jakość będzie się liczyć “za bardzo”? Możemy zakończyć z produktem o bardzo wysokiej jakości technicznej, napisanym zgodnie z wszystkimi standardami takimi jak SOLID, DRY, TDD, KISS, BDD, TDD… (lista zapewne jest długa) ale o niewielkiej wartości biznesowej która nie pozwoli firmie zarobić pieniędzy a więc i przetrwać.
Napiszę więc z odpowiedzialnością : chociaż jakoś jest ważna to może być nigdy celem w samym sobie. Celem programistów jest zarabianie pieniędzy a jakość ma temu pomagać (tylko i aż). Pragmatyzm przede wszystkim!
Gdzie więc jest prawda? Jak zwykle – pośrodku. Obie strony (biznesowa i techniczna) muszą nawzajem sobie ufać, pomagać i współpracować. Każda ze stron powinna pozwolić drugiej stronie na przechylenie powyższej szali w przeciwną stronę.
Czasem potrzebujemy dostarczyć produkt szybko aby zacząć zarabiać pieniądze i z ich wykorzystaniem zadbać następnie o dług techniczny (jak z kredytem w banku). Czasami potrzebujemy poczekać z dostarczaniem nowych funkcjonalności gdyż dług techniczny nam to utrudnia. I wtedy po otrzymaniu nowych wymagań architekci i programiści muszą zadbać o zmianą architektury, pakietów, testów tak aby przygotować projekt i kod pod nowe rozszerzenia.
Czy kiedykolwiek zastanawialiście się nad tym ile równowagi może dać refaktoryzacja?
- Dla waszego rozwoju?
- Dla waszego spokoju?
- Dla waszej rodziny?
- Dla waszego zdrowia?
- I ostatecznie dla firmy w której pracujecie?
