fbpx

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?

Spread the word. Share this post!