Znani programiści o programowaniu

Dziś podchodzimy do tematu programowania i do programistów w nietypowy sposób. Oddajemy głos znanym osobom z branży IT, nierzadko autorytetom. Ich wypowiedzi osobno mogą się wydawać tylko zgrabnymi powiedzonkami, ale zestawione razem, dają interesujący obraz tego, czym jest programowanie i czym być powinno. Zatem oddajmy głos tym, którzy wiedzą lepiej.

Ludzie sądzą, że informatyka to sztuka dla geniuszy, ale w rzeczywistości jest zupełnie odwrotnie. To praca wielu zwykłych ludzi, którzy razem tworzą coś większego, jak mur zbudowany z wielu małych kamieni.

Tak mawiał Donald Knuth i trzeba mu przyznać, że wiele w tym racji. Knuth wiedział zresztą doskonale, co mówi, ponieważ obserwował z bliska i od środka wszystkie te procesy, które ukształtowały współczesny świat programistów. Ten amerykański matematyk jest przede wszystkim pionierem informatyki, a znamy go głównie jako autora wielotomowego dzieła „Sztuka programowania”. Bo czy ktoś tego chce, czy nie, kodowanie jest sztuką, a nie tylko działalnością rzemieślniczą. Trzeba jednak pamiętać, że bywa też harówą.

Teoretycznie istnieją dwa trudne problemy z informatyką: czyszczenie pamięci podręcznej, dobieranie nazw i błąd off-by-one.

Tak wyraził się przewrotnie niejaki Leon Bambrick, rozwijając myśl Philipa Karltona z Netscape. To jak jest z tym pisaniem kodu?

Sztuka pisania kodu

Jednym z podstawowych zajęć programisty jest pisanie kodu. Przynajmniej jest tak w teorii, bo w praktyce bywa z tym różnie. Załóżmy jednak, że programista rzeczywiście ma to szczęście, że koncentruje się głównie na kodowaniu. Samo pisanie kodu jest dość proste, haczyk jest w tym, żeby wszystko miało “ręce i nogi”.

Znany specjalista od architektury oprogramowania i autor wielu poczytnych książek z dziedziny programowania, Martin Fowler, stwierdził, że:

Każdy głupiec może napisać kod zrozumiały dla komputera. Dobrzy programiści potrafią stworzyć kod zrozumiały dla ludzi.

Widać tu inspirację słowami Harolda Abelsona, który w „Structure and Interpretation of Computer Programs” (książka uważana przez wiele osób za jeden z najlepszych podręczników programowania) pisał, że:

Programy muszą być pisane dla ludzi, a tylko przy okazji dla maszyn, które je wykonają.

Martin Golding również podkreślał znaczenie czytelności i jasności kodu:

Zawsze pisz kod tak, jakby gość, który ma się nim zajmować, był agresywnym psychopatą, który wie, gdzie mieszkasz.

Ze sztuką pisania kodu (dobrego), w ogóle jest kłopot. Dobry programista stawia na jakość, a nie na ilość kodu. Bill Gates, którego specjalnie nie trzeba przedstawiać, powiedział, że:

Mierzenie postępów w tworzeniu programu ilością kodu jest jak mierzenie postępów budowy samolotu za pomocą wagi. Trzeba wiedzieć nie tylko, co można dodać, ale też, z czego zrezygnować.

Ken Thompson, twórca Unixa i języka programowania B, a także zdobywca Nagrody Turinga, chwalił się swego czasu:

Jednym z moich najbardziej produktywnych dni był ten, w którym wyrzuciłem 1000 linijek kodu.

Prawdziwe programowanie polega nie tylko na bezmyślnym wklepywaniu kolejnych linijek kodu, ale przede wszystkim na tworzeniu całościowej wizji oprogramowania. W tej wizji sam proces kodowania jest tylko małą częścią działań. Chodzi przecież o stworzenie solidnego i niezawodnego produktu. Dlatego:

Napisanie pierwszych 90% kodu aplikacji zajmuje 90% czasu pracy. Napisanie pozostałych 10% kodu zajmuje pozostałe 90% czasu pracy.

jak głosi znana reguła „90-90”, przypisywana Tomowi Cargill z Bell Labs, a rozpropagowana przez magazyn "Programming Pearls" w jednym z numerów z 1985 roku.

Popiera to również prawo Hofstadtera, które głosi, że:

Wszystko zajmuje więcej czasu, niż się spodziewałeś, nawet jeżeli weźmiesz pod uwagę prawo Hofstadtera.

Dużą część czasu pracy może zająć naprawianie bugów i debugowanie kodu.

Wojna z błędami, czyli sztuka debugowania

Nie oszukujmy się - tam, gdzie mamy do czynienia z programowaniem, prędzej czy później, będziemy mieli do czynienia również z błędami. Taka jest kolej rzeczy. Nie bez przyczyny Edsger W. Dijkstra, holenderski informatyk i zdobywca Nagrody Turinga w 1972 roku powiedział, że:

Jeśli debugowanie jest procesem usuwania błędów z oprogramowania, to programowanie musi być procesem ich umieszczania.

Można nawet pokusić się o śmiałe stwierdzenie, że debugowanie jest nieodłączną częścią programowania. W każdym razie skuteczna walka z błędami również jest sztuką. Kto zajmował się tym chociaż raz w życiu, może potwierdzić, że znajdowanie bugów bywa bardzo żmudnym procesem, w którym nierzadko autor kodu nie ma sobie nic do zarzucenia, bo przecież „u mnie działało”!

Lepiej oczywiście zapobiegać niż leczyć - najlepszą formą walki z błędami jest niepopełnianie ich.

Czasami bardziej opłaca się zostać w łóżku w poniedziałek, niż spędzić resztę tygodnia, debugując kod z poniedziałku.

- Christopher Thompson.

Dennie van Tassel, autor takich książek jak „Program Style” czy „Debugging and Testing”, dodawał nie bez złośliwości:

W końcu dowiedziałem się, co oznacza termin "kompatybilność wsteczna". Oznacza, że trzeba zachować wszystkie stare błędy.

Robienie błędów jest rzeczą ludzką i nawet ma pewien pozytywny aspekt: Nie martw się, gdy coś nie działa dobrze. Gdyby wszystko działało, nie miałbyś pracy (Mosher’s Law of Software Engineering).

Bycie programistą to też sztuka

Sztuka kodowania nie byłaby oczywiście możliwa bez programisty. Analizując różne wypowiedzi ludzi związanych z IT, można dojść do wniosku, że bycie koderem to też sztuka. To nie jest wcale bułka z masłem.

Trudno jest kontrolować pracę dewelopera na każdym etapie.

Kłopot z programistami jest taki, że nigdy nie wiadomo, co robią, do czasu, gdy jest za późno.

To wypowiedź Seymoura Rogera Craya, amerykańskiego informatyka, który był twórcą superkomputerów Cray. Trudno podejrzewać go o pogardę dla programistów. To raczej uszczypliwość, podobnie jak stwierdzenie innego laureata Nagrody Turinga (1999 rok), specjalisty od architektury komputerów i inżynierii oprogramowania, czyli Freda Brooksa:

To, co jeden programista może zrobić w miesiąc, dwóch programistów zrobi w dwa miesiące.

Twórca języka Perl, Larry Wall powiedział:

Większość z Was zna zalety programisty. Oczywiście są trzy: lenistwo, niecierpliwość i pycha.

Programista musi być leniwy, żeby za mocno się nie narobić, a… zrobić. Brak cierpliwości do słabych programów sprawia, że deweloper myśli więcej o tym, jak je usprawnić. Pycha - nieco dyskusyjna zaleta - powoduje, że przykładasz się do tego, co robisz, dzięki czemu inni na pewno będą pod wrażeniem twojego dzieła.

Obok wiedzy technicznej i zamiłowania do rozwiązywania problemów, nieraz potrzebne jest także poczucie humoru i gruba skóra. W ostatecznym rozrachunku i tak za niejednym nowoczesnym urządzeniem, używanym na co dzień przez zwykłego Kowalskiego, kryje się programista. Ważne, aby był to dobry programista. Larry Niven, amerykański pisarz science-fiction, stwierdził:

Niektórzy ludzie sądzą, że nie cierpią komputerów. Tak naprawdę nie cierpią kiepskich programistów. Trudno temu zaprzeczyć.

Podsumowanie

Czy ktoś chce, czy nie, współczesny świat nie może obejść się bez programistów. Tak naprawdę to w dużej mierze od nich samych zależy, czy programowanie będzie stawało się bardziej sztuką, czy rzemieślniczym wklepywaniem kodu. Niektórzy deweloperzy powtórzą za Brianem Kernighanem, autorem między innymi książki “Software Tools”, że to zarządzanie złożonością jest istotą programowania. Dla innych esencja kodowania kryje się gdzie indziej. Niezależnie od tego, czym dla Was jest programowanie - kodujcie jak najwięcej! Może kiedyś to Wasze cytaty zainspirują młodych deweloperów?