Programista-MacGyver

From The Joel on Software Translation Project

Jump to: navigation, search

Jamie Zawinski to taki typ programisty, który ja nazywam programistą-MacGyverem. I mówię to z całym szacunkiem. Jamie jest ciężko pracującym programistą, tworzącym przyszłościowe, użyteczne narzędzia, które pozwalają innym ludziom wykonywać ich pracę. Takiego właśnie gościa chcesz mieć w swoim zespole budującym gokarty, ponieważ jego ulubionymi narzędziami są: taśma klejąca i WD-40. I będzie je dzierżył niewzruszenie, dumnie i z gracją, nawet jeśli Twój gokart zacznie z zawrotną prędkością pędzić w dół zbocza. W tym czasie pozostali programiści wciąż będą na linii startu, debatując nad tym, czy powinni użyć tytanu czy może jakiegoś nowoczesnego, kosmicznego materiału kompozytowego, którego Boeing używa przy konstrukcji swojego Dreamlinera 787.

Gdy będzie już po wszystkim, być może zostaniesz z odrobinę niechlujnym gokartem, ale bez wątpienia będzie śmigał jak marzenie.

Przeczytałem właśnie wywiad z Jamiem w książce Coders at Work ("Koderzy w pracy") autorstwa Petera Seibela. Do sklepu marsz. Jest to niesamowity zbiór wywiadów ze znakomitymi programistami, takimi jak Peter Norvig, Guy Stelle i Donald Knuth. Ta książka jest tak ciekawa, że wczoraj na bieżni zamiast 30 minut spędziłem 60, ponieważ nie mogłem przestać czytać. Jak już mówiłem -- kupcie ją.

Mówię serio. Kupcie ją! Ja poczekam.

23.jpg

Chciałbym przedstawić powody, dlaczego lubię programistów w typie MacGyvera. Czasem jest tak, że będąc w jakimś zespole siedzisz sobie i zawzięcie klepiesz kod, gdy nagle ktoś podchodzi do Twojego biurka z kawą w ręku i zaczyna trajkotać o tym, że gdybyś użył wielowątkowych przedziałów COM, to Twoja aplikacja byłaby o 34% bardziej elegancka, i że to wcale nie byłoby trudne, ponieważ on napisał już pełno szablonów, i jedyne co musiałbyś zrobić to użyć wielokrotnego dziedziczenia po 17 takich szablonach, z których każdy bierze średnio 4 parametry, i nawet nie musiałbyś prawie nic implementować. Po prostu jeden gigantyczny ciąg wielokrotnego dziedziczenia po różnych klasach i presto -- wielo-przedziałowe wątki COM. A Ty wywracasz oczami, bo nie masz zielonego pojęcia, o czym ten pieprznięty oszołom gada, i nijak nie możesz się go pozbyć, a nawet gdyby Ci się to udało, to on i tak wróci do swojego pokoju, aby napisać jeszcze więcej tych jego wymyślnych klas utworzonych wyłącznie przy pomocy wielokrotnego dziedziczenia po szablonach, bez grama konkretnej implementacji, i oczywiście to jego kod wywali się na produkcji z wielkim hukiem i to do Ciebie zadzwonią w środku nocy, żebyś to posprzątał, bo on oczywiście w tym czasie będzie na jakiejś cholernej konferencji na temat "Wzorców Projektowych".

A programista-MacGyver nie boi się powiedzieć: "Wielokrotne dziedziczenie to bagno. Przestań tego używać. Po prostu przestań.".

Widzisz, każdy inny programista za bardzo obawia się, że wyjdzie na głupka, ponieważ nie jest w stanie jednocześnie pomieścić w głowie wystarczającej liczby faktów, żeby sprawić, że wielokrotne dziedziczenie albo szablony albo model COM albo wielowątkowość czy coś podobnego zadziałają. Podążają więc potulnie za jakąkolwiek, nieważne jak szaloną, modą, zesłaną nam przez bujających w obłokach architektów, którzy wykładają na konferencjach i piszą książki i artykuły i są dużo bystrzejsi od nas, a nie zdają sobie sprawy z tego, że to, o czym mówią jest dla nas po prostu za trudne.

Oto co Zawinski powiedział o Netscapie: "To właśnie takie decyzje jak rezygnacja z C++ i wielowątkowości sprawiły, że udało nam się wypuścić produkt na czas".

Później brał udział w tworzeniu klienta mailowego w Netscapie, ale zespołowi odpowiedzialnemu za faktyczne wyświetlanie wiadomości na ekranie nie udało się dokończyć swojego komponentu. "Wszystko co mieliśmy to wielki, pusty prostokąt na środku okna, w którym miała być wyświetlana wiadomość, czystym tekstem. Zespół podszedł do swojego projektu bardzo akademicko. Próbowali rozgryźć to od strony DOM i DTD. 'Tak, właśnie, powinniśmy dodać tutaj kolejną warstwę abstrakcji i stworzyć delegata do tego delegata do tego delegata. I wówczas na ekranie pojawi nam się jeden znak.'".

Peter zapytał Zawinskiego: "Widzę że mocno cię mierzi, gdy ktoś przedabrza przy projektowaniu".

23bikes.jpg

"Taa," odpowiedział, "Koniec końców naszym zadaniem jest przecież wypuścić ten pieprzony produkt! Super jest przepisywać swój kod i czynić go bardziej przejrzystym. Po trzecim razie będzie już całkiem ładny. Ale nie o to tu chodzi -- Twoim celem nie jest pisanie kodu; Twoim celem jest ukończenie produktu.".

Mój bohater.

Zawinski nie pisał za wiele testów jednostkowych. "Generalnie są one świetne, ale pod warunkiem, że nie masz presji. Ale gdy stoisz przed obliczem 'Musimy od zera do ukończenia dojść w ciągu sześciu tygodni.', wówczas cóż, nie uda nam się, jeśli czegoś nie pominiemy. To co pominę, to będą rzeczy, które nie są absolutnie krytyczne. A testy jednostkowe nie są krytyczne. Klient nie będzie narzekał, jeśli ich nie będzie.".

Zanim się skrzywisz, pamiętaj, że Zawinski był w Netscapie, gdy zmieniali świat. Pracowali w przeświadczeniu, że mają tylko kilka miesięcy zanim ktoś inny się pojawi i zje ich kawałek tortu. Sporo ważnego kodu powstaje w takich warunkach.

Programista-MacGyver jest pragmatyczny. Zawinski spopularyzował koncepcję Gorsze jest lepsze. Produkt w 50% dobry, którego ludzie używają, rozwiązuje więcej problemów i żyje dłużej niż produkt w 99% dobry, ale którego nikt nie używa, ponieważ znajduje się w Twoim laboratorium, gdzie poddawany jest nieustannym zabiegom upiększającym. Wypuszczenie produktu to ficzer. Naprawdę ważny ficzer. Twój produkt musi go mieć.

Jedna z zasad, którą programista-MacGyver dobrze rozumie, mówi, że jakakolwiek technika programistyczna, która jest choć trochę skomplikowana, sprowadzi na Twój projekt zagładę. Taki programista będzie starał się unikać C++, szablonów, wielokrotnego dziedziczenia, modelu COM, architektury CORBA czy też innych technologii, które są całkiem rozsądne, gdy tylko poświęcisz sporo czasu na ich dogłębne zrozumienie, ale szczerze mówiąc są one za skomplikowane, aby ludzki umysł mógł je pojąć.

Fakt, oficjalnie w porządku jest próbować pisać wielowątkowy kod w C++ pod Windows używając modelu COM. Ale takie podejście jest podatne na błędy, bugi, które objawiają się rzadko i tylko w ściśle określonych warunkach uzależnionych od czasu i sekwencyjności operacji. Dzieje się tak, ponieważ nasze mózgi naprawdę nie są na tyle doskonałe by pisać tego rodzaju kod. Przeciętni programiści mogą tutaj przyjąć postawę obronną, ponieważ nie chcą przyznać, że nie są w stanie pisać tak skomplikowanego kodu. Pozwalają więc hardkorowcom z zespołu przeorać jakąś zapomnianą przez Boga architekturę opartą na szablonach C++, ponieważ w przeciwnym wypadku musieliby przyznać, że nie czują się na tyle bystrzy, żeby użyć czegoś, co mogłoby być doskonałą techniką programowania, ale dla kogoś takiego jak SPOCK. Programistę-MacGyvera nie obchodzi, co myślą o nim inni. Pozostaje on przy podstawowych technikach i narzędziach po to, by wolne moce przerobowe mózgu wykorzystać w celu tworzenia użytecznych funkcjonalności dla swoich klientów.

Jest jedna rzecz, o której musisz jednak pamiętać. Programista-MacGyver w świecie oprogramowania jest odpowiednikiem przystojniaka... młodego faceta o niesamowitym wyglądzie, który może wytoczyć się z łóżka i bez golenia, bez czesania się, bez mycia zębów, wsiąść do metra we wczorajszych brudnych ciuchach i wciąż wyglądać pięknie, ponieważ taki właśnie jest. Ty, mój przyjacielu, nie możesz pokazać się publicznie bez uprzedniego uczesania się. Przestraszyłbyś dzieci. Bo nie jesteś taki ładny. Programista-MacGyver musi mieć spory talent, żeby robić swoje. Musi być na tyle dobrym programistą, żeby doprowadzać projekty do końca, a my wybaczymy mu jeśli nie napisze ani jednego testu jednostkowego albo za pomocą XORa upakuje wskaźniki "next" i "prev" listy połączonej w jednym DWORDzie, żeby zaoszczędzić 32 bity, ponieważ jest na tyle ładny i na tyle bystry, że mu to wyjdzie.

Kupiłeś już Coders at Work? Jeśli nie -- zrób to! To był dopiero pierwszy rozdział!

Personal tools