mmazur.7thguard.net

Krótki esej sprzed paru tygodni o tym dlaczego najlepiej by było, gdyby przeciętni programiści nie istnieli. W tym konkretnym przypadku tłumaczący jak bardzo stymulującym intelektualnie zajęciem jest opiekowanie się czyimś kodem.

Pierwsza reakcja -- iiiijasne, przecież wszyscy wiedzą, że ci Najlepsi Programiści kochają Wolność i możliwość Nieskrępowanego Tworzenia robiących Różne Cudowne Rzeczy kawałków kodu, a nie zajmowanie się paskudnym kodem jakiś śmiertelników!

Hmm. To ja się chyba muszę od razu przyznać bez bicia, że z archetypicznym romantycznym hakerem (najlepiej z brodą i zacinającą się drukarką z zamkniętymi sterownikami) nie mam nic wspólnego. Nie lubię i nigdy nie lubiłem dłubania dla samego dłubania, tylko po to, żeby sprawdzić jak coś działa, czy też czy da się coś osiągnąć. Jawi mi się to jako strata czasu. Prawda jest taka, że kodowanie samo w sobie jest zajęciem nudnym (podobnie jak pisanie tekstów :) i jedyną rzeczą, dzięki której jestem w stanie w sobie utrzymać motywację, jest perspektywa (jak najszybszego) otrzymania gotowego systemu (za który później mi zapłacą kupę kasy, bądź też który jest mi potrzebny w innym celu). I nie chodzi tu o na prędce sklecony kod, codename "Frankenstein's monster", przy którym później będę sobie wypruwał żyły próbując coś dopisać/poprawić, ale rzecz na tyle dobrze przemyślaną i czysto napisaną, żebym na późniejszych zmianach tracił minimalne ilości czasu (i nerwów).

I właśnie w tym miejscu ujawniają się same plusy przejmowania po kimś kodu. To nie ja spędziłem czas rozgryzając jakiś protokół, klnąć na nieścisłości w implementacji, etc. To nie ja ryzykowałem, że w końcu się okaże, iż całość nie działa, bo nie. I szefie, to nie jest moja wina, że ten program działa tak, a nie inaczej, ale bardzo chętnie wezmę trochę pieniędzy za poprawienie go.

Oczywiście pierwszą rzeczą, jaką muszę w tym wypadku zrobić, jest zapoznanie się z kodem i wykombinowanie jak on w ogóle działa. Jeśli oryginalni autorzy się spieszyli, to najprawdopodobniej nie mam do dyspozycji nawet jakiegoś krótkiego tekstu tłumaczącego strukturę kodu i ogólne założenia projektowe. Ale w rzeczywistości to nie jest aż taki wielki problem. Na pierwszą linię idzie grep, dzięki któremu jestem w stanie prześledzić ścieżki wywołań funkcji, a przy okazji zaglądania w źródła wywalić zakomentowany kod (który z mojego punktu widzenia tylko przeszkadza w czytaniu i grepowaniu, a jeśli rzeczywiście kiedykolwiek będę się musiał do niego odwołać, to od tego jest SCM), dostosować formatowanie do moich preferencji i generalnie nie zmieniając w ogóle funkcjonalności spowodować, że jestem w stanie względnie komfortowo poruszać się po całości.

Brzmi potencjalnie groźnie, ale o ile oryginalnym autorem nie był jakiś totalny patałach, to wcale nie ma się czego bać, gdyż w rzeczywistości nie ma żadnej gwarancji, że gdybym to ja pisał ów kod od początku, to ostatecznie wyglądałby lepiej, niż to co otrzymałem po zastosowaniu zabiegów kosmetycznych na kodzie odziedziczonym. Ba, nie mam nawet gwarancji, że udałoby mi się stworzyć coś działającego (równie dobrze), a w tym konkretnym wypadku jestem panisko, bo dostaję coś, co już działa, a ja mam tylko dodawać jakieś inkrementalne zmiany i wyłapywać ewentualne problemy.

(Oczywiście podstawową wadą nie bycia oryginalnym autorem jest to, że nie zna się powodów, dla których coś jest zakodowane w ten, a nie inny sposób, a co za tym idzie trzeba być bardzo ostrożnym przy wprowadzaniu zmian. Bardzo ostrożnym.)

W tym momencie warto wspomnieć o chyba klasycznym tekście Joela Spolsky'ego poruszającym ten temat (głównie na przykładzie firmy Netscape i tego jak przekichała sprawę tworząc Mozillę od zera i nie będąc w stanie przez kilka lat pokazać klientom czegoś, co nadawałoby się do użytku).

No dobra, ale co w takim razie z tymi magikami kodu, którzy w pojedynkę potrafią w rekordowym czasie tworzyć cuda na kiju?

No cóż. Jeśli mają szczęście, to znajdą dla siebie jakąś niszę, ale prawda jest taka, że ogólnie pojęta informatyka (programiści, administratorzy i tacy tam) ze względu na złożoność systemów komputerowych już dawno temu stała się sportem zespołowym i w związku z tym promuje pewne określone cechy. Znowu odwołam się tu do Spolsky'ego, który dobrze to ujął:

Różnica pomiędzy miernymi, a świetnymi programistami nie leży w tym, ile języków którzy znają, czy też w ich preferencjach względem Pythona, albo Javy. Leży ona w tym, czy potrafią oni przekazywać swoje pomysły. Przekonując innych ludzi, uzyskują oni wpływ na różne rzeczy. Pisząc jasne komentarze i specyfikacje techniczne, pozwalają innym programistom zrozumieć ich kod, dzięki czemu owi programiści zaczynają go używać, zamiast pisać od nowa. Bez tego, ów kod byłby prawie bezwartościowy. Pisząc klarowną dokumentację dla użytkowników, pozwalają innym ludziom na zrozumienie co ich kod ma robić, dzięki czemu mogą oni docenić jego wartość. Jest wiele wartościowego i przydatnego kodu zagrzebanego gdzieś na sourceforge'u, którego nikt nigdy nie używa, ponieważ jego autorzy nie potrafili jasno pisać (albo w ogóle nie potrafili pisać), skutkiem czego nikt się nie dowiedział czego dokonali, a ich błyskotliwy kod obumiera.

Bill Gates nie napisał całego Windowsa, on tylko wytłumaczył ludziom, których zatrudnił, czego od nich oczekuje. Linus nie napisał całego Linuksa, on tylko dogadał się z resztą deweloperów jak co ma wyglądać i jakie standardy należy ustalić. (A malekithowe Nemerle pozostałoby pewnie tylko zabawką paru osób, gdyby nie otwarty model rozwoju i dokumentacja.)

Takie przykłady można mnożyć. Moce przerobowe pojedyńczego człowieka są bardzo ograniczone, więc jedyna szansa, żeby mógł on coś osiągnąć, to wymyślenie czegoś sensownego i przedstawienie swoich planów innym ludziom w taki sposób, żeby przy ich pomocy (docelowo zapewne znacznie przewyższającej wkład własny) móc stworzyć coś ciekawego, pod czym później można się podpisać.

I na koniec dodam jeszcze bardzo dobry tekst o tym, jak duże znaczenie ma metodologia pracy wypracowana przy tworzeniu Linuksa na postrzeganie rozwoju oprogramowania w ogóle (zwłaszcza w kontekście open source). Oczywiście to całe oczernianie SVNa i CVSa jest sporym uproszczeniem, ale sama esensja tego tekstu to coś, z czego naprawdę warto sobie zdawać sprawę.

Ajć, piąta rano. Dobranoc.

Data 03 VII 2006, 04:53:55.

»

Adde commentarium.

Trackback link.