Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00069 005621 13254826 na godz. na dobę w sumie
Sztuka kodowania. Sekrety wielkich programistów - książka
Sztuka kodowania. Sekrety wielkich programistów - książka
Autor: Liczba stron: 408
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2755-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Zajrzyj bezkarnie programiście przez ramię!

Programiści to tajemnicze osoby, które potrafią zmusić komputery do wykonywania karkołomnych zadań, wymyślanych przez zwykłych użytkowników. Spędzają cały dzień przed komputerem, a ich świat to monitor, klawiatura i hektolitry kawy. Czy to prawda? Na to pytanie odpowiada książka, którą trzymasz w rękach. Dzięki niej spojrzysz na ten zawód z zupełnie innego punktu widzenia. Jej autor przeprowadza wywiady z najbardziej rozpoznawalnymi osobami z tej branży. Mówią one o swoich pierwszych krokach w świecie programowania, opowiadają, jak nauczyły się swojego pierwszego języka oraz jak widzą tę gałąź wiedzy w przyszłości.

Czym naprawdę jest programowanie? Rzemiosłem, sztuką, a może nauką? Te pytania stawia autor we wprowadzeniu i ma nadzieję, że wypowiedzi jego gości choć trochę zbliżą go do znalezienia odpowiedzi. Ta unikalna książka pozwoli Ci poznać bliżej wybitne osoby, od lat związane z informatyką. Anegdoty, ciekawe opowieści, wiele przykładów to tylko niektóre z proponowanych przez nią atrakcji. Zagłębiając się w kolejne wypowiedzi, przekonasz się, jak często przypadek decyduje o sukcesie lub porażce.

W trakcie lektury będziesz mieć okazję zapoznać się z wypowiedziami takich sław, jak:

Poznaj tajemny świat programistów, hakerów i wybitnych specjalistów!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Idź do • Spis treści • Przykładowy rozdział Katalog książek • Katalog online • Zamów drukowany katalog Twój koszyk • Dodaj do koszyka Cennik i informacje • Zamów informacje o nowościach • Zamów cennik Czytelnia • Fragmenty książek online Kontakt Helion SA ul. Kościuszki 1c 44-100 Gliwice tel. 32 230 98 63 e-mail: helion@helion.pl © Helion 1991–2010 Sztuka kodowania. Sekrety wielkich programistów Autor: Peter Seibel Tłumaczenie: Tomasz Walczak, Mikołaj Szczepaniak ISBN: 978-83-246-2755-4 Tytuł oryginału: Coders at Work Format: 168×237, stron: 416 Zajrzyj bezkarnie programiście przez ramię! • Czym naprawdę jest programowanie? • Jak swoją przygodę rozpoczynali wielcy tej branży? • Czy istnieje bezbłędny program? Programiści to tajemnicze osoby, które potrafią zmusić komputery do wykonywania karkołomnych zadań, wymyślanych przez zwykłych użytkowników. Spędzają cały dzień przed komputerem, a ich świat to monitor, klawiatura i hektolitry kawy. Czy to prawda? Na to pytanie odpowiada książka, którą trzymasz w rękach. Dzięki niej spojrzysz na ten zawód z zupełnie innego punktu widzenia. Jej autor przeprowadza wywiady z najbardziej rozpoznawalnymi osobami z tej branży. Mówią one o swoich pierwszych krokach w świecie programowania, opowiadają, jak nauczyły się swojego pierwszego języka oraz jak widzą tę gałąź wiedzy w przyszłości. Czym naprawdę jest programowanie? Rzemiosłem, sztuką, a może nauką? Te pytania stawia autor we wprowadzeniu i ma nadzieję, że wypowiedzi jego gości choć trochę zbliżą go do znalezienia odpowiedzi. Ta unikalna książka pozwoli Ci poznać bliżej wybitne osoby, od lat związane z informatyką. Zagłębiając się w kolejne wypowiedzi, przekonasz się, jak często przypadek decyduje o sukcesie lub porażce. W trakcie lektury będziesz mieć okazję zapoznać się z wypowiedziami takich sław, jak: • Jamie Zawinski – wybitny programista Lisp, pracujący przy pierwszych wersjach przeglądarki Netscape • Brad Fitzpatrick – najmłodsza osoba w gronie, programista „od zawsze” • Douglas Crockford – starszy architekt JavaScript w Yahoo!; pomysłodawca formatu JSON • Brendan Eich – twórca języka JavaScript • Joshua Bloch – szef Java Architect w Google; w trakcie pracy w Sun Microsystem był kierownikiem zespołu projektującego i implementującego Java Collections Framework • Joe Armstrong – autor języka programowania Erlang • Simon Peyton Jones – rozpoczął projekt, którego efektem było powstanie języka Haskell • Peter Norvig – dyrektor działu badań w Google, wcześniej pracujący dla NASA • Guy Steele – znawca języków; Cobol, Fortran, PDP-10, Java, Haskell to tylko niektóre z jego repertuaru • Dan Ingalls – współtwórca języka Smalltalk • L. Peter Deutsch – programista od końca lat pięćdziesiątych; zaczynał w wieku jedenastu lat • Ken Thompson – współtwórca systemu UNIX • Fran Allen – przez czterdzieści pięć lat pracował dla firmy IBM; instruktor języka Fortran • Bernie Cosell – współautor oprogramowania wykorzystywanego w pierwszych węzłach sieci ARPANET • Donald Knuth – autor jedynego najprawdopodobniej bezbłędnego programu – TeX Poznaj tajemny świat programistów, hakerów i wybitnych specjalistów! Spis treści O autorze Podziękowania Wprowadzenie Rozdział 1. Jamie Zawinski Rozdział 2. Brad Fitzpatrick Rozdział 3. Douglas Crockford Rozdział 4. Brendan Eich Rozdział 5. Joshua Bloch Rozdział 6. Joe Armstrong Rozdział 7. Simon Peyton Jones Rozdział 8. Peter Norvig Rozdział 9. Guy Steele Rozdział 10. Dan Ingalls Rozdział 11. L Peter Deutsch Rozdział 12. Ken Thompson Rozdział 13. Fran Allen Rozdział 14. Bernie Cosell Rozdział 15. Donald Knuth Dodatek Bibliografia Skorowidz 7 9 11 13 45 75 101 123 147 169 197 221 251 277 299 321 341 369 391 395 R O Z D Z I A Ł 8 Peter Norvig Peter Norvig jest z natury człowiekiem o szerokich horyzontach i hakerem. Kiedyś napisał program do znajdowania w dziennikach wyszukiwania serwisu Google trzech kolejnych zapytań jednego użyt- kownika składających się na haiku (oto jedno z tych, które najbardziej utkwiły mi w pamięci: „java ECC / java elliptical curve / playboy faq”). Na swojej stronie Norvig udostępnia odnośniki do standardowych materiałów: napisanych przez sie- bie książek i prac, slajdów z wygłoszonych wykładów oraz różnych fragmentów kodu. Jednak oprócz tego znajdują się tam odsyłacze do tekstów opublikowanych w McSweeney’s Quarterly Concern, dowcipny opis prac nad programem do generowania rekordowo długich palindromów i prezentacja Gettysburg Powerpoint Presentation (jest to parodia programu PowerPoint Microsoft wspomnia- na przez Edwarda Tuftego i pojawiająca się na pierwszej stronie wyników po wpisaniu w wyszuki- warce Google hasła PowerPoint). Norvig jest obecnie dyrektorem do spraw badań w firmie Google. Wcześniej piastował stanowisko dyrektora do spraw jakości wyszukiwania. Przedtem kierował działem nauk obliczeniowych w ośrod- ku NASA Ames Research Center, a jeszcze wcześniej pracował w powstałym pod koniec lat dziewięć- dziesiątych dwudziestego wieku internetowym startupie Junglee. W 2001 roku Norvig otrzymał na- grodę NASA Exceptional Achievement Award i jest członkiem organizacji American Association for Artificial Intelligence oraz Association for Computing Machinery. Dzięki pracy w Google, NASA i Junglee Norvig ma doświadczenie w stosowaniu „hakerskich” i „in- żynieryjnych” technik budowania oprogramowania, a w wywiadzie opowiada o zaletach oraz wa- dach obu tych podejść. Ponieważ jest byłym wykładowcą nauk komputerowych, a obecnie pracuje w jednej z największych na świecie firm zajmujących się oprogramowaniem, ma też ciekawy punkt widzenia na relacje między akademickimi naukami komputerowymi i praktyką ze świata przemysłu. Oprócz tego, rozmawiamy, jak zmieniło się programowanie w ostatnich latach, dlaczego żadne tech- niki projektowania nie zastąpią wiedzy na temat wykonywanych zadań i dlaczego dla NASA korzyst- niejsze może być stosowanie bardziej zawodnego, ale tańszego oprogramowania. 198 Sztuka kodowania. Sekrety wielkich programistów Seibel: Kiedy nauczyłeś się programować? Norvig: W szkole średniej. Szkoła miała komputer PDP-8, tak mi się wydaje, i zapisałem się na kurs. Zaczęliśmy od programowania w języku BASIC i to był mój początek. Seibel: W którym to było roku? Norvig: Skończyłem średnią szkołę 1974, dlatego musiał to być rok 1972 lub 1973. Pamiętam z tych czasów parę rzeczy. Przykładowo nauczycielkę, która próbowała nauczyć nas tasowania talii kart. Jej algorytm działał tak: użyj generatora liczb losowych do wyboru dwóch miejsc, a następnie za- mień karty z tych pozycji miejscami; przechowuj wektor bitowy z informacją o przeniesionych kartach i kontynuuj proces do czasu zamiany wszystkich kart. Pamiętam, że pomyślałem wtedy: „To bez sensu. Musi to być najgłupsze rozwiązanie na świecie. Algorytm może działać w nieskoń- czoność, ponieważ może znaleźć się jedna para, której nigdy nie wybierzemy”. Nie wiedziałem wte- dy, że wystarczy stwierdzić, iż złożoność to n kwadrat, choć powinna to być złożoność liniowa n. Wiedziałem jednak, że rozwiązanie jest po prostu złe. Potrafiłem wymyślić, jak mi się zdaje, algo- rytm Knutha, który zamieniał kartę zerową z pięćdziesiątą drugą, potem zerową z pięćdziesiątą pierwszą itd. — daje to złożoność liniową n. Pamiętam, że nauczycielka broniła swojego podej- ścia. Wtedy pomyślałem: „No cóż, może mam talent do programowania”. Pomogło mi to także stwierdzić, że chyba nauczyciele nie wiedzą wszystkiego. Seibel: Czy zaraz po tym, jak nauczycielka opisała algorytm, uznałeś, że jest błędny? A może naj- pierw przez pewien czas eksperymentowałeś z nim, a dopiero potem stwierdziłeś: „Jejku, to strasz- nie dużo operacji”? Norvig: Chyba od razu zauważyłem problem. Trudno stwierdzić, co naprawdę myślałem, ale chy- ba od razu dostrzegłem, że algorytm może nie zakończyć pracy. Nie jestem pewien, czy równie dobrze zdawałem sobie sprawę z oczekiwanego czasu działania. Pamiętam też, że znalazłem na strychu stare numery „Scientific American” ojca. Był w nich arty- kuł Christophera Stracheya na temat inżynierii oprogramowania. Strachey pisał, że zaczniemy używać języków wyższego poziomu. Wymyślił język, dla którego nigdy nie utworzono kompilatora. Był to język „papierowy”. Strachey stwierdził, że napisze w tym języku program do gry w warca- by. Pamiętam, jak go czytałem. Był to pierwszy skomplikowany program, z którym się zapozna- łem — w szkole uczyliśmy się tylko, jak tasować karty i robić podobne rzeczy. Niedawno ponow- nie przeczytałem artykuł i pierwszą rzeczą, jaką zauważyłem, było to, że znajduje się w nim błąd. To wspaniałe uczucie, ponieważ wiesz, że to Christopher Strachey i powinien wiedzieć, co robi. Dodatkowo to magazyn „Scientific American” — pracują nad nim redaktorzy i inni ludzie, którzy powinni wykryć błędy. W tekście autor twierdzi, że funkcja make-move przyjmuje pozycję na plan- szy i zwraca posunięcie. Kiedy zajrzysz do kodu, zobaczysz, że funkcja make-move przyjmuje pozy- cję na planszy i dodatkowy parametr. Najwidoczniej autor najpierw napisał tekst, a dopiero po- tem kod. Okazało się, że głębokość przeszukiwania nie może być nieskończona, dlatego Strachey dodał nowy parametr. Określa on głębokość przeszukiwania. Program przechodzi rekurencyjnie do określonego poziomu, a następnie kończy przeszukiwanie. Operację tę dodano później, ale autor nie poprawił dokumentacji. Seibel: Był to więc pierwszy ciekawy kod, który przeczytałeś. Jaki pierwszy interesujący program napisałeś? Norvig: Chyba był to program Game of Life. Napisałem go w ramach zadania domowego. Szybko je ukończyłem, a wtedy — oczywiście — nie mieliśmy dobrych wyświetlaczy. Nie posiadałem swoje- go trzydziestocalowego monitora — miałem dalekopis z żółtym papierem. Stwierdziłem, że szkoda drukować jedno małe pole (mieliśmy chyba użyć pola dziesięć na dziesięć kratek), a potem następne Peter Norvig 199 i jeszcze następne. Dlatego stwierdziłem, że wydrukuję pięć pokoleń, jedno za drugim. Pamiętam, że w języku BASIC nie można było stosować tablic trójwymiarowych, a z jakiegoś powodu nie mogłem nawet użyć zestawu tablic dwuwymiarowych. Prowadziło to do wyczerpania pamięci lub czegoś w tym rodzaju. Dlatego musiałem wymyślić, jak utworzyć pięć lub sześć potrzebnych tablic dwuwymiarowych. Wtedy odkryłem pola bitowe. Seibel: Z uwagi na ograniczenia pamięci utworzyłeś własną pamięć na dużą ilość danych. Czy ktoś nauczył cię używać tablic bitów i wymyśliłeś, jak je zastosować, czy może przeglądałeś podręcznik i stwierdziłeś: „O, popatrzcie, mamy tu instrukcje PEEK i POKE” lub coś w tym rodzaju? Norvig: No cóż, zapisywałem w każdej lokalizacji zero lub jedynkę, a gdzie indziej musiałem za- pisać więcej danych. Stwierdziłem: „Och, zapiszę inne liczby tutaj”. W zasadzie nawet nie pamię- tam, czy użyłem pamięci bitowej. Możliwe, że stosowałem cyfry i to raczej dziesiętne niż dwójko- we, ponieważ nikt nie przedstawił nam systemu dwójkowego w ciekawy sposób. Potem dodałem różne możliwości, np. sprawdzanie, czy liczby się nie powtarzają, a jeśli tak, to w jakim cyklu. Nie można było tego zrobić przy przechowywaniu tylko jednego wcześniejszego pokolenia. Seibel: Kiedy rozwijałeś się jako programista, czy robiłeś coś specjalnego, aby wzbogacić swoje umiejętności w tym obszarze, czy po prostu pisałeś programy? Norvig: Wydaje mi się, że tylko pisałem programy. Przede wszystkim robiłem to, co sprawiało mi przyjemność. Działo się tak zwłaszcza na studiach, kiedy byłem mniej zależny od harmonogramu. Znajdowałem ciekawy problem i próbowałem go rozwiązać. Robiłem to dla przyjemności, a nie dlatego, że prowadził do postępów w pisaniu pracy dyplomowej. Seibel: W college’u studiowałeś przedmioty komputerowe, ale nauki komputerowe nie były twoim głównym kierunkiem, prawda? Norvig: Kiedy zaczynałem, kursy komputerowe były prowadzone na wydziale matematyki sto- sowanej. Zanim ukończyłem college, powstał wydział nauk komputerowych, ale moim głównym kierunkiem pozostała matematyka. Miałem wrażenie, że jeśli chcę ukończyć nauki komputerowe jako główny kierunek, muszę jako główny kierunek studiować IBM. Trzeba było poznać ich asem- bler, ich system operacyjny 360 itd. Nie uznałem tego za ciekawe. Niektóre kursy mi się podobały, dlatego się na nie zapisałem, ale nie chciałem brać udziału we wszystkich wymaganych zajęciach. Po college’u przez dwa lata pracowałem w firmie programistycznej w Cambridge. Po tych dwóch latach stwierdziłem: „Szkoły zacząłem mieć dość po czterech latach, a pracy — po dwóch, może więc dwa razy bardziej lubię szkołę?”. Seibel: Co robiłeś w tej firmie? Norvig: Jej głównym produktem był pakiet narzędzi do projektowania oprogramowania. Firma prowadziła też doradztwo z różnych obszarów oprogramowania. Założyciele pracowali w Draper Labs w Cambridge w ramach misji Apollo i nad podobnymi projektami. Mieli znajomości w lot- nictwie i otrzymywali zlecenia od rządu. Posiadali swoją wizję projektowania oprogramowania. Nigdy w nią nie wierzyłem, ale była ciekawa. Pamiętam, że jeden z projektów w tej firmie wymagał napisania narzędzia do rysowania diagra- mów przepływu. Pomysł polegał na tym, że narzędzie miało analizować program i generować dla niego diagram przepływu. Było to idealne rozwiązanie, ponieważ właśnie w ten sposób ludzie ko- rzystają z takich diagramów. Należy je przygotować na początku, ale nikt tego nie robi — two- rzymy je po napisaniu kodu. Narzędzie było pomysłowe, ponieważ miało specyficzną gramatykę częściową, dlatego działało dla programów niepoprawnych składniowo i ukrywało elementy, któ- rych nie potrafiło przetworzyć. Narzędzie musiało umieć przetwarzać instrukcje IF, ponieważ 200 Sztuka kodowania. Sekrety wielkich programistów składały się one na różne bloki, natomiast inne elementy miało jedynie umieszczać w blokach. Uzyskaliśmy kontrakt na opracowanie tego programu. Zleceniodawca określił, że narzędzie ma działać w systemie Unix. Pożyczyliśmy więc maszynę z uczelni MIT i użyliśmy do budowania kom- pilatora wszystkich uniksowych narzędzi — narzędzia yacc i innych. W ostatniej chwili zlecenio- dawca stwierdził, że chcą zainstalować program w systemie VMS. Nagle okazało się, że nie mamy dostępu do narzędzia yacc. Uznaliśmy jednak, że nie stanowi to problemu, ponieważ go nie po- trzebujemy. Narzędzie to było potrzebne tylko do wygenerowania tablic, co już zrobiliśmy. Seibel: Dopóki gramatyka się nie zmieni, wszystko będzie w porządku. Norvig: To prawda. Udostępniliśmy więc produkt, a odbiorca był zadowolony. Jednak wtedy — oczywiście — gramatyka się zmieniła, a my nie mieliśmy już dostępu do żadnych maszyn z Unik- sem. Ostatecznie musiałem poprawiać gramatykę przez domyślanie się, co oznaczają tablice. Odby- wało się to tak: „Tu mamy przejście do innego stanu — w porządku, wymyślę nowy stan i przejdę w zamian właśnie do niego”. Seibel: Czy rzeczywiście było to odpowiednie rozwiązanie? Czy nie pomyślałeś o tym, aby po pro- stu napisać nowy parser? Norvig: Prawdopodobnie powinienem był tak zrobić, ale chodziło tylko o tę jedną małą poprawkę. Seibel: Czy nie wpadłeś przez to w pułapkę związaną z tym, że odbiorca co kilka tygodni zgłaszał nową zmianę w gramatyce? Norvig: Wtedy poszedłem na studia doktoranckie. Ktoś inny musiał zmierzyć się z tym problemem i nie wiem, co się stało. Seibel: Nie było to już twój problem. Uzyskałeś tytuł doktora. Czy zmieniłbyś coś w sposobie, w jaki uczyłeś się programowania? Norvig: Ostatecznie trafiłem do środowiska komercyjnego, dlatego mogłem wcześniej robić więcej rzeczy z tego obszaru. Nauczyłem się ich, jednak dużo czasu spędziłem w college’u i na studiach doktoranckich. Sprawiało mi to wiele frajdy, dlatego niczego nie żałuję. Seibel: Czego musiałeś nauczyć się o programowaniu w środowisku komercyjnym? Norvig: Musiałem przestrzegać terminów i dbać o zadowolenie członków zespołu, klientów oraz menedżerów. Na studiach doktoranckich nie trzeba tego robić. Wystarczy od czasu do czasu spot- kać się z opiekunem. Chyba największą zmianą było przejście od samodzielnej pracy do działania w zespole i poznawa- nie interakcji między ludźmi. Z tym zwykle nie spotykamy się na studiach. Wydaje mi się, że nie- które uczelnie zaczynają wprowadzać do programu zajęcia z tego obszaru. Kiedy byłem na studiach, pracę zespołową nazywano oszukiwaniem. Seibel: Jakie umiejętności, oprócz pisania kodu, powinny rozwijać osoby, które chcą pracować w branży informatycznej? Norvig: Przede wszystkim komunikowanie się z innymi. Ważna jest umiejętność zrozumienia oczekiwań klienta — ustalenia, co trzeba utworzyć i czy przygotowane rozwiązanie jest popraw- ne. Trzeba umieć komunikować się z odbiorcami oraz innymi członkami zespołu. Istotne są też interakcje z osobami zajmującymi wyższe stanowiska w firmie i z klientami. Są to różne relacje społeczne wymagające odmiennych umiejętności. Seibel: Czy obecnie programowanie stało się zadaniem bardziej społecznym niż kiedyś? Peter Norvig 201 Norvig: Tak uważam. Etapy programowania były kiedyś bardziej rozdzielone od siebie. W daw- nych czasach stosowano przede wszystkim przetwarzanie wsadowe, dlatego interfejs był znacznie prostszy. Można było używać modelu wodospadu i stwierdzić, że danymi wejściowymi ma być np. talia kart, a danymi wyjściowymi — przykładowo raport z daną liczbą w określonej kolumnie. Prawdopodobnie nie był to najlepszy sposób tworzenia specyfikacji. Należało od początku częściej komunikować się z klientem. Jednak wydawało się, że poszczególne etapy są bardziej niezależne od siebie. Teraz wszystko wydaje się bardziej płynne i interaktywne, dlatego sensowniejsze jest stwierdzenie: „Zamiast od początku przygotowywać kompletną specyfikację, zbierzmy klientów i rozpocznijmy burzę mózgów”. Seibel: Czy pamiętasz konkretne momenty „olśnienia”, w których zauważyłeś różnice między sa- modzielną pracą a wykonywaniem zadań w zespole? Norvig: Nie wiem, czy były to konkretne momenty. Raczej zdałem sobie sprawę, że nie mogę zro- bić wszystkiego sam. Uważam, że dużą część procesu programowania można wykonać w głowie, ale nie da się w ten sposób zrobić wszystkiego — przynajmniej ja tego nie potrafię. Później trzeba polegać na innych osobach mających odpowiednie pomysły i je wykorzystać. Zacząłem myśleć: „W jaki sposób jest to prawdopodobnie zrobione?” zamiast: „Wiem, jak jest to zrobione, ponie- waż sam to napisałem”. Jak zrobiłbym daną rzecz, gdybym otrzymał takie zadanie? Zakładam, że tak właśnie to działa, a jeśli jest inaczej, muszę ustalić, dlaczego tak jest, a następnie odkryć, jak z tego korzystać. Seibel: Czy uważasz, że nauczenie się działania w zespole umożliwia ci pracę nad większymi za- daniami w pojedynkę, tak jakbyś był specyficznym zespołem rozproszonym w czasie? Norvig: Chyba rzeczywiście tak jest. Z pewnością widzę to u młodych programistów, którzy obec- nie zaczynają pracę. Inna różnica między przeszłością i teraźniejszością polega na tym, że obecnie programowanie bardziej przypomina składanie elementów niż pisanie wszystkiego od podstaw. Teraz kiedy ktoś wykonuje zadaną pracę, mówi: „Potrzebowałem witryny, dlatego użyłem Ruby on Rails do tego, systemu Drupal w tej części, następnie wykorzystałem ten skrypt w Pythonie, a potem pobrałem tę procedurę do obliczeń statystycznych”. Wystarczy dodać skrypty łączące elementy — nie trzeba pisać wszystkiego od początku. Dlatego uważam, że zrozumienie interfej- sów i współdziałania między nimi jest dużo ważniejsze niż opanowanie szczegółów działania po- szczególnych pakietów. Seibel: Czy uważasz, iż oznacza to, że obecnie inne osoby mogą odnosić sukcesy w programowaniu? Norvig: Uważam, że prawdziwe sukcesy odnoszą takie same osoby — przynajmniej w moim śro- dowisku. Jednak rzeczywiście, trochę ważniejsze jest szybkie niż kompletne zrozumienie potrzeb- nych elementów. Sądzę, że jest w tym trochę brawury, gotowość do powiedzenia: „Po prostu to zrobię”, brak obaw przed stwierdzeniem: „Nie rozumiem wszystkiego, ale zajrzałem do dokumen- tacji i poznałem te trzy elementy; wypróbowałem rozwiązanie i zadziałało, dlatego idę dalej”. Po- zwala to dojść do pewnego poziomu, ale myślę, że to nie wystarczy do zostania naprawdę dobrym programistą. Do tego trzeba zrozumieć coś więcej i zapytać: „Czy to bezpieczne? Co jest przyczy- ną błędu? Rzeczywiście, raz spróbowałem i zadziałało, ale czy zawsze tak będzie? Jak mam napisać przypadki testowe, aby to pokazać i lepiej zrozumieć program? Kiedy już to zrobię, jak wyodręb- nić wykonaną pracę i udostępnić nowe narzędzie przydatne innym osobom dlatego, że złożyłem elementy w określony sposób?”. Seibel: Jaki sposób pracy w zespole ci odpowiadał, kiedy byłeś programistą? Czy lepiej podzielić problem, tak aby każdy otrzymał jego fragment? A może wolisz model programowania ekstremal- nego, kiedy wszystko jest pisane w parach, a kod jest własnością całego zespołu? 202 Sztuka kodowania. Sekrety wielkich programistów Norvig: Bardziej odpowiada mi podział pracy. Steve Yagge napisał kiedyś artykuł Good Agile, Bad Agile. Uważam, że ma rację. Przez 10 czasu naprawdę warto pracować razem, aby wszyscy rozu- mieli zadanie w ten sam sposób. Przez większość tego czasu programiści nie są w pełni efektywni. Jeśli zespół składa się z dwóch dobrych programistów, lepiej, żeby pracowali osobno, a następnie debugowali nawzajem swój kod po zakończeniu zadania. Gorsze jest podejście: „Zgadzamy się na 50 spowolnienie pracy w zamian za dodatkową parę oczu”. Uważam, że współpraca jest ważna przy ustalaniu planu pracy. Chodzi tu o analizy problemu do rozwiązania i dodawanych funkcji. Przed rozpoczęciem pracy nie wiadomo, czym ma być pro- dukt. Naprawdę warto wtedy pracować razem. Następnie grupa dochodzi do etapu, kiedy można powiedzieć: „W porządku, wiemy, co chcemy zrobić. Jak podzielimy pracę?”. Także to warto zro- bić razem. Kiedy już wiadomo, co trzeba robić, uważam, że lepiej pracować samodzielnie. Infor- macje zwrotne są przydatne, dlatego myślę, że każdy fragment kodu powinien przejrzeć ktoś oprócz autora, ale nie musi się to odbywać w czasie rzeczywistym, w trakcie pisania kodu. Pamiętam pomysł mistrza programisty promowany przez IBM. Wydało mi się to najgłupszą rze- czą, jaką kiedykolwiek usłyszałem. Dlaczego ktoś miałby pracować na rzecz jednego prawdziwego programisty? Seibel: Dziwi mnie, że uważasz model mistrza programisty za tak zły pomysł. W eseju „Teach Yourself Programming in Ten Years” napisałeś, że programowanie to dziedzina, której prawdzi- we opanowanie wymaga — podobnie jak inne umiejętności — około dziesięciu lat. W wielu dzie- dzinach obowiązuje hierarchia typu mistrz – czeladnik – uczeń. Możliwe, że nikt nie chce być uczniem, ale czy to takie dziwne, że osoba z dziesięcioletnim doświadczeniem ma robić coś inne- go niż ktoś świeżo po studiach? Norvig: Uważam, że najlepsza w byciu uczniem jest możliwość podpatrywania mistrza. Chciałbym częściej widzieć takie podejście. Dlatego uważam, że jest to następne zastosowanie programowa- nia w parach. Dla początkującego naprawdę korzystne może być podglądanie kogoś o znacznie większym doświadczeniu. Dotyczy to zwłaszcza zadań, których szkoły nie uczą, np. debugowania. Każdy może nauczyć się algorytmów i tym podobnych zagadnień, ale szkoły naprawdę nie uczą debugowania. Przydatne jest podglądanie kogoś, kiedy można powiedzieć: „Nigdy bym o tym nie pomyślał”. Sądzę, że związki mistrz – uczeń rozwinęły się po części z powodu niedostatku materiałów. Jubi- ler miał do dyspozycji tylko niewielką ilość złota. Chirurg operuje tylko jedno serce, dlatego pra- cować powinna tylko najlepsza osoba, a pozostałe mają służyć pomocą. Przy pisaniu kodu jest in- aczej. Mamy dostęp do wielu terminali i klawiatur. Nie trzeba ich racjonować. Seibel: Wspomniałeś o rzeczach, których szkoły nie uczą. Pracujesz na uczelni i w przemyśle. Czy uważasz, że akademickie nauki komputerowe i programowanie komercyjne są dopasowane do siebie? Norvig: To poważne pytanie. Sądzę, że program nauk komputerowych zawiera mało nieprzydat- nych elementów. Uważam, że studenci uczą się głównie bardzo wartościowych rzeczy. Moim zda- niem, studia są przydatne, ale nie wystarczą do odniesienia sukcesu w branży lub przy budowaniu systemów. Myślę, że program na wielu uczelniach zmienia się za wolno. Dotyczy to wielu obsza- rów. Szkoły nie uczą pracy w zespole. Nie pokazują także, jak łączyć różne elementy, ale młodzież w jakiś sposób się tego uczy, dlatego może nie stanowi to problemu. W Google interesują nas du- że chmury obliczeniowe, przetwarzanie równoległe itd. Szkoły nie uczą tych zagadnień, choć — moim zdaniem — cieszą się one dużym zainteresowaniem. Dlatego uważam, że występuje tu pewne opóźnienie, natomiast uczelnie na pewno są przydatne. Peter Norvig 203 Seibel: Czy istnieją obszary, w których naukowcy wyprzedzają przemysł? Czy firmy czasem igno- rują wartościową wiedzę na temat budowania oprogramowania? Norvig: W pewnym stopniu tak się zdarza. Prawdopodobnie najlepszy przykład to weryfikacja modelowa. Intel nie przywiązywał do tego dużego znaczenia, a następnie musiał wycofać produkt z rynku i stracił dużo pieniędzy, ponieważ w mnożeniu był błąd. Wtedy firma zaczęła zwracać uwa- gę na tę kwestię i zgłosiła się do naukowców z pytaniem: „Jak możecie pomóc?”. Coś więc było na rzeczy. Teraz weryfikacja modelowa to integralna część procesu Intela, dlatego to dobry przykład. W pewnym stopniu dotyczy to także języków programowania. Trwają intensywne prace w tym obszarze, ale nie widać ich dużego wpływu na nowsze języki programowania. Naukowcy pracują też nad systemami operacyjnymi. Wspieramy kierowany przez Dave’a Pattersona ośrodek RAD Lab w Berkeley i inne jednostki. Jednak — oczywiście — to przemysł styka się z większymi pro- blemami. Możliwe, że nie zna rozwiązań każdego z nich, ale firmy pracują nad nimi ciężej niż pra- cownicy uczelni. Seibel: Uważasz więc, że w na uczelniach nie powstają pomysły pomijane przez przemysł z uwagi na opór przed pewnymi zmianami? Może generacja programistów, którzy sami nauczyli się PHP, nigdy nie zafascynuje się Haskellem, nawet jeśli jest to lepszy sposób na pisanie oprogramowania? Norvig: Jestem dość sceptycznie nastawiony. Uważam, że jeśli jakaś technika ma rzeczywiste za- lety, ludzie z niej skorzystają. Nie sądzę, że rynek jest optymalny i natychmiast znajduje najlepsze rozwiązanie, jednak niewiele do tego brakuje. Naukowcy mogą nie dostrzegać całego problemu, z którym zmaga się przemysł. Po części jest to kwestia systemu edukacji, ale jeśli w firmie pracuje wielu programistów, którzy nie wiedzą, czym jest monada, i nie ukończyli kursów z teorii katego- rii, występuje luka. Częścią problemu są starsze systemy, których nie można po prostu wyrzucić, dlatego przechodze- nie odbywa się stopniowo. Jestem pewien, że w niektórych obszarach przemysł powinien być bar- dziej nastawiony na przyszłość zgodnie z podejściem: „Pewnie, nie możemy dokonać zmiany już dziś, ale musimy mieć plan określający, gdzie będziemy za dziesięć lat. Powinien on także infor- mować, jak mamy się tam znaleźć”. Jednak firmy oczekują usprawnień w obszarach, które będą miały duże znaczenie. Uważam, że prace nad językami programowania odbywają się często na zbyt niskim poziomie, aby miało to tak duży wpływ na przemysł, jak tego oczekują projektanci. Twórca języka może powiedzieć: „Po- patrzcie, w moim nowym wspaniałym języku tych sześć wierszy kodu można zapisać za pomocą dwóch wierszy”. No cóż, świetnie, podejrzewam, że pozwala to zwiększyć produktywność progra- mistów oraz uprościć debugowanie i konserwowanie kodu. Jednak możliwe, że napisany kod to tylko mała część całego systemu produkcyjnego, a prawdziwym problemem jest codzienne aktu- alizowanie danych, zbieranie informacji z internetu, zapisywanie ich w systemie i przekształcanie na odpowiedni format. Dlatego trzeba pamiętać, że rozwiązanie często dotyczy tylko bardzo ma- łego fragmentu całego problemu. Oznacza to, że musi istnieć bardzo poważna przeszkoda do po- konania, aby warto było dokonać zmiany. Seibel: Pomińmy teraz praktyczne badania nad językiem. Uważasz, że przebyliśmy długą drogę od czasu, kiedy nauki komputerowe przypominały kierunek „IBM”? Norvig: Tak. Uważam, że program jest obecnie dobry. Smutne jest to, że tak mało studentów z tego korzysta. Liczba zapisów spada. Oczywiście, jest grupa osób, które kochają komputery lub projek- towanie tak bardzo, że trafiają na studia informatyczne. Dbamy o tę grupę. Jednak wielu najlep- szych i najinteligentniejszych studentów wybiera fizykę, biologię lub coś innego, ponieważ są to najpopularniejsze dziedziny. Jeszcze inna grupa mówi: „Tak, lubię komputery, ale nie mam przy- szłości w tej branży, ponieważ wszystkie stanowiska i tak są przenoszone do Indii. Dlatego wybiorę 204 Sztuka kodowania. Sekrety wielkich programistów kursy przygotowujące do studiów prawniczych lub coś innego, abym mógł znaleźć pracę”. Szko- da, że tak się dzieje. Uważam, że te osoby mają błędne informacje. Seibel: Chcesz powiedzieć, że to szkoda, ponieważ licznym z tych osób programowanie spodoba- łoby się, czy dlatego, iż ich potrzebujemy? Norvig: Oba powody są ważne. Wiele osób może czerpać przyjemność z rozmaitych zajęć. Jeśli daną osobę w równym stopniu interesują dwa kierunki, nie chcę twierdzić, że powinna wybrać nauki komputerowe. Jednak sądzę, że występuje brak dopasowania. Potrzebujemy większej liczby dobrych ludzi. Sądzę, że mogą oni mieć duży wpływ na świat. Jeśli to właśnie chcą osiągnąć, po- winniśmy kierować większą liczbę najlepszych osób na nauki komputerowe. Seibel: W jednej z prac Dijkstra opisuje, że nauki komputerowe to część matematyki, a studenci tego kierunku przez pierwszych n lat edukacji nie powinni nawet dotykać komputera. Zamiast te- go mają nauczyć się manipulowania systemami formalnych symboli. Jak sądzisz, w jakim zakresie musi znać matematykę kompetentny programista? Norvig: Nie uważam, że potrzebny jest poziom postulowany przez Dijkstrę. Poza tym koncentruje się on na specyficznym rodzaju matematyki — na matematyce dyskretnej, dowodach logicznych. Ja jestem związany z obszarem, gdzie ma to mniejsze znaczenie. Dziedzina ta jest bardziej proba- bilistyczna niż logiczna. Rzadko tworzę program, którego poprawność mogą udowodnić. Czy wyszukiwarka Google działa poprawnie? No cóż, wpisz dowolne słowa, a otrzymasz dziesięć stron. Jeśli wystąpi awaria, działanie wyszukiwarki będzie nieprawidłowe, jeżeli jednak otrzymasz te dziesięć odnośników zamiast dziesięciu innych, nie będziesz mógł określić, które wyniki są po- prawne. Możesz mieć swoje zdanie na temat tego, które są lepsze, ale nie stwierdzisz nic więcej. Sądzę, że Dijkstrze nie o to chodziło. Uważam, że kiedy zacznie się rozwiązywać tego typu proble- my lub kwestię poruszania się robota kierowcy po mieście bez wjechania w kogokolwiek, próba przeprowadzenia logicznego dowodu jest skazana na niepowodzenie. Seibel: Czy istnieje kluczowa umiejętność potrzebna dobrym programistom? W różnych dziedzi- nach obowiązują — oczywiście — inne wymagania, czy jednak występują pewne punkty wspólne związane z pisaniem kodu? Norvig: Musisz robić postępy, a następnie wprowadzać poprawki. To wszystko, co musisz umieć w życiu. Potrzebujesz jakiegoś pomysłu, aby powiedzieć: „Oto kierunek, w którym mam zmierzać”. Następnie musisz stwierdzić: „Teraz trzeba to poprawić”. Oto możliwe przyczyny usprawnień: „Nie zrobiłem tego dobrze — zapomniałem o obsłudze pewnych warunków” albo „Teraz, kiedy lepiej to rozumiem, utworzę bardziej abstrakcyjne narzędzie, aby ułatwić sobie pisanie podobnych systemów w przyszłości”. Sądzę, że potrzebna jest do tego introspekcja związana z pytaniami: „Do- kąd chciałem dojść? Jak to zrobiłem? Czy istnieje lepszy sposób na wykonanie zadania?”. Seibel: Sądzisz więc, że ta umiejętność — czyli tworzenie rozwiązania, usuwanie błędów i powta- rzanie tego procesu — to rodzaj myślenia, którego należy uczyć wiele osób, także tych, które nie chcą zostać programistami? Czy gdybyś tworzył program nauczania dla szkoły średniej lub uczel- ni, chciałbyś, aby wszyscy uczyli się programowania w ten sposób? A może jest to zbyt wyspecja- lizowana umiejętność? Norvig: Myślę, że jest to wyspecjalizowana umiejętność. Uważam, że programowanie to tylko jeden przykład opisanego sposobu myślenia. Byłbym zadowolony także z wprowadzenia innych przy- kładów, takich jak problemy mechaniczne: „Oto zbiór części. Jak sprawić, aby woda przepłynęła stąd dotąd i znalazła się w kubku?”. Nie musi chodzić o manipulowanie wierszami kodu. Może to być praca z różnego rodzaju elementami i obserwowanie ich współdziałania. Peter Norvig 205 Seibel: Do jak niskiego poziomu powinni schodzić programiści? W eseju „Teach Yourself Pro- gramming in Ten Years” piszesz o tym, że trzeba wiedzieć, jak dużo czasu zajmuje wykonanie in- strukcji w porównaniu z odczytem danych z dysku itd. Czy nadal musimy uczyć się asemblera? Norvig: Nie wiem. Knuth twierdził, że powinniśmy wszystko pisać w asemblerze, ponieważ kod w języku C jest zbyt niewydajny. Nie zgadzam się z tym. Uważam, że warto wiedzieć, które instruk- cje są niewydajne, jednak obecnie nie dotyczy to poziomu pojedynczych instrukcji. Nie chodzi o porównywanie sekwencji składających się z dwóch i trzech instrukcji. Ważne jest, czy wystąpił błąd strony lub nieudanego odczytu danych z pamięci podręcznej. Myślę, że nie musimy znać asemblera. Potrzebna jest wiedza o architekturze. Należy zrozumieć, czym jest asembler, a także wiedzieć, że istnieje hierarchia pamięci, a przenoszenie danych z jednego poziomu hierarchii na inny związane jest z dużym spadkiem wydajności. Jednak nadal uważam, że należy zrozumieć ten system na poziomie abstrakcyjnym. Seibel: Czy są jakieś książki, które — twoim zdaniem — powinien przeczytać każdy programista? Norvig: Myślę, że wybór jest duży. Nie ma jednej, jedynej ścieżki. Trzeba przeczytać jedną z ksią- żek o algorytmach. Nie wystarczy wycinać i wklejać algorytmów. Może to być książka Knutha lub Cormena, Leisersona i Rivesta. Są też inni autorzy, np. Sally Goldman, która napisała nową książ- kę z bardziej praktycznym ujęciem algorytmów. Moim zdaniem, jest to całkiem ciekawa pozycja. Należy więc przeczytać coś o algorytmach. Trzeba też zapoznać się z książką o abstrakcji. Lubię pozycję Abelsona i Sussmana, ale są też inne książki. Trzeba dobrze poznać używany język programowania. Przeczytać podręcznik. Zapoznać się z książ- kami opisującymi zarówno mechanizmy języka, jak i cały proces debugowania oraz testowania — coś w rodzaju Code Complete. Myślę jednak, że jest wiele różnych ścieżek. Nie twierdzę, iż trzeba przeczytać jeden zestaw książek. Seibel: Wprawdzie twoja praca nie wymaga dużej ilości programowania, ale nadal piszesz progra- my na potrzeby esejów z witryny. Jak podchodzisz do tworzenia tych małych programów? Norvig: Uważam, że jedną z najważniejszych kwestii jest umiejętność jednoczesnego utrzymywa- nia wszystkich informacji w głowie. Jeśli to potrafisz, masz dużo większe prawdopodobieństwo powodzenia. Wtedy tworzenie małych programów jest łatwiejsze. Przy większych programach potrzebne są do tego dodatkowe narzędzia. Ważne jest też, aby wiedzieć, co się robi. Kiedy pisałem program do rozwiązywania sudoku, nie- którzy blogerzy pisali komentarze na ten temat. Zwracali uwagę na różnice między programem do sudoku Norviga, a podejściem innego programisty, którego nazwiska zapomniałem — jest on jednym z guru z obszaru projektowania opartego na testach. Programista ten zaczął pracę i napi- sał: „Zamierzam zająć się sudoku. Potrzebna będzie ta klasa, a pierwszą rzeczą, jaką zrobię, będzie napisanie zestawu testów”. Jednak nie udało mu się nic osiągnąć. Zamieścił pięć wpisów na blogu, w każdym z nich dodał fragment kodu i napisał mnóstwo testów, ale nie utworzył działającego programu, ponieważ nie wiedział, jak rozwiązać problem. Ja, znając sztuczną inteligencję, wiedziałem, że jest coś takiego jak propagacja ograniczeń i że to działa. Wiedziałem, że jest coś takiego jak wyszukiwanie rekurencyjne i że to działa. Potrafiłem od razu dostrzec, że można połączyć te dwie techniki i rozwiązać sudoku. Wspomniany programista tego nie wiedział, dlatego w pewnym sensie błądził w ciemnościach, choć jego kod „działał”, po- nieważ przygotował przypadki testowe. Blogerzy zawzięcie spierali się, czego to dowodzi. Moim zdaniem, nie dowodzi niczego. Uważam, że projektowanie sterowane testami to świetna technika. Obecnie stosuję ją znacznie częściej niż 206 Sztuka kodowania. Sekrety wielkich programistów kiedyś. Jeśli jednak nawet przetestujesz wszystkie elementy, a nie wiesz, jak podejść do problemu, nie uzyskasz rozwiązania. Seibel: Można zadać pytanie, skąd inny programista miał wiedzieć to, co ty? Czy powinien zrobić doktorat i specjalizować się w sztucznej inteligencji? Nikt nie zna wszystkich algorytmów. Obecnie można skorzystać z wyszukiwarki Google, jednak znalezienie odpowiedniego podejścia do proble- mu różni się nieco od wyszukania platformy do tworzenia aplikacji sieciowych. Norvig: Chodzi ci o to, skąd wiemy, czego nie wiemy? Seibel: Właśnie. Norvig: Ważne są dwie kwestie. Po pierwsze, trzeba założyć, że może istnieć znane rozwiązanie problemu. Można powiedzieć: „No cóż, na pewno nikt nie wie, jak to zrobić, dlatego szukanie roz- wiązania na chybił trafił to równie dobry pomysł jak każdy inny”. To jedna możliwość. Oto inne podejście: „No cóż, prawdopodobnie ktoś wie, jak to zrobić. Nie wiem, jak nazywa się potrzebny algorytm, dlatego muszę to ustalić”. Moim zdaniem, po części wynika to z intuicji i podejścia ty- pu: „Wydaje mi się, że tego rodzaju rozwiązania powinny być częścią wiedzy z obszaru sztucznej inteligencji”. Następnie trzeba ustalić, jak znaleźć rozwiązanie. Wspomniany programista praw- dopodobnie mógł poszukać informacji o sudoku i znaleźć potrzebne metody. Może myślał, że to oszukiwanie. Nie wiem. Seibel: Załóżmy, że jest to oszukiwanie. Przyjmijmy, że byłeś pierwszą osobą, która próbuje roz- wiązać sudoku. Techniki, które zastosowałeś, cały czas istniały i czekały na zastosowanie. Norvig: Powiedzmy, że chcę rozwiązać pewien problem z obszaru biologii. Nie wiem, które algo- rytmy najlepiej nadają się do sekwencjonowania genów lub wykonywania innych zadań. Zdaję sobie jednak sprawę, że takie algorytmy istnieją. Wtedy rozpoczynam poszukiwania. Na innym poziomie niektóre kwestie są podstawowe — jeśli nie wiesz, czym jest programowanie dynamicz- ne, znajdujesz się w bardzo trudnej sytuacji. Problem ten będzie cały czas wracał, jeśli nie znasz ogólnej idei poszukiwań, jeżeli nie wiesz, że można dokonać wyboru i cofnąć się, kiedy dany ele- ment okaże się niepotrzebny. Wszystkie te pomysły pochodzą z lat sześćdziesiątych dwudziestego wieku. Ludzie odkryli te rozwiązania w pierwszych latach po powstaniu dziedziny związanej z pro- gramowaniem. Wydaje mi się, że wszyscy powinni znać takie pomysły. Natomiast niektóre roz- wiązania, np. wymyślone w zeszłym roku, nie muszą być znane każdemu. Seibel: Zatem programiści powinni czytać stare prace? Norvig: Nie, ponieważ zdarza się wiele nietrafionych pomysłów. Ponadto występują „fuzje”, kie- dy to w dwóch różnych dziedzinach rozwijane są zupełnie niezależne technologie i terminologie, po czym naukowcy odkrywają, że robili to samo. Uważam, iż należy patrzeć raczej ze współcze- snej perspektywy, niż dokładnie śledzić rozwój pomysłów. Należy jednak je znać. Nie wiem, które książki będą tu najlepsze, ponieważ sam uczyłem się w trudniejszy sposób — po kawałku. Seibel: Wróćmy do projektowania oprogramowania. Co możesz powiedzieć o pracy nad większy- mi programami, kiedy nie można zapamiętać, jak współdziałają wszystkie fragmenty kodu? Jak projektujesz takie rozwiązania? Norvig: Uważam, że warto mieć dobrą dokumentację na poziomie projektu całego systemu. Co można uzyskać dzięki temu i w jaki sposób? Dokumentowanie każdej metody jest zwykle zbyt żmudne. Przeważnie polega to na powielaniu informacji, które można wyczytać z nazw funkcji i parametrów. Jednak naprawdę ważne jest, aby na początku opracować ogólny projekt tego, co mają robić poszczególne elementy. Musi to być opis, który wszyscy rozumieją. Musi to być także Peter Norvig 207 prawidłowe rozwiązanie. Jedną z najważniejszych rzeczy w pracy nad udanymi projektami jest to, aby ludzie mieli doświadczenie wystarczające do zbudowania odpowiedniego programu. Jeżeli te- go brakuje, a rozwijasz coś, czego wcześniej nie tworzyłeś, i nie wiesz, jak to zrobić, następnym najlepszym podejściem jest zachowanie elastyczności, tak aby można wprowadzić zmiany po po- pełnieniu błędu. Seibel: Jak długo możesz zastanawiać się, jak coś powinno działać, jeśli wcześniej nie budowałeś podobnego rozwiązania? Czy musisz zacząć pisać kod, aby naprawdę zrozumieć problem? Norvig: Jednym ze sposobów myślenia o rozwiązaniu jest cofanie się. Chcesz osiągnąć końcowy stan, czyli dobry produkt, a w przypadku niektórych problemów istnieje tylko jedno dobre roz- wiązanie. W innych sytuacjach są ich miliony i można wybrać wiele różnych kierunków, a każdy z nich będzie porównywalny z innymi. Dlatego uważam, że praca wygląda inaczej, w zależności od rodzaju problemu. Następnie warto zastanowić się nad trudnymi i prostymi wyborami. Co doprowadzi do prawdzi- wych kłopotów, jeśli dokonasz niewłaściwego wyboru w obszarze architektury? Jeżeli natrafisz na wbudowane ograniczenia lub po prostu utworzysz złe rozwiązanie? W Google natrafiamy na pro- blemy każdego rodzaju. Cały czas powraca problem skalowalności. Jeśli spojrzymy na obecny stan rzeczy i stwierdzimy, że zbudujemy coś, co potrafi obsłużyć dziesięciokrotnie większe obciążenie, za kilka lat wzrost przekroczy szacunki. Wtedy trzeba będzie wyrzucić rozwiązanie i zacząć wszyst- ko od nowa. Należy jednak dokonać prawidłowego wyboru przynajmniej w kontekście wybranych warunków działania. System ma działać dla przedziału od miliarda do dziesięciu miliardów stron internetowych. Co to oznacza w kategoriach rozpowszechniania danych do wielu maszyn? Jakie- go rodzaju dane będą przesyłane w obu kierunkach? Trzeba przekonująco opisać system na tym poziomie. Na niektóre pytania można odpowiedzieć na podstawie obliczeń wykonanych na ser- wetce, w innych przypadkach trzeba przeprowadzić symulacje, a w niektórych sytuacjach — prze- widzieć przyszłość. Seibel: Wydaje mi się, że na tego rodzaju pytania znacznie łatwiej odpowiedzieć poprawnie na podstawie obliczeń na serwetce lub symulacji niż przez pisanie kodu. Norvig: Tak, też tak uważam. W takich sytuacjach obliczenia są prawdopodobnie lepszym podej- ściem. Pojawiają się też inne kwestie. Producent informuje, że w przyszłym roku udostępni prze- łącznik, który obsłuży dziesięciokrotnie większy ruch. Czy zaprojektujesz program pod tym kątem? Czy wierzysz producentowi? A może zaprojektujesz program na podstawie dzisiejszych możliwo- ści? Wymaga to uwzględnienia wielu plusów i minusów. Występują też problemy związane z interfejsem użytkownika, które pojawiają się dopiero po utwo- rzeniu produktu. Myślisz, że interakcja będzie przebiegać doskonale, ale kiedy pokazujesz program użytkownikom, połowa z nich nie potrafi z niego korzystać. Wtedy trzeba zrobić krok wstecz i wy- myślić coś nowego. Seibel: Pomińmy teraz projektowanie interakcji z użytkownikami. Kiedy warto tworzyć prototy- py, zamiast tylko wyobrażać sobie, jak coś będzie działać? Norvig: Myślę, że warto wyobrazić sobie rozwiązanie, aby stwierdzić, czy będzie działać. Warto określić, czy wygląda na wygodne. Przydatny jest zestaw narzędzi pomagający zbudować potrzeb- ne rozwiązanie, a także ułatwiający modyfikowanie systemu w przyszłości. Jeśli zaczniesz tworzyć prototyp i nagle okaże się, że jest niewygodny, może przygotowałeś zły zestaw podstawowych ele- mentów. Warto dowiedzieć się o tym tak wcześnie, jak to możliwe. Seibel: Jak oceniasz pomysł sterowania projektowaniem za pomocą testów? 208 Sztuka kodowania. Sekrety wielkich programistów Norvig: Traktuję testy bardziej jak technikę poprawiania błędów niż projektowania. Ekstremalne podejście działa mniej więcej tak: „Najpierw piszemy test, który na końcu pracy poinformuje, że mamy poprawne rozwiązanie”. Potem uruchamiamy test. Kończy się niepowodzeniem, a wtedy pytamy: „Czego teraz potrzebuję?”. Według mnie, nie jest to odpowiednia metoda projektowania. Wydaje mi się, że technika ta miałaby sens tylko wtedy, gdyby istniało z góry określone rozwiąza- nie. Uważam, że najpierw trzeba pomyśleć o problemie. Trzeba zadać sobie pytania: „Jakie elemen- ty występują? Jak napiszę testy dla elementów, skoro niektórych nie znam?”. Następnie, po przej- ściu tego etapu warto utworzyć testy dla każdego elementu i dobrze zrozumieć interakcje między nimi, przypadki brzegowe itd. Testy należy przygotować dla wszystkich elementów. Nie sądzę jednak, że cały proces projektowania powinien być sterowany stwierdzeniem: „Test zakończył się niepowodzeniem”. Inną rzeczą, która mi nie odpowiada, jest to, że wiele problemów, na które natrafiamy w firmie Google, nie wpasowuje się w prosty dwuwartościowy model testowania. Kiedy przyjrzysz się ze- stawom testów, zobaczysz asercje assertEqual, assertNotEqual, assertTrue itd. Jest to przydatne, ale chcemy też używać asercji w rodzaju assertAsFastAsPossible i zastosować ją do dużej bazy danych możliwych zapytań. Uzyskujemy precyzję na określonym poziomie przy wykrywalności na danym poziomie i chcielibyśmy to zoptymalizować. Pakiety testów nie obejmują tego rodzaju statystycznych lub ciągłych wartości, które próbujesz zoptymalizować, a tylko dwuwartościowe testy informujące, czy rozwiązanie jest prawidłowe, czy błędne. Seibel: Jednak ostatecznie wszystko można przekształcić na logikę dwuwartościową. Wystarczy uruchomić zestaw zapytań, zapisać wszystkie wartości i sprawdzić, czy znajdują się w odpowied- nim przedziale. Norvig: Jest to możliwe. Jednak na podstawie metod dostępnych w pakietach testów można stwier- dzić, że nie są one dostosowane do wykonywania takich zadań. Jestem zaskoczony tym, jak bardzo opisane przeze mnie podejście jest akceptowane w Google. Kiedy pracowałem w Junglee, pamię- tam, że musiałem nauczyć go ludzi z działu jakości. Pracowaliśmy nad wyszukiwarką cen i po- wiedziałem: „Potrzebuję testu. To zapytanie ma dawać 80 prawidłowych odpowiedzi”. Dział ja- kości odpowiedział: „W porządku! A więc zła odpowiedź oznacza błąd, prawda?”. Powiedziałem: „Nie, jedna zła odpowiedź jest dopuszczalna, jeśli nie ma ich więcej niż 80 ”. Na to dział jakości stwierdził: „A więc zła odpowiedź nie jest błędem?”. Traktowali to tak, jakby były tylko dwie moż- liwości. Nie wpadli na pomysł, że chodzi bardziej o pewien kompromis. Seibel: Jesteś jednak zwolennikiem testów jednostkowych. W jaki sposób programiści powinni traktować testy? Norvig: Należy pisać wiele testów. Programiści powinni myśleć o różnych warunkach. Uważam, że obok testów jednostkowych warto używać bardziej złożonych testów regresyjnych. Trzeba też zastanowić się nad symptomami błędów. Pamiętam jedną ze znakomitych lekcji na temat progra- mowania. Zjawiłem się na lotnisku Heathrow, a akurat miała miejsce awaria prądu i żaden z kom- puterów nie działał. Mimo to, mój samolot wystartował zgodnie z planem. Obsługa znalazła gdzieś wydruki dotyczące wszystkich lotów. Nie wiem, skąd je wzięli — jeden z komputerów musiał działać poza lotniskiem. Nie wiem, czy obsługa wydrukowała dane tylko tego dnia, czy robią to zawsze poprzedniego wieczoru, a jeśli nie wystąpi awaria, po prostu wyrzu- cają wydruki do śmieci. Jednak dane były dostępne i obsługa przy bramkach znała procedurę ko- rzystania z papierowego rozwiązania awaryjnego zamiast systemu komputerów. Uznałem to za doskonałą lekcję z dziedziny projektowania oprogramowania. Sądzę, że większość programistów nie myśli o tym, jak program zadziała, kiedy zabraknie prądu. Peter Norvig 209 Seibel: Jak działa Google bez zasilania? Norvig: Google nie funkcjonuje zbyt dobrze bez prądu. Jednak mamy awaryjne generatory i kilka centrów danych. Ponadto myślimy, jak będzie działał dany fragment, jeśli serwer będzie nieak- tywny lub wystąpią inne awarie. Jeżeli program działa na tysiącu maszyn, zastanawiamy się, co się stanie, kiedy jedna z nich przestanie pracować. W jaki sposób obliczenia zostaną wznowione w in- nym miejscu? Seibel: Knuth w eseju na temat rozwijania programu TeX napisał o włączaniu destrukcyjnej oso- bowości do kontroli jakości i dokładaniu wszelkich starań w celu wywołania awarii w swoim ko- dzie. Jak myślisz, czy większość programistów dobrze sobie z tym radzi? Norvig: Nie. Mam przykład w postaci mojego narzędzia do sprawdzania pisowni. Popełniłem błąd w kodzie, który mierzył, jak dobrze sobie radzę, a w tym samym czasie wprowadziłem drobne zmiany w kodzie programu. Uruchomiłem aplikację i uzyskałem o wiele lepszy wynik. I uwierzy- łem w ten wynik! Gdyby był znacznie gorszy, nigdy bym nie pomyślał, że drobna zmiana w funk- cji to spowodowała. Jednak chciałem wierzyć, że drobna modyfikacja znacznie poprawiła wynik. A powinienem być sceptyczny i pomyśleć: „Nie, to nie mogło mieć tak dużego wpływu. Coś musi być nie tak”. Seibel: W jaki sposób unikasz nadmiernego uogólniania i tworzenia większej ilości kodu, niż to potrzebne, oraz marnowania w ten sposób zasobów? Norvig: To ciągła walka i wiele bitew. Prawdopodobnie nie jestem najlepszą osobą, aby odpowie- dzieć na to pytanie, ponieważ wolę rozwiązania eleganckie od praktycznych. Dlatego muszę walczyć ze sobą i powtarzać, że w czasie pracy nie mogę pozwolić sobie na tego rodzaju myślenie. Muszę powiedzieć: „Jesteśmy tu, aby udostępnić najsensowniejsze rozwiązanie. Jeśli istnieje rozwiązanie doskonałe, prawdopodobnie nie stać nas na jego przygotowanie”. Musimy zrezygnować i stwier- dzić: „Zrobimy to, co jest w tej chwili najważniejsze”. Muszę przypominać o tym sobie i osobom, z którymi pracuję. W języku niemieckim jest powiedzenie, że lepsze jest wrogiem dobrego. Zapo- mniałem, skąd dokładnie pochodzi. Każdy praktyczny inżynier musi nauczyć się tej lekcji. Seibel: Dlaczego takie kuszące jest rozwiązywanie problemów, które tak naprawdę nie istnieją? Norvig: Chcesz poczuć się mądry i zamknąć pewien etap — ukończyć coś i przejść do innych za- dań. Uważam, że ludzie są zbudowani tak, iż potrafią zajmować się tylko określoną ilością rzeczy. Dlatego chcesz powiedzieć: „To jest już gotowe. Mogę o tym zapomnieć i iść dalej”. Jednak mu- sisz policzyć, jaki będzie zwrot z inwestycji w przygotowanie całego rozwiązania. Ilustruje go zaw- sze krzywa w kształcie litery S, dlatego po ukończeniu prac na poziomie 80 – 90 zyski są coraz mniejsze. W dolnej części krzywej znajduje się setka innych rzeczy, które przyniosą większy zwrot. W pewnym momencie trzeba powiedzieć: „Wystarczy. Zakończmy to i zabierzmy się za coś, co da lepsze wyniki”. Seibel: W jaki sposób programiści mogą nauczyć się lepiej określać miejsce na krzywej, w którym obecnie się znajdują? Norvig: Uważam, że potrzebne jest odpowiednie, nastawione na wyniki środowisko. Myślę, że ludzie potrafią się sami tego nauczyć. Chcesz zoptymalizować efekty, ale jeśli zostaniesz pozosta- wiony sam sobie, zadbasz w własne poczucie komfortu. Jednak wyniki należy optymalizować pod innym kątem. Według niektórych chodzi o zwrot z inwestycji dla firmy, według innych — o za- dowolenie klientów. Trzeba pomyśleć, jakie będą zyski dla klienta, jeśli rozbuduję daną funkcję z 95 do 100 , zamiast pracować nad dziesięcioma innymi funkcjami, których poziom rozbudowy wynosi 0 . 210 Sztuka kodowania. Sekrety wielkich programistów W Google jest to proste, ponieważ pracujemy zgodnie z filozofią „udostępniaj wcześnie i często”. Wynika to także z wielu cech tej firmy. Po pierwsze, za większość produktów nie pobieramy opłat, dlatego łatwo powiedzieć: „No cóż, udostępnijmy to. Jak bardzo użytkownicy mogą się skarżyć?”. Po drugie, nie tłoczymy płyt CD i nie umieszczamy ich w pudełkach, dlatego jeśli coś nie jest go- towe na dziś i nawet jeżeli wystąpi błąd, nie prowadzi to do katastrofy. Większość oprogramowa- nia znajduje się na serwerach, dlatego możemy jutro wprowadzić poprawki, a wszyscy natychmiast otrzymają aktualizacje. Nie miewamy koszmarów o instalowaniu aktualizacji. Dlatego łatwiej nam powiedzieć: „Udostępnimy to, uzyskamy informacje zwrotne od użytkowników, a potem popra- wimy, co trzeba, i nie będziemy przejmować się innymi elementami”. Seibel: Jakich narzędzi używasz, kiedy projektujesz duży system? Czy siedzisz nad arkuszem pa- pieru technicznego, czy używasz narzędzia do rysowania diagramów UML? Norvig: Nigdy nie lubiłem narzędzi w rodzaju UML-a. Zawsze uważałem, że jeśli nie można cze- goś zrobić w samym języku, jest to jego wada. Myślę, że wiele rzeczy rozpatrujemy na wyższym poziomie. W Google często się zastanawiamy, jak podzielić pewne zadania i wykonywać je rów- nolegle. Kod trzeba uruchamiać na wielu maszynach, jednak mamy tak wielu użytkowników i — w przypadku licznych aplikacji — tak dużo danych, że nie wiadomo, jak ma działać. Dlatego czę- ściej myślimy na poziomie maszyn i szafek z komputerami niż na poziomie funkcji i interakcji. Kiedy ogólne kwestie zostaną ustalone, można zająć się poszczególnymi funkcjami i metodami. Seibel: Czyli na tym poziomie opisu używacie po prostu języka naturalnego? Norvig: Tak, przede wszystkim. Niektóre osoby przygotowują rysunki i mówią: „Ten serwer bę- dzie obsługiwał żądania tego rodzaju i będzie połączony z tym serwerem. Następnie użyjemy tych narzędzi do przechowywania danych oraz wykorzystamy dużą rozproszoną tablicę haszującą i in- ne mechanizmy. Zastosujemy te trzy gotowe narzędzia, a następnie zastanowimy się, czy musimy budować nowe. Pomyślimy, które z istniejących rozwiązań się sprawdzają i czy potrzebujemy cze- goś innego”. Seibel: Jak przebiega ocena projektów tego rodzaju? Norvig: Trzeba pokazać je osobom, które wcześniej wykonywały podobne zadania. Te osoby mo- gą powiedzieć: „Wygląda na to, że tu potrzebna będzie pamięć podręczna. Sam system będzie za wolny, ale wiele żądań powinno się powtarzać, dlatego bardzo pomocne będzie, jeśli zainstaluje- cie tu pamięć podręczną o tym rozmiarze”. Należy przeprowadzić przegląd projektu, w czasie któ- rego ludzie przyglądają się projektowi i oceniają, czy ma sens. Następnie można rozpocząć two- rzenie i testowanie rozwiązania. Seibel: Czy przeprowadzacie formalne przeglądy projektów? Pracowałeś w NASA, gdzie przeglą- dy projektów były bardzo formalne. Norvig: Nie stosujemy żadnego formalnego podejścia, inaczej niż NASA. Stawka jest niższa, po- nieważ łatwo można przywrócić stan systemu po wystąpieniu awarii. W NASA zwykle pierwsza awaria jest krytyczna, dlatego potrzebna jest znacznie dalej posunięta ostrożność. W Google nie przejmujemy się tym tak bardzo. W większym stopniu przeprowadzamy konsultacje niż przeglądy. Niektóre osoby oficjalnie czytają dokumenty projektowe i oceniają je. Należy przejść ten etap, a projekt zostaje zatwierdzony. Jednak jest to znacznie mniej formalne niż w NASA. Taki prze- gląd ma miejsce przed uruchomieniem projektu. W trakcie jego trwania odbywają się okresowe przeglądy, jednak nie obejmują one dogłębnej analizy kodu. Bardziej chodzi o pytania: „Jak wam idzie? Czy wyprzedzacie harmonogram, czy może macie opóźnienie? Jakie duże problemy wystą- piły?” — i inne z tego poziomu. Peter Norvig 211 Najbardziej formalny jest proces udostępniania oprogramowania. Używamy listy kontrolnej, któ- ra jest bardzo formalna w zakresie bezpieczeństwa. Jeśli udostępnimy rozwiązanie, czy ktoś będzie mógł się włamać i zastosować technikę XSS, aby przejąć inny komputer? Zasady są dość ścisłe. Seibel: Pewnego razu powiedziałeś mi, że kiedy Guido van Rossum przyszedł do firmy, musiał przejść test z Pythona, a Ken Thompson — test z języka C, aby potwierdzić, że spełniają bardzo ści- śle określone standardy kodowania. Czy macie równie ściśle określone standardy projektowania? Norvig: Nie. Niektóre standardy kodowania dotyczą kwestii projektowych, natomiast w zakresie projektu swoboda jest dużo większa. Jednak określone są pewne zasady, dlatego programista musi otrzymać certyfikat, zanim zacznie przesyłać kod do repozytorium. Każdy przesyłany kod musi zostać przejrzany przez kogoś innego i zweryfikowany. Seibel: Czy każdy kod przesyłany do repozytorium p4 depot jest przeglądany? Norvig: Można samodzielnie tworzyć eksperymentalne rozwiązania. Ponadto występują wyjątki, kiedy można przesłać kod, który zostanie przejrzany w przyszłości. Jednak programiści powinni jak najrzadziej stosować to podejście. Seibel: W zasadzie sprowadza się to do klasycznej analizy kodu. Pokazujesz kod, ktoś go czyta i mówi: „Tak, to jest poprawne”. Norvig: Tak. Tego dotyczył pierwszy projekt Guida. Używaliśmy standardowych narzędzi diff do sprawdzania kodu, co było dość niewygodne. Dlatego Guido napisał rozproszony system z bar- dziej wymyślnym wyglądem i kolorowaniem kodu, co usprawniło przeglądanie przesyłanych frag- mentów. Seibel: Firmy twierdzą, że należy przeprowadzać przeglądy, jednak bardzo rzadko to robią. Na pewnym poziomie trzeba wyszkolić ludzi do wykonywania tego zadania. Norvig: Uważam, że zawsze tak było, dlatego ludzie to akceptują. No cóż, może nie całkowicie. Niektóre osoby potrzebują czasu, aby się przyzwyczaić. Jeden z typowych problemów ma miejsce, kiedy przychodzi nowy pracownik, który nie jest przyzwyczajony do danego sposobu pracy. Taka osoba tworzy eksperymentalne odgałęzienie i przechowuje w nim cały kod. Inni pracownicy mó- wią mu: „Słuchaj, nie przesłałeś jeszcze żadnego kodu”. Taka osoba odpowiada: „Tak, tak, właśnie go porządkuję. Prześlę kod jutro”. Mija następny tydzień, potem jeszcze następny, aż wreszcie nowy pracownik przesyła gigantyczny pakiet kodu. Oznacza to problemy. Minęło zbyt dużo cza- su, trudno ocenić cały kod na raz, a niektóre rzeczy uległy zmianie. Wtedy nowa osoba widzi kło- poty, do jakich doprowadziła, i uczy się tego nie robić. Seibel: To dotyczy pisania kodu. Czy recenzenci rozwijają jakieś umiejętności? Norvig: Oczywiście, są osoby uznawane za lepszych recenzentów od innych. Przy przeglądach trzeba uwzględnić plusy i minusy dwóch podejść — możesz pójść do kogoś, od kogo uzyskasz wiele cennych informacji zwrotnych, lub wybrać osobę, która jak najszybciej zatwierdzi kod. Seibel: Co sprawia, że niektórzy recenzenci są lepsi? Norvig: Dostrzegają więcej rzeczy. Niektóre z nich to banalne kwestie, np. zła liczba odstępów we wcięciu itp., jednak czasem można usłyszeć: „Uważam, że projekt będzie bardziej przejrzysty, jeśli przeniesiesz to tutaj”. Dlatego niektóre osoby częściej przeprowadzają przeglądy, a inne się tym nie zajmują. 212 Sztuka kodowania. Sekrety wielkich programistów Seibel: Następne pytanie po części jest z tym związane. Czy każdy dobry programista zostaje do- brym architektem? A może niektóre osoby są doskonałymi koderami, ale tylko na pewnym pozio- mie, dlatego nie należy pozwalać im rozwijać większych projektów? Norvig: Uważam, że poszczególne osoby mają różne umiejętności. Jeden z naszych najlepszych ludzi zajmujących się wyszukiwaniem z pewnością nie jest najlepszym programistą, jeśli chodzi o wygląd kodu. Jednak kiedy spytasz: „Ten nowy czynnik — no wiesz, liczba kliknięć na stronie po zrobieniu tego i tego — jak włączyć go w wyniki wyszukiwania?”, on odpowie: „Och, w wierszu czterysta dwudziestym siódmym znajduje się zmienna alpha. Musisz wziąć nowy czynnik, pod- nieść go do kwadratu, pomnożyć to przez półtora i dodać do tej zmiennej”. Eksperymentujesz przez kilka miesięcy i wypróbowujesz różne rozwiązanie, po czym odkrywasz, że twój rozmówca miał rację, tylko należy użyć wartości jeden i trzy dziesiąte zamiast jeden i pięć. Seibel: Chcesz więc powiedzieć, że ta osoba ma bardzo dobry model rozumowy działania opro- gramowania? Norvig: Perfekcyjnie rozumie kod. Inne osoby potrafią lepiej pisać kod, ale on rozumie wszystkie skutki różnych rozwiązań. Seibel: Czy uważasz, że te kwestie są powiązane? Często mam wrażenie, że osoby, które piszą naj- mniej zrozumiały kod, potrafią utrzymywać w głowie najwięcej informacji. To tylko dzięki temu mogą pisać kod tego rodzaju. Norvig: Tak, myślę, że rzeczywiście może tak być. Seibel: Tak więc przeglądy w Google są mniej formalne niż w NASA. Jakie inne różnice występu- ją między etosem „inżyniera” i „hakera” w najlepszym tych słów znaczeniu? Norvig: Poważną różnicą jest struktura organizacji i sposób akceptowania oprogramowania. Google założono jako firmę związaną z oprogramowaniem, a następnie zatrudniono dyrektora wykonaw- czego z tytułem doktora nauk komputerowych z Berkeley i wiceprezesa do spraw sprzedaży z do- świadczeniem w inżynierii komputerowej. Takie sytuacje mają miejsce w całej firmie. W NASA pracują naukowcy od rakiet! Nie znają się na oprogramowaniu. Mówią: „Oprogramowanie to zło konieczne. Prosty wiersz kodu potrafię jeszcze zrozumieć. Jeśli występuje pętla, sprawy się kompli- kują. Jeżeli wewnątrz pętli znajduje się rozgałęzienie, no cóż, wtedy odbiegamy od tego, co mogę rozwiązać za pomocą równania różniczkowego z teorii kontroli”. Dlatego nie mają zaufania do kodu. Seibel: Choć powinni! Norvig: To prawda, powinni. Nie mają też zaufania do innowacji. Możesz powiedzieć: „Popatrz, jaki świetny prototyp przygotowałem”. Usłyszysz odpowiedź: „To fantastyczne. Chciałbym pole- cieć tym na misję, kiedy zostanie już sprawdzony w dwóch innych lotach”. Możesz pójść do do- wolnej innej osoby i usłyszysz to samo. Dan Goldin objął stanowisko administratora w NASA i powiedział: „Musimy pracować lepie
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Sztuka kodowania. Sekrety wielkich programistów
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: