"Poprawię to później" jest największym jakie znam kłamstwem programisty. Najczęściej jeszcze połączone z drugim: "bo teraz nie mam czasu". Oba się świetnie sprzedają w świecie IT. Przecież naszemu klientowi na czasie bardzo zależy. Im szybciej dostarczymy gotowy kod tym szybciej może go wykorzystać, więc co w tym złego, że chcemy usprawnić kod później, gdy przyjdzie na to czas? Uważam, że nic, jeśli programista jest szczery i naprawdę chce dany kod poprawić. Najczęściej jednak taki programista w ogóle czegoś takiego nie powie. Profesjonalista, uzna swoją pracę za skończoną dopiero wtedy, gdy jest skończona czyli gdy jego kod jest wystarczająco dobry. Oczywiście, zdarza się, że i on potrzebuje więcej czasu jednak zamiast kłamać po prostu zostanie po godzinach i kod dopracuje.
Kiepscy programiści nie zdają sobie sprawy z implikacji swoich poczynań. Z kodem jest podobnie jak z zabezpieczeniami. Jest tak dobry jak jego najsłabsza część. Jeśli system, który budujemy zawiera słabe rozwiązanie to właśnie ono najczęściej zawodzi. Nie jest wówczas istotne, że pozostałe 99% systemu działa poprawnie bo dla użytkownika program zawiódł jako całość. Pół biedy jeśli leń po prostu zrobił błąd, który daje się niewielkim kosztem naprawić. Zwykle nie jest jednak tak różowo, szczególnie z przypadku poważniejszych architektonicznie zmian. Takie zmiany bywają w praktyce nieodwracalne. Nasz piękny system, nad którym w pocie czoła miesiącami pracowaliśmy poległ z ręki nieodpowiedzialnego programisty.
Subscribe to:
Post Comments (Atom)
2 comments:
Marcin, nie zgodzę się z tym do końca.... Teoretycznie masz rację, każdy programista doświadczony powinien szukać/usprawniać swój własny kod non-stop to prawda, a nie szukać błędu u kolegi.. ale w praktyce gdy gonią realne terminy nie wszystko da się zrobić na czas. Software komercyjne niestety nie jest robione 'kiedy bedzie' tylko ma określony deadline które sa obłożone z kolei umowami... Więc w praktyce nie ma czegoś takiego jak 100% działajace idealne oprogramowanie.... Nie widziałem i nie słyszałem o takim idealistycznym oprogramowaniu. Ja bardziej jestem za programowaniem 'iteracyjnym' czyli klient dostaje jak najszybciej software do testów takie jak jest i próbuje używać zgłasza błędy i tak w kółko. Wtedy jest jakby współtworcą programu. A często widzę rozdzwięk między tym co programista zrozumiał a co klient chce. Dlatego szlifowanie tego 1% aby uzyskac 100% jest praktycznie niemożliwe i nie warto tego robić. Idealistycznym oprogramowaniem miał być np. GNU/Debian, który ma być gotowy wtedy gdy będzie doskonały.... Polecam zobaczyć jak to wyglada w praktyce.... Marcin to utopia... :-)) Pozdrawiam,
Rozumiem to, że zwykle oprogramowanie piszę się dłużej niż się planowało, są opóźnienia, nie można na czas oddać wszystkiego. Chodzi mi jednak o to, że ta funkcjonalność, którą faktycznie dostarczamy klientowi powinna być dobrze napisana. Jestem jak najbardziej za iteracyjnym pisaniem. Przykładowo jeśli mam do zaimplementowania dwie rzeczy A i B i nie udało mi się skończyć na czas B to oczywiście, że powiem wówczas, że B będzie dostarczone później. Ale nie o takim czymś pisałem w poście. Chodzi mi o programistów, którzy mówią skończyłem A na 99%, dostarczamy to, a później okazuje się, że rozwiązanie jest beznadziejne.
Post a Comment