O utrudnianiu sobie życia

Blisko rok temu zamieściłem na blogu notkę o kardynalnych błędach, czyli pomyłkach popełnianych przez dużą część programistów w wielu projektach. Teraz chciałbym niejako uzupełnić tamtą listę o kolejne powszechne błędy, ale tego nie zrobię.

Programowanie jest trudne

Ciężko jest mi napisać cokolwiek na bloga, gdyż wszystkie kwestie, które chciałbym omówić znacznie się zazębiają. Nie da się ich poruszyć oddzielnie, a z drugiej strony jeden post o wszystkim byłby strasznie długi, chaotyczny i bezużyteczny jak scrum konfiguracja IoC w XML.

Na przykład - trudno wyjaśnić ludziom, że nadużywają interfejsów, skoro wychodzą od złych założeń dotyczących testów jednostkowych oraz legend na temat wymogań kontenerów IoC. W efekcie powstaje kupa spaghetti, które nie jest ani testowalne, ani podatne na zmiany, ani utrzymywalne, a do tego ma 3 razy więcej kodu niż powinno. No, ale ludzie są z siebie dumni, że postępują zgodnie z wzorcami. Jakimi? Tego nie wiem, a gdy o to spytam, to zazwyczaj się dowiaduje, że to “ogólna zasada programowania”, o której “mowa w wielu książkach”. Argumentacja doprawdy powalająca.

Dwie strony lenistwa (wyjątkowo nie mojego)

Naszła mnie ostatnio myśl, że te wszystkie problemy wynikają z lenistwa. Ludzie zamiast myśleć samodzielnie wolą dostać proste do zaimplementowania hasła w rodzaju: “static to zło”, “każda klasa musi mieć interfejs”, “klasa jest rzeczownikiem”, “code review sprawia, że kod jest dobry”, “LINQ jest lepszy od pętli”, “Git to taki nowy SVN”, “każda klasa jest zależnością i powinna być mockowana w testach”, “IoC trzeba konfigurować w XML”, . Ślepe trzymanie się takich “zasad” jest zazwyczaj prostą drogą do brzydkiego kodu oraz nieefektywnej pracy. No, ale dla niektórych najwyraźniej bardziej od estetyki i sensu, liczy się wykonywanie rozkazów.

Jest jeszcze jedna kategoria lenistwa programistycznego, reprezentowana głównie przez ciężko pracujących ludzi. Taka osoba, gdy trafia do projektu natychmiast zaczyna błyskawicznie implementować zadania, dzięki czemu “biznes” jest z niej zadowolony. Niestety prawda jest zazwyczaj taka, że taki ktoś jest projektowym zbrodniarzem. Dlaczego? Otóż, taki ciężko pracujący programista, który dodaje nowe funkcje do aplikacji na wzór i podobieństwo dotychczasowej implementacji, powiela przy okazji cały istniejący dług technologiczny i architektoniczne nonsensy. Zamiast przemyśleć, zastanowic się i poprawić, usunać jakąś patologię z projektu, skupia się wyłącznie na bieżących zadaniach, jednocześnie dodając roboty temu, kto w końcu będzie musiał to posprzątać.

Zamiast zakończenia

Wiernych czytelników przepraszam, że ten post to takie solenie bez ładu, składu i przede wszystkim mięsa (wychodzi na to, że właśnie napisałem BigMaca).