Inna definicja refaktoryzacji
Refaktoryzacja to nic innego jak sposób i technika aby zachować równowagę umożliwiającą kontynuację wszystkich działań. Ale jaka to równowaga? Emocjonalna? Z pewnością także, bo przecież jest nam łatwiej kiedy kod który piszemy jest czytelny, testowalny. Jest nam bardziej komfortowo także kiedy kod jest czysty, rozszerzalny i działa zgodnie z wymaganiami biznesowymi.
Produkcja a zdolność produkcyjna
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.Produkcja to ilość pieniędzy którą DZISIAJ zarabiamy poprzez dostarczanie klientom wartości biznesowej. “PC” (production capability) symbolizuje zdolność produkcyjną, czyli to czy JUTRO nadal będziemy w stanie wartość biznesową dostarczać. A jutro mogą się pojawić nowe wymagania lub zmiany w istniejącej funkjonalności. Może się pojawić konieczność 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.
Co będzie kiedy liczy się tylko jakość biznesowa?
To najczęstszy przypadek, z reguły będący pochodną wartości w firmie, że “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 oraz zmieniać te już istniejące. Szybka poprawa znalezionych w oprogramowaniu błędów stanie się niemożliwa.
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ę. Po chwili stwierdzą że szkoda ich nerwów. Ostatecznie konkurencyjne firmy które dbały o jakość będą długotermonowo szybsze i bardziej skuteczne w dostarczaniu konkurencyjnego produktu.
A co kiedy liczy się tylko jakość techniczna?
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ć.
To może równowaga?
Napiszę więc z odpowiedzialnością : chociaż jakość kodu 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 jest więc 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ę w zależności od sytuacji.
Czasem potrzebujemy dostarczyć produkt szybko aby zacząć zarabiać pieniądze i z ich wykorzystaniem aby następnie zadbać 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.
Zadanie domowe
Czy kiedykolwiek zastanawialiście się nad tym ile równowagi może dać refaktoryzacja?
- przy rozwoju produktu?
- dla naszego zdrowia i spokoju?
- przy planowaniu i estymowaniu zmian w kodzie?
- I ostatecznie dla firmy w której pracujecie?
Ale dlaczego umieściłem firmę na końcu powyższej listy?
