Czytając wpis Michała Bartyzela, „Czysty Kod”, wujka Boba oraz rozważając ostatnie wydarzenia w fabryce dochodzę do wniosku, że głównym wrogiem dobrego, czystego kodu jest biznes. Nie jest to dobrze widoczne ponieważ biznes zawsze będzie mówił językiem marketingu o „najwyższej jakości”, „niezawodności”, „najnowocześniejszych technologiach. Czyli ujmując prościej pierdolenie kotka przy pomocy młotka. Może to kwestia odpowiedniego uodpornienia na reklamę, a może patologiczne postrzeganie biznesu, ale jakoś nigdy to do mnie nie trafiało… Istnieją pewne wskazówki pozwalające na wskazanie biznesu jako głównego podejrzanego w sprawie o psucie kodu.

Jakość biznesowa != jakość

Ta stara prawda odnosi się do wszystkich aspektów rynkowych. Nie tylko IT. Wspominałem ostatnio, że wolny rynek ma tendencję do tworzenia rozwiązań w ramach „planu minimum”. Z punktu widzenia klienta kupującego aplikację oznacza to minimum kosztów, minimum czasu, maksymalne pokrycie wymagań. Dobry handlowiec wie o tym i takie właśnie wymagania przekaże do realizacji programistom. Ci mając na uwadze terminy i specyfikację oraz fakt, że dobry kod w przeciwieństwie do pizzy nie wyżywi czteroosobowej rodziny zaczynają popadać w bylejakość. Inaczej… zaczyna robić szybko i niedokładnie. Zaczyna ignorować zasady, które zna, ale ich zastosowanie wymaga czasu.
W pierwszej kolejności ofiarą jakości biznesowej padają zazwyczaj testy. Kod testów nie wnosi nic do aplikacji. Za kod testów klient zazwyczaj nie płaci i nie ma zamiaru płacić. Zatem jeżeli przygotowanie testów zajmie ci cały dzień, a na ich podstawie kodowanie 2 godziny i porównamy to do sytuacji gdy bez testów przygotujesz działający kod w 6 godzin to zdaniem klienta przepłaca o 4 godziny. Ty masz robić kod aplikacji, a nie testów…
Na drugim miejscu jest dokumentacja. Najlepszy rodzaj dokumentacji to kod samodokumentujący się. Jednak by takie coś było możliwe trzeba przygotować pewną przynajmniej szczątkową dokumentację. Jeżeli nasze API jest zbiorem pewnych pojęć domenowych to do ich zrozumienia i tak potrzebna jest wiedza o tym czym jest domena. Brak takiej wiedzy, którą czerpie się z dokumentacji, będzie owocował konfliktami pojęć pomiędzy elementami systemu, nieporozumieniami pomiędzy programistami i klientami, a w ostateczności nieprawidłowym użyciem API co prowadzi do budowania różnych dziwnych obejść, a te tylko wprowadzają większy burdel.
Trzecie miejsce zajmuje organizacja kodu. Paradoksalnie chcąc przyspieszyć sobie pracę zaczynamy zmieniać organizację kodu w taki sposób by „mieć pod ręką” to co aktualnie potrzebujemy. „Pod ręką” oznacza zazwyczaj w tym samym pliku. Przykładem jest wbijanie w klasy biznesowe obsługi połączeń do bazy danych. Szczególnie widać to w trochę starszych aplikacjach gdzie programiści nie mieli jeszcze do czynienia z ORMami czy frameworkami IoC/DI.

Mamy zatem pierwszą poszlakę. Biznes narzucając sztywne ramy czasowe i oczekując tylko na wynik powoduje, że produkt końcowy ma ładne opakowanie, niezłą funkcjonalność, ale stając wobec problemu wymiana akumulatora zaczynamy być bezradni. Oczywiście sztywne ramy czasowe są nieodzowne, bo inaczej programiści tworzyli by do świętej nigdy, ale niech będą to rozsądne terminy, a nie terminy najtańsze. W ten sposób mamy jakość biznesową. Jakość działa, jakość się nie wysypuje.

Biznes ślepo wierzy w „mądrości ludowe”

Jedna z nich mówi, że „lepiej poprawiać niż przepisywać od nowa”. Jest ona słuszna, ale tylko do pewnego etapu. Załóżmy, że odziedziczyliśmy po wujku starego malucha. Chcemy jednak mieć samochód sportowy. Ferrari najlepiej. Mamy dwie opcje, jeżeli chcemy korzystać z mądrości ludowej, jak nie to jedną. Po pierwsze możemy kupić Ferrari. Nie jest to głupie rozwiązanie, ale kłóci się z mądrością o „poprawianiu, a nie robieniu od nowa”. Zatem wybieramy rozwiązanie drugie, głupie. Kupujemy wiadro czerwonej olejnej, paczkę tazosów i zamykamy się w garażu. Dzielnie przemalowujemy naszego malucha na czerwono, a z paczki tazosów staramy się wyciągnąć tego z kucykiem. Kucyka przykleimy na maskę.
Generalnie mamy Ferrari. Silnik jest? Jest! Koła sztuk cztery są? Są! Kolor czerwony? Wedle rozkazu! Konina ma mace? No ba!!! Zajeżdżamy naszym „Ferrari” do warsztatu, mechanik otwiera maskę tył (o kurwa… nawet silnik jest z tyłu!!!) i …. albo nas wypierdoli z warsztatu, albo jeżeli jest informatykiem to nie chcąc być gorszym od pizzy zacznie grzebać w jakiejś domowej roboty instalacji gazowej.

Poszlaka numer dwa. Biznes zbyt sztywno trzyma się reguł i „złotych myśli” nawet tam gdzie jest to zbyt ryzykowne w porównaniu do pójścia w przeciwnym kierunku.

Biznes olewa zdanie programistów

Wymień trzy największe firmy/inicjatywy IT ostatnich 15 lat. Goolge, Facebook, Nasza Klasa. Co je łączy? Każda z nich jest lub była dowodzona przez informatyków. Gości, którzy wiedzą co to są wzorce projektowe, czym jest test jednostkowy i dlaczego niektóre rzeczy choć wyglądają na biznesowo dobre to w praktyce polegną.
Generalnie pracowałem już w kilku miejscach i mam porównanie. Z szefami-informatykami idzie się dogadać znacznie łatwiej niż biznesmenami dla których komputer to czarna magia.
Tacy ludzie wychodzą z założenia, że programista jest tylko zasobem. Takim samym jak ci Chińczycy, których popędzał batem w poprzedniej firmie gdzie sprzedawał jakieś cichy. W dodatku zasobem łatwo wymienialnym i nie wartym przez to uwagi. Programiści nie robią nic konkretnego (filozoficzny temat – „programista produkuje nic – czyli dlaczego upadł system gospodarczy”), są drodzy w utrzymaniu, a ich praca jest zbyt delikatna i zbyt odpowiedzialna z biznesowego punktu widzenia by mogli ją wykonywać tacy ludzie. Niestety innych nie ma, a zastąpienie programistów tresowanymi małpami też odpada (ekoterroryści). Kilkukrotnie spotkałem się z takim podejściem, że programista nic nie wie. Nie rozumie tego co ma być zrobione i generalnie jest sabotażystą chcącym zniszczyć biznes. Biznes jednak nie łapie, że programista jako z natury leniwy będzie szukał rozwiązań optymalnych, a nie oczywistych.
Przykładem jest pewien program zliczający krotki w bazie danych. Wersja oczywista dla programisty – dwa triggery jeden na insert drugi na delete. Względnie zamiast drugiego procedura usuwająca w przypadku konieczności wycofania transakcji w późniejszym czasie (takie trochę to zagmatwane, bo transakcja biznesowa składa się z kilkudziesięciu kroków – transakcji, a te mają po kilkaset transakcji w sensie RDMS) lub tak jak w moim przypadku w przypadku „przeterminowania” krotki i konieczności jej usunięcia (co jest kolejnym debilizmem systemu…), ale jednocześnie nie chcemy usuwać informacji o tym, że była (krotka to po prostu usługa biznesowa, która idzie do faktury). Rozwiązanie biznesowe… oddzielna procedura, która musi być odpalona w odpowiednim momencie i w dodatku nie ma możliwości jej powtórzenia po jakimś czasie, bo dane fizycznie wyleciały z bazy.
Ech… najlepsze jest to, że testy są prowadzone w taki sposób, że co kilka dni trzeba weryfikować warunki, by przechodziły „ilościowo”.

Zatem kolejna poszlaka. Biznes nie słucha programistów, ignoruje ich doświadczenie i umiejętności sprowadzając ich do roli łatwo wymienialnego zasobu. Powoduje to stawianie dziwnych celów, które owocują jeszcze dziwniejszymi rozwiązaniami. Jeżeli dodamy do tego poprzedni punkt to otrzymujemy ciekawą mieszankę… coś jak młotek do śrub.

Korporatyzacja innowacyjności

CepeliaW jest najlepszym przykładem tego co kryje się pod powyższym pojęciem. PRL był zbudowany z różnych absurdów. Moim zdaniem duża część z nich wynikała w dużej mierze ze zwykłej ludzkiej złośliwości, a nie z jakiegoś „ducha komunizmu”. Niektóre jednak były ucieleśnieniem idei państwa kontrolującego wszystko. Cepelia była czymś takim. Państwo zaczęło kontrolować coś co jest spontaniczne – twórczość ludową. To tak jak mówienie rzeźbiarzowi z Leska, że diabeł bieszczadzki ma mieć równe rogi.
We współczesnych korporacjach mamy do czynienia z podobnym podejściem do innowacyjności. Innowacyjność, a szerzej pomysłowość jest z natury swojej dość spontaniczna. Czasami jest wynikiem pracy, ale najczęściej objawia się w momencie gdy trzeba coś zrobić i nie za bardzo wiadomo jak. Tego nie da się wyłapać. Artysta tym różni się od rzemieślnika, że tworzy pod wpływem impulsu, a nie na rozkaz.
Firmy IT, a im większe tym silniej, mają dziwną tendencję do tworzenia mechanizmów kontrolujących pomysłowość. Często jest to bardzo komiczne, ponieważ przy okazji nieudanej „sesji pomysłowości” ludzie tworzą rozwiązania, które są na prawdę dobre, ale umykają „oficjalnej linii”, przez co albo trafiają do społeczności OS albo giną gdzieś w jakimś zapyziałym repozytorium CVS. Dodatkowo powoduje to frustrację twórców i zabija w nich poczucie misji.

Poszlaka ostatnia. Biznes stara się kontrolować rzeczy niepodlegające kontroli. Tworzy sobie złudne wrażenie, że ma na coś wpływ, a w praktyce tylko ogranicza rzeczywiste możliwości.

Podsumowanie

Jeżeli zapytasz programistę jaki kod jest dobry to usłyszysz coś w rodzaju opinii zamieszczonych na początku „Clean Code” wujka Boba.
Jeżeli zapytasz programistę dlaczego nie stosuje tego w praktyce to zapewne usłyszysz jakąś wariację wymienionych przeze mnie przyczyn. W różnej skali i sile, ale niosących ten sam sens.

Biznes zabija dobry kod ponieważ nie potrafi dostrzec wartości dodanej takiego kodu. Patrząc tylko przez pryzmat pieniędzy nie dostrzega, że dysponuje znacznie większymi zasobami, ale ich odpowiednie użycie nie jest tak proste jak w innych gałęziach przemysłu.

Smutne…