Podekscytowanych fanów Chucka Norrisa muszę niestety srodze rozczarować. Chodzi o Clifta Norrisa, programistę.
Otóż odkrył on zjawisko dotyczące świata programowania komputerów - a konkretnie rzecz ujmując - programistów. Okazuje się, że każdy programista ma swoją liczbę Norrisa, która - w zależności od doświadczenia - może wahać się od mniej więcej dwóch tysięcy do około trzech milionów.
Żeby wyjaśnić, o co chodzi z liczbami Norrisa, zacznę od analogii niezwiązanej z komputerami.
Wobraźmy sobie niemowlaka, który właśnie opanował raczkowanie. Po jakimś czasie zaczyna chodzić, najpierw przytrzymując się mebli, potem samodzielnie. Kolejnym etapem jest bieganie. Taki człowiek może sobie pomyśleć, że przy odpowiednio długim i intensywnym wysiłku może osiągnąć w zasadzie dowolną prękość - jednak trywialna prawda jest taka, że nie da się pobiec szybciej niż około 37 km/h - ciało ludzkie ma swoje granice wytrzymałościowe. Żeby przemieszczać się szybciej, trzeba opanować jazdę na rowerze, dajmy na to.
Ale rower też ma swoje ograniczenia (oczywiście są wariaci jeżdżący ponad 200 km/h na bardzo specjalistycznych wehikułach ledwie mieszczących się w zakresie pojęcia słowa "rower" - ale, jak już nadmieniłem, to są wariaci...). Żeby pojechać szybciej, trzeba się przesiąść na samochód. Czyli zrobić prawo jazdy itd.
Potem można - ewentualnie - zostać jeszcze pilotem myśliwca.
W ostateczności... kosmonautą.
Szybciej się nie da, chociaż do prędkości światła jeszcze zostało całkiem sporo.
Chodzi jednak nie o prędkość, tylko o zmianę sposobu myślenia. Niemowlaka od kosmonauty dzieli ogromna przepaść, a w zasadzie kilka przepaści.
Wróćmy teraz do liczb Norrisa. Liczbą Norrisa danego, konkretnego programisty, nazywamy ilość linii kodu, które taki programista potrafi "ujarzmić" w ramach projektu - rozumiemy przez to swobodne, pewne poruszanie się po takim kodzie, oraz jego modyfikowanie w taki sposób, żeby nie "popsuć" reszty projektu, niezależnie od tego, czy jest to malutka pchełka na bloga, czy fragment kodu źródłowego jakiegoś dużego systemu operacyjnego.
Liczby te, chociaż różne dla różnych programistów, mają jednak pewne łatwo zauważalne progi - to są właśnie te "przejścia" między bieganiem a jazdą na rowerze, między samolotem a pojazdem kosmicznym.
"Raczkujący" programista natrafi na ścianę w okolicach 2,000 linii kodu. Do tej ilości pojedynczy mózg jest w stanie zapamięcać i "poukładać" sobie w zasadzie dowolnie zagmatwany, bałaganiarski i kiepski kod, "połatać" dziury między powyginanymi deskami, wbić tu i ówdzie symbolicznego gwoździa, przewiązać jakiś kawałek rury sznurkiem od snopowiązałki - i program zadziała.
Programista, który już trochę potrafi sobie zorganizować pracę z kodem, natrafi na drugą ścianę w okolicach około 20,000 linii kodu. Tam bowiem nawet dość porządnie napisany kod zaczyna wymykać się spod kontroli.
Kolejna ściana pojawia się w okolicach ćwierci miliona linii kodu. To już są całkiem spore projekty, nad którymi pracują kilku - kilkunastoosobowe grupy programistów przez długie miesiące, czasem lata. Tu już nie wystarczy sama umiejętność organizowania kodu w logiczne moduły, zwartego i przejrzystego stylu ani nawet jakaś superinteligencja. Przy projektach tej skali trzeba umieć odrzucać wszystko, co nie jest absolutnie niezbędne. Minimalizm i mówienie "nie" rzeczom, które nie sa naprawdę niezbędne, stają się drugą naturą takiego programisty. Oprócz tego trzeba zdawać sobie sprawę, że każda linia kodu to źródło potencjalnych błędów, a zależności między modułami należy redukować aż do przesady, ponieważ wykładniczo zwiększają one szanse na wystąpienie błędu.
Ostatnia, czwarta ściana, kórej jak na razie nie udało się skutecznie pokonać współczesnymi metodami ani metodologiami, pojawia się w okolicach trzech milionów linii kodu.
Nie oznacza to, oczywiście, że nie ma projektów większych, niż te magiczne trzy miliony. Jądro Linuksa, najpopularniejszego systemu serwerowego na świecie (odpowiedzialnego między innymi za działanie bloga, który właśnie czytsz), ma ponad 6 milionów linii kodu (a wersja 4.x będzie miała ich ponad 20 milionów). Systemy Microsoftu przebijają te liczby ponaddwukrotnie - Windows Server 2003 ma ponad 50 milionów linii kodu. A więc - owszem, da się. Chodzi jednak o to, że w okolicach magicznej granicy 3 milionów linii kodu każdy projekt zaczyna zwalniać - i nic się z tym nie da zrobić. Dokładanie większej liczby programistów do projektu nie poprawia sytuacji (podobnie jak dziewięć kobiet nie jest w stanie skrócić ciąży do jednego miesiąca...).
Gdzie ja jestem w tym całym zestawieniu?
Hm.
Brałem udział w projektach, które miały kilkadziesiąt tysięcy linii kodu, ale dawało się tam już odczuć pewien chaos. Raczej poradzę sobie z projektem na 10,000 LOC (LOC to po naszemu Lines of Code, czyli właśnie linie kodu), co jest odpowiednikiem miejskiego roweru. Kolarzówka, samochód - czy już w ogóle samolot - są w tym kontekście poza moim zasięgiem, jak sądzę.
Całe szczęście, że specjalizuję się w pchełkach 😉
nie da się zwiększać ciągle wydajności, bo po pewnym czasie napotyka się barierę. Jeśli zapominasz jaki jest dzisiaj dzień tygodnia i musisz to sprawdzić w kalendarzu (lub na kompie) to znaczy się, że właśnie trafiłeś na taką barierę. Podobnie jest jeśli nie pamiętasz imion ludzi ze swojego zespołu, a pracujesz z nimi pół roku. Albo gdy ktoś do ciebie mówi a ty w trakcie wypowiedzi zastanawiasz się co powiedział na początku. Sporo kolegów inżynierów tak ma. A to znaczy, że się przeciążyłeś i nie wyrabiasz.
Zgadza się, aczkolwiek niewiele ma to wspólnego z tematem wpisu 😉