[groman43]

Post @vilay i dyskusja pod nim przypomniała o pewnym architekcie, z którym miałem przyjemność pracować dobre kilka lat temu.

Architekt miał ksywę Yoda. Niski (stąd nick), nie rzucający się w oczy. Zwykle przemykał niezauważony korytarzami w biurze wielkiej korporacji. Pod ścianą, tak żeby nie zajmować za wiele miejsca. Nie można było go wyprowadzić z równowagi, epatował spokojem. Mówił bardzo cicho. Ale, co najważniejsze, nie otwierał ust jeśli nie miał czegoś naprawdę mądrego do powiedzenia.

Pamiętam jak kiedyś natrafiłem na poważny problem w kodzie. Nie bardzo wiedziałem, jak mogę go naprawić małym kosztem, więc poprosiłem Yodę o pomoc. Powiedziałem „znalazłem buga”. Yoda odpowiedział „po co szukałeś?”. Byłem tym zszokowany, nie potrafiłem dojrzeć mądrości w tej odpowiedzi.

Lata mijały, zdecydowałem się pójść własną ścieżką. Aż pewnego pięknego poranka znalazłem kolejny bardzo poważny problem. Bug był triggerowany w około 20% przypadków i miał wpływ na performance. Ale nie powodował, że wszystko przestawało działać. Mogłem podeprzeć kod kawałkiem męskiego ciała i szybko o wszystkim zapomnieć, albo naprawić problem porządnie. Jeszcze młody byłem, ambitny. Nie chciałem zwiększać długu technicznego. Dlatego spędziłem dwa tygodnie nad fixem, przeorałem spory kawałek kodu. Nie zajmowałem się niczym innym, więc później ja, jak i moich koledzy, musieli nagdaniać, tak aby nie przegapić deadlinu. Poza tym, pewnie naprawiłem jednego buga, a zaimplementowałem 5 innych. Kiedy to wszystko sobie uświadomiłem, w końcu zrozumiałem mądrość Yody.

#programowanie

[Hulleck123]

@groman43: Ty 2 tygodnie, a reszta? testy, akceptacja, wgranie, ewentualne nowe błędy, a po miesiącu przychodzi klient i mówi, że od jutra ta funkcjonalność nie jest całkowicie potrzebna XD

[groman43]

@Hulleck123: Testy akurat były proste - po prostu reprodukujesz problem w testach i sprawdzasz czy wszystko działa tak jak powinno. Plus oczywiście odpalenia istniejącej regresji. Jeśli przechodzi (plus oczywiście code review), zmiany lądują w następnym releasie.

[Krolik]

@groman43: jak masz dobrze poukładany projekt, z odpowiednim pokryciem testów, napisany w języku z dobrym statycznym systemem typów (używanym mądrze, a nie że wszystko na stringach lata), to naprawianie bugów i refaktoring bardzo rzadko kończy się wprowadzaniem nowych bugów. Błedy powinno poprawiać się w pierwszej kolejności, przed dokładaniem nowej funkcjonalności.

musieli nagdaniać, tak aby nie przegapić deadlinu

Czyli dostarczenie nowych ficzerów jest ważniejsza niż poprawienie poprzednich. To jest patologia i śmierdzi

[groman43]

@Krolik: Tja, nie wiem dlaczego, ale skojarzyły z Twoją odpowiedzią jednorożce srające tęczą. Oczywiście masz rację. Problem w tym, że świat nie jest idealny. Szczególnie jeśli projekt jest rozwijany od kilku dobrych lat, przez zespoły na całym świecie i ma 10+ milionów linii kodu. Wtedy na pewno pokrycie testami jest na odpowiednim poziomie i nikt nie zrobił czegoś głupiego, żeby ominąć statyczne typowanie.

Nie ważne jakbyś się starał, kombinował, testował, wprowadzał

[Hulleck123]

@Krolik: @groman43: a mnie zawsze boli w taki rozmowach wyciąganie skrajności, z opisu wywnioskowałem że nie był to problem dla klienta, a całość można streścić słowami - lepsze jest wrogiem dobrego
oczywiście bezdyskusyjne należy dbać o jakość kodu i testy, ale nie zapominajmy o celu, bo klient płaci za rezultat, a nie jakiś ideał do którego dążymy

zawsze mnie rozbraja to jak wpada jakiś prelegent na konferencji i jak dla

[Krolik]

Wtedy na pewno pokrycie testami jest na odpowiednim poziomie i nikt nie zrobił czegoś głupiego, żeby ominąć statyczne typowanie.

@Hulleck123: Nie chodzi o to, że nikt nie zrobił czegoś głupiego, bo w dużym projekcie zawsze znajdzie się taki ktoś, a nawet najlepszym się zdarza, tylko chodzi o priorytety w projekcie i podejście do sytuacji kiedy już problem zostanie odkryty. Jeśli priorytety masz ustawione "poprawność" > "nowe ficzery, których chce marketing" to