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

Czy Twoje oprogramowanie jest projektowane przez Kłapouchego?

Oryginalny post: Is Eeyore Designing Your Software?

Autor: Jeff Atwood

Ten klasyczny wpis Erica Lipperta w straszliwie boleśnie dokładny sposób opisuje to, ile pracy potrzeba, aby dodać funkcję ChangeLightBulbWindowHandleEx do kodu w Microsofcie:

  • Jeden programista, który poświęci pięć minut na implementację ChangeLightBulbWindowHandleEx.
  • Jeden program manager, który napisze specyfikację.
  • Jeden ekspert od lokalizacji, który przejrzy specyfikację pod kątem ewentualnych problemów z lokalizacją.
  • Jeden ekspert od użyteczności, który przejrzy specyfikację pod kątem problemów z dostępnością i użytecznością.
  • Przynajmniej jeden programista, tester oraz PM, aby przeprowadzić burzę mózgów odnośnie wrażliwości zabezpieczeń.
  • Jeden PM, który doda model zabezpieczeń do specyfikacji.
  • Jeden tester, który napisze plan testów.
  • Jeden kierownik testerów, który uaktualni harmonogram testów.
  • Jeden tester, który napisze przypadki testowe i doda je do nocnej automatyzacji.
  • Trzech bądź czterech testerów, którzy wezmą udział w spontanicznym poszukiwaniu błędów.
  • Jeden pisarz techniczny, który napisze dokumentację.
  • Jeden recenzent techniczny, który potwierdzi dokumentację.
  • Jeden edytor, który potwierdzi dokumentację.
  • Jeden menadżer od dokumentacji, który zintegruje nową dokumentację z istniejącym tekstem, uaktualni spis treści, indeksy, itp.
  • Dwudziestu pięciu tłumaczy, którzy przetłumaczą dokumentację i informacje o błędach na wszystkie wspierane przez Windows języki. Menadżerowie tłumaczów mieszkają w Irlandii (języki europejskie) oraz Japonii (języki azjatyckie), które to kraje są w zupełnie innych strefach czasowych niż Redmond, więc współpraca z nimi może być niekiedy dosyć złożonym problemem logistycznym.
  • Zespół starszych menadżerów do koordynowania pracy wszystkich tych ludzi, wypisania czeków i wyjaśnienia kosztów ich wiceprezesowi.

Myślę, iż czasem programiści zapominają, jak dużo pracy wymaga stworzenie oprogramowania w dużych firmach. Coś, co z zewnątrz może wydawać się nam oczywistą zmianą pięciu linijek kodu, w rzeczywistości wymaga pięciu osobo-tygodni pracy, kiedy wliczysz w to cały narzut związany z procesem. Wytykamy tutaj Microsoftowi, ale to nie znaczy, że tyczy się to tylko tej firmy; jest to prosta funkcja skali i odbiorców dla całego komercyjnego oprogramowania.

Tak więc oczywiste pytanie: kto robi wszystkie te rzeczy dla niekomercyjnego, open-source'owego oprogramowania? Odpowiedź, której udzielił Raymond Chen w komentarzu pod tym samym wpisem, to "nikt":

Kto rozwija plany testów dla oprogramowania open-source? Kto aktualizuje zrzuty ekranów w instrukcji użytkownika i pomocy online? Oraz kto tłumaczy dokumentację na polski i turecki? Kto weryfikuje, czy dana funkcjonalność nie łamie Amerykańskiej Ustawy o Niepełnosprawnych, bądź Niemieckich Praw odnośnie Prywatności? Wtedy, gdy pracowałem nad Linuxem, odpowiedzią było "Nikt. Nie ma czegoś takiego jak plan testów, drukowana instrukcja użytkownika, jedyną dokumentacją, jaka istnieje, to ta po angielsku, oraz nikt nie przejmuje się zgodnością z jakimikolwiek prawami." Może coś się pozmieniało od tamtego czasu.

Oto moje szczere pytanie: czy oprogramowanie open source potrzebuje procesu, aby odnieść sukces? Czy to nie jest tak, że radykalny brak narzutu procesowego w open source nie jest słabością, ale w zasadzie ewolucyjną zaletą? To, czego oprogramowanie open source nie posiada w odniesieniu do procesów, nadrabia wszechobecnością i społecznością. Innymi słowy, jeśli elbończycy kładą duży nacisk na lokalizację, sami mogą podjąć się tego wysiłku. W tym samym czasie, programiści mają więcej czasu na implementację funkcjonalności, które zachwycają największą część klientów, zamiast przedzierać się przez utrudnienia procesowe przy każdej, najmniejszej nawet zmianie kodu.

Czy duże firmy tworzące oprogramowanie są upośledzone przez własne procesy?

Jeśli otwarcie będziesz wynagradzał i promował ludzi za zabijanie pracy poprzez użalanie się nad ryzykiem, kosztem testów, wpływem lokalizacji na każdą z funkcjonalności oraz przerywanie żądania zmiany designu tak, jakby to był Dan Brown zakuty w kajdany przed wściekłym ze złości Papieżem, cóż, każdy złapie widły i krzyknie "Tak się nie da! Nie da się tak dostarczyć produktu!" - efekt Bandwagon murowany.

To zmusza mnie do zastanowienia się nad tym, ile miałem spotkań odnośnie funkcjonalności oraz nad tym, jak mały ich procent został kiedykolwiek wdrożony. To nie jest tak, że każda funkcjonalność to dobry pomysł, ale czasami jasno widać, że dana funkcjonalność powinna zostać zaimplementowana. Niczym Kłapouchy: "O nie. Teraz będziemy musieli to wspierać. Podejrzewam, że żądanie hotfixa może nadejść w każdej chwili.."

Aż za często wydaje się, że oprogramowanie od Microsoft jest zaprojektowane przez Kłapouchego.

Kłapouchy i ptak

W tym przypadku ptaszek reprezentuje funkcjonalności, które zachwycają klientów.

Data publikacji oryginału: 24 marca, 2008

Zapraszamy na konferencję ABB Dev Day

Serdecznie chcielibyśmy zaprosić Was do uczestnictwa w wydarzeniu, którego koordynatorami są Rafał Legiędź (rafek) oraz Michał Śliwoń (mXs), a której organizatorem a zarazem głównym sponsorem jest firma ABB Sp. z o.o. ABB Dev Day jest pierwszą tego typu imprezą organizowaną przez firmę ABB i miejmy nadzieję, że nie ostatnią.

Głównym założeniem przy organizacji tego wydarzenia było zebranie w jednym miejscu pasjonatów z naszej branży, aby ci mogli wymieniać się swoimi doświadczeniami. Dodatkowo myślimy, iż udało nam się zaprosić naprawdę ciekawe osobistości z naszej społeczności: Rob Ashton, Tiberiu Covaci, Szymon Pobiega, Michał Brzozowski, czy Paweł Brodziński.

Więcej informacji o konferencji znajdziecie na stronie oficjalnej ABB Dev Day. W tym miejscu pragniemy jeszcze wspomnieć, że ilość miejsc jest ograniczona do 200, więc jeśli ktoś z Was jest zainteresowany, to zachęcamy do jak najszybszej rejestracji.

Related Posts with Thumbnails