Fanem Joela Spolsky’ego jestem od paru lat. Ten niesamowicie trzeźwo myślący właściciel niewielkiej nowojorskiej firmy softwareowej przeszedł całą ścieżkę, od szeregowego programisty, poprzez managera produktu a na właścicielu firmy skończywszy. Jego witryna, prezentująca rozsądne podejście do informatyki, stopniowo zaczyna przedostawać się do „głównego nurtu” biznesu informatycznego – ostatnio na porady rekrutacyjne Joela powoływał się Computerworld.
Na podstawie pisanego przez lata blogu, Joel wysmażył zresztą kilka książek (w skład których wchodzą rozbudowane i przeredagowane wpisy z blogu). Parę lat temu wydawca Joela postanowił (jak sądzę) zrobić „skok na kasę” i pokazać nam, czytającym Joela, co czytam sam Joel. Rezultatem jego selekcji był wybór 29 „tekstów” autorstwa 27 osób. Każdy z rozdziałów opatrzony jest komentarzem Joela (i czasami zdarza się niestety, że komentarz ten jest ciekawszy niż tekst owego cytowanego autora…). Książka nosi polski tytuł “Sztuka pisania oprogramowania. Wybór i redakcja Joel Spolsky”, zaś w wersji angielskiej po prostu – “The Best Software Writing I: Selected and Introduced by Joel Spolsky”. Niestety,to już kolejny przykład jak dowcipne i wieloznaczne tytułyJoela tracą przy przekładzie…
Książka rozpoczyna się od rozważania Kena Arnolda o ważności stylu w programowaniu. Styl rozumiany jest tu jak najbardziej dosłownie – ilość spacji, rodzaje wcięć, wielkość liter w nazwach zmiennych, etc. Każdy z nas zna uczucie, gdy chce (musi) poznać działanie jakiegoś kawałka systemu i – łup – zostaje ogłuszony jakimś kosmicznie zamotanym stylem. Ken proponuje dość kontrowersyjne rozwiązanie tego problemu. Czy ma szansę się ono przyjąć? Cóż… zobaczymy 😉
Wbrew temu, co mogłoby wynikać z pierwszego rozdziału, książka nie dotyczy jedynie oprogramowania rozumianego jako tworzenie pojedynczych linijek kodu. Oto bowiem Michael Bean rozprawia się z koncepcjami outsourcingu programistycznego, a jego tekst, czytany z perspektywy polskiej, wyjaśnia dlaczego polskie oddziały dużych informatycznych korporacji „babrają się w jakimś g*****”. Problem złożoności procesu tworzenia oprogramowania atakuje z innej strony Adam Bosworth, promujący zasadę tworzenia prostych rozwiązań, które będą zrozumiałe dla wielu i przez to uniwersalne, podając jako przykład język SGML, którego prawie nikt nie rozumiał, a który po znaczących „cięciach” dokonanych przez Barnesa – Lee jako HTML opanował świat. Wiele o tym, na czym tak naprawdę polega biznes informatyczny mówi krótki esej Raymonda Chena, który odpowiadał miedzy innymi za kompatybilność wsteczną Windows 95. Raymond opisuje jak projektanci Windows 95 zezwolili aplikacji SimCity na dokonywanie rzeczy, której system operacyjny absolutnie nie powinien tolerować: na pisanie po zwolnionym obszarze pamięci. Działanie takie było konieczne, gdyż twórcy SimCity stworzyli swoją aplikację w sposób iście hakerski, wykonując triki, które choć nielegalne, pod Dosem były możliwe, lecz w Windows nie powinny w ogóle działać. Microsoft wiedział jednak, że jeśli SimCity przestanie działać w Windows 95 – zdesperowani użytkownicy SimCity stwierdzą że „w Dosie działa, Windows jest do bani”. Stąd wprowadzono „zaślepkę”. Podejście Chena, obecnie zarzucone, nie jest jednak pozbawione logiki: sam wielokrotnie czytałem różne fora dyskusyjne, gdzie gracze narzekali na Windows Vista, iż w tym systemie nie działają ich ulubione gry, przestrzegając innych graczy przed upgradem…
Tego typu praktyki związane są z testowaniem, którego wagę stara się podkreślić Bruce Eckel, proponujący rezygnację z całej tej okazałej menażerii wyjątków w Javie, i zamiast nich rzucanie jedynie RuntimeException. Uzyskany w ten sposób czas, należałoby przeznaczyć na bardziej skrupulatne testowanie. Czasami myślę sobie, że Bruce Eckel przeżył ten komentarz tylko dlatego, że bez nowych wydań „Thinking In Java” środowisko programistów Javy umarłoby niczym ryba bez wody…
Ciekawie kształtują się tematy dotyczące spraw „ludzkich” w informatyce. Autor (lub autorka) ukrywający się pod pseudonimem ea_spouse przedstawia nam prawdziwe realia pracy w Electronic Arts nad kolejnymi edycjami gry FIFA, nad którymi pracuje jej / jego mąż. Pracowałem w kilku firmach, ale takiej plantacji bawełny, jak w tym rozdziale w życiu nie widziałem. Cóż, rotacja 50% powoduje, że w firmie zostają sami nieudacznicy lub złapani na korpolep absolwenci. Czynnik ludzki zdaje się wszak decydować: o wpływie dobrych ludzi na projekt pisze także Paul Graham, rozważający pojęcie „Wielkiego Hakera”. Haker jest tu rozumiany w pierwotnym znaczeniu, jako superspecjalista. Rekrutację specjalistów omawia Erik Sink, pisząc o niebezpieczeństwach i loterii związanej z zatrudnianienim (nie tylko specjalistów, ale i handlowców, których to Sink omawia przy okazji dwuczęściowej rozprawy o tym, jak małe firmy IT winny przybliżać klienta do siebie i w ten sposób zwiększać sprzedaż).
W tekstach przewijają się także sprawy związane z organizacją – Mary Poppendick opisuje jak systemy motywacyjne w firmach mogą zabijać motywację (vide obiecywanie wielkich premii za dotrzymanie terminu, o którym wszyscy wiedzą, że jest absolutnie niemożliwy do dotrzymania), natomiast Larry Osterman pokazuje jak NIE wynagradzać testerów (i dlaczego). Ciekawy jest też krótki poradnik dla świeżo mianowanego kierownika technicznego projektu, którego autorem jest Michael „Rands” Loop. W przyjemny sposób polepsza on humor, opisując jak obsuwający się termin nie jest tak wielkim problemem, jakby się nam mogło zdawać.
Autorzy poszczególnych rozdziałów opisują nam też świat, którego istnienia często nie zauważamy. Eric Lippert opisuje na przykład, ilu pracowników Microsoftu potrzeba do napisania jednej prostej funkcji. Trzeba przyznać, że rezultat jest zaskakujący – o ile samo napisanie kodu zajmuje pięć minut, o tyle analiza pod kątem bezpieczeństwa, stabilności, dostępności trwa kilka dni. Dodanie do systemu dokumentacji i przetłumaczenie jej na wszystkie niezbędne języki (dla nas z reguły cała dokumentacja jest dokumentacją angielską, nie zapominajmy jednak, że angielski jest jednym z głównych języków w Microsoft – hiszpański czy japoński są dla nich równie ważne). Wydaje się, że to co pisze Lippert stanowi jasną granicę między programowaniem studenckim, a wielkoskalowym programowaniem przemysłowym – może granica ta nie jest wprost zaznaczona, jednak jej istnienie zaczynamy po lekturze zauważać.
Ciekawą rozrywkę stanowią z kolei krótkie humoreski i pastisze: Ken Bambrick naśmiewa się z „psa do wyszukiwania” w Windows XP, Rory Blyth pokazuje jak marketingowcy używają Excela, Kelvin Cheng i Tom Chi „kopią lamę” a Aaron Swartz „miksuje” eseje w Power Poincie.
Niestety, pomimo tylu pieśni pochwalnych, w zbiorze są także teksty niestrawne, dotykające może ciekawej tematyki, ale zupełnie, zupełnie niestrawne. Fanem jednego z tych autorów jest Joel Spolsky, piszący o „pięknych zdaniach”. Nie wiem, być może piękne owe zdania były po angielsku, ale jak dla mnie są one grafomanią i bełkotem. Pozwolę sobie nie podawać nazwisk autorów owych tekstów – kto przeczyta książkę, sam będzie się miał okazję przekonać.
Całość tomu domknięta jest przez istną perełkę w świecie dydaktyki – jest to „Krótka, ilustrowana i (mam nadzieję) bezstresowa wycieczka po języku Ruby napisana przez autora ukrywającego się pod pseudonimem why the lucky stiff. Krótki i sprawiający niesamowitą radość w czytaniu tekst, okraszony wieloma komiksowymi rysunkami i dygresjami opisuje cały język Ruby. Joel podaje go jako przykład jak można ciekawie napisać o języku. I trudno się z Joelem w tym miejscu nie zgodzić…
Joel Spolsky (wybór i redakcja): Sztuka pisania oprogramowania. Wybór i redakcja Joel Spolsky, Helion, Gliwice 2007
PS: Wcale nie jestem w Helionie na prowizji 😉