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

Prostota

Oryginalny post: Simplicity

Autor: Joel Spolsky

Donald Norman stwierdza, że prostota jest przereklamowana: "Ale kiedy przyszedł moment, aby dziennikarze zrecenzowali 'proste' produkty, wszyscy narzekali na brak kluczowych wg nich funkcjonalności. Co więc ludzie mają na myśli, kiedy chcą prostoty? Operacje wywoływane pojedynczym przyciskiem -- oczywiście -- ale wraz ze wszystkimi swoimi ulubionymi funkcjonalnościami".

Dawno temu pisałem: "Wielu programistów zostało zwiedzionych starą zasadą 80/20. Na pierwszy rzut oka zdaje się to mieć sporo sensu: 80% użytkowników wykorzystuje 20% dostępnych funkcjonalności. Więc przekonujesz samego siebie, że wystarczy zaimplementować tylko 20% funkcjonalności i sprzedawać 80% kopii programu.

Niestety, to nigdy nie jest te same 20%. Każdy używa innych funkcji. Przez ostatnie 10 lat słyszałem o dziesiątkach firm zdeterminowanych, aby nie uczyć się od pozostałych. Próbowali wypuścić 'lekki' edytor tekstu, który implementowałby 20% funkcjonalności. To historia stara jak PC. W większości przypadków dawali swój program do recenzji dziennikarzowi, a on do napisania recenzji wykorzystywał ten nowy edytor. Kiedy dziennikarz próbował znaleźć funkcję do policzenia słów w tekście - której potrzebował, bo większość dziennikarzy ma narzucony limit słów - orientował się, że takiej funkcji nie ma, że jest w tych 80%, których nikt nie używa. Ostatecznie dziennikarz pisał artykuł i stwierdzał, że 'lekkie' programy są dobre, przeciążanie funkcjonalnością jest złe, i że nie może używać tego cholerstwa, "bo nie policzy moich słów".

Tworzenie prostych, 20%-owych produktów jest doskonałą strategią na wystartowanie. Możesz stworzyć je przy ograniczonych zasobach i zdobyć klientów. To strategia Judo - wykorzystanie słabości jako siły, tak jak w Blair Witch Project. Dzieciaki nakręciły film bez żadnych pieniędzy, ręczną kamerą. Fabuła była skonstruowana w ten sposób, że było to zaletą. Sprzedajesz więc 'prostotę', jakby było to coś wspaniałego, a niejako przypadkowo jest to jedyna rzecz jaką ze swoimi środkami możesz wyprodukować. Cóż za szczęśliwy zbieg okoliczności, to doprawdy cudowne!

Ale to co działa dla startupu, moim zdaniem, nie zadziała już jako strategia długookresowa. Nie ma możliwości powstrzymania kolejnego dwuosobowego startupu przed sklonowaniem twojej prostej aplikacji, no i nie możesz walczyć z ludzką naturą: "ludzie chcą tych funkcjonalności", mówi Norman. To że ręczna kamera była idealna dla Blair Witch, to jeszcze nie znaczy, że każdy hollywoodzki szlagier będzie ją wykorzystywał.

Apple iPod Wyznawcy prostoty przywołają 37signals oraz iPod Apple'a jako dowody na to, że prostota się sprzedaje. Uważam że w obu tych przypadkach sukces jest wynikiem połączenia wielu rzeczy: wykreowania grupy odbiorców, ewangelizacji, przejrzystego designu, zaangażowania emocjonalnego, estetyki, szybkiego reagowania, bezpośredniego feedbacku od użytkowników. Model oprogramowania dopasowany do modelu użytkowników daje w rezultacie łatwość w użytkowaniu i kontrolę osobom korzystającym z programu. Są to funkcjonalności (cechy) tego samego rodzaju, w tym sensie, że użytkownicy lubią i chcą za nie płacić, ale żadna z nich tak naprawdę nie może być nazwana 'prostą'. Przykładowo, iPod ma cechę bycia ładnym, której nie ma Creative Zen Ultra Nomad Jukebox, więc poproszę iPoda. W przypadku iPoda bierze się to z przejrzystego i prostego designu, ale nie musi tak być. Hummer jest estetycznie pociągający dokładnie dlatego, że jest brzydki i skomplikowany.

Mówienie, że iPod odniósł sukces, ponieważ ma mało funkcji jest moim zdaniem nieporozumieniem. Jeśli zaczniesz w to wierzyć, będziesz wierzył, że aby zwiększyć sukces swojego produktu, powinieneś usuwać z niego funkcjonalności. Z sześcioletniego doświadczenia w prowadzeniu własnej firmy programistycznej mogę Ci powiedzieć, że w Fog Creek nic nigdy nie zwiększyło naszych dochodów bardziej niż wypuszczenie nowej wersji programu z większą liczbą funkcji. Nic. Wpływ nowych wersji z nowymi funkcjami na nasze zyski jest absolutnie niepodważalny. To jak grawitacja. Kiedy testowaliśmy reklamy Google, kiedy realizowaliśmy różne programy partnerskie, albo kiedy pojawiał się artykuł o naszym produkcie (FogBugz) w prasie, ledwo dostrzegaliśmy wpływ na zyski. Natomiast kiedy wychodziła nowa wersja z nowymi funkcjami, widzieliśmy niezaprzeczalny, znaczny i stały wzrost dochodów.

Jeśli używasz terminu 'prostota' w odniesieniu do produktu, w którym model użytkownika koresponduje z modelem programu, tak, że produkt jest łatwy w użyciu, super, plus dla Ciebie. Jeśli używasz terminu 'prostota' w odniesieniu do produktu z oszczędnym i czystym wyglądem, jakby termin nie znaczył nic innego ponad opisywanie wrażeń estetycznych, super, plus dla Ciebie. Minimalistyczna estetyka jest dziś czymś ekstra. Ale jeśli myślisz, że prostota znaczy "niezbyt dużo funkcji" albo "robi jedną rzecz a dobrze", wtedy pochwalę Twoją szczerość, ale nie zajedziesz daleko z produktem, który celowo został okrojony z funkcjonalności. Nawet iPod ma darmową grę Solitaire. Nawet Ta-da List wspiera RSS.

Tymczasem, lecę... czas najwyższy wymienić moją komórkę na taką, która ma szybki dostęp do internetu, e-maila, podcastów i odtwarzacz MP3.

Data publikacji oryginału: 9 grudnia, 2006

Karta Praw Programisty

Oryginalny post: The Programmer's Bill of Rights

Autor: Jeff Atwood

To niewiarygodne, że firma jest w stanie płacić programiście $60-$100k rocznie, a przy tym upośledzać go okropnymi warunkami pracy oraz obdartym sprzętem z drugiej ręki. Nie ma w tym żadnego biznesowego sensu. A jednak dostrzegam to przez cały czas. Szokujące jest to, jak wiele przedsiębiorstw wciąż nie dostarcza programistom niezbędnych rzeczy do osiągnięcia celu.

Proponuję abyśmy przyjęli Kartę Praw Programisty, by chronić ich praw poprzez uniemożliwianie firmom zabraniania im podstaw potrzebnych do skutecznej pracy.

  1. Każdy programista powinien mieć dwa monitory

    W obliczu spadających cen paneli LCD oraz wszechobecnych kart video z podwójnymi wyjściami, musiałbyś być głupcem, by ograniczać swoich programistów do jednego ekranu. Korzyści płynące z podwojenia swojego pulpitu są teraz dobrze udokumentowane. Jeśli chcesz zmaksymalizować efektywność programisty, upewnij się, że każdy z nich ma dwa monitory.

  2. Każdy programista powinien mieć szybki komputer

    Programiści muszą mieć uruchomionych wiele aplikacji, aby wykonywać swoją pracę: środowiska programistyczne, silniki bazodanowe, serwery webowe, wirtualne maszyny, itd. Aby to wszystko działało potrzebny jest szybki komputer z dużą ilością pamięci. Im szybszy komputer programisty tym krótszy czas kompilacji. Nierozsądnym by było, gdybyś płacił olbrzymie kwoty za najwydajniejszy sprzęt -- ale zawsze upewnij się, że kupujesz sprzęt z prawie najwyższej półki. Wyposaż swoich programistów w szybkie komputery z dużą ilością pamięci. Czas spędzony na gapieniu się w pasek postępu to zmarnowany czas.

  3. Każdy programista powinien mieć możliwość wyboru myszy oraz klawiatury

    Na studiach prowadziłem firmę malarską. Każdy malarz, którego zatrudniałem, musiał kupić własne pędzle. To była jedna z pierwszych rzeczy, których się nauczyłem. Zaopatrywanie malarzy w standardowy pędzel nie zdawało egzaminu. "Firmowe" pędzle były szybko zaniedbywane i zużywane do stanu, w którym wymagały naprawy. Ale malarze, którzy sami kupowali swoje pędzle, dbali o nie. Malarze, którzy sami kupowali swoje pędzle, nauczyli się doceniać różnice pomiędzy ich pędzlem za $20 a tanimi jednorazowymi pędzlami. Posiadanie swojego własnego pędzla wywoływało trwałą odpowiedzialność i kunszt. Programiści powinni być w takich samych stosunkach ze swoją klawiaturą i myszką -- to najbardziej istotne narzędzia w naszej codziennej pracy, których używamy, aby uprawiać swoje rzemiosło.

  4. Każdy programista powinien mieć wygodne krzesło

    Spójrzmy prawdzie w oczy. Zarabiamy na życie siedząc 8 godzin dziennie na swoich tyłkach. Czemu by nie spędzać tych 8 godzin na wygodnym, dobrze zaprojektowanym krześle? Daj programistom krzesła, na których siedzenie przez 8 godzin nie jest tylko znośne, ale jest przyjemne. Oczywiście, zatrudniasz programistów przede wszystkim dla ich umysłów, ale nie zapominaj o innych wartościowych rzeczach programisty.

  5. Każdy programista powinien mieć szybki dostęp do Internetu

    Dobrzy programiści nigdy nie piszą czegoś, co mogą ukraść. A Internet jest najlepszym kanałem dla kradzionych rzeczy jaki kiedykolwiek wynaleziono. Jak najbardziej jestem za książkami, ale ciężko jest sobie wyobrazić wykonaną robotę bez szybkich przeszukań Internetu, które są na wyciągnięcie ręki.

  6. Każdy programista powinien mieć ciche środowisko pracy

    Programowanie wymaga umysłowej koncentracji. Programiści nie mogą pracować efektywnie w środowisku pełnym zakłóceń. Upewnij się, że Twoje środowisko pracy chroni stan skupienia programistów, w przeciwnym razie będą tracić oni mnóstwo czasu na powracanie do tego stanu po zaburzeniu.

Te kilka praw, o które prosimy, są łatwe. To nie są ekstrawaganckie wymagania. Są one podstawą jakości miejsca pracy programisty. Przestrzeganie tych praw nie jest ani kosztowne ani trudne -- jeśli firma, dla której pracujesz tego nie robi. Domagaj się swoich praw jako programista! I pamiętaj: możesz albo zmienić swoją firmę, albo zmienić swoją firmę.

Data publikacji oryginału: 24 sierpnia, 2006

Inwestowanie w dobrej jakości krzesło do programowania

Oryginalny post: Investing in a Quality Programming Chair

Autor: Jeff Atwood

W Drugiej najważniejszej rzeczy programisty opisałem, jak zakup dobrego jakościowo krzesła może być jedną z najmądrzejszych inwestycji, jaką możesz zrobić, będąc programistą.

W rzeczywistości, po poszukiwaniach krzeseł przez ostatnich kilka lat mojej kariery, doszedłem do jednego wniosku: nie możesz oczekiwać, że uda Ci się dostać porządne krzesło za mniej niż $500. Jeśli zamierzasz wydać mniej niż tyle na siedzenie -- chyba, że robisz interes życia na aukcjach po bankrutujących dot-comowych firmach -- prawdopodobnie popełniasz błąd.

Nadal uważam, że to prawda i nalegam, aby każdy programista, który to czyta, poważnie rozważył wartość tego, na czym siedzi podczas gdy pracuje. W naszej profesji miejsce do siedzenia ma znaczenie:

  • Krzesła są podstawową częścią doznań podczas programowania. Osiem godzin dziennie, każdego dnia, przez resztę Twojego zawodowego życia -- siedzisz na jednym z nich. Czy Ci się to podoba czy nie, bez względu na to na czym siedzisz, ma to wymierny wpływ na Twoje doznania podczas pracy.
  • Tanie krzesła są do bani. Może stałem się nieco zepsuty, ale nie miałem jeszcze okazji siedzieć na dobrym, tanim krześle. W moim doświadczeniu różnica pomiędzy naprawdę świetnymi krzesłami a tanimi jest ogromna. Dobre jakościowo krzesło jest tak wygodne i niedające o sobie znać, że możesz skupić się na swojej pracy. Nędzne, tanie krzesło przypomina Ci bez przerwy, jak wiele godzin pracy jeszcze Ci zostało.
  • Krzesła są trwałe. W momencie gdy to piszę, nadal siedzę w swoim oryginalnym krześle Aeron, które kupiłem w 1998 roku. Nie przypominam sobie o jakimkolwiek innym sprzęcie, którego używam w mojej pracy, i który przetrwał przez dziesięć pełnych lat i więcej. Podczas gdy początkowy szok cenowy dobrego jakościowo krzesła może Cię odrzucić, spróbuj w myśli zamortyzować ten koszt na następne dziesięć lub więcej lat.

Problem wyboru siedzenia jest nieodłącznie związany z branżą tworzenia oprogramowania, w przeciwieństwie do wszystkich innych aspektów, które podlegają nieustannym zmianom. Krzesła są długoterminową inwestycją. Dlaczego by nie wybierać krzesła z taką samą troską i rozważaniami, z którymi podejmujesz inne strategiczne decyzje, które będą trwać do końca Twojej kariery? Skąpienie na krześle po prostu nie ma sensu.

Mimo iż byłem całkiem zadowolony ze swojego krzesła Herman Miller Aeron przez ostatnie 10 lat, to zawsze byłem odrobinę rozczarowany sposobem, w jaki został on skojarzony z dot-comową przesadą.

W latach 90-tych Aeron stał się emblematem bańki dot-comowej; symbolizował mobilność, szybkość, efektywność i tygodnie pracy po 24 godziny dziennie. Aeron był czymś, co każdy gorący startup musiał mieć, ponieważ nie wyglądał on jak mebel biurowy: był bardziej jak kawałek maszyny albo surowej techniki. Czarna siatka Pellide była wytrzymała i skrywała wszystkie plamy po Joltcie czy Red Bullu. Napięta przez aluminiową ramę siatka, pozwalała powietrzu cyrkulować i utrzymywać Twoje ciało schłodzone. Co więcej, krzesło wyszło w trzech rozmiarach, niczym spersonalizowane narzędzie. Wyposażone w gałki i dźwignie pozwalało Ci na dostosowanie wysokości siedzenia, siły nachylenia, obszaru nachylenia, nachylenia do przodu, wysokości ramion, szerokości ramion, rozstawu ramion, głębokości lędźwi i ich wysokości. Aeron był zaawansowany technologicznie, ale jednocześnie sexy -- jak to postrzegali dot-commersi.

Ale młodzi prezesi nie czuli sympatii do Aerona tylko za to, jak wyglądał. Aeron był wizualną ekspresją antykorporacyjnego ducha czasu, niehierarchicznej filozofii miejsca pracy. Biuro pełne Aeronów niejawnie odrzucało ranking Fortune 500, garnitury oraz tradycyjny model firmy, w którym szef siedział na przesadnie drogim i wielkim, skórzanym dinozaurze, podczas gdy jego sekretarka balansowała na stołku z Office Max robiąc notatki.

Ostatnio, gdy byłem w podróży, miałem okazję siedzieć na nowszym krześle Herman Miller Mirra i byłem zaskoczony, o ile wygodniej było mi w nim niż w moim klasycznym Aeronie.

Krzesło Mirra było także świetną leżanką. Byłem zawiedziony tym, jak słabo pochyla się Aeron. Właściwie to złamałem raz gałkę do pochylania w moim Aeronie i musiałem ją sam wymienić. Zatem nauczyłem się już nie pochylać, co jest niezręczne jako, iż z natury lubię leżakować.

To wszystko spowodowało, iż zacząłem się zastanawiać nad wysłaniem mojego Aerona na emeryturę, a samemu sprawić sobie coś lepszego. Podobało mi się krzesło Mirra, ale komentarze do mojego oryginalnego wpisu o krzesłach zawierały wiele innych sugestii co do siedzeń. Poniżej przedstawiam zdjęcia i odnośniki do krzeseł, które były najczęściej wymieniane jako konkurencyjne jako dodatek do pokazanych wcześniej Mirry i Aerona:

Steelcase Think Chair

Steelcase Leap Chair

Ergohuman Mesh Chair

HumanScale Freedom Chair

HumanScale Liberty Chair

Było również parę mniej znanych rekomendacji takich, jak krzesła Haworth Zody, Nightingale CXO, BodyBilt ergo, Hag kneeling, NeutralPosture ergo, Chadwick Chair od projektanta Aerona oraz coś co się nazywało The Swooper.

Dopasowanie krzesła jest oczywiście sprawą subiektywną. Jeśli inwestujesz $500 bądź więcej w krzesło, rzeczą zrozumiałą byłoby, iż chciałbyś być pewien, że jest to "to jedyne". Rzeczą jaką należy zrobić, jest znalezienie lokalnego sklepu, który sprzedaje wszystkie te krzesła i wszystkie je wypróbować. Cóż, powodzenia z tym życzę. Nawet nie próbuj z Twoim lokalnym sieciowym supermarketem. Najlepszym wyborem wydają się być specjalne sklepy z krzesłami, gdyż mają one zazwyczaj na stanie bardziej egzotyczne krzesła. Najwyraźniej mają oni klientów, którzy są w stanie zapłacić za komfort.

Recenzje pojedynczych krzeseł są względnie łatwe do znalezienia, ale nie są pomocne, gdy nie ma porównania. To czego potrzebujemy, to zbiorowy przegląd krzeseł. Jedyny godny uwagi przegląd jaki znam, to przegląd Slate'a z końca 2005 roku Sit Happens: The Search for the Best Desk Chair. Nie jest on tak wszechstronny, jak bym chciał, ale zawiera większość głównych kandydatów. Zwycięzcą Slate'a było krzesło HumanScale Liberty.

Oto kilka innych pomocnych źródeł, które znalazłem zarówno w komentarzach do tego wpisu jak i gdzie indziej:

Jeśli to trochę za dużo meblowej pornografii jak na Wasz gust, to rozumiem. Jeśli chodzi o mnie, to skierowałem się do lokalnego, zaprzyjaźnionego sklepu, by dojść do tego, które z tych krzeseł najlepiej zastąpi mojego starzejącego się Aearona. Według moich kalkulacji, Aeron kosztował mnie około $7 miesięcznie przez dziesięć lat jego życia; myślę, że moje trwające zdrowie i komfort podczas programowania jest warte conajmniej tyle.

Aktualizacja: Jako iż ludzie mnie wypytują, ostatecznie zdecydowałem się, że osobiście najbardziej pasuje mi krzesło Herman Miller Mirra. W porównaniu do mojego dziesięcioletniego Aerona to duże ulepszenie. Jest jakby o trzy bądź cztery poprawki lepszy. Na przykład, przednia część siedzenia jest regulowana, co rozwiązuje problem, który miałem z moim Aeronem -- poodbnie jak lepsze pochylanie, o którym wcześniej wspominałem. Jedyną nieprzewidzianą wadą jest to, że plastikowe oparcie jest nieco szorstkie dla skóry, jeśli siedzisz, yy.. bez koszulki. Mimo iż jestem bardzo zadowolony z mojego nowego krzesła Mirra z żółtym oparciem (pic), namawiam Cię do wypróbowania krzeseł przed podjęciem decyzji.

Data publikacji oryginału: lipiec 4, 2008

Postępowanie z zakałami projektu

Oryginalny post: Dealing With Bad Apples

Autor: Jeff Atwood

Robert Miesen przysłał mi następującą historię o patologii projektu:

Byłem częścią zespołu, który pisał internetowy system do aplikowania o pracę i klasyfikowania kandydatów (klient nazywał to kioskiem pracy). Razem z zespołem i klientem uzgodniliśmy, że do zaimplementowania tego kiosku użyjemy Windowsa, Apache'a, PHP5 oraz ZendFrameworka -- wszyscy się na to zgodzili oprócz jednego członka zespołu, którego będę nazywał "Joe". Przez całą fazę ustalania technologii Joe zalecał użycie JavaScriptu mimo, iż klient całkiem jasno określił oczekiwania, że większość kiosku, wraz z całą walidacją, ma być zaimplementowana z użyciem technologii po stronie serwera.

Fakt, iż klient to zatwierdził, jakkolwiek, nie powstrzymał Joe od dalszego zachęcania do JavaScriptu -- o zgrozo. Za każdym razem, gdy nasz projekt napotykał na przeszkody, Joe rozpoczynał tyradę o tym, o ile prostsze byłoby nasze życie, jeżeli tylko pisalibyśmy ten kiosk z użyciem JavaScriptu. Joe ciągle sprzeczał się o to, że wszystko co robimy jest źle, ponieważ nie robimy tego za pomocą JavaScriptu. Nie pofatygował się nawet nauczyć technologii, których używaliśmy, a kiedykolwiek jakiś kolega z zespołu próbował grzecznie przywrócić go do porządku (zazwyczaj używając poczty elektronicznej), Joe po prostu obrażał biedaka. W swoim najgorszym momencie pro-JavaScriptowego fanatyzmu Joe regularnie rzucałby komentarzami w stylu: "Cóż, jeśli tylko robilibyśmy to za pomocą JavaScriptu,", do tego stopnia, że zespół lepiej by na tym wyszedł, gdyby Joe odszedł (albo został przeniesiony bądź zwolniony).

Po przeczytaniu tej historii, musiałem powstrzymać się od chęci pochylenia się do przodu, podparcia brody w zamyśleniu, zmarszczenia czoła i zapytania -- czy próbowaliście JavaScriptu?

Robert myślał, że to była ostrzegawcza historia na temat uzależnienia od technologii, ale ja dostrzegam co innego: problematyczny członek zespołu, typowa zakała.

Jestem pewien, że "Joe" miał najlepsze intencje, ale w momencie, gdy aktywnie agitujesz przeciwko projektowi i postępujesz wbrew woli kolegów z zespołu -- jesteś obciążeniem dla projektu.

Koszt problematycznego personelu w projekcie jest poważny, jak jest to opisane w rozdziale 12 książki McConnella Rapid Development: Taming Wild Software Schedules.

Jeśli tolerujesz choć jednego programistę, którego reszta uważa za problem, ranisz morale dobrych programistów. Dajesz do zrozumienia, że nie tylko oczekujesz tego, aby pracownicy dawali z siebie wszystko; oczekujesz od nich, aby to robili, kiedy inni współpracownicy pracują przeciwko nim.

W przeglądzie 32 zespołów zarządzających, Larson i LaFasto zauważyli, iż najczęstsze skargi od członków zespołu dotyczyły tego, że ich kierownicy byli niechętni do konfrontacji i rozwiązywania problemów związanych z kiepską wydajnością, spowodowaną indywidualnymi członkami zespołu. (Larson i LaFasto 1989). Donoszą, iż "bardziej niż przez jakikolwiek inny aspekt przywództwa, wydajność pracowników jest zaburzona przez kierowników, którzy są niechętni do bezpośredniego i efektywnego radzenia sobie z egoistycznymi oraz nieprzykładającymi się współpracownikami." Dalej dochodzą do tego, iż jest to kluczowy problem, którego nie dostrzega kadra zarządzająca, ponieważ menedżerowie zawsze uważają, że ich zespoły lepiej sobie radzą, niż członkowie tych zespołów.

Jak identyfikujemy problem z personelem? To nie takie trudne jakby mogło się wydawać. Kiedyś jeden z moich przyjaciół określił kogoś w swoim zespole -- i to jest dosłowny cytat -- mianem "raka". W momencie kiedy Ty bądź ktokolwiek inny z zespołu używacie słów typu rak do opisania kolegi, macie doczynienia z poważną patologią projektu. Nie musicie się przyjaźnić z każdym członkiem projektu, niemniej jednak to pomaga, ale pewien podstawowy poziom osobistego i profesjonalnego szacunku jest konieczny w każdym zespole, by normalnie funkcjonować.

Steve przedstawia kilka znaków ostrzegawczych mówiących o tym, że macie do czynienia z zakałą w zespole:

  1. Ukrywają swoją niewiedzę zamiast uczyć się od współpracowników. "Nie wiem jak wyjaśnić mój projekt; Po prostu wiem, że działa." albo "Mój kod jest zbyt skomplikowany, by go testować." (Oba stwierdzenia są prawdziwymi cytatami.)
  2. Posiadają nadmierną potrzebę prywatności. "Nie potrzebuję, aby ktokolwiek przeglądał mój kod."
  3. Są terytorialni. "Nikt poza mną nie może poprawiać błędów w moim kodzie. Teraz jestem zbyt zajęty, by je poprawić, ale zrobię to w następnym tygodniu."
  4. Narzekają na decyzje zespołu i powracają do starych dyskusji długo po tym, jak zespół ruszył dalej. "Wciąż uważam, iż powinniśmy się cofnąć i przeprojektować to, o czym rozmawialiśmy w zeszłym miesiącu. To, na co się zdecydowaliśmy nie będzie działało."
  5. Zespół dowcipkuje bądź narzeka regularnie na tę samą osobę. Programiści często nie narzekają bezpośrednio, więc musisz popytać, czy jest jakiś problem, gdy słyszysz wiele żartobliwych komentarzy.
  6. Nie udzielają się w aktywnościach zespołu. W jednym z projektów, w których pracowałem, na dwa dni przed ostatecznym terminem, programista poprosił o dzień urlopu. Powód? Chciał spędzić dzień na wyprzedaży odzieży męskiej w pobliskim mieście -- wyraźny znak, że nie zintegrował się z zespołem.

Pozwól, że wyrażę się jasno na ten temat: jeśli Twój team leader bądź menedżer nie radzi sobie z zakałami w Twoim projekcie, to nie wykonuje on swojej pracy.

Nigdy nie powinieneś obawiać się usunięcia -- albo nawet zwolnienia -- ludzi, w których interesie nie leży dobro zespołu. Możesz rozwinąć umiejętność, ale nie możesz rozwinąć pozytywnego nastawienia. Im dłużej te zakłócające spokój osobistości są uwikłane w projekt, tym gorszy tego efekt. Będą powoli rozsiewać truciznę w Twoim projekcie, w formie kodu, stosunków oraz kontaktów.

Usuwanie kogoś z zespołu jest bolesne; dla nikogo nie jest zabawne. Ale zdanie sobie sprawy z tego, że powinno się usunąć kogoś sześć miesięcy temu, jest o wiele bardziej bolesne.

Data publikacji oryginału: kwiecień 17, 2008

Biały znak: cichy zabójca

Oryginalny post: Whitespace: The Silent Killer

Autor: Jeff Atwood

Zdarzyło Ci się kiedyś mieć taki dzień, w którym wszystko, co wysyłałeś do systemu kontroli wersji, było złe?

Tak w ogóle, to czym dokładnie taki dzień różni się od każdego innego? Ale bądźmy poważni.

Kod, który jest widoczny to kod, który może być niepoprawny. Nie powinno to być zaskoczeniem. Ale czy wiesz, że nawet kod, którego nie widać, również może być zły?

Są to pytania, które doprowadzają młodych programistów do szaleństwa. Spójrzmy na przykład na ten zupełnie niewinny kawałek kodu.

Kod źródłowy - białe znaki niewidoczne

Wygląda w porządku, prawda? Ale poczekaj. Przyjrzyjmy mu się raz jeszcze, trochę dokładniej.

Kod źródłowy - białe znaki widoczne

O. MÓJ. BOŻE!

Jeśli nie jesteś programistą, możesz patrzeć na te dwa obrazki i zastanawiać się, o co chodzi. W porządku. Ale muszę skromnie stwierdzić, że, cóż, nie jesteś jednym z nas. Nie jesteś w stanie docenić, ani nawet wyobrazić sobie, jak to jest spędzać każdą cholerną minutę każdego cholernego dnia na męczeniu się na nad każdym, nawet najdrobniejszym szczegółem programu, który właśnie piszesz. Nie dlatego, że tego chcemy, w żadnym wypadku. Ale dlatego, że świat eksploduje, jeśli tego nie będziemy robić.

Mówię tutaj dosłownie. Cóż, prawie. Jeśli choć jeden średnik znajduje się w złym miejscu, wszystko zaczyna iść nie tak, jak byś chciał. Tak właśnie jest w świecie programowania. I to jest fajne! Czasami! Przyrzekam!

Pakujemy się w tę branżę ponieważ, mówiąc szczerze, jesteśmy maniakami kontrolowania. Tacy właśnie jesteśmy. To właśnie robimy. Wyobraź sobie teraz te wszystkie głupie, bezużyteczne białe znaki, które, na nasze nieszczęście, wiszą sobie na końcach naszych wierszy. One tam są, ale nie możemy ich zobaczyć. Cóż, to są właśnie koszmary, na podstawie których kręci się horrory dla osób z zaburzeniami obsesyjno-kompulsyjnymi. Samo gadanie o tym sprawia, że całe ciało mnie swędzi.

W zależności od tego, jak głęboko w króliczą norę chcesz zajrzeć, jest kilka rzeczy, które możesz zrobić:

  • napisz skrypt, korzystający z wyrażenia regularnego w rodzaju \s*?$, który po każdym buildzie będzie usuwał nadmiarowe białe znaki przed wysłaniem kodu do systemu kontroli wersji,
  • uruchom makro, które usuwa białe znaki z końca wierszy,
  • stwórz regułę, która podświetla dodatkowe białe znaki,
  • używaj swojego IDE z włączoną opcją pokazywania białych znaków albo włączaj ją od czasu do czasu.

OK, w porządku, być może świat nie eksploduje, jeśli w moim kodzie będzie trochę nadmiarowych białych znaków.

Mimo to myślę, że w przyszłości dwa razy upewnię się, że te irytujące białe znaki nie będę akumulowały się w moim kodzie, gdy nie będę patrzył. To że ich nie widzę, nie oznacza, że ich tam nie ma i że nie czekają na okazję, by mnie dopaść.

Data publikacji oryginału: listopad 9, 2009


Zachęcamy do wzięcia udziału w sondzie, jak również do podzielenia się w komentarzach własnymi doświadczeniami związanymi z tematyką dzisiejszego posta.

Kto jest Twoim kumplem do kodowania?

Oryginalny post: Who's Your Coding Buddy?

Autor: Jeff Atwood

Zdumiewa mnie, jak bardzo mój kod zyskuje po tym jak zostanie przejrzany przez kogoś innego. Nie mam tu na myśli formalnej recenzji kodu, wysyłania go do publicznej oceny w Internecie lub uciążliwego reżimu programowania w parach. Jedna szybka próba wyjaśnienia i pokazania mojego kodu koledze/koleżance z zespołu -- to zazwyczaj wystarcza, by wyłapać błędy.

To oczywiście nie jest nic nowego. Doskonała książka autorstwa Karla Wiegersa Peer Reviews in Software: A Practical Guide opublikowana w roku 2002 jest kompletnym przewodnikiem na ten temat.

Peer Reviews in Software: a Practical Guide

Nie sądzę, by ktokolwiek podważał wartość spojrzenia innej osoby na twój kod, ale istnieją przeszkody, które zapobiegają praktykowaniu takich działań we wszystkich firmach. W rozdziale zatytułowanym A Little Help from Your Friends (pdf), Karl wyjaśnia:

Pracownicy czasami niechętnie poświęcają swój czas na sprawdzenie pracy kolegów. Możesz nie mieć zaufania do współpracownika, który prosi Cię o ocenę swojego kodu. Czy brakuje mu pewności siebie? Czy chce byś myślał za niego? "Każdemu, kto potrzebuje weryfikacji swojego kodu, nie powinno się płacić za bycie programistą", szydzą przeciwnicy recenzowania kodu.

W zdrowej kulturze programistycznej, członkowie zespołu angażują swoich współpracowników do poprawy jakości swojej pracy i poprawy wydajności. Rozumieją, że czas poświęcony nad oceną pracy kolegi zwraca się, kiedy inni członkowie zespołu oceniają rezultaty swojej pracy. Najlepsi programiści, których znam aktywnie poszukuja recenzentów swojej pracy . Istotnie, informacje zwrotne od wielu recenzentów w trakcie ich kariery były częścią tego, co sprawiło, że stali się najlepszymi.

Oprócz wymienionego wyżej rozdziału, możesz pobrać część rozdziału trzeciego (pdf) dzięki uprzejmości autora na stronie Process Impact. To nie jest wzięte z kosmosu. Za tym stoją rzeczywiste dane. Badania pokazują, że inspekcje kodu są zaskakująco efektywne.

Średni poziom wykrywania błędów wynosi tylko 25 procent dla testów jednostkowych, 35 procent dla testów funkcjonalnych i 45 procent dla testów regresyjnych. Średnia efektywność projektowania i inspekcji kodu to 55 i 66 procent..

Tak więc dlaczego nie wykonujesz recenzji kodu? Może dlatego, że nie wybrałeś jeszcze swojego kumpla do kodowania.

Pamiętasz te szkolne wycieczki, gdzie wszyscy byli upominani, by wybrali kolegę i trzymali się go? Miało to na celu zarówno uchronić nas od kłopotów jak i zapewnić nam bezpieczeństwo. Te same zasady mają również zastosowanie w budowaniu oprogramowania. Zanim wyślesz kod do repozytorium, daj go do sprawdzenia swojemu kumplowi. Czy umiesz wytłumaczyć ten kod? Może jest coś o czym zapomniałeś?

Jestem teraz zobowiązany przez prawo, by podać link do tego komiksu.

the only valid measurement of code quality: WTFs per minute

Jedyna poprawna miara jakości kodu: liczba słów WTF na minutę. Inspekcja kodu. Dobry kod: WTF, WTF. Zły kod: WTF, WTF, to jest do niczego, kolego WTF, WTF, WTF, WTF ...

Dziękuję Ci, spędzę tutaj cały tydzień.

Ten komiks ilustruje jak może wyglądać inspekcja, której potrzebujemy. Nie musi być skomplikowana, by była efektywna. Wartość WTF/minutę jest doskonale akceptowalną jednostką pomiarową, której możesz używać w pracy z twoim kumplem do kodowania. Społeczność XP (przyp. tłum. Extreme Programming) promuje programowanie w parach od lat, ale uważam, że posiadanie kumpla do kodowania jest dużo bardziej praktyczną drogą do osiągnięcia tych samych wyników.

Poza tym, kto nie chciałby być częścią wspaniałego programistycznego duetu?

Batman and Robin

To o wiele bardziej ekscytujące, niż perspektywa bycia przykutym do jednego komputera z drugą osobą. Pomyśl o wszystkich innych dynamicznych duetach jakie istnieją:

Jednostki mogą dokonać wielkich rzeczy, ale mogą osiągnąć jeszcze więcej, kiedy będą pracować razem. Na pewno jest przynajmniej jeden programista z którym pracujesz, którego podziwiasz lub przynajmniej darzysz szacunkiem wystarczającym, by został twoim kumplem do kodowania. Jeśli nie, rozważ zmianę firmy.

Jedną z uciech programowania jest to, że nie robisz tego sam. Tak więc kto jest twoim kumplem do kodowania?

Data publikacji oryginału: luty 25, 2009

Programowanie gier, analizowanie gier

Oryginalny post: Programming Games, Analyzing Games

Autor: Jeff Atwood

Dla wielu programistów wstępem do programowania był ich ojciec zmuszający do pisania własnych gier. Zamiast nowej, lśniącej konsoli Atari 2600, którą chciałem, dostałem komputer Texas Instruments TI-99/4a. Oczywiście nie o to mi wtedy chodziło, ale ta nieodwracalna decyzja zapoczątkowała karierę, która trwa już trzydzieści lat.

Najwyraźniej nie jestem sam. Mike Lee miał podobne przeżycia:

Urodziłem się w 1976, w tym samym roku co Apple, tak więć mój ojciec był w odpowiednim wieku, aby zainteresować się wczesnymi wynikami sceny homebrew. Jednym z moich wspomnień z wczesnego dzieciństwa jest on wracający do domu z Sinclairem 2000 i książką o grach. Godzinami przesiadywał wklepując kod od Space Invaders, a następnie graliśmy w nią może przez 30 minut przed wyłączeniem maszyny i anulowaniem całej jego pracy.

Tak jak Shawn Oster:

Tworzę oprogramowanie od 25 lat, poczynając od ósmego roku życia, zaczynałem z książką o nazwie "Twój pierwszy program w BASICu", którą kupił mi mój ojciec, ponieważ posiadaliśmy PC wtedy, gdy wszyscy moi znajomi grali w StarBlazers na ich Apple II. Mówił mi, że jeśli chcę grać w gry, to mógłbym je sobie sam napisać. W tamtej chwili byłem trochę rozczarowany (OK, załamany), ale teraz.. cóż, tato, dziękuję.

Dlatego własnie fascynujące jest powracanie do najwcześniejszych gier komputerowych. Przemysł komputerów osobistych dorastał razem z nami. Uczyliśmy się jak programować poprzez wpisywanie tych prostych gier z magazynów i książek. Przyjrzyj się uważnie, a zauważysz, że te stare gry są prymitywnymi początkami większości programistów, są niczym pień mózgu, który istnieje w głowie każdego z nas.

Nawet skromna, prosta, mała gierka jak Saper ma głębokie korzenie sięgające czasów kart perforowanych:

Początki Sapera sięgają najwcześniejszych gier mainframe'owych w latach 60 i 70. Wikipedia podaje Kostkę Davida Ahl'a za najwcześniejszego przodka Sapera. Ale mimo iż Kostka zawiera "miny", ciężko przyjąć ją za poprzednika Sapera. W Kostce miny są rozłożone losowo i jedynym sposobem na ich odkrycie jest zakończenie gry. Wchodzisz na minę i umierasz; nie możesz uniknąć miny bądź odgadnąć gdzie ona jest bez uprzedniej próby wejścia na nią.

W każdym bądź razie, istnieje bardzo dużo wczesnych gier typu "ukryj i szukaj", w których zadaniem jest znalezienie ukrytych miejsc na siatce. Na przykład w Hurkle Boba Albrechta musisz znaleźć potwora kryjącego się na siatce dziesięć na dziesięć. Po każdej próbie odgadnięcia dostajesz podpowiedź, w którym ogólnie kierunku znajduje się Hurkle. Depth Charge Dany Noftle'a jest tym samym tylko w trzech wymiarach. Mugwump Buda Valentiego ma wiele ukrytych celów, a po każdej próbie odgadnięcia otrzymujesz przybliżoną odległość do każdego z nich. W przeciwieństwie do Kostki, te gry bardziej przypominają Sapera: zrób losowy ruch by rozpocząć, potem używaj dostarczonych informacji, aby odkryć ukryte elementy. Oczywiście inaczej niż w Saperze (czy Kostce), nie było niebezpieczeństwa "wybuchu", jedynym ograniczeniem było odnalezienie ukrytych lokalizacji w skończonej liczbe ruchów.

Najbliższym przodkiem Sapera jest prawdopodobnie Hunt the Wumpus Gregorego Yoba.

Mimo iż Wumpus bazował na niekonwencjonalnej siatce (oryginalna gra używała wierzchołków dwunastościannu foremnego, a późniejsza wersja używała Wstęgi Möbiusa i innych nieprawdopodobnych kształtów), to ewoluował od swoich poprzedników w wielu różnych kierunkach.

Byłem zaintrygowany nowo odkrytym połączeniem między Saperem a Hunt the Wumpus, ponieważ Wumpus jest moim wewnętrznym zwierzęciem.

Większość wczesnych gier nie była nawet tak zabawna. Analizowanie kodu gry było prawie tak samo przyjemne jak granie w nią; sama czynność wpisywania i zrozumienia programu była wystarczającą "grą" dla wielu z nas. Ale niektóre z tych wczesnych gier ewoluowały i przetrwały po dziś dzień, tak jak Saper -- który stał się tak zakorzeniony w społecznej świadomości, że jest teraz przedmiotem zabawnych filmów parodiujących. Pomimo prostoty Sapera (i jego popularności), jest to zaskakująco głęboka gra logiczna, tak jak jest to opisane na Wikipedii:

Saper jest wciąż popularny wśród programistów; Automine, na przykład, jest programem napisanym w Javie, który automatycznie gra w Sapera czytając z ekranu i manipulując myszką.

Artykuł o Saperze jest częścią niesamowitej serii Beyond Tetris na GameSetWatch, w której klasyczne gry łamigłówkowe są analizowane z punktu widzenia projektanta i programisty gier. Gorąco polecam. Uczciwe ostrzeżenie: nie przeklikuj się przez to, dopóki nie masz mnóstwa wolnego czasu. Dla programisty, analizowanie gier jest prawie taką samą zabawą jak granie w nie.

Data publikacji oryginału: sierpień 22, 2007

Paradoks wielkiego wyświetlacza

Oryginalny post: The Large Display Paradox

Autor: Jeff Atwood

W miarę jak monitory stają się większe i tańsze, coraz więcej użytkowników będzie miało względnie wielkie wyświetlacze. Nikt już nie kupuje 15- czy 17-calowych monitorów; niedługo, pod względem finansowym, nie będzie sensu kupowania wyświetlacza mniejszego niż 20-calowego. W końcu, jeśli ten trend się utrzyma, wszyscy będą mieli 30-calowe wyświetlacze na swoich biurkach. Oczywiście jest to dobra rzecz. Nigdy nie jest tak, że masz wystarczająco przestrzeni na ekranie. Ale istnieje pewna niezamierzona konsekwencja dużych monitorów.

Jak na ironię, jedną z zalet małych monitorów jest to, że ponieważ iż są małe, zmuszają użytkowników do prostszej, bezokienkowej metody pracy. Zamiast marnować czas na zmienianie rozmiarów, przemieszczanie oraz układanie okienek, użytkownicy mają do czynienia tylko z jednym zmakysmalizowanym okienkiem na raz. Mogą przełączać się między zmaksymalizowanymi aplikacjami w sposób, w jaki przełączają kanały w telewizji. Ale jeśli Twój wyświetlacz osiągnie rozdzielczość 1600 x 1200, bądź więcej, prosty model typu jedna-aplikacja-na-ekran nie jest już realny. Dan ostatnio natknął się na taki problem, kiedy zmienił sobie monitor na 30-calowy:

Użytkownicy 30-calowych monitorów napotykają się na naprawdę potworny problem efektywnego wykorzystania całej przestrzeni. Często nie chcesz maksymalizować folderu bądź dokumentu na tak wielkim ekranie; albo skończysz z dużą ilością białej przestrzeni, a ważne przyciski będą rozdzielone kolosalnym obszarem pustki, albo otrzymasz linie tekstu o 300 bądź więcej znakach długości, które są ciężkie do czytania.

Oto paradoks wielkiego wyświetlacza. Posiadanie tak wielkiej przestrzeni może spowodować, że staniesz się mniej produktywny w związku z manipulacją okienkami, z którą musisz się uporać, by móc efektywnie z nich korzystać.

Osobiście, jestem pełnoprawnym członkiem prestiżowego klubu trzech monitorów, co oznacza, że jestem jeden krok dalej niż Dan. Przynajmniej dopóki nie podwoi bądź nie potroi liczby monitorów:

Mimo iż moje wyświetlacze są 20-calowe, mam je trzy. Maksymalizując okno na 20 cali, 1600 x 1200 jest rozsądną przestrzenią wyświetlacza, z którą można pracować przez większość czasu. Używam również aplikacji UltraMon, która daje mi nieodzowną możliwość przenoszenia zmaksymalizowanych okien pomiędzy monitorami. Ciągle chwytam zmaksymalizowane okna i "rzucam" nimi z monitora na monitor, ala Raport Mniejszości.

Pracując na moich trzech monitorach, mam bardzo dużą podstawową przestrzeń wyświetlacza oraz drugorzędne obszary, do których mogę "przyczepić" elementy potrzebne jako odnośniki, a które nie będą mi przeszkadzać. Mam naturalną siatkę dopasowującą, ponieważ używam trzech fizycznych monitorów. Jest to efekt uboczny sprzętu, ale na tyle ważny, że zacząłem na nim polegać.

Dan posiada wyłącznie jeden wielki, 30-calowy monitor, tak więc nie ma naturalnej siatki, do której mógłby dopasowywać okna. Potrzebuje jakiegoś oprogramowania do pomocy:

Używam WinSplit Revolution, aby zarządzać tym problemem. Jest to porządna, mała, Windowsowa aplikacja, za pomocą której można w prosty sposób rzucać (większością) okienek dookoła ekranu oraz zmieniać ich rozmiar, aby zajmowały tyle miejsca ile prawdopodobnie chcesz. Dwa obszary, każdy po 1280 x 1600, dają w rezultacie parę 20 calowych "ekranów" w formacie portretowym, które nadają się do wielu zadań.

Natknąłem się poniekąd na taki problem na moich trzech 20-calowych monitorach, ale to mały problem. Będę w poważnych tarapatach, jeśli kiedykolwiek sprawię sobie monitory większe niż 20 cali. (Będę również potrzebował o wiele większego biurka.) Bez wątpienia zmaksymalizowane okna nie są efektywne na wielkich wyświetlaczach. Dla więszkych ekranów, musiałbym rozszerzyć efekt siatki dopasowującej do każdego monitora indywidualnie.

To jest dokładnie to, co robi aplikacja WinSplit Revolution. Jest całkiem intuicyjna; używasz CTRL+ALT+(numpad) do przerzucenia aktualnie zaznaczonego okna na część ekranu, która jest przypisana do numeru. Poprzez naciśnięcie sekwencji wiele razy, zostaną zaprezentowane dwa bądź trzy możliwe rozmiary w tej szczególnej pozycji. Poniższy diagram przedstawia to lepiej niż ja za pomocą tekstu:

Jak można zauważyć, otrzymuje się kilka możliwych układów siatki używając jedynie prostego mapowania klawiatury numerycznej. Ale wciąż jest to trochę wysiłku; Muszę zaznaczyć każde okno, a następnie użyć klawiatury numerycznej (albo odpowiedniego wyskakującego okienka), aby przesunąć je w miejsce, które chcę. Od wersji 1.8, WinSplit Revolution doskonale radzi sobie z wieloma monitorami i nawet dostarcza wygodnych skrótów klawiaturowych do przesuwania okien z monitora na monitor.

Na szczęście jest jeszcze GridMove, który wspiera wiele monitorów. Używając środkowego przycisku myszy do przesunięcia okna, uruchamia się aktualny szablon siatki, który dostarcza automatyczne obszary dopasowujące dla tego okienka.

W nie tak dalekiej przyszłości, każdy użytkownik będzie miał tak duży monitor, że dla większości aplikacji maksymalizowanie okna nie będzie miało sensu. Szkoda, że jakiś rodzaj automatycznej siatki dopasowującej nie może być osadzony w systemie operacyjnym, aby pomagać użytkownikom w uporaniu się z wielkimi obszarami wyświetlacza. Tak jak Dan będziemy tego potrzebować prędzej czy później. Do tej pory, powyższe aplikacje -- albo podobne do nich -- mogą uzupełnić te braki.

Data publikacji oryginału: 7 sierpnia, 2007

Nazwę ją... SomethingManager

Oryginalny post: I Shall Call It.. SomethingManager

Autor: Jeff Atwood

Alan Green tak narzekał na stosowanie bezsensownych nazw takich jak SomethingManager:

Ile klas z którymi się spotkałeś miały sufiks "Manager" (np. ConnectionManager, SessionManager)? Każdy większy system wydaje się być pełen takich klas - SessionManager, ConnectionManager, PolicyManager, QueueManager, UrlManager, ConfigurationManager, albo co jeszcze smutniejsze EJBManager.

Słowa "manager" i "manage" posiadają przynajmniej dziesięć różnych znaczeń - od "stworzyć coś i utrzymywać w zgodzie z wytycznymi" do "osiągnąć określony cel". Pamiętam jak pewnego dnia recepcjonistka przemianowała się na "Switchboard Manager". Częścią wspólną tych wszystkich definicji wydaje się być "dba o rzeczy".

Ta nieprecyzyjność powoduje, że słowo "Manager" jest złym słowem do stosowania w nazwach klas. Weźmy na przykład klasę o nazwie "UrlManager" - nie jesteś w stanie powiedzieć, czy ta klasa odpowiedzialna jest za przechowywanie adresów URL w pamięci podręcznej, operacje na adresach URL czy też dba o poprawne ich używanie. Nazwa "UrlManager" mówi Ci tylko tyle, że klasa coś robi z adresami URL. Z drugiej strony nazwa "UrlBuilder" daje dużo lepszy obraz tego, za co odpowiedzialna jest klasa.

W świecie Javy sufiks "Manager" jest często spotykany. Prawie wszędzie znajdują się klasy, które odpowiedzialne są w jakiś sposób za inne klasy, co powoduje, że automatycznie otrzymują sufiks "Manager".

Nie ma nic bardziej wieloznacznego niż klasa nazwana z użyciem sufiksu "Manager". Unikaj tego słowa. Alan zaproponował kilka alternatyw we wpisie na swoim blogu, który może być pomocny w sprecyzowaniu jakiej nazwy potrzebuje Twoja klasa.

Nadawanie dobrych, opisowych nazw klasom i obiektom nie jest łatwe. Steve McConnell dostarczył kilka porad na temat nazywania procedur w książce Code Complete:

  1. Nazwa opisuje wszystko, co wykonuje procedura Dosłownie wszystko. Jeśli sprawia to, że nazwa procedury staje się śmiesznie długa, nazwa nie jest problemem. Problemem jest Twoja procedura.

  2. Unikaj bezsensownych, ogólnikowych lub mało konkretnych czasowników Na przykład: UrlManager, HandleOutput(), PerformServices(). Bądź konkretny. Co robi procedura? Jeśli nie możesz odpowiedzieć na to pytanie zwięźle, być może nadszedł czas na refaktoring kodu, który pozwoli Ci odpowiedzieć na to pytanie.

  3. Nie wprowadzaj numeracji w nazwach procedur Dołączyłem to tylko by lista były kompletna. Jeśli kiedykolwiek znajdziesz się w sytuacji, w której piszesz procedurę OutputUser1() i OuputUser2(), niech Bóg ma Cię w swojej opiece. I niech ma też w swojej opiece zespół w którym pracujesz.

  4. Stosuj nazwy tak długie, jak to konieczne Według McConnella, optymalna długość zmiennej to 9-15 znaków. Procedury zazwyczaj są bardziej skomplikowane i dlatego zasługują na dłuższe nazwy. Zastosuj tak długą nazwę, by stała się zrozumiała.

  5. Dołączaj opis zwracanej wartości Łatwa i prosta zasada. Przykłady: printer.IsReady(), pen.CurrentColor(), itp.

  6. Używaj przeciwieństw precyzyjnie Dla każdej funkcji Open(), powinna istnieć także funkcja Close(). Dla każej funkcji Insert(), funkcja Delete(). Dla każdej funkcji Start(), funkcja Stop().

  7. Wypracuj i trzymaj się konwencji nazewniczych Najlepiej zilustrować to na przykładzie. McConnell przedstawił taki w swojej książce: employee.id.Get() dependent.GetId() supervisor() candidate.id()

    W takiej sytuacji pojawia się pytanie: jak pobrać Id dla innego obiektu?

Zmiana nazw klas i zmiennych jest moją najczęstszą czynnością wykonywaną podczas refaktoryzacji. Tworzenie dobrych nazw jest trudne, ale to powinno być trudne. Trudno jest nazwać coś, czego nie skończyłeś jeszcze pisać. Większość kodu nigdy nie jest całkowicie ukończona, zatem nazwy mogą zmieniać się z czasem. Zwięzłe, opisowe nazwy zmiennych, obiektów, klas i funkcji mogą sprawić, że zamiast Daily WTF code otrzymasz kod, z którym chcesz pracować na co dzień.

Data publikacji oryginału: 29 marca, 2007

Największy wynalazek w dziedzinie informatyki

Oryginalny post: The Greatest Invention in Computer Science

Autor: Jeff Atwood

Jak myślisz, co jest największym wynalazkiem w dziedzinie informatyki? Oprócz komputera oczywiście.

Poważnie, przed dalszym czytaniem, zatrzymaj się na chwilę i rozważ pytanie.

Mówiłem wcześniej o tym, jak młode są w rzeczywistości tak zwane nowoczesne języki programowania i warto to powtórzyć dla kontekstu.

C ma z grubsza tyle lat co ja; FORTRAN jest w wieku moich rodziców. Ale co z nowymi dzieciakami na osiedlu? Strona z metrykami TCPI firmy TIOBE software dostarcza pewnych danych odnośnie popularności języków programowania od 2001 roku. Weźcie pod uwagę dziecięcy wiek wielu najnowszych i najmodniejszych języków programowania:

Ruby jest zaledwie nastolatkiem. JavaScript oraz PHP nie osiągnęły jeszcze nawet wieku nastoletniego.

We wszystkich naszych rozmowach o nowych, wymyślnych cechach języków programowania, czasem myślę, że zapominamy o fundamentalnym budulcu, który leży u podstaw każdej z nich: skromna procedura. Uwierzcie na słowo Steve'owi McConnellowi, który zachęca nas do rutynowego używania procedur:

Oprócz wynalezienia komputera, procedura jest prawdopodobnie największym wynalazkiem w dziedzinie informatyki. Sprawia, iż programy są łatwiejsze w czytaniu i rozumieniu. Skraca je (wyobraź sobie, o ile dłuższy byłby Twój kod, jeśli musiałbyś powtórzyć kod procedury dla każdego jej wywołania). Przyspiesza je (wyobraź sobie, jak trudno byłoby zwiększać wydajność w kodzie, który jest użyty w setkach miejsc, zamiast zwiększać wydajność w jednej procedurze). W większości, procedury są tym, co czyni nowoczesne programowanie możliwym.

Jeśli nie jesteś na tyle stary, by pamiętać życie przed procedurami, pomyślałem, że James Shore dał świetny przykład czystej różnicy w swoim doskonałym artykule Quality With a Name:

Przed programowaniem strukturalnym:

1000 NS% = (80 - LEN(T$)) / 2 1010 S$ = "" 1020 IF NS% = 0 GOTO 1060 1030 S$ = S$ + " " 1040 NS% = NS% - 1 1050 GOTO 1020 1060 PRINT S$ + T$ 1070 RETURN

Po programowaniu strukturalnym:

public void PrintCenteredString(string text) { int center = (80 - text.Length) / 2; string spaces = ""; for (int i = 0; i < center; i++) { spaces += " "; } Print(spaces + text); }

Skromna procedura jest podporą programowania w jakimkolwiek nowoczesnym języku. Jestem pewien, że jesteście dobrymi przykładami nowoczesnych programistów, więc nie będę Was zanudzał wyjaśnieniami, dlaczego procedury są dobrym pomysłem. Oryginalny artykuł McConnella z IEEE z 1998 roku pokrywa całkiem dobrze przesłanki stojące za procedurami. W rozdziale 7 książki Code Complete 2 znajduje się rozwinięta wersja tego materiału.

Procedury są tak fundamentalne dla dzisiejszego programowania, że są w zasadzie niewidoczne. I to jest problem z procedurami: zajmują tylko minutę, by się ich nauczyć, ale całe życie, by je opanować. Jeśli było możliwe złe programowanie niestrukturalne, tak też możliwe jest strukturalne. Możesz pisać stylem FORTRANowym w dowolnym języku. Siłowanie się z niewymowną istotą procedur jest, na pierwszy rzut oka, tym czym jest teraz programowanie:

  • Jak długa powinna być ta procedura? Jak długa jest już za długa? Jak krótka jest za krótka? Kiedy kod jest "za prosty", żeby zostać procedurą?
  • Jakie parametry powinny być przekazane do tej procedury? Jakie struktury danych bądź typy? W jakiej kolejności? Jak będą używane? Które będą zmodyfikowane jako wynik procedury?
  • Jaka jest dobra nazwa dla tej procedury? Nazywanie jest trudne. Naprawdę trudne.
  • Jak ta procedura ma się do sąsiednich procedur? Czy są wywoływane w tym samym momencie, albo w tej samej kolejności? Czy dzielą wspólne dane? Czy naprawdę stanowią całość? W jakiej powinny być kolejności?
  • Po czym powinienem poznać, że kod w procedurze zakończył się sukcesem? Powinna zwrócić kod sukcesu czy błędu? Jak będą obsługiwane wyjątki, problemy i błędy?
  • Czy ta procedura powinna w ogóle istnieć?

Dobrzy programiści -- niezależnie od tego w jakim języku mają okazję pisać -- rozumieją znaczenie tworzenia każdej procedury z najwyższą uwagą. Procedury w Twoim kodzie powinny być traktowane jak malutkie, dobrze wypolerowane diamenty, gdzie każdy kolejny jest bardziej wykwintnie wypolerowany i wyszlifowany niż poprzedni.

Przyznam się, że to nie jest szczególnie głęboka wnikliwość. To nie jest nawet oryginalna rada. Ale jeśli wierzysz, tak jak ja, w nieustanne powtarzanie podstaw, nigdy nie przestaniesz opanowywać sztuki pisania perfekcyjnej procedury.

To jest, jakby nie było, największy wynalazek w dziedzinie informatyki.

Data publikacji oryginału: 6 czerwca, 2008

Do sukcesu przez porażki

Oryginalny post: Fail Early, Fail Often

Autor: Jeff Atwood

Scott Hanselman uważa, że umieszczanie certyfikatów branżowych w podpisie jest niezręczne:

Jeśli nierozsądne byłoby umieszczenie w CV wyników egzaminów ze studiów, to czemu umieszczenie

Scott Hanselman, MCSD, MCT, MCP, MC*.*

jest rozsądne? Posiadanie certyfikatu znaczy tyle, że jesteś w stanie przyswoić dużą dawkę wiedzy technicznej. Chwileczkę. Proponuję podpisywanie się w następujący sposób:

Scott Hanselman, 11 dużych projektów zakończonych sukcesem, 3 projekty Open-Source, 1 projekt zakończony gigantyczną porażką

Czyż tak nie byłoby lepiej?

Owszem, ja się zgadzam. To właśnie projekty, nad którymi pracowałeś, powinny stanowić Twoje referencje. Uważam jednak, że Scott umieścił je w złej kolejności. Powinieneś podkreślić liczbę projektów, nad którymi pracowałeś i które zakończyły się porażką.

Jednak jak zdefiniować sukces projektu? Czy cele zostały zrealizowane? Czy projekt zarabia pieniądze? Czy użytkownicy lubią wytworzone oprogramowanie? Czy ktoś go w ogóle jeszcze używa? Naprawdę ciężko powiedzieć. Przez pewien czas pracowałem w środowisku, gdzie każdy projekt kończył się sukcesem. Nikt nie chciał spowiadać się z ograniczeń, kompromisów i problemów w oprogramowaniu, nad którym pracował i które zostało wypuszczone w świat. Osoby zarządzające projektem chciały być postrzegane jako osoby odnoszące sukces. Powodowało to, że czuliśmy się jak uczestnicy dziwnych zawodów informatycznych, w których każdy projekt, mimo wszystko, jest zwycięzcą. Użytkownicy, z drugiej strony, nie byli już takimi szczęśliwcami.

Sukces jest względny i ulotny. Porażka natomiast jest rzeczą trwałą. Jeśli naprawdę chcesz wiedzieć, czy ktoś jest kompetentny w tym co robi, zapytaj go o jego porażki. W zeszłym roku cytowałem artykuł na temat przewidywania sukcesów i porażek chirurgów:

Charles Bosk, socjolog z Uniwersytetu Pensylwania, przeprowadził pewnego razu serię wywiadów z młodymi lekarzami, którzy bądź to zrezygnowali, bądź zostali wyrzuceni ze specjalizacji neurochirurgicznej, w celu ustalenia co wyróżnia chirurga, któremu udało się utrzymać na specjalizacji.

Bosk wywnioskował, że o wiele bardziej niż techniczne umiejętności lub inteligencja, do osiągnięcia sukcesu (utrzymanie się na specjalizacji) liczyło się posiadanie odpowiednich cech charakteru -- pragmatycznego umysłu, który świadom jest możliwości porażki i jej potencjalnych konsekwencji. Kiedy przeprowadzałem wywiad z chirurgiem, który został wyrzucony, zazwyczaj kończyłem wywiad cały roztrzęsiony. Chciałem usłyszeć przerażające historie o tym, co zrobili źle, ale problem był taki, że oni nawet nie zdawali sobie sprawy z tego, że to co zrobili było złe. W trakcie wywiadów wypracowałem pytania, po zadaniu których mogłem stwierdzić z dużą dozą prawdopodobieństwa, czy ktoś będzie dobrym neurochirurgiem czy też nie. Były to takie pytania jak: "Czy kiedykolwiek popełniłeś błąd? Jeśli tak, jaki był twój najgorszy błąd?" Ludzie którzy odpowiadali: "Ojej, nigdy nie popełniłem błędu" lub "Wynik leczenia był zły, ale to ze względu na czynniki, na które nie miałem wpływu" -- byli dla mnie najgorszymi kandydatami na neurochirurga. Natomiast praktykanci którzy mówili: "Popełniam błędy cały czas. Zdarzyła się okropna rzecz wczoraj i było to ...". To właśnie oni byli najlepsi. Mieli tę umiejętność, by przemyśleć wszystko, co zrobili i byli w stanie wyobrazić sobie, jak sprawy potoczyłyby się, gdyby postąpili inaczej.

Najlepsi programiści uwielbiają porażki -- a tak naprawdę mają na ich punkcie obsesję. Jeśli zapomniałeś już, jak łatwo jest popełniać krytyczne błędy, to najprawdopodobniej poniesiesz kolejną porażkę. I tym powinieneś się martwić.

Michael Hunter idzie krok dalej. Zachęca nas do częstego ponoszenia porażek:

Jeśli Twoja rodzina zachęca Cię do ponoszenia porażek, to zaliczasz się do szczęściarzy. Jeśli naprawdę urodziłeś się pod szczęśliwą gwiazdą, to również Twoi nauczyciele to robią. Nauka nie płynie z samej porażki, ale z analizy jej przyczyn, próby wyciągnięcia i sformułowania wniosków oraz próby ponownego zmierzenia się z problemem. Z biegiem czasu da Ci to głębokie zrozumienie obszaru wiedzy, którym się zajmujesz (może to być zarówno programowanie, mieszanie kolorów lub cokolwiek innego) -- dzięki temu się uczysz. Ćwiczysz w ten sposób swój mózg, co jest dobre samo w sobie, plus wiedza, którą zdobyłeś, zwiększa Twoje szanse na sukces w nowych sytuacjach.

Im większa liczba projektów zakończonych porażką w twoim portfolio, tym lepiej. Jeśli raz na jakiś czas nie poniesiesz porażki, znaczy to, że nie starasz się wystarczająco mocno.

Musisz wytężyć swoje siły, by znaleźć granice swoich możliwości, a następnie je przekroczyć. Dodatkowo upewnij się, że poniesiesz spektakularną porażkę w czasie pracy nad następnymi projektami.

Data publikacji oryginału: 1 maja, 2006

Related Posts with Thumbnails