W ostatnim poście marudziłem na management. Zwalanie na management ma tą zaletę, że zwalnia nas programistów z odpowiedzialności. To jest ICH wina, to ONI doprowadzili do takiego a nie innego stanu i tak dalej i tak dalej. Pułapką takiego zachowania jest “wymówka”. Wymówka przenosi naszą odpowiedzialność na kogoś lub coś innego. Wymówka jest świetna bo wybiela nas. Na konferencji 33 degree trafiłem ciasteczko z wróżbą o takiej treści:
W życiu ma się albo wymówki albo wyniki
Dlatego pora zmienić coś na lepsze i przestać mieć wymówki a zacząć mieć wyniki. Żeby zaś mieć wyniki to zobaczmy co my programiści robimy źle nieświadomie zaciągając dług technologiczny.
Happy path – sprawdzenie tylko działającej ścieżki w programie. Mechanizm często wygląda tak, pracując pod silną presją czasu spieszymy się aby napisać działające minimum. Wiele rzeczy nie sprawdzamy po drodze, nie sprawdzamy warunków brzegowych ani wyjątkowych. Odpalamy program – klikamy – działa!!! Ponieważ pracujemy pod presją czasu to wrzucamy kod do repozytorium i lecimy do następnego zadania. Co się stanie jak nie będzie istniał katalog roboczy albo plik będzie zabezpieczony przed zapisem, albo baza nie będzie istniała albo nie będzie internetów czy innych intranetów? No cóż, program się pięknie wyp….. ee poinformuje użytkownika o nagłym zamknięciu. Dług polega na tym, że to zadanie wróci do nas w postaci błędów a im później do nas wróci tym więcej czasu będziemy nad nim siedzieli.
To się nigdy nie wydarzy – jeżeli piszemy mały program, taki na szybko, prawie model na jakieś demo, coś co później naprawimy – to częściej niż rzadziej okazuje się, że spędzimy nad tym mnóstwo czasu poprawiając i zmieniając. Wielokrotnie więcej niż gdybyśmy od razu napisali to tak jak powinno – zgodnie ze sztuką. Wielokrotność jest wielokrotnością czasu jaki upłyną od czasu kiedy stwierdziliśmy “to się nigdy nie wydarzy” i od ilości użytkowników.
Dorobię to później – najlepszy chyba przykład trace-y czy logowanie błędów. Dopisze się to później – jak będzie potrzebne. Problem polega na tym, że jak będą potrzebne bo pojawi się jakiś dziwny błąd to ich nie będziemy mieli. Co więcej dopisując je będziemy musieli przerzucić sporo kodu, żeby umieścić w każdym wymaganym miejscu – a i tak zrobimy to gorzej niż gdybyśmy dodali to od razu.
Później to zmienię – piszemy szybką sklejkę kilku linijek, które jako tako działają – tak na MacGyver-a z założeniem że później to zmienimy. Praktyka wskazuje jednak na coś innego. Taki kod nie zostanie zmieniony. Będzie zatruwał projekt do czasu aż będzie tak uciążliwy, że ktoś to przerobi – i mieć tylko nadzieję, że będzie się to dało jeszcze przerobić.
Miejsc i sposobów na zaciąganie długu technologicznego przez programistów jest jeszcze więcej, dużo więcej. Generalnie każda droga na skróty powoduje, że pozostawiamy mniejszą lub większą dziurę, w którą my sami pewnego dnia wpadniemy.
