Rozmiar jest wrogiem

Oryginalny post: Size Is The Enemy

Autor: Jeff Atwood

Ostatni wpis Steve'iego Yegge, Najgorszy Wróg Kodu, jest niczym wszystkie jego wpisy: bogaty, dający satysfakcję i niedorzecznie długi. Steve nie pisze zbyt często, ale jak już coś napisze, to jest to wypas. Tak jak wspominałem o tym rok temu, zaczałem chałupniczo wykopywać niesamowite i potrafiące wyjąć godzinę z naszego życia wpisy Steve'a, a następnie kondensować je w krótsze formy pod postacją punktów. Tak więc zacznijmy:

  1. Steve zaczął pisać multiplayerową grę Wyvern około roku 1998. Jeśli zastanawiasz się, jak ona wygląda, zobacz pierwszy i drugi zrzut ekranu.
  2. Przez ostatnie 9 lat przybyło Wyvernowi 500000 linii kodu w Javie.
  3. Steve zdał sobie sprawę z tego, że żaden programista nie jest w stanie utrzymywać samodzielnie pół miliona linii kodu. Nawet jeśli jest się Stevem Yegge.

Jest tego więcej, ale chciałem się na chwilę tu zatrzymać. Całkowitą prawdą jest to, że jakikolwiek programista, który samodzielnie utrzymuje pół miliona linii kodu należy automatycznie do całkiem elitarnego klubu. Steve ma co do tego rację. Większość programistów nie będzie miało tego ponadludzkiego przywileju utrzymywania 500k LOC (bądź więcej). W każdym rozsądnym zespole programistycznym, będziesz miał zespół ludzi, którzy będą nad tym pracować, bądź otworzysz źródła po to, aby rozproszyć nakład pracy na społeczność.

Ale jest coś, czego nie rozumiem:

Tak się składa, że podzielam ciężko zdobytą opinię mniejszości na temat kodu. Konkretniej wierzę - mógłbym dodać, że całkiem zagorzale - że najgorsza rzecz, która może się przydarzyć bazie kodu, to jest rozmiar.

Tak więc Steve twierdzi, że większość programistów, gdy napotka na kod, który w przybliżeniu jest wielkości Gwiazdy Śmierci, myśli:

Z całą pewnością mógłbym to napisać.

Jest to wymowny wskażnik niesamowicie brodatego tłumu informatyków, za którym Steve podąża. Prawdopodobnie chodzą też w klapkach do pracy. Pośród programistów, których znam, bardziej odpowiednią - i na pewno bardziej racjonalną - reakcją na taką ilość kodu źródłowego byłaby krzyk oraz ucieczka możliwie jak najdalej. I ja byłbym zaraz za nimi.

Niesądzę, abyś musiał spędzić 10 lat na pisaniu 500000 linii kodu w Javie, aby niezależnie dojść do tej samej konkluzji. Rozmiar jest wrogiem. Zwykłe przejście z 1k na 10k LOC - zakładając, że jesteś wystarczająco świadomy jako programista - wystarczy, aby ujrzeć szaleńczą przepaść, która leży pomiędzy. Nawet jeśli napisałeś zero linii kodu, a kiedykolwiek przeczytałeś którąś z książek Steve'a McConnella, to wiesz, że zasada wielkości zostaje pobita, raz za razem:

Rozmiar projektu jest najbardziej znaczącym wyznacznikiem nakładu, kosztu oraz harmonogramu [dla projektu związanego z oprogramowaniem]. W rzeczy samej, ludzie zakładają, że system, który jest większy o 10 razy od innego systemu, będzie potrzebował mniej więcej dziesięciokrotnego nakładu pracy, aby go zbudować. Niemniej jednak nakład pracy dla systemu z 1000000 LOC jest o wiele większy niż dziesięciokrotność nakładu pracy dla systemu z 100000 LOC.

Jedną z najbardziej fundamentalnych i naprawdę efektywnych rad, jaką mógłbyś udzielić zespołowi tworzącemu oprogramowanie — jakiemukolwiek zespołowi tworzącemu oprogramowanie — to pisanie małej ilości kodu za wszelką cenę. Rozbij projekt na wiele mniejszych podprojektów. Dostarczaj je jako uzupełniające się fragmenty. Spróbuj iteracyjnego podejścia. Zaprzestań implementacji w asemblerze, czy APLu. Zatrudnij lepszych programistów, którzy sami z siebie piszą mniej kodu. Kup kod od kogoś innego. Zrób wszystko, co potrzeba, aby pisać możliwie mniej kodu, ponieważ najlepszy kod, to brak kodu w ogóle.

Jeszcze nie skończyłem. Ostrzegałem, że to będzie długi wpis. Tak więc kontynuując:

  1. Ponieważ Java jest statycznie typowanym językiem, wymaga dużej ilości nudnego, powtarzalnie banalnego kodu, aby osiągnąć cel.
  2. Ten nudny i powtarzalnie banalny kod został skodyfikowany w wiarę Java pod postacią wpływowych książek "Design Patterns" oraz "Refactoring".
  3. Programiści Java przesadnie gorąco wierzą w to, że IDE jest w stanie poradzić sobie z nieuniknioną, olbrzymią ilością kodu Java.
  4. Przepisanie Wyverna z Javy na język dynamiczny, który jest uruchamiany w JVM, mogłoby zredukować ilość czystego kodu z 50% do 75%.

I w tym miejscu Steve, nie tak łagodnie, przechodzi z "rozmiar jest problemem" do "Java jest problemem".

Rozmiar to coś, z czym musisz żyć programując w Javie. Wzrost jest faktem życia. Java jest niczym Tetris, w którym żaden z nowych kawałków nie jest w stanie wypełnić luk powstałych w wyniku ułożenia poprzednich części, co w efekcie powoduje, że klocki nawarstwiają się bez końca.

tetris game over

Powracając do naszej szalonej gry w Tetrisa, wyobraź sobie, że posiadasz narzędzie, które potrafi zarządzać takim ekranem Tetrisa, który ma setki warstw. W takim scenariuszu, nawarstwianie się klocków nie jest problemem, więc nie ma potrzeby możliwości ich usuwania. To jest problem kulturalny: [programiści Java] nie zdają sobie sprawy z tego, że nie grają już w tę grę co potrzeba.

Steve wyszczególnia Martina Fowlera, który ostatnio "porzucił" statyczno-językową religię Java na rzecz dynamicznie typowanego Ruby. Fowler całkiem formalnie napisał książke o refaktoringu, więc pewnie jest trochę prawdy w tym, co twierdził Steve, że surowa architektura klasycznych, statycznie typowanych języków, ostatecznie powstrzymuje Cię przed refaktoryzowaniem kodu w stopniu jakim byś chciał. Jeśli Fowler nie potrafi zrefaktoryzować kawałków kodu Java, to kto ma potrafić?

Bruce Eckel jest kolejną rozpoznawalną osobistością w świecie Javy, która najwyraźniej doszła do takich samych konkluzji na temat Javy parę lat temu.

Nie jestem w stanie określić [kosztu silnego typowania]. Nie mogłem przeprowadzić żadnego matematycznego dowodu na to, ponieważ zależy to w pewnej mierze od czynnika ludzkiego, jak na przykład ile czasu potrzeba na zapamiętanie jak otworzyć plik, ustawić blok try w odpowiednim miejscu, przeczytać linie z pliku, a następnie pamiętać, co tak naprawdę chciało się osiągnąć czytając te linie. W Pythonie mogę przetwarzać linie pliku następująco:

  for line in file("FileName.txt"):
   # Process line
 

Nie musiałem tego wyszukiwać, ani nawet o tym myśleć, ponieważ to takie naturalne. Zawsze muszę sprawdzać, jaki jest sposób otwierania pliku i czytania go w Javie. Mniemam, że mógłbyś się kłócić o to, że Java nie była projektowana z myślą o przetwarzaniu tekstu i zgodziłbym się z Tobą, ale niestety wydaje się, że Java jest głównie wykorzystywana na serwerach, gdzie najpopularniejszym zadaniem jest właśnie przetwarzanie tekstu.

Linie kodu są i zawsze będą wrogiem. Więcej linii kodu oznacza więcej czytania, więcej do rozumienia, więcej usuwania problemów oraz więcej debuggowania. Ale możliwym jest zapędzenie się za bardzo w drugim kierunku. Jeśli nie jesteś uważny, możesz zacząć grać w zupełnie inną grę — tak, udało Ci się mądrze uniknąć nieskończenie wysokiego Tetrisa w Javie, ale czy nie prześlizgnąłeś się zamiast tego do gry w Perl Golfa?

Perl "golf" jest rozrywką polegającą na redukowaniu ilości znaków użytych w Perlu do bezwzględnego minimum w taki sposób, jak gracze golfa starają się wykonać najmniejszą ilość uderzeń podczas rundy.

golf perl

Na początku skupiano się głównie na JAPHach, które widniały w sygnaturach na Usenecie, czy gdzie indziej, ale wykorzystanie Perla do napisania programu, który wykonywał szyfrowanie RSA, zaowocowało w rozprzestrzenieniu się tej rozrywki. W kolejnych latach, kod golfa stał się rozrywką również w językach innych niż Perl.

W naszej wojnie o rozwlekłość istnieje nieuchronny kompromis pomiędzy rozwlekłością a byciem zrozumiałym. Steve potwierdza to poprzez wybór swojego języka JVM do takiego, który jest "składniowo w mainstreamie": JRuby, Groovy, Rhino (JavaScript) oraz Jython. Zepsuję Wam nie tak zaskakujące zakończenie: Steve przepisuje Wyvern w Rhino, a w międzyczasie pomaga w uaktualnienu Rhino o zgodność z nadchodzącą poprawką EcmaScript 4 do JavaScript. Nie istnieje cudowne rozwiązanie, ale wydaje się to być rozsądnym kompromisem mając na uwadze jego cele.

I tak kończy się dziesięcioletnia opowieść o Steve'ie i jego wesołej bandzie Wiwernirów. Ale gdzie nas to doprowadziło? Oczywiście, mam swoje zdanie:

  • Jeśli osobiście napisałeś 500000 linii kodu w jakimkolwiek języku, to masz totalnie przerąbane.
  • Jeśli osobiście przepisałeś 500000 linii kodu w języku statycznym na 190000 linii kodu w dynamicznym języku, to nadal masz całkiem przerąbane. I też będziesz miał rok wycięty z życiorysu.
  • Jeśli rozpoczynasz nowy projekt, rozważ użycie dynamicznego języka, takiego jak Ruby, JavaScript, czy Python. Może się okazać, że jesteś w stanie napisać mniej kodu, który w rzeczywistości więcej znaczy. Bardzo dużo niesamowicie mądrych ludzi, takich jak Steve, przedstawia fascynujące przypadki tego, że trawa naprawdę jest zieleńsza po swojej dynamicznej stronie. W najgorszym wypadku dowiesz się jak żyją inni i może usuniesz klapki z oczu, o których sam nawet nie wiesz.
  • Jeśli utknąłeś w wyłącznie statycznych językach, zadaj sobie takie pytanie: dlaczego musimy pisać tak dużo kodu, aby cokolwiek zrobić — jak można to zmienić? Proste rzeczy powinny być łatwe, złożone rzeczy powinny być możliwe. Zdrowo jest kwestionować kompetencje, w szczególności kompetencje języków.

Pamiętaj: rozmiar naprawdę jest wrogiem. Zaraz po nas oczywiście.

Data publikacji oryginału: 23 grudnia, 2007

7 komentarze:

Anonimowy pisze...

Świetny wpis. Ciekawe spostrzeżenia. Dzięki!

czepol pisze...

Szkoda, że ograniczył się tylko do dynamicznych języków JVM, bo można by rozszerzyć wymienioną listę o Scalę

Greg pisze...

Usuwanie kodu jest jedną z najprzyjemniejszych rzeczy, które robię jako programista :D

Daniel pisze...

Nie chcę być czepialski, ale co to jest "kod golfa", który stał się rozrywką wśród programistów? Może kodowy golf albo programistyczny golf (wolę to 2. określenie)?

kadoel pisze...

Ja powiem: nie ma najlepszych rozwiązań! Nie można stwierdzić jaki język jest najlepszy. Zawsze wszystko ma swoje wady i zalety. Java jest elastyczna i uniwersalna. Nie jest szybka taka jak C++, generuje dużo kodu itp. Kiedyś mój profesor wykładowca od wstępu do programowania mówił, że Java nie jest dla profesjonalistów, ale nigdy nie argumentował swojej wypowiedzi. Jedynie wspominał o języku ADA, w którym pisze się profesjonalne projekty... Java jest elastyczna i to jest jej zaletą.

Krzysztof Szumny - noisy pisze...

Jeżeli jest zimno, ubieram sweter, jeżeli pada, biore parasol...

Wybór języka to nie tylko "widzi mi się"... Jest masę rzeczy, które możemy mieć "za darmo" tylko dlatego, że zdecydujemy się na wybór właśnie konkretnego języka.

Pisząc duży projekt, zawsze znajdzie się taki obszar, który można by napisać lepiej korzystając z innego języka. Nie bez przyczyny jednak naprawdę duże projekty są "multijęzykowe"... to nie jest żadna nowość, że języki potrafią ze sobą współpracować... i nie jest żadną nowością też to, że czasami lepiej użyć gotowych rozwiązań w języku którego nie lubimy, niż robić samemu coś w języku, który uwielbiamy... nawet jeżeli zrobimy to 10 razy krocej...

owszem... rozmiar jest naszym wrogiem, jednakże jeszcze większym jest czas! Pytanie czy dysponujemy tylko swoim czasem, czy by zyskać np. wydajność jesteśmy w stanie zatrudnić jeszcze kilka osób?

kadoel pisze...

Tak samo można by powiedzieć o C#. Jak robimy mega projekt, naprawdę mega. To wiadomo, że będą miliony kodu czy to Java czy C# czy C++ .

Prześlij komentarz

Related Posts with Thumbnails