1. Możliwe, że przesadziłem z wyceną
Wycofanie się programisty z wyceny, którą zrobił może oznaczać kilka rzeczy, a każda z nich jest zła… Po pierwsze możliwe, że programista jest leniwy i ją zawyżył. Druga opcja, to niestaranne jej przygotowanie. Trzecia wreszcie to, że programiście takiemu brak odwagi cywilnej i woli skłamać, niż powiedzieć gorzką prawdę.
2. Lepiej tego nie ruszajmy
Powyższe zdanie sygnalizuje przede wszystkim zły stan projektu. Jakaś jego część jest tak krucha, że strach ją zmieniać. Jednak jest to również symptom kiepskiej jakości programisty, bo osoba doświadczona powiedziałaby raczej – modyfikacja tego fragmentu projektu jest ryzykowna – po czym spróbowała sytuację naprawić.
3. To 10 minut roboty
Niewinne, ale jednak łgarstwo. Nawet niewielkie zmiany w kodzie, przy złożoności technologii i narzędzi, jakich używamy w rozwoju oprogramowania nie zajmują 10 minut. Jeśli programista obiecuje takie dziesięciominutowe rozwiązania, to najpewniej składa również inne obiecanki-cacanki.
4. Czysty kod to kwestia gustu
Znany z innych obszarów życia relatywizm – nie ma brzydoty, bo komuś coś się podoba. Cóż – czysty kod jest jak czyste miasto. Kiedy widzimy wybite szyby i opadające tynki; kiedy widzimy bełkotliwe nazwy zmiennych i rozwlekłe metody – wiemy, że jesteśmy w mieście, wiemy, że jesteśmy w kodzie brudnym, upadłym, gnijącym. Nie ma tu miejsca na relatywizm. I nie można bronić swojego niechlujstwa relatywizowaniem.
5. To tak było od zawsze
Konserwatyzm jest może dobry w pewnych dziedzinach życia, ale na pewno nie w rozwoju oprogramowania. Nasza branża premiuje dynamiczne zmiany i jeśli ktoś trzyma się starych rozwiązań bez rzeczowego uzasadnienia, a tylko na podstawie tego, że są stare – nie jest dobrym reprezentantem naszego zawodu.
6. Jest bałagan, ale nie mamy czasu na refaktor
O ile są zawody i branże wymagające działania tu i teraz, jak na przykład bycie strażakiem, o tyle – za wyjątkiem “gaszenia pożarów” na produkcji – rozwój oprogramowania nie jest tą branżą, a programowanie tym zawodem. Jeśli jest bałagan, to znaczy, że struktura kodu, projektu przeszkadza nam w pracy. Jeśli programista doprowadza do takiego stanu, to już jest sygnał alarmowy. Jeśli w dodatku tego stanu nie umie zakończyć – rozmawiając z biznesem, wygospodarowując czas, poświęcając wysiłek na uporządkowanie chaosu – to już oznacza, że jest po prostu bałaganiarzem szukającym wymówek, a nie efektywnym profesjonalistą.
7. Nie było czasu na testy
Jeśli nie było czasu na testy, to po co był czas na pisanie kodu? Kod bez testów jest gorszy niż brak kodu w ogóle, bo działanie szkodliwe jest gorsze od zaniechania działania. Co więcej – jeśli nie było czasu na testy, to najwidoczniej nie został on przez programistę uwzględniony na etapie planowania albo też pojawiły się problemy, które podczas implementacji przemilczał, podejmując bez wiedzy biznesu decyzję o obniżeniu jakości.
Chyba tylko z 3 i 4 mogę się zgodzić.
Raczej to są zdania, które niedoświadczony programista ocenia jako charakterystyczne dla złego programisty.
Mam prośbę, wydrukuj sobie te zdania i stawiaj kreseczkę za każdym razem gdy Tobie takie stwierdzenia się ‘wymskną’ :).
Twój DOBRY programista chyba działa poza czasem, budżetem i w projektach które na może w całości ogarnąć.
No i oczywiście jest nieomylny albo przynajmniej jego pomyłki na pewno nie powodują opóźnień i strat w działaniu firmy.
Sorki ale nie kupuję tego – być może jestem złym programistą ;).
Będę miał chwilkę, to się odniosę do poszczególnych punktów.
Zdaję sobie sprawę, że ja sam, będąc dość doświadczonym, czasami niektóre z tych zdań wypowiadam lub kiedyś wypowiedziałem. Jednak to są zdania złe, szkodliwe lub nieodpowiedzialne. Z czasem wypowiadam je coraz rzadziej, a niektórych przestałem używać.
Przede wszystkim moim zdaniem jako programiści jesteśmy współodpowiedzialni za biznes. Te zdania są według mnie przykładem braku takiej odpowiedzialności.
Artykuły które pisze zły programista…
Heh.
1, 2, 6, 7 IMHO są mocno dyskusyjne.
1. Wycena jest tylko przybliżeniem, estymatą kosztu. Człowiek naturalnie a) ma problem z ekstrapolowaniem nieliniowych procesów, a programowanie w dużej części takim jest; np. zrobienie pierwszego widoku z ostylowaniem powinno zająć tyle co 5 kolejnych, B) przypisuje poduszki, bufory na niewiadome. Są techniki minimalizowania buforów. Czy to w łańcuchach dostaw, zakładach produkcyjnych, czy właśnie w dziedzinie wytwarzania oprogramowania. Nazywanie kogoś leniwym, bo przesadził z wyceną z tego lub innego powodu to jak pretensje do psa że szczeka.
2. O ile każdy kod powinien być czysty – proporcjonalnie do skali i celu – tak nie każdy – już – brudny kod jest wart refaktoringu, czy przepisania. Kod jest narzędziem do tworzenia produktów, usług. Nie róbmy z tego religii – do problemów podchodźmy z pragmatyzmem. Od strony marketingowej – jeśli masz w stajni konia, co mu uczciwy rok pracy został do “emerytury” to mu nowego siodła, czy tam wozu nie dokupisz.
6. To wraca do punktu 2ego. Masz często jakąś część aplikacji 20letniej, która działa, chociaż nikt nie wie dlaczego, a co dopiero jak. Inwestowanie budżetu w analizę kodu który powinien trafić do kosza, albo z racji zmian na świecie przestanie mieć sens jest głupotą. Często lepiej zamknąć ten kod w pudło i iść do przodu – starać się by kod nowy nie sięgnął tego etapu.
7. Testy też trzeba utrzymywać – poszukaj na reddicie artykułu od pracownika Oracle. Stwierdzeniem że kod nieotestowany jest gorszy od braku kodu, robisz z siebie… Testy jednostkowe są formalizacją, potwierdzeniem działania które każdy może odpalić, są bardzo przydatne. I pisanie testów powinno zastępować 60% użyć debuggera… Ale posiadają wady także. W zależności jak daleko z nimi zabrniesz, mogą skutecznie zatrzymać wszelki refaktoring. Bo przecież testy dowodzą istnienia jakiejś tajemniczej funkcjonalności której nikt już nie potrzebuje. No po prostu i do ludzi, i do testów trzeba podejść z rozwagą.
Nie jesteśmy zasranymi yes-manami, a oprogramowanie dalej jest tworem ludzkich rąk… Do wszystkiego z umiarem, a nie szukać złych programistów jak czarownic czy nazywać ich leniami. Z takim podejściem to bliżej ci do PMa niż do programisty.
Ad. 1. Być może powinienem sformułować to lepiej. Nie chodzi o to, że ktoś przesadził z wyceną w tym sensie, że okazało się, że zadanie zajęło mniej czasu, a o to, że się z wyceny wycofuje pod presją i bez zmiany scope. Po prostu ktoś przychodzi i mówi “za dużo” a programista odpowiada “ok, myślę, że jednak dam radę szybciej”.
Ad. 2. Nie pisałem o elementach, które nie wymagają modyfikacji, a o takich, które jej wymagają, ale robi się fikołki, żeby nie dotknąć jakiegoś starego kodu. O ile zgadzam się, że jeśli coś jest spisane na straty, na pewno zostanie na przykład za miesiąc wyłączone, to oczywiście nie ma sensu tego usprawniać. Natomiast wielokrotnie spotykałem się z fragmentami żyjącego projektu, który jest rozwijany i modyfikowany, które to były toną gnijącego mięsa na zapleczu restauracji.
Ad. 6. Istnienie takich aplikacji jest moim zdaniem własnie produktem złych programistów, którzy do tego koszmarnego stanu dopuścili, stawiając swoich następców i management w okropnej sytuacji.
Ad. 7. Oczywiście testy, ręczne, jednostkowe, czy integracyjne mają swoje wady i zalety, ale uważam, że w pewnym minimalnym stopniu jednak powinny być implementowane i przeprowadzane. Jeśli ich nie ma, to po prostu tracimy na jakości i taka decyzja nie powinna być podejmowana samodzielnie, ona oddziałuje na cały projekt, jest to nieodpowiedzialne “przycinać” na tym aspekcie.