Pierwsza wersja jest beznadziejna, ale i tak ją wydaj

Oryginalny post: Version 1 Sucks, But Ship It Anyway

Autor: Jeff Atwood

Jestem niezadowolony z każdego, najmniejszego kawałka kodu, jaki kiedykolwiek opublikowałem. Częściowo dlatego, że -- podobnie jak wielu programistów -- jestem perfekcjonistą. No i właśnie, nieuchronnie pojawiają się... problemy:

  • Harmonogram był zbyt agresywny i krótki. Potrzebujemy więcej czasu!
  • Napotkaliśmy niewidoczne wcześniej problemy techniczne i zmuszają nas one do zawierania niekomfortowych kompromisów.
  • Mieliśmy zły projekt i trzeba było go zmienić w samym środku procesu tworzenia oprogramowania.
  • Nasz zespół doświadczył wewnętrznych konfliktów, których nie przewidzieliśmy.
  • Konsumenci nie byli tymi, o których myśleliśmy.
  • Komunikacja między projektantami, programistami oraz pozostałymi członkami zespołu nie była tak efektywna, jak myśleliśmy, że będzie.
  • Niedoszacowaliśmy czasu, jaki potrzebny jest na nauczenie się nowej technologii.

Ta lista ciągnie się i ciągnie. Powodów, dla których projekty programistyczne się nie udają jest mnóstwo.

Na sam koniec cyklu produkcji zostajesz z oprogramowaniem, które jest bladym cieniem świecącego, wspaniałego monumentu inżynierii oprogramowania, jaki wyobrażałeś sobie, kiedy zaczynałeś.

Pojawia się skłonność do uznania porażki -- żeby dać więcej czasu w harmonogramie, aby wszystko poprawić zanim produkt zostanie wypuszczony na rynek. Jest jednak tak, że prawdziwy deweloper publikuje.

Jestem tutaj, aby powiedzieć Ci o pewnym błędzie.

Tak, zrobiłeś w tym projekcie od groma rzeczy źle. Zrobiłeś źle od groma innych rzeczy, o których jeszcze nawet nie wiesz. Nie ma możliwości, aby dowiedzieć się, czym te rzeczy są, dopóki nie wypuścisz aktualnej wersji i nie pokażesz jej użytkownikom oraz konsumentom. Myślę, że Donald Rumsfeld ujął to znakomicie:

Jak wiemy,
Są wiadome wiadome.
Są rzeczy, o których wiemy, że wiemy.
Wiemy również,
Że są znane niewiadome.
To znaczy,
Wiemy, że są pewne rzeczy,
Których nie wiemy.
Ale są również nieznane niewiadome,
Te, o których nie wiemy,
Że nie wiemy.

Kiedy staniesz oko w oko z nieuniknionymi niespodziankami na zakończenie projektu -- pojawią się przymusowe kompromisy, zupełnie niesatysfakcjonujące poprawki na szybko i częściowe rozwiązania -- możesz wziąć się w garść i zacząć wylizywać swoje rany. Możesz spędzić kilka dodatkowych miesięcy naprawiając obecną wersję przed jej opublikowaniem. Możesz nawet poczuć się dobrze, że zdecydowałeś się wykonać tę pracę inżynieryjną, zanim pokazany został światu kolejny niekompletny kod pełen błędów.

Niestety, to nawet większy błąd niż opublikowanie ułomnej wersji.

Zamiast spędzać trzy miesiące poprawiając obecną wersję w sterylnych, wyizolowanych warunkach laboratoryjnych, mógłbyś spędzić te same trzy miesiące słuchając opinii od rzeczywistych, do bólu uczciwych, denerwującychoddanych użytkowników Twojego oprogramowania. Nie oprogramowania, które sobie wymarzyłeś, nie od użytkowników których sobie wymarzyłeś, ale takich, jacy istnieją w realnym świecie. Możesz więc zmienić podejście i wykorzystać ten bezpośredni feedback nie tylko, aby naprawić wszystkie kiepskie fragmenty pierwszej wersji, ale również, aby wydawać budżet projektowy bardziej efektywnie, opierając się na twardych danych otrzymywanych od Twoich użytkowników.

Uwaga, nie mówię, że masz wypuszczać chłam. Uwierz mi, wszyscy jesteśmy tutaj perfekcjonistami. Ale prawdziwy świat może być brutalny i nieprzejednany dla nas, perfekcjonistów. Rozsądniej jest pozwolić oprogramowaniu „odejść”, a kiedy zorientujesz się, że rozbiło się o skaliste wybrzeże realnego świata, rozczarowanie jest nieuchronne... ale wyleczalne! To co jest ważne, to raczej nie pierwotny stan oprogramowania -- w zasadzie niektórzy mówią nawet, że jeśli nie jesteś zawstydzony pierwszą wersją, to nie opublikowałeś jej wystarczająco wcześnie -- ale to, co robisz po jego opublikowaniu.

Szybkość i kontaktowość Twojego zespołu z użytkownikiem wpłynie na jakość oprogramowania bardziej niż jakiekolwiek pojedyncze wydanie. To jest to, w czym potrzebujesz być dobry. Nie platoniczna idea dostarczania mitycznego, perfekcyjnego oprogramowania, ale bycie kontaktowym względem Twoich użytkowników oraz konsumentów i okazywanie im tego poprzez proces ulepszania i udoskonalania oprogramowania zgodnie z ich opinią. Więc do tego stopnia, do którego optymalizujesz chcąc otrzymać bliskie perfekcji wersje oprogramowania, optymalizujesz źle.

Nie ma wątpliwości, że jakimkolwiek budżetem czasu byś nie dysponował, otrzymasz lepsze oprogramowanie wydając je tak wcześnie, jak to tylko możliwe, a następnie wykorzystując pozostały czas na iteracje w oparciu o opinie użytkowników.

Więc zaufaj mi: nawet jeśli pierwsza wersja jest kiepska, wydaj ją mimo to.

Data publikacji oryginału: 3 grudnia, 2009

Życzenia świąteczne

choinka

Z okazji nadchodzących Świąt Bożego Narodzenia oraz Nowego 2010 Roku, pragniemy przesłać najserdeczniejsze życzenia.

Niech będzie to niezapomniany czas spędzony bez pośpiechu, troski i zmartwień, przepełniony spokojem i radością, wśród Rodziny, Przyjaciół oraz wszystkich Bliskich Osób.

Życzy zespół DevBlogi.pl

P.S. Brak nowych wpisów jest mocno skorelowany z napięciem przedświątecznym. :)

Jak powinniśmy nauczać informatyki?

Oryginalny post: How Should We Teach Computer Science?

Autor: Jeff Atwood

Greg Wilson przesłał mi ostatnio e-mailem następujące pytanie:

Od stycznia wykładam inżynierię oprogramowania dla studentów 3-ciego roku na Uniwersytecie Toronto i chciałbym choć jedną godzinę poświęcić na wdrożenia -- [wdrożenia] nigdy nie pojawiły się na moich wykładach i są dość często pomijane w podręcznikach do inżynierii oprogramowania, a z doświadczenia wiem, że bywają one wyzwaniem niemniej trudnym jak samo napisanie aplikacji.

Wdrożenie jest wielkim problemem. Jest wyzwaniem nawet dla najlepszych zespołów programistycznych i jest niesamowicie ważne: jeśli użytkownicy nie mogą przejść przez fazę instalacji, to cały kod, który napisałeś, nie ma znaczenia! A wciąż, tak jak zaznaczył Greg, istniejące podręczniki do inżynierii oprogramowania pobieżnie traktują ten ważny temat. Podobnie, parę tygodni temu młodszy współpracownik powiedział mi, że nigdy nie uczył się o kontroli wersji na żadnych z zajęć na informatyce. Jak to możliwe? Kontrola wersji jest podstawą inżynierii oprogramowania.

Jeśli na uniwersytetach nie nauczamy fundamentalnych zagadnień z inżynierii oprogramowania, takich jak wdrożenia czy kontrola wersji, to nauczamy informatyki w zły sposób. Czym jest nauczanie pisania kodu w oderwaniu od rzeczywistości, jeśli nie możesz pracować nad tym kodem zespołowo w kontrolowanym środowisku oraz nie możesz wdrożyć wynikowego oprogramowania? Wielu absolwentów informatyki dowiaduje się tego z opóźnieniem, gdy znajdą się już w prawdziwej pracy jako programiści -- nie ma w tym nic dobrego.

Dzisiejsi studenci informatyki powinni rozwijać oprogramowanie w warunkach jak najbardziej zbliżonych do tych z prawdziwego świata albo przypominających takie. Każda linijka kodu powinna być pisana pod kontrolą wersji przez cały czas. To nie podlega dyskusji. Kiedy przychodzi czas wdrożenia, spróbuj to zrobić na współdzielony serwer komercyjny i dowiedz się wszystkiego, co ta czynność za sobą pociąga. Jeśli jest to aplikacja wykonywalna, stwórz samodzielną paczke instalacyjną, którą użytkownicy mogą ściągnąć, zainstalować, a następnie mieć dostęp do mechanizmu, za pomocą którego mogą raportować błędy, na które napotkają. Studenci powinni badać każdy nadesłany błąd w aplikacji, którą napisali.

Czy to będzie bolesne? O stary, zawsze takie będzie. Będzie potworne. Studenci znienawidzą to. Zaczną kwestionować to, dlaczego ktoś o zdrowych zmysłach chciałby pisać oprogramowanie.

Witamy w prawdziwym świecie.

Po tym jak odpowiedziałem Gregowi, Joel Spolsky zamieścił wpis o nauczaniu informatyki, który na moje oko wygląda zadziwiająco podobnie do rady, której udzieliłem:

Myślę, iż rozwiązaniem byłoby stworzenie BFA z tworzenia oprogramowania ze wzmożonym programowaniem -- Julliard dla programistów. Program studiów zawierałby zespołowe tworzenie nadających się do zastosowania w praktyce kawałków oprogramowania wraz z bardzo doświadczonymi nauczycielami oraz odrobinę zajęć ze sztuk wyzwolonych dla równowagi.

Kiedy mówię BFA, Bakałarz Sztuk Pięknych, mam na myśli to: tworzenie oprogramowania jest sztuką, a istniejący model nauczania informatyki, gdzie masz się nauczyć paru rzeczy o NP-zupełności oraz Quicksorcie, jest wybitnie nieadekwatny, jeśli chodzi o nauczanie studentów jak rozwijać oprogramowanie.

Wyobraź sobie natomiast program nauczania, który zawiera 1/3 sztuk wyzwolonych oraz 2/3 pracy związanej z tworzeniem oprogramowania. Nauczyciele to doświadczeni twórcy oprogramowania związani z branżą. Studia byłyby czymś w rodzaju firmy wytwarzającej oprogramowanie. Mógłbyś specjalizować się w wytwarzaniu gier i na przykład pracować nad konkretnym tytułem gry, i tak byś spędzał większość czasu, tak jak studenci filmówki spędzają dużo czasu na właściwym robieniu filmów, a studenci tańca spędzają większość czasu tańcząc.

Nie chodzi o to, aby wyrzucić teorię z programów nauczania informatyki. Fundamentalne pojęcia takie jak algorytmy i struktury danych są nadal ważne. Moje zajęcia z algorytmów były moimi ulubionymi i, co więcej, najbardziej użytecznymi zajęciami, na jakie uczęszczałem podczas studiów. Ale nauczanie tych rzeczy kosztem bardziej prozaicznych umiejętności z inżynierii oprogramowania -- umiejętności, których niesamowicie potrzebujesz jako praktykujący programista -- jest olbrzymią pomyłką. To jest to, do czego Steve Yegge czynił aluzję w jego fantastycznym wypracowaniu o Szkole Czarodziejów.. jak sądzę.

I tu jest problem -- wszystkie te napuszone stopnie naukowe z informatyki możnaby zdegenerować do czegoś w stylu szkół zawodowych, o czym wspominał Joel w swoim znakomitym przemówieniu na Yale:

W instytucjach z Ligii Bluszczowej wszystko jest o Unixie, programowaniu funkcjonalnym i o teoretycznych rzeczach na temat automatów skończonych. Idąc dalej, do mniej wymagających uczelni, zaczyna pojawiać się Java. Posuwając się dalej zaczynasz dosłownie dostrzegać zajęcia o tematyce typu Microsoft Visual Studio 101, 3 punkty zaliczeniowe. Do czasu aż dotrzesz do 2-letnich instytucji, zobaczysz kursy "certyfikacyjne" SQL-Server-w-21-dni, które są reklamowane w weekendy na kablówce. Czy to nie czas by rozpocząć karierę w (zmiana głosu) Java Enterprise Beans!

Można osiągnąć obie rzeczy jednocześnie. Dlatego jestem tak entuzjastycznie nastawiony do praktyk. Informatyka na uniwersytecie jest tak sucha i jałowa, że musisz poświęcić swoje wakacje na pracę w branży, inaczej nie posiądziesz niezbędnych umiejętności z zakresu inżynierii oprogramowania, których będziesz potrzebował, aby przetrwać po ukończeniu studiów. Nieistotne małe rzeczy jak, powiedzmy, kontrola wersji, wdrożenia czy zmaganie się z użytkownikami. Ciągle ględzę o praktykach, jak tylko spotkam studenta w pogoni za stopniem naukowym z informatyki. To dla Waszego własnego dobra.

Uderzająco niesprawiedliwe jest to, że studenci są zmuszeni polegać na praktykach, by dokończyć swoją edukację informatyki. Albo nawet coś o wiele gorszego. "Chcesz nauczyć się informatyki? Nie potrzeba uniwersytetu! Ściągnij tylko parę obrazów ISO i załóż swój własny startup w postaci portalu społecznościowego!" Wyzwolenie nagiej chciwości tłumu TechCrunch na wrażliwe programistyczne umysły zdaje się być całkowicie okrutne.

Tak więc, jak powinniśmy nauczać informatyki? Cynicy powiedzą, że tego się nie da zrobić. Myślę że to jest zrzucenie odpowiedzialności. Jeśli studenci chcą się przygotować na karierę w branży tworzenia oprogramowania, muszą pozbyć się teorii i spędzić znaczną część swojego czasu na tworzeniu oprogramowania ze wszystkimi jego brodawkowatowymi, kłującymi, niebędącymi żadnym wyzwaniem elementami. Połowa inżynierii oprogramowania to łagodzenie bólu. Jeśli nie przeklinasz co tydzień swojego dostawcy hostingowego, nie walczysz z systemem kontroli wersji każdego dnia, nie odszyfrowywujesz raportów błędów od swoich użytkowników co godzinę -- nie byłeś uczony informatyki.

Data publikacji oryginału: 12 stycznia, 2008

Ostrzenie piły

Oryginalny post: Sharpening the Saw

Autor: Jeff Atwood

Jak ostrzysz swoją piłę jako programista?

Ostrzenie piły odnosi się do wszystkiego co robisz, co nie jest programowaniem, a ma na celu (teoretycznie) zrobienie z Ciebie lepszego programisty. Pojęcie to pochodzi z książki Coveya -- 7 Nawyków Skutecznego Działania.

Pewien facet natknął się w górach na drwala. Mężczyzna zatrzymał się, aby poobserwować drwala, gdy ten gorączkowo ścinał bardzo duże drzewo. Zauważył, że drwal pracował w pocie czoła, piłował i piłował, i nic z tego nie było. Obserwator zwrócił uwagę na to, iż piła drwala była tak ostra jak nóż do masła. Tak więc powiedział do niego, "Przepraszam panie drwalu, ale zauważyłem, jak bardzo męczy się pan z tym drzewem bez jakiegokolwiek rezultatu." Drwal odpowiedział z potem płynącym mu po twarzy, "Tak, wiem. To drzewo wydaje się stawiać mi opór." Przechodzeń odpowiedział, "Ale panie drwalu, pańska piła jest tak tępa, że prawdopodobnie nic by nie przecięła." "Tak wiem", powiedział drwal, "ale jestem tak zajęty piłowaniem, że nie mam czasu na ostrzenie piły."

Oczywiście, najlepszą drogą aby stać się w czymś lepszym jest robienie tego jak najczęściej. Ale jeśli jesteś tak zajęty kodowaniem, że nie masz czasu na dyskusję, introspekcję czy naukę, to tak naprawdę nie rozwijasz się. Musisz sobie ustalić świadomą równowagę pomiędzy praktykowaniem swojej profesji, a tym jak ją praktykujesz.

Scott Hanselman ma dobre pomysły na to, jak zachęcać członków swojego zespołu, by ostrzyli swoje piły. Jest również oczywisty sposób, czyli rzecz, którą robisz teraz: czytanie blogów programistycznych. Nie chodzi mi o ten blog, ale o te, które są wartościowe. Jeśli posiadasz otwarty umysł, to możesz ostrzyć swoją piłę w sposób, jaki opisał Reginald Braithwaite:

Robimy następujące rzeczy: czytamy wpis na blogu, jedną rzecz po drugiej, z którymi się zgadzamy i jeśli natrafimy na rzecz, która nie pasuje do naszego światopoglądu, domagamy się poprawki. Jeśli teza wpisu koliduje z naszymi uprzedzeniami, to oskarżamy autora o bycie idiotą. Szczerze, bylibyśmy beznadziejni jako sprzedawcy. Dalibyśmy sobie spokój w momencie, gdyby ktoś się z nami nie zgodził.

Sugeruję abyśmy naśladowali sprzedawców. Kiedy czytamy wpis na blogu bądź książkę, albo przyglądamy się nowemu językowi załóżmy, że część lub całość tej rzeczy nie będzie nowa. Załóżmy, że naprawdę będziemy nienawidzieć jakiejś części tego. Ale spójrzmy na to ze strony naszych korzyści: wygrywamy jeśli doszukamy się choć jednej rzeczy, która uczyni nas lepszymi programistami.

To wszystko czego potrzebujemy z wpisu na blogu. Jeśli znajdziemy jedną rzecz, to będzie wielka wygrana. Do licha, to jest wielka wygrana, jeśli przeczytamy 100 wpisów i nauczymy się jednej wartościowej rzeczy.

Jeśli poszukujesz dobrych programistycznych blogów, by ostrzyć swoją piłę (albo chociaż by dopiec swej intelektualnej ciekawości), to znam dwie strony agregujące z doskonałymi linkami do stron programistycznych, które pomogą Ci je znaleźć.

Pierwszym jest Hacker News, którego gorąco polecam.

Hacker News jest wynalazkiem Paula Grahama, tak więc częściowo odzwierciedla jego udział w Y Combinator oraz w przedsiębiorczych rzeczach jak na przykład startupy. Paul podchodzi poważnie co do moderacji na stronie, więc w dodatku do głosowania w stylu Digga, ukryta jest starannie dobrana grupa spiskowców (lubię ich utożsamiać z Ośmiokątem, "nikt nie przyzna, że oni wciąż istnieją!"), która usuwa oflagowane wpisy. Co ważniejsze, dyskusje na stronie dotyczące artykułów są całkiem sensowne, z bardzo małą ilością zakłóceń i trolowania.

Inną stroną jest programming reddit. Dyskusje tam są bardziej chaotyczne, gdzie wszystko przechodzi, a jedyną przeszkodą są głosy oddane przez społeczność. Ale całkiem rozsądnym jest wykopywanie dużej ilości różnorodnych odnośników, które interesują programistów.

Rzeczą jasną jest, że zbyt częste ostrzenie piły, albo losowe, nieukierunkowane ostrzenie piły, może się stać inną formą prokrastynacji. Ale programista, który zdaje się być kompletnie niezainteresowany takimi rzeczami, jest wielką czerwoną flagą. Tak jak to wyjaśnia Peter Bergman, obsesja może być dobra:

Ludzie często odnoszą sukcesy nie pomimo swoich dysfunkcji, ale przez nie. Obsesje są jednym z najlepszych znaków ostrzegawczych sukcesu. Gdy zrozumiesz obsesję człowieka, zrozumiesz jego naturalną motywację. Rzecz, za którą poszedłby na koniec świata.

Dobrze jest mieć trochę obsesji na punkcie ostrzenia swojej piły, jeśli to oznacza aktywne zamieszczanie bądź komentowanie programistycznych artykułów na przykład na Hacker News.

Jaką formę ostrzenia piły polecasz jako programista?

Data publikacji oryginału: 10 marca, 2009

Co potrafisz zbudować za pomocą 600 linijek kodu?

Oryginalny post: What Can You Build in 600 Lines of Code?

Autor: Jeff Atwood

Joseph Cooney przypomina nam, że w styczniu 2007 roku, firma 37signals wypuściła swój produkt, który został napisany w 579 liniach kodu:

Dobrze przeczytaliście, nie w 60000 czy 600000, ale komercyjny projekt napisany w mniej niż 600 linijkach kodu Ruby. Kiedy po raz pierwszy zobaczyłem tę liczbę, niedowierzałem -- pisałem procedury składowane, które są dłuższe. Mój obecny projekt ma więcej linii konfiguracji. Pisałem nawet aplikacje konsolowe w notatniku, które miały więcej kodu i kompilowałem je z linii poleceń, ponieważ myślałem, iż są tak małe, że nie potrzebują plików .sln i .proj. A mimo to 37signals wypuściło swój produkt, który został napisany za pomocą 579 linijek kodu Ruby.

Jak to zostało opisane na blogu Rails, pierwotna premiera produktu została przedstawiona na blogu twórcy języka Ruby -- Matz'a -- w jego natywnym języku, którym jest japoński. O dziwo, istotne fakty wciąż są czytelne:

Oczywiście, prosta liczba linii kodu nie jest całą historią -- najpierw zbudowali cały framework Rails, aby umożliwić tworzenie małych aplikacji typu ta-da list. Ani kod frameworku Rails, arkuszy stylów, JavaScriptu, HTMLa i tak dalej nie zawierają się w tej liczbie. Ale wciąż zgadzam się z Josephem: to zadziwiające osiągnięcie i prowadzi ono do ciekawych przemyśleń:

Mam od czasu do czasu jakieś pomysły na produkt. Jaka jest minimalna ilość kodu, który należałoby napisać, by zrealizować ideę? Jeśli byłbym przygotowany, aby operować z ograniczeniami platformy (jakakolwiek by ona nie była), ile zachodu by mi to zaoszczędziło? Ile jeszcze "interesujących pomysłów" mógłbym zrealizować, gdybym był przygotowany trzymać się tych ograniczeń? O ile więcej fajnych/użytecznych rzeczy mógłbyś zbudować, jeśli narzuciłbyś sobie, że każda z nich miałaby 600 linii kodu?

Co Ty potrafisz stworzyć za pomocą 600 linii kodu? Pomyśl o tym jak o ćwiczeniu na minimalizm. Czy Twój ulubiony język programowania bądź środowisko daje Ci swobodę tworzenia czegoś interesującego i użytecznego przy takim założeniu?

Data publikacji oryginału: 24 stycznia, 2008

Najlepszy kod to brak kodu w ogóle

Oryginalny post: The Best Code is No Code At All

Autor: Jeff Atwood

Rich Skrenta pisze, że kod jest naszym wrogiem.

Kod jest nieznośny. Gnije. Wymaga okresowego konserwowania. Zawiera błędy, które trzeba znaleźć. Nowe funkcjonalności wymagają adaptowania starego kodu. Im więcej masz kodu, tym więcej miejsc, gdzie mogą ukrywać się błędy. Tym dłuższe przygotowanie i kompilacja programu. Tym więcej czasu zajmie nowemu pracownikowi zrozumienie twojego systemu. Jeśli będziesz musiał go refaktoryzować, będzie więcej elementów do zreorganizowania.

Kod jest tworzony przez inżynierów. Napisanie większej ilości kodu wymaga większej liczby inżynierów. Inżynierowie komunikują się z kosztem kwadratowym (n^2), kod dodawany przez nich do systemu zwiększa jego możliwości, ale równocześnie koszty. Powinieneś robić wszystko co możliwe, aby zwiększyć produktywność poszczególnych programistów, aby pisany przez nich kod był tym, który jest najbardziej zwięzły. Mniej kodu do zrobienia tego samego (a może też lepiej). Mniej programistów do zatrudnienia. Mniejsze koszty komunikacyjne.

Na to wskazuje Rich, ale prawdziwym problemem nie jest kod. Kod w momencie napisania go dla świata jest zupełnie niewinny, niczym nowonarodzone dziecko. Kod nie jest naszym wrogiem. Chcesz zobaczyć prawdziwego wroga? Idź spojrzeć w lustro. Tam jest twój problem, właśnie tam.

samochód lusterko widok

Jako programista jesteś swoim najgorszym wrogiem. Im wcześniej to dostrzeżesz, tym lepiej dla Ciebie.

Wiem, że masz najlepsze intencje. My wszyscy je mamy. Jesteśmy programistami, kochamy pisać kod. To jest to, co robimy. Nigdy nie spotkaliśmy się z problemem, którego nie moglibyśmy rozwiązać przy pomocy taśmy klejącej, prowizorycznego wieszaka i szczypty kodu. Natomiast Wil Shipley przekonuje, że powinniśmy powstrzymać się w naszej naturalnej tendencji do pisania dużej ilości kodu:

Fundamentalną właściwością kodowania z naszego programistycznego punktu widzenia jest spostrzeżenie, że każda decyzja jaką podejmujemy jest kompromisem. Aby być dobrym programistą należy zrozumieć naturę tych kompromisów i być ich świadomym podczas pisania czegokolwiek.

W kodowaniu masz wiele kryteriów wg których możesz oceniać kod:

  • zwięzłość
  • szeroki zakres funkcjonalności
  • szybkość wykonywania
  • czas spędzony na kodowaniu
  • solidność
  • elastyczność

Teraz zapamiętaj, te kryteria stoją do siebie w opozycji. Możesz spędzić trzy dni pisząc algorytm, który jest naprawdę piękny i szybki, zwiększyć dwukrotnie ocenę w tej kategorii, ale poświęciłeś na to trzy dni, więc ocena w kategorii “czas spędzony na kodowaniu” spada w dół.

Więc, kiedy to się opłaca? Na jakiej podstawie podejmujemy takie decyzje? Odpowiedź okazuje się być bardzo rozsądna, bardzo prosta, a także taka, że nikt nigdy jej nie słucha: Zacznij zwięźle. Polepszaj inne kryteria kiedy testy pokażą, że jest to niezbędne.

Całkowicie się zgadzam. Dawałem podobne rady, kiedy nawoływałem programistów do Zwięzłego Kodowania (Code Smaller). I nie mówię tutaj o zredukowanych do absurdu konkursach podczas których używamy wszystkich mądrych sztuczek z naszych książek, aby kod zajmował mniej fizycznego miejsca. Mówię o praktycznych, rozsądnych zasadach, które pozwolą zmniejszyć objętość kodu, który programista musi przeczytać, aby zrozumieć jak program działa. Tutaj jest trywialny i krótki przykład tego, o czym mówię:

if (s == String.Empty) if (s == "")

Dla mnie oczywistym jest, że drugi przypadek jest lepszy, ponieważ jest po prostu krótszy. A jestem zupełnie pewny, że znajdą się programiści, którzy będą ze mną walczyć, na śmierć i życie, ponieważ są absolutnie przekonani, że nadmiarowość String.Empty jest przyjaźniejsza dla kompilatora. Gdybym się tym przejmował. Gdyby ktokolwiek się tym przejmował.

Dla większości programistów, którzy tak bardzo kochają kodowanie, bolesne jest, żeby to potwierdzić, ale najlepszy kod to brak kodu w ogóle. Każda nowa linia kodu, którą chcesz dać światu wymaga debugowania, kod będzie musiał być czytany, zrozumiany, kod będzie musiał być wspierany. Za każdym razem kiedy piszesz nowy kod, powinieneś robić to niechętnie, jakby pod przymusem, ponieważ nie masz innego wyjścia, wyczerpałeś wszystkie inne możliwości. Kod jest naszym wrogiem dlatego, że nas - programistów piszących cholernie dużo kodu - jest tak wielu. Jeśli nie możesz wytrzymać bez kodu, najlepszą rzeczą jaką możesz zrobić jest zacząć zwięźle.

Jeśli kochasz pisanie kodu – naprawdę, szczerze kochasz pisanie kodu – pisz go tak mało jak jest to tylko możliwe.

Data publikacji oryginału: maj 30, 2007

Related Posts with Thumbnails