Mistrz czystego kodu. Kodeks postępowania profesjonalnych programistów - ebook

Pochwały dla _Mistrza czystego kodu_

Wujek Bob Martin w swojej nowej książce zdecydowanie podnosi poprzeczkę. Opisuje swoje oczekiwania wobec zawodowych programistów w zakresie interakcji z kadrą zarządzającą, zarządzania czasem, radzenia sobie z presją, współpracy w zespole oraz doboru narzędzi. Martin zaznacza, że każdy programista chcący uznawać się za profesjonalistę powinien znać techniki wykraczające poza TDD oraz ATDD, a dodatkowo powinien ściśle śledzić ich rozwój, tak żeby podsycać swoją pasję do programowania.

_— Markus Gärtner_

_Senior Software Developer_

_it-agile GmbH_

_www.it-agile.de_

_www.shino.de_

Niektóre książki techniczne nie tylko uczą, ale też inspirują. Inne zachwycają i bawią. Tylko rzadko zdarza się, żeby książka techniczna miała te wszystkie cechy. Książki Roberta Martina zawsze na mnie działały, a _Mistrz czystego kodu_ nie jest tu wyjątkiem. Czytaj, ucz się, poznawaj lekcje zawarte w książce, a z pewnością uznasz się za zawodowego programistę.

_— George Bullock_

_Senior Program Manager_

_Microsoft Corp._

Jeżeli do uzyskania tytułu nauk komputerowych konieczne byłoby przeczytanie pewnej lektury, to na pewno byłaby to ta książka. W rzeczywistym świecie zły kod nie znika po zakończeniu semestru, nie dostaje się piątki za maraton kodowania na dzień przed oddaniem projektu, a najgorsze jest to, że trzeba kontaktować się z innymi ludźmi. Oznacza to, że guru programowania niekoniecznie można nazwać zawodowcami. _Mistrz czystego kodu_ opisuje podróż w kierunku profesjonalizmu… a robi to w wyjątkowo zabawny sposób.

_— Jeff Overbey_

_Uniwersytet stanu Illinois w Urbana–Champaign_

_Mistrz czystego kodu_ jest czymś więcej niż tylko zbiorem zasad i wskazówek. Zawiera mądrość popartą praktyką oraz wiedzę, którą normalnie trzeba zdobywać przez lata prób i błędów, pracując jako uczeń mistrza. Jeżeli nazywasz siebie zawodowym programistą, to ta książka jest dla Ciebie niezbędna.

_— R.L. Bogetti_

_Lead System Designer_

_Baxter Healthcare_

_www.RLBogetti.com_W latach od 1986 do 2000 ściśle współpracowałem z Jimem Newkirkiem, kolegą z firmy Teradyne. Mieliśmy wspólną pasję do programowania i tworzenia czystego kodu. Razem spędzaliśmy całe wieczory i noce, a nawet weekendy, bawiąc się różnymi stylami programowania oraz technikami projektowymi. Bez ustanku zastanawialiśmy się nad różnymi pomysłami na biznes. W końcu założyliśmy firmę Object Mentor Inc. Podczas wspólnych prac nauczyłem się od Jima wielu rzeczy. Jednak jego najważniejszą cechą była _etyka pracy_. To coś, nad czym staram się cały czas pracować. Jim jest zawodowcem, a ja jestem dumny, że mogłem razem z nim pracować i nazywać go moim przyjacielem.------------------------------------------------------------------------

SŁOWO WSTĘPNE

------------------------------------------------------------------------

Skoro ta książka wzbudziła w Tobie zainteresowanie, to zakładam, że mam do czynienia z zawodowcem. To dobrze, bo i ja się za takiego uważam. A skoro zdobyłem już Twoje zainteresowanie, to pozwól, że powiem, dlaczego ja zająłem się tą książką.

Wszystko zaczęło się nie tak dawno temu, w całkiem nieodległym miejscu. Kurtyna w górę, światła, kamery i Charley…

Kilka lat temu pracowałem w średniej wielkości korporacji sprzedającej produkty podlegające ścisłej regulacji. Z pewnością znasz ten typ: siedzieliśmy w przedziałach, w trzypiętrowym budynku. Dyrektorzy i tym podobni mieli prywatne gabinety, a zebranie wszystkich osób potrzebnych na jednym spotkaniu trwało mniej więcej tydzień.

Działaliśmy na rynku z bardzo dużą konkurencją, a wtedy rząd otworzył drzwi dla całkowicie nowego produktu.

Nagle stanęła przed nami cała rzesza nowych, potencjalnych klientów. Wystarczyło tylko przekonać ich do zakupu naszego produktu. Oznaczało to, że musieliśmy złożyć we właściwym czasie i w odpowiednim urzędzie pewien dokument, następnie w określonym terminie przejść pozytywnie audyt i szybko wprowadzić produkt na rynek.

Od czasu do czasu kadra zarządzająca przypominała nam o tym, jak ważne są poszczególne daty. Jeden poślizg i urzędnicy na rok wykluczą nas z rynku, a jeżeli klienci nie będą mogli skorzystać z naszego produktu już od samego początku, to pójdą do konkurencji, przez co całkowicie wypadniemy z obiegu.

Powstało to specyficzne środowisko, w którym część ludzi narzeka, a inni powtarzają tylko, że „pod ciśnieniem powstają diamenty”.

Byłem technicznym menedżerem projektu, awansowanym z działu rozwojowego. Moim zadaniem było uruchomienie strony projektu w dniu jego oficjalnego udostępnienia, tak żeby potencjalni klienci mogli pobrać niezbędne informacje, a przede wszystkim formularze zamówień. Moim współpracownikiem w ramach tego projektu był menedżer biznesowy, którego tutaj będę nazywał Joe. Jego zadaniem była praca po drugiej stronie, czyli obsługa sprzedaży, marketingu oraz wymagań niezwiązanych z technikaliami. Był też jednym z tych powtarzających frazę o „diamentach powstających pod ciśnieniem”.

Jeżeli zdarzyło Ci się pracować w amerykańskich korporacjach, to zapewne wiesz, że to całe wskazywanie palcem, poszukiwanie winnych i niechęć do pracy są całkowicie naturalne. W naszej firmie Joe i ja znaleźliśmy całkiem ciekawe rozwiązanie tego problemu.

Naszym zadaniem było wykonanie roboty i czuliśmy się z tym zupełnie jak Batman i Robin. Codziennie spotykałem się z zespołem technicznym, za każdym razem poprawialiśmy plan prac, wypatrywaliśmy potencjalnych problemów i usuwaliśmy z naszej drogi wszystkie powstające przeszkody. Jeżeli ktoś potrzebował określonego oprogramowania, to je zdobywaliśmy. Jeżeli ktoś „z chęcią” zająłby się konfiguracją zapory internetowej, ale „o rany, właśnie mam przerwę obiadową”, to kupowaliśmy i dostarczaliśmy cały obiad. Jeżeli ktoś chciał popracować nad problemem z konfiguracją, ale miał aktualnie inne priorytety, to Joe i ja zaczynaliśmy rozmawiać z jego przełożonym.

A potem z menedżerem.

A potem z dyrektorem.

Po prostu wszystko załatwialiśmy.

Może pewną przesadą jest twierdzenie, że przewracaliśmy krzesła, krzyczeliśmy i wrzeszczeliśmy, ale dla osiągnięcia celu wykorzystaliśmy wszystkie znane nam metody, przy okazji wymyślając kilka nowych. Wszystko, co robiliśmy, robiliśmy zgodnie z zasadami etyki, z czego jestem dumny do dzisiaj.

Uważałem się za członka zespołu. Nie byłem ponad to, żeby samodzielnie napisać wymagane zapytanie SQL albo wykonać inne prace, byle tylko przygotować kod na czas. Wtedy podobnie myślałem i o Joe — jako o członku zespołu, a nie kimś ponad nami.

Ostatecznie przekonałem się, że Joe nie podzielał tej opinii. To był dla mnie bardzo smutny dzień.

Był piątek, godzina 13.00, a tworzona przez nas strona była gotowa do uruchomienia w następny poniedziałek.

Byliśmy gotowi. GOTOWI. Każdy system był sprawdzony i przygotowany. Zebrałem cały zespół w ramach ostatniego spotkania scrumu, na którym gratulowaliśmy sobie doskonałej pracy. I nie chodziło tylko o zespół „techniczny”. Towarzyszyły nam też osoby z działu marketingu, a nawet właściciele produktu.

Wszyscy byliśmy dumni. To był naprawdę wspaniały moment.

Wtedy na zebranie wpadł Joe.

Powiedział coś w rodzaju: „Złe wieści. Dział prawny nie przygotował jeszcze formularzy zamówień, czyli nie możemy jeszcze uruchomić strony”.

Nie był to wielki problem. Przez cały czas trwania projektu wstrzymywały nas najróżniejsze przeciwności, dzięki czemu całkiem dobrze odnajdowaliśmy się w rolach Batmana i Robina. Byłem gotowy, dlatego odpowiedziałem: „Dobra, partnerze. Zrobimy to jeszcze raz. Dział prawny jest na trzecim piętrze, o ile pamiętam”.

I wtedy się zaczęło.

Zamiast się ze mną zgodzić, Joe zapytał: „O czym ty w ogóle mówisz, Matt?”.

Odpowiedziałem: „No wiesz, ten nasz zwyczajowy taniec. W końcu chodzi o cztery pliki PDF. Do tego one są gotowe. Dział prawny musi tylko je zatwierdzić. Powisimy w ich boksach, pozłościmy się na nich i w końcu to _załatwią_”.

Joe nie zgodził się z moją oceną i po prostu stwierdził: „Uruchomimy stronę w ciągu przyszłego tygodnia. To przecież żaden kłopot”.

Z pewnością możesz sobie wyobrazić ciąg dalszy tej rozmowy. Szło mniej więcej tak:

Matt: „A niby dlaczego? Przecież mogą to zrobić w parę godzin”.

Joe: „Oj, to może potrwać trochę dłużej”.

Matt: „Przecież mają cały _weekend_. To masa czasu. Do roboty!”.

Joe: „Matt, to przecież zawodowcy. Nie możemy przecież wisieć nad nimi i żądać, żeby poświęcali swój prywatny czas dla naszego małego projektu”.

Matt: (chwila ciszy) „Joe… a co niby robiliśmy z zespołem inżynierów przez kilka ostatnich miesięcy?”.

Joe: „No tak, ale tutaj mówimy o zawodowcach”.

Cisza.

Głęboki oddech.

Co. Joe. Właśnie. Powiedział?

W tym czasie uważałem, że zespół techniczny składał się z zawodowców w najlepszym znaczeniu tego słowa.

Teraz gdy o tym myślę, wcale nie jestem tego pewien.

Przyjrzyjmy się jeszcze raz technice Batmana i Robina, przyjmując tym razem inną perspektywę. Sądziłem, że w ten sposób motywujemy zespół do jeszcze lepszej pracy, ale teraz myślę, że Joe bawił się z nami i zakładał, że zespół techniczny jest jego przeciwnikiem. Wystarczy pomyśleć: Dlaczego konieczne były ciągłe bieganie, przewracanie krzeseł i inne działania?

Czy nie mogliśmy po prostu zapytać zespołu, kiedy będą gotowi, otrzymać solidnej odpowiedzi, w którą moglibyśmy uwierzyć, i się na niej nie sparzyć?

Oczywiście w przypadku zawodowców moglibyśmy… a jednocześnie wcale nie. Joe nie dowierzał naszym zapewnieniom i dlatego uznał, że konieczne będzie mikrozarządzanie całym zespołem technicznym. Równocześnie z tych samych powodów był w stanie zaufać działowi prawnemu i wcale nie chciał stosować wobec nich mikrozarządzania.

O co tu chodzi?

W jakiś sposób dział prawny zademonstrował swój profesjonalizm, czego nie zdołał zrobić zespół techniczny.

Innej grupie udało się przekonać Joego, że niepotrzebny jest jej nadzorca, że nie bawią się w takie gierki i że należy ich traktować jak godnych szacunku współpracowników.

Nie sądzę, żeby miały tu znaczenie te wszystkie certyfikaty wiszące na ścianach ani kilka dodatkowych lat studiów. Choć to ostatnie mogło pomóc w uzyskaniu doświadczenia i umiejętności właściwego zachowania się w takich sytuacjach.

Od tego dnia, a było to już lata temu, zastanawiałem się, jak będą się musiały zmienić zawody techniczne, żeby w końcu ich przedstawicieli uznano za zawodowców.

I rzeczywiście wpadło mi kilka pomysłów. Trochę blogowałem, sporo czytałem, zdołałem poprawić własną sytuację w pracy, a nawet pomóc kilku innym osobom. Nie znam jednak żadnej książki, która szkicowałaby czytelnikowi określony plan i jawnie prezentowała poszczególne elementy.

W końcu któregoś dnia, całkowicie niespodziewanie, otrzymałem ofertę recenzowania wczesnego szkicu książki. Dokładnie tej, którą właśnie trzymasz w ręku.

To z tej książki dowiesz się, jak prezentować się i współpracować jak na zawodowca przystało. Bez stosowania tanich sztuczek, bez wykorzystywania haków, ale właśnie tak, jak należy to robić.

W niektórych przypadkach takie przykłady są absolutnie dosłowne.

Część przykładów zawiera odpowiedzi, kontry, wyjaśnienia, a nawet porady na wypadek, gdyby ta druga osoba próbowała Cię „po prostu ignorować”.

Och, popatrz na to, Joe wraca na scenę, choć tym razem coś się zmienia: znowu jesteśmy w wielkiej firmie, Joe i ja, i znów pracujemy nad wielkim projektem konwersji strony WWW.

Jednak tym razem wyobraź sobie nieco inną sytuację.

Zamiast unikać zobowiązań, zespół techniczny faktycznie je podejmuje. Zamiast przemilczać szacunki albo pozwalać na przygotowywanie planów przez innych (a potem narzekać na te plany), zespół techniczny sam się organizuje i definiuje rzeczywiste zobowiązania.

Wyobraź sobie, że taki zespół rzeczywiście ze sobą współpracuje. Jeżeli infrastruktura „wytrzymuje” programistów, to wystarczy jeden telefon, żeby administratorzy wykonali niezbędne prace.

Gdy Joe zamierza przyspieszyć prace nad błędem 14321, to okazuje się, że nie ma takiej potrzeby, ponieważ od razu widzi, że administrator bazy danych nad nim pracuje, a nie surfuje w sieci. Podobnie wszystkie szacunki, jakie otrzymał od zespołu, nie są ze sobą sprzeczne i nie tworzą wrażenia, że cały projekt otrzymał priorytet gdzieś między obiadem a sprawdzaniem poczty. Na wszelkie próby manipulowania przygotowanym planem zespół nie odpowiada „spróbujemy”, ale „to są nasze zobowiązania, jeżeli chcesz tworzyć własne, to rób je we własnym zakresie”.

Sądzę, że po pewnym czasie Joe zacząłby uważać zespół techniczny za, zaskoczenie, zawodowców. I miałby całkowitą rację.

Co trzeba zrobić, żeby przekształcić się ze zwykłego technika w zawodowca? Wszystko znajdziesz w tej książce.

Witaj na kolejnym etapie swojej kariery. Wydaje mi się, że będzie Ci się podobać.

_— Matthew Heusser_

_Software Process Naturalist_

------------------------------------------------------------------------WPROWADZENIE

------------------------------------------------------------------------

28 stycznia 1986 roku, o godzinie 11.39, po zaledwie 73,124 sekundy od startu, na wysokości 48 000 stóp prom kosmiczny Challenger został rozerwany na strzępy przez uszkodzenie prawego silnika wspomagającego. Zginęło siedmioro dzielnych astronautów, w tym nauczycielka Christa McAuliffe. Do dzisiaj prześladuje mnie wyraz twarzy jej matki obserwującej śmierć swojej córki 15 kilometrów nad sobą.

Challenger rozpadł się, ponieważ gorące gazy wylotowe z uszkodzonego silnika wspomagającego wydostały się spomiędzy segmentów jego obudowy, trafiając na główny zbiornik paliwa. Podstawa głównego zbiornika z ciekłym wodorem została rozerwana, paliwo się zapaliło, przez co zbiornik przesunął się w kierunku zbiornika z ciekłym tlenem. W tym samym momencie silnik wspomagający zerwał się z tylnego wspornika i obrócił wokół tylnego. Jego czubek przebił zbiornik z ciekłym tlenem. Te wszystkie nieskoordynowane siły spowodowały, że lecący z prędkością 1,5 macha prom zaczął obracać się w poprzek strumienia powietrza. Siły aerodynamiczne szybko rozerwały całość na kawałeczki.

Pomiędzy koncentrycznymi segmentami silnika znajdowały się dwie okrągłe uszczelki z syntetycznej gumy. Gdy segmenty były łączone ze sobą, uszczelki zostały ściśnięte, tworząc uszczelnienie, którego gazy wylotowe nie powinny być w stanie przebić.

Niestety, w noc poprzedzającą start temperatura na wyrzutni spadła do –8°C (17°F), czyli o 12°C (23°F) poniżej minimalnej temperatury dla tych uszczelek. Było to też o całych 18°C (33°F) mniej niż przy którymkolwiek wcześniejszym starcie. W efekcie uszczelki zesztywniały i nie były w stanie odpowiednio blokować gorących gazów. W momencie odpalenia silnika wspomagającego nastąpił nagły wzrost ciśnienia wynikający z szybkiego gromadzenia się gazów wylotowych. Segmenty silnika zostały rozciągnięte, co zmniejszyło stopień ściśnięcia uszczelek, które były na tyle zesztywniałe, że nie zdołały się odpowiednio rozprężyć i wypełnić powstałych szczelin. W efekcie część uciekających gorących gazów odparowała uszczelki na długości 70% łuku.

Inżynierowie z firmy Morton-Thiokol, którzy projektowali silniki wspomagające, wiedzieli o problemach z uszczelkami i przez siedem poprzednich lat informowali o nich kadrę zarządzającą firmy oraz NASA. Rzeczywiście uszczelki używane w poprzednich startach zostały uszkodzone na kilka różnych sposobów, choć żadne z tych uszkodzeń nie mogło doprowadzić do katastrofy. Podczas startu w najniższej temperaturze zostały jednak uszkodzone najmocniej. Inżynierowie przygotowali rozwiązanie tego problemu, ale jego wprowadzenie zostało mocno opóźnione.

Inżynierowie podejrzewali, że uszczelki sztywniały pod wpływem zimna. Wiedzieli też, że temperatury panujące podczas startu Challengera były niższe niż podczas któregokolwiek wcześniejszego startu — znacznie poniżej temperatury dopuszczalnej. W skrócie: inżynierowie _wiedzieli_, że ryzyko jest zbyt wielkie i wykorzystując tę wiedzę, zaczęli odpowiednio działać. Pisali notatki i zapalali światła alarmowe. Nastawali na menedżerów Thiokolu i NASA, żeby opóźnić start. Na jedenastogodzinnym spotkaniu tuż przed startem zaprezentowali wszystkim posiadane dane. Wściekali się, przymilali, komu trzeba, i protestowali. Ostatecznie jednak menedżerowie ich zignorowali.

Część inżynierów nie chciała nawet oglądać przekazów ze startu wahadłowca, ponieważ obawiali się, że wybuchnie jeszcze na platformie. Jednak Challenger zgrabnie wzniósł się w niebo, przez co napięcie zaczęło opadać. Na kilka chwil przed zniszczeniem pojazdu, w momencie gdy przekraczał on prędkość 1 macha, jeden z inżynierów stwierdził, że „tym razem się udało”.

Mimo wszystkich protestów, notatek i uwag zgłaszanych przez inżynierów menedżerowie uznali, że to oni mają rację. Sądzili, że inżynierowie najzwyczajniej przesadzają, dlatego nie ufali ich danym oraz wnioskom. Uruchomili silniki Challengera, ponieważ sami byli pod wielką presją finansową i polityczną. Mieli tylko _nadzieję_, że wszystko się uda.

Wszyscy ci menedżerowie nie tylko byli głupi, ale stali się przestępcami. Tego mroźnego poranka zginęło siedmioro dzielnych kobiet i mężczyzn, a nadzieje całych pokoleń marzących o podróżach w kosmos zostały zawiedzione dlatego, że kilku menedżerów przedłożyło własne obawy, nadzieje i przeczucia nad słowa zatrudnianych przez siebie ekspertów. Podjęli decyzję, której nie mieli prawa podejmować. Przypisali sobie autorytet ludzi, którzy _wiedzieli_, co robić: inżynierów.

A co z inżynierami? Z pewnością zrobili to wszystko, co powinni byli zrobić. Poinformowali przełożonych i ciężko walczyli, prezentując swoje zalecenia. Przeszli przez wszystkie właściwe kanały i powołali się na odpowiednie protokoły. Zrobili zatem, co mogli w _ramach_ istniejącego systemu, ale menedżerowie i tak postawili na swoim. Wygląda na to, że inżynierowie mogą mieć czyste sumienie.

Czasami jednak zastanawiam się, czy któryś z nich nie może spać w nocy, prześladowany przez obraz matki Christy McAuliffe, rozważając, dlaczego nie zadzwonił do Dana Rathera.

O tej książce

To książka o profesjonalizmie przy tworzeniu oprogramowania. Zawiera wiele pragmatycznych wskazówek i próbuje w ten sposób odpowiedzieć na takie pytania, jak:

- Kim jest zawodowy programista?
- Jak zachowuje się profesjonalista?
- Jak zawodowiec radzi sobie z konfliktami, krótkimi terminami i nierozsądnymi menedżerami?
- Kiedy i jak profesjonalista powinien powiedzieć „nie”?
- Jak zawodowiec radzi sobie z naciskami?

W tych pragmatycznych poradach znajdziesz też rodzącą się postawę. Jest to postawa pełna godności, honoru, poszanowania oraz dumy. Jest w niej też gotowość do zaakceptowania tego straszliwego zobowiązania związanego z byciem rzemieślnikiem i inżynierem. Częścią tego zobowiązania jest konieczność wykonywania czystej i dobrej pracy, a także utrzymania dobrej komunikacji i dokonywania prawidłowych szacunków. Dotyczy ono też zarządzania swoim czasem i mierzenia się ze skomplikowanymi decyzjami typu ryzyko – nagroda.

Do tego zobowiązania należy też jeszcze jedna, niezwykle przerażająca rzecz. Jako inżynier dysponujesz dogłębną wiedzą o swoich systemach i projektach, która nie jest dostępna dla menedżerów. Z tą wiedzą związane jest zobowiązanie do _działania_.

Bibliografia

: Malcolm McConnell, _Challenger. A Major Malfunction_, New York, Simon & Schuster, 1987.

: „Katastrofa promu Challenger”, _http://pl.wikipedia.org/wiki/
Katastrofa_promu_Challenger_.

------------------------------------------------------------------------PODZIĘKOWANIA

------------------------------------------------------------------------

Moja kariera jest całą serią epizodów współpracy i planowania. Sam miałem wiele różnych marzeń i dążeń, ale zawsze udawało mi się znaleźć kogoś, kto je podzielał. Pod tym względem czuję się trochę jak Sith. „Zawsze dwóch ich jest”.

Pierwsza współpraca, którą mógłbym uznać za profesjonalną, miała miejsce, gdy miałem 13 lat, a moim współpracownikiem był John Marchese. Razem planowaliśmy zbudowanie własnego komputera. Ja miałem mózg, a on mięśnie. Pokazywałem mu, gdzie ma przylutować przewód, a on go przylutowywał. Pokazywałem, gdzie ma zamocować przekaźnik, a on go mocował. To była przednia zabawa, na której spędziliśmy setki godzin. I rzeczywiście zbudowaliśmy kilka całkiem imponująco wyglądających rzeczy wyposażonych w przyciski, przekaźniki, światełka, a nawet teletekst! Oczywiście żadna z tych rzeczy nie wykonywała nic konkretnego, ale były niezwykle imponujące i poświęciliśmy im bardzo dużo czasu. Dziękuję Ci za to, John!

W pierwszym roku szkoły średniej na lekcjach niemieckiego spotkałem Tima Conrada. Tim był naprawdę _mądry_. Gdy przystępowaliśmy do budowania komputera, to on był mózgiem, a ja mięśniami. Nauczył mnie elektroniki i zapoznał z komputerem PDP-8. Razem zbudowaliśmy działający elektroniczny kalkulator 18-bitowy, wykorzystując do tego podstawowe elementy. Potrafił on dodawać, odejmować, mnożyć i dzielić. Zajęło nam to wszystkie weekendy jednego roku oraz całe wakacje letnie i bożonarodzeniowe. Pracowaliśmy nad nim bez ustanku i na koniec kalkulator działał doskonale. Dziękuję Ci za to, Tim!

Razem z Timem nauczyłem się programować komputery. W roku 1968 nie było to łatwe, ale jakoś się udało. Zdobyliśmy książki o asemblerze komputera PDP-8, o językach Fortran, Cobol oraz PL/1 i po prostu je pochłanialiśmy. Pisaliśmy programy, których nie dało się nawet uruchomić, ponieważ nie mieliśmy dostępu do komputera. Ale pisaliśmy je mimo to z czystej przyjemności.

W drugiej klasie liceum nasza szkoła zaczęła prowadzić zajęcia z nauk komputerowych. Do modemu telefonicznego o prędkości 110 bodów podłączono teletekst ASR-33. Szkoła miała własne konto w systemie podziału czasu Univac 1108 prowadzonym przez Institute of Technology w stanie Illinois. Tim i ja bardzo szybko staliśmy się faktycznymi operatorami tego sprzętu. Nikt poza nami nie miał prawa się do niego zbliżać.

Połączenie modemowe wykonywało się przez podniesienie słuchawki i ręczne wybranie numeru. Po usłyszeniu pisków modemu z drugiej strony należało nacisnąć przycisk „orig” na teletekście, żeby nasz modem zaczął piszczeć w drugą stronę. Teraz wystarczyło odwiesić słuchawkę i połączenie było ustanowione.

Tarcza telefonu była zabezpieczona kluczem, do którego dostęp mieli wyłącznie nauczyciele. Nie miało to jednak znaczenia, ponieważ wykombinowaliśmy, że można wybrać numer (dowolny), wystukując go za pomocą wyłącznika pod słuchawką. Byłem perkusistą, więc miałem całkiem niezłe wyczucie czasu i refleks. Nawet przy zablokowanej tarczy telefonu byłem w stanie wybrać numer w mniej niż 10 sekund.

W laboratorium dostępne były dwa telegrafy. Tylko jeden z nich był maszyną podłączoną do sieci telefonicznej, ale oba były używane przez uczniów do pisania programów. Pisali oni programy, których kod był wybijany na taśmie papierowej. Każde naciśnięcie klawisza powodowało wybicie nowych dziurek w taśmie. Programy były pisane w niezwykle rozbudowanym, interpretowanym języku IITran. Przygotowane taśmy z programami należało zostawić w koszyku umieszczonym obok telegrafów.

Po szkole Tim i ja wybieraliśmy numer komputera (oczywiście wystukując go), ładowaliśmy zawartość taśm do systemu wykonawczego IITran i rozłączaliśmy się. Przy prędkości 10 znaków na sekundę cała procedura zajmowała trochę czasu. Po mniej więcej godzinie ponownie łączyliśmy się z komputerem, aby wydrukować wyniki. Znów z prędkością 10 znaków na sekundę. System nie rozdzielał listingów poszczególnych uczniów na pojedyncze strony. Drukował po prostu stronę za stroną, dlatego musieliśmy pociąć je nożyczkami, dołączyć odpowiednie taśmy z programami i odłożyć do koszyka z wynikami.

Tim i ja byliśmy w tym mistrzami. Nawet nauczyciele nas nie nadzorowali, gdy byliśmy w laboratorium. Wiedzieli, że wykonujemy ich pracę, choć nigdy nas o to nie prosili ani nawet nie zasugerowali takiej możliwości. Nigdy też nie dostaliśmy klucza do telefonu. Po prostu my się tym zajmowaliśmy, a oni wychodzili, pozostawiając nam bardzo dużo swobody. Dziękuję zatem moim nauczycielom matematyki: panu McDermitowi, panu Fogelowi i panu Robienowi.

Potem, po zakończeniu prac domowych, mogliśmy zająć się zabawą. Pisaliśmy program za programem, a robiły one najróżniejsze szalone i dziwaczne rzeczy. Napisaliśmy program rysujący okręgi i parabole za pomocą znaków ASCII drukowanych przez telegraf. Pisaliśmy generatory losowych słów. Do ostatniej cyfry wyliczaliśmy silnię z 50. Poświęcaliśmy całe godziny na wymyślanie programów, pisanie ich i uruchamianie.

Dwa lata później Tim, nasz kolega Richard Lloyd i ja zostaliśmy zatrudnieni jako programiści w firmie ASC Tabulating w Lake Bluff w stanie Illinois. W tym czasie Tim i ja mieliśmy po 18 lat. Zdecydowaliśmy, że liceum to strata czasu i powinniśmy od razu zacząć nasze kariery. To właśnie w tej firmie spotkaliśmy Billa Hohriego, Franka Rydera, Wielkiego Jima Carlina oraz Jona Millera. To dzięki nim żółtodzioby mogły się dowiedzieć, co oznacza profesjonalne tworzenie oprogramowania. Doświadczenie to nie było ani całkowicie pozytywne, ani całkowicie negatywne, ale z całą pewnością było pouczające. Dziękuję zatem wszystkim wymienionym oraz Richardowi, który był katalizatorem i siłą napędową całego tego procesu.

W wieku 20 lat, po złożeniu wypowiedzenia i uspokojeniu się, przez pewien czas pracowałem jako serwisant kosiarek do trawy w firmie mojego szwagra. W tym fachu byłem tak fatalny, że szwagier był zmuszony mnie wyrzucić z pracy. I za to Ci dziękuję, Wes!

Jakiś rok później rozpocząłem pracę w firmie Outboard Marine Corporation. W tym czasie miałem już żonę i dziecko w drodze. Stamtąd też zostałem zwolniony. Dziękuję Wam, John, Ralph i Tom!

Następnie zacząłem pracę w firmie Teradyne, gdzie spotkałem Russa Ashdowna, Kena Findera, Boba Copithorne’a, Chucka Studee oraz CK Srithrana (teraz Krisa Iyera). Ken był moim szefem, a Chuck i CK kolegami. Od nich wszystkich bardzo dużo się nauczyłem. Dziękuję Wam, chłopaki!

Później pojawił się Mike Carew. W Teradyne razem stworzyliśmy dynamiczny duet. Razem napisaliśmy kilka systemów. Jeżeli ktoś chciał coś przygotować i zrobić to naprawdę szybko, to Bob i Mike doskonale się do tego nadawali. Świetnie się razem bawiliśmy. Dziękuję Ci, Mike.

Jerry Fitzpatrick również pracował w Teradyne. Poznaliśmy się podczas wspólnych sesji Dungeons & Dragons i bardzo szybko zaczęliśmy współpracować. Napisaliśmy oprogramowanie dla Commodore 64 wspomagające graczy w D&D. W Teradyne rozpoczęliśmy też prace nad nowym projektem, który otrzymał nazwę „elektronicznego recepcjonisty”. Pracowaliśmy razem przez kilka lat, a Jerry został i pozostał moim bliskim przyjacielem. Dziękuję Ci za to, Jerry!

Pracując dla firmy Teradyne, spędziłem cały rok w Anglii, gdzie spotkałem Mike’a Kergozou. Razem snuliśmy wiele różnych planów, choć większość z nich była związana z motocyklami i pubami. Mike był jednak oddanym programistą poświęcającym wiele uwagi kwestiom jakości i dyscypliny (choć sam pewnie by się nie zgodził z tym twierdzeniem). Dziękuję Ci, Mike!

Gdy w 1987 roku wróciłem z Anglii, zacząłem swoje zwykłe planowanie wspólnie z Jimem Newkirkiem. Obaj odeszliśmy z Teradyne (w odstępie miesiąca) i zatrudniliśmy się w start-upie o nazwie Clear Communications. Następnych kilka lat spędziliśmy razem, harując w nadziei na miliony, które jakoś się nie pojawiły. Nigdy jednak nie zaprzestaliśmy planowania. Dziękuję Ci, Jim!

Na koniec wspólnie założyliśmy firmę Object Mentor. Jim jest najbardziej bezpośrednią, zdyscyplinowaną i skupioną osobą, z jaką kiedykolwiek zdarzyło mi się pracować. Nauczył mnie tak wielu rzeczy, że nawet trudno byłoby mi je wymienić. W zamian zadedykowałem mu tę książkę.

Współpracowałem i snułem plany z wieloma innymi osobami, a jeszcze więcej miało wpływ na moje zawodowe życie: Lowell Lindstrom, Dave Thomas, Michael Feathers, Bob Koss, Brett Schuchert, Dean Wampler, Pascal Roy, Jeff Langr, James Grenning, Brian Button, Alan Francis, Mike Hill, Eric Meade, Ron Jeffries, Kent Beck, Martin Fowler, Grady Booch i wielu, wielu innych. Wszystkim Wam z całego serca dziękuję.

Oczywiście moim najważniejszym współpracownikiem była moja ukochana żona Ann Marie. Ożeniłem się z nią w wieku 20 lat, całe trzy dni po jej 18 urodzinach. Przez 38 lat była moim niezłomnym kompanem, moim sternikiem i żaglem, miłością mojego życia. Mam nadzieję przeżyć z nią kolejne cztery dekady.

Aktualnie moimi współpracownikami i partnerami w snuciu planów są moje dzieci. Ściśle współpracuję z moją najstarszą córką Angelą — moją dzielną opiekunką i nieustraszoną pomocnicą. Nigdy nie pozwala mi zboczyć z wybranej ścieżki ani zapomnieć o terminach lub zobowiązaniach. Obmyślam plany biznesowe z moim synem Micahem, założycielem firmy 8thlight.com. Muszę powiedzieć, że ma znacznie lepszą głowę do interesów, niż ja miałem kiedykolwiek. Nasz ostatni projekt — _cleancoders.com_ — jest naprawdę bardzo ekscytujący.

Mój młodszy syn Justin właśnie zaczął pracować razem z Micahem w 8th Light. Z kolei młodsza córka Gina jest chemikiem i pracuje dla Honeywell. Z tymi dwojgiem dopiero zaczęliśmy poważne planowanie.

To właśnie dzieci są w stanie nauczyć Cię więcej niż ktokolwiek inny w Twoim życiu. Dziękuję Wam za to, dzieciaki!

------------------------------------------------------------------------O AUTORZE

------------------------------------------------------------------------

ROBERT C. MARTIN („WUJEK BOB”) był programistą od 1970 roku. Jest założycielem i prezesem Object Mentor, międzynarodowej firmy skupiającej doświadczonych inżynierów oprogramowania oraz menedżerów specjalizujących się we wspomaganiu firm podczas prac nad najróżniejszymi projektami. Firma Object Mentor oferuje korporacjom na całym świecie konsultacje z usprawniania procesów i obiektowego projektowania oprogramowania, szkolenia oraz usługi z zakresu rozwoju umiejętności oprogramowania.

Martin opublikował dziesiątki artykułów w najróżniejszych specjalistycznych magazynach i jest częstym prelegentem na międzynarodowych konferencjach i targach.

Jest autorem oraz redaktorem wielu książek, w tym:

- _Designing Object Oriented C++ Applications Using the Booch Method_
- _Patterns Languages of Program Design 3_
- _More C++ Gems_
- _Extreme Programming in Practice_
- _Agile Software Development: Principles, Patterns, and Practices_
- _UML for Java Programmers_
- Czysty kod. Podręcznik dobrego programisty, (Helion 2010)

Będąc liderem przemysłu tworzącego oprogramowanie, Martin przez trzy lata pracował jako główny redaktor magazynu „C++ Report” oraz przewodniczący organizacji Agile Alliance.

Robert jest też założycielem firmy Uncle Bob Consulting LLC, a wspólnie ze swoim synem Micahem — współzałożycielem firmy The Clean Coders LLC.

------------------------------------------------------------------------