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?

Spread the word. Share this post!