Programista-MacGyver

Oryginalny post: The Duct Tape Programmer

Autor: Joel Spolsky

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.

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".

"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ł!

4 komentarze:

Anonimowy pisze...

Super artykuł! Chociaż jestem programistą urządzeń embedded, jestem bardziej związany z elektroniką ale to praktycznie ten sam temat. Są ludzie, którzy dziobią na studiach, piszą wspaniałe referaty i uważają się za zdolnych w swoim fachu. Nigdy nie zapomnę przygód na kole naukowym, będąc jeszcze na studiach (a byłem uczniem trójkowym) gdy wielcy studenci karcili mnie za stosowanie np tranzystora do sterowania LEDow duzej mocy o zbyt wysokich parametrach niz trzeba bylo. Proponowali użycie takich i takich (wziętych z katalogu np elfy). To ja im odpowiadałem, że mój tranzystor w sklepie kosztuje 1zł, a wasz 3zł, i co z tego, ze ma przesadnie lepsze parametry skoro jest tanszy? Gdzie mogli, chcieli wciskać układy fpga, a ja im proponowałem użycie 8bitowego mikrokontrolera. Okazało się, że wykonałem kilkanaście projektów, a oni pisali referaty i jeździli na seminaria do warszawy lub wrocławia :)

xyz pisze...

Ma działać i koniec :) a to, że ładnie nie wygląda to już tylko mój problem. Jestem "informatykiem", który zaczynał od Basica na przeglądaniu kodu innych projektów. Teraz pisze w C# i nie lubie ludzi, dla których jeżeli podam przykład rozwiązania problemu mówią, że ten kod jest niekompatybilny i u nich wszystko musi być na cacy(mój kod 3 linijki - ich 20 linii w dwóch klasach). Zgroza

Procent pisze...

Oryginał tego artykułu wywołał swego czasu sporą burzę, a tłumaczowi udało się idealnie zachować jego wymowę. Super! Ale polecam na spojrzenie na poruszaną tematykę również z drugiej strony, szczególnie odpowiedź Ayende wydaje mi się bardzo trafna:)
"Oh, wait, let me see. Netscape is the company that:
- Routinely shipped a browser that kept crashing
- Wasn’t able to compete with IE
- Got their source code into a bad enough shape that they had to rewrite it from scratch and lose 5 – 6 YEARS doing so
- Collapsed"

Całość: http://ayende.com/Blog/archive/2009/09/30/duct-tape-programmers.aspx.

Anonimowy pisze...

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

Z pragmatycznego punktu widzenia rozwiązania tego typu można by odrzucić dlatego że np. nic dodatkowego nie wnoszą do produktu albo że są niezarządzalne, natomiast na pewno nie dlatego, że "Wielokrotne dziedziczenie to bagno". Takie podejście to nie jest pragmatyzm, tylko ego: "XYZ jest do bani, bo ja z niego nie korzystam". Pragmatyczne podejście mogłoby również polegać na złamaniu takiego typu niepisanej umowy o niekorzystaniu z wielobazowego dziedziczenia wtedy, kiedy widać byłoby, że zalety mocno przeważają nad wadami lub gdy tych drugich po prostu nie ma.

Ten przykład z wielobazowym dziedziczeniem (a konkretnie - odpowiedź jaką dałby Programista-MacGyver) w moim odczuciu jest dosyć śmieszny.

Prześlij komentarz

Related Posts with Thumbnails