Poznaj swoje IDE - Heinz Kabutz (27. z 97 rzeczy)

Opublikowane zostało nowe tłumaczenie z cyklu 97 rzeczy:
  • Poznaj swoje IDE (autor: Heinz Kabutz)

    W latach 80-tych nasze środowiska programistyczne były niczym więcej niż wychwalanymi pod niebiosa edytorami tekstowymi (jeśli mieliśmy szczęście). Podświetlanie składni, które w dzisiejszych czasach bierzemy za coś oczywistego, było luksusem, który nie był dostępny dla każdego. Aby poprawić formatowanie naszego kodu korzystaliśmy z zewnętrznych narzędzi. Debuggery zaś były niezależnymi programami posiadającymi wiele skomplikowanych skrótów klawiszowych.
Pozdrawiamy, Zespół devBlogi.pl

Rozmiar jest wrogiem

Oryginalny post: Size Is The Enemy

Autor: Jeff Atwood

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

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

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

Ale jest coś, czego nie rozumiem:

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

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

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

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

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

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

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

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

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

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

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

tetris game over

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

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

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

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

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

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

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

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

golf perl

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

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

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

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

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

Data publikacji oryginału: 23 grudnia, 2007

Czy Twoje oprogramowanie jest projektowane przez Kłapouchego?

Oryginalny post: Is Eeyore Designing Your Software?

Autor: Jeff Atwood

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

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

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

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

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

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

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

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

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

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

Kłapouchy i ptak

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

Data publikacji oryginału: 24 marca, 2008

Zapraszamy na konferencję ABB Dev Day

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

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

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

Podejście do poprawiania błędów w stylu macho

Oryginalny post: Hard-assed Bug Fixin'

Autor: Joel Spolsky

Jakość oprogramowania lub jej brak jest czymś, na co ludzie lubią narzekać. Teraz mam swoją firmę i w też postanowiłem coś z tym zrobić. Przez ostatnie dwa tygodnie zatrzymaliśmy wszystko w Fog Creek, aby wydać nową wersję FogBUGZ, mając na celu wyeliminowanie wszystkich znanych błędów (było ich około 30).

Poprawianie błędów to dobra rzecz. Ale czy na pewno? Czy zawsze to dobry pomysł?

Nie!

Warto poprawić błąd tylko wtedy, kiedy zysk z jego poprawienia przekracza koszt wymaganej pracy.

Te rzeczy są trudne, ale nie są niemożliwe do zmierzenia. Pozwól, że przytoczę przykład. Wyobraź sobie, że zarządzasz fabryką kanapek z masłem orzechowym i galaretką. Twoja fabryka produkuje 100000 kanapek dziennie. Niedawno, z powodu wprowadzenia kanapek w nowych smakach (czosnkowe masło orzechowe z ostrym dżemem Habanero), popyt na Twoje produkty poszybował ostro do góry. Niestety maksymalna wydajność Twojej fabryki to tylko 100000 kanapek, podczas gdy rynek byłby wstanie wchłonąć 200000. Ponieważ każda wyprodukowana kanapka przynosi Ci 15 centów zysku, każdego dnia tracisz $15000.

Zbudowanie nowej fabryki kosztowałoby o wiele za dużo. Nie masz na to środków i obawiasz się, że ostre, czosnkowe kanapki są tylko chwilową zachcianką. Nie zmienia to faktu, że tracisz $15000 każdego dnia.

Na szczęście zatrudniłeś Jasona. Jest on czternastoletnim programistą, który włamał się do systemów zarządzających fabryką i wierzy, że znalazł sposób, by dwukrotnie przyspieszyć taśmę produkcyjną. Czytał on kiedyś o podkręcaniu na stronie slashdot. Okazało się, że faktycznie to działa.

Jest tylko jedna rzecz, która wstrzymuje Cię przed wprowadzeniem tych zmian. Mały, malutki błąd, który sprawia, że co godzinę rozwala się jedna kanapka. Jason chciałby go naprawić. Uważa, że jest w stanie tego dokonać w ciągu trzech dni. Pozwoliłbyś mu na to, czy wdrożyłbyś zmianę do systemu z tym małym błędem?

Opóźniając wprowadzenie zmiany o trzy dni zmniejszysz swoje zyski o $45000. Ale dzięki temu zaoszczędzisz koszt wyprodukowania 72 kanapek (w obu przypadkach Jason poprawi błąd w ciągu 3 dni). Cóż, nie wiem ile kanapki kosztują na Twojej planecie, ale na Ziemi ich łączna cena nie przekroczy $625.

O czym to ja mówiłem. Aha. Czasami nie warto poprawiać błędu. Przytoczę kolejny błąd, który nie jest wart poprawienia. Program wywala się podczas otwierania dużych plików. Występuje on tylko u jednego użytkownika, który ma zainstalowany system operacyjnego OS/2 i który nawet nie używa, z tego co wiesz, dużych plików. Cóż, nie naprawiaj go. Podobnie przestałem przejmować się ludźmi z 16 kolorowymi ekranami lub używającymi Windows 95 bez żadnych uaktualnień od 7 lat. Tacy ludzie nie wydają dużo pieniędzy na oprogramowanie. Uwierz mi.

Niemniej w większości przypadków, warto poprawiać błędy. Nawet jeśli są to "nieszkodliwe" błędy. Mogą one podważyć reputację Twojej firmy i Twojego produktu, co na dłuższą metę będzie miało znaczący wpływ na Twoje zyski. Ciężko jest poprawić reputację, kiedy ma się produkt pełen błędów. Kiedy chcesz wydać wersję .01, poniżej znajdziesz kilka pomysłów jak znaleźć i naprawić właściwe błędy. To znaczy te, dla których jest to ekonomicznie uzasadnione.

Krok pierwszy: Upewnij się, że masz wszystkie informacje o błędzie.

W przypadku FogBUGZ mamy na to dwa sposoby. Po pierwsze: wyłapujemy wszystkie błędy z naszego darmowego serwera demo, zbieramy tyle informacji, ile to możliwe i wysyłamy e-mail do całego zespołu programistów. Dzięki temu znaleźliśmy wiele błędów. Na przykład odkryliśmy kilka osób, które nie wpisały dat na stronie "Fix For". W tej sytuacji nie wyświetlaliśmy nawet komunikatu o błędzie. Program po prostu się wywalał (co w przypadku aplikacji webowej objawia się tym, że wyświetlana jest paskudna strona zawierająca szczegóły błędu). Ojej.

Kiedy pracowałem w Juno, mieliśmy nawet fajniejszy system do automatycznego zbierania danych o błędach od użytkowników. Instalowaliśmy handler wykorzystując bibliotekę TOOLHELP.DLL tak, aby za każdym razem kiedy Juno się wywalił, żył on na tyle długo, aby zapisać obraz stosu wywołań do pliku. Podczas następnego uruchomienia program łączył się z Internetem i wysyłał e-mail z załączonym plikiem. Podczas beta testów zbieraliśmy te pliki, gromadziliśmy wszystkie nieobsłużone wyjątki i wprowadzaliśmy je do bazy śledzenia błędów. Pozwoliło nam to znaleźć dosłownie setki błędów, które powodowały nieprawidłowe działanie programu. Kiedy masz milion użytkowników, niesamowite jest to, co może być powodem błędu. Często wynikało to z poważnych problemów z pamięcią lub bardzo gównianych komputerów (czy potrafisz przeliterować Packard Bell?). Wyobraź sobie, że Twój program zawiera poniższy kod:

  int foo(object& r)
  {
   r.Blah();
   return 1;
  }
 

Może się on wywalić, ponieważ referencja r miała wartość NULL, nawet jeśli jest to niemożliwe i nie ma czegoś takiego jak referencja NULL, bo C++ to gwarantuje. Nie musisz mi wierzyć, ale kiedy czekasz wystarczająco długo, masz milion użytkowników oraz fanatycznie zbierasz ich zrzuty pamięci, odkryjesz, że program może wywalić się w takich miejscach jak to i nie uwierzysz swoim oczom. (I nie naprawisz tego.Użytkowniku, spraw sobie nowy komputer i tym razem nie instaluj każdego fajnego sharewarego oprogramowania, które znajdziesz. Kurde!).

Po drugie: każde (bez wyjątku) wezwanie wsparcia technicznego jest traktowane jako przejaw błędu. Kiedy je obsługujemy, próbujemy znaleźć sposób, aby wyeliminować podobne zgłoszenia. Na przykład, stary instalator FogBUGZ zakładał, że FogBUGZ będzie uruchomiany na koncie użytkownika anonimowego. To było poprawne założenie w 95 i błędne w 5 procentach przypadków, ale każdy z tych 5% kończył się telefonem do naszego wsparcia technicznego. Zmodyfikowaliśmy instalator tak, by pytał użytkownika o konto, na którym ma być uruchomiony FogBUGZ.

Krok drugi: Upewnij się, że dostajesz ekonomiczny feedback

Możesz nie być w stanie dowiedzieć się dokładnie, jaką wartość ma poprawienie każdego błędu, ale jest coś, co możesz zrobić: pobierać opłaty za obsługę techniczną od działu produktowego. Na początku lat 90-tych w Microsofcie odbyła się finansowa reorganizacja, która ustanowiła, że każdy dział produktowy będzie obciążany pełnym kosztem wszystkich wezwań wsparcia technicznego. Działy produktowe zaczęły nalegać, by PSS (wsparcie techniczne Microsoftu) dostarczał regularnie listę 10 najczęstszych błędów. Kiedy zespół programistów skoncentrował się na nich, koszt obsługi technicznej drastycznie spadł.

Zaprzecza to trochę nowemu trendowi, w którym dział obsługi technicznej jest samodzielnie finansowany. Tak robi większość dużych firm. W Juno oczekiwano od działu obsługi technicznej pobierania opłat za pomoc techniczną. Przez przeniesienie na użytkowników ekonomicznego bałaganu związanego z finansowaniem błędów, tracisz tę ograniczoną możliwość sprawdzenia szkód, które wyrządzają. (Zamiast tego masz zirytowanych użytkowników, którzy odmawiają zapłaty za Twój błąd, którzy rozpowiadają o tym swoim znajomym i nawet nie możesz zmierzyć, ile to wszystko Cię kosztuje. Aby być sprawiedliwym wobec Juno: produkt był bezpłatny, tak więc przestań narzekać.)

Jednym ze sposobów rozwiązania tego problemu jest nie pobieranie opłat od użytkownika, kiedy zgłoszenie spowodowane jest błędem w Twoim własnym produkcie. Microsoft tak robi i jest to całkiem przyjemne. Nigdy nie zapłaciłem za wsparcie techniczne Microsoftu. Zamiast tego, pobierz od grupy produktowej $245 lub tyle, ile kosztuje poprawienie zgłoszenia przez programistę. To zniweluje ich zysk za produkt, który ci sprzedali (kilkukrotnie) i tworzy właściwe motywacje ekonomiczne. Przypomina mi to o jednym z powodów, dla których gry DOS były strasznym biznesem. Aby sprawić, by wyglądały dobrze i działały szybko, potrzebowały zazwyczaj dziwnych sterowników kart graficznych. Jedno wezwanie pomocy technicznej na ich temat mogło zniwelować zysk ze sprzedaży 20 kopii twojego produktu, zakładając, że Egghead, Ingram i reklama na MTV nie pochłonęły wszystkich Twoich zysków.

Krok trzeci: Dowiedz się, ile jest dla Ciebie warte poprawienie wszystkich błędów

Ponieważ Fog Creek Software jest malutką firmą (poza naszymi umysłami), zespół programistów zajmuje się też wsparciem technicznym. Każdego dnia poświęcaliśmy temu 1 godzinę. Kosztowało nas to około $75000 rocznie (bazując na cenach naszych konsulatacji). Byliśmy pewni, że możemy ograniczyć ten czas do 15 minut, gdyby udało nam się poprawić wszystkie znane błędy.

Używając bardzo nieprecyzyjnych liczb: wartość bieżąca netto z oszczędności wynosiłaby około $150000. To uzasadnia koszt 62 roboczodni. Jeśli można to zrobić szybciej, to warto to zrobić.

Korzystając z wbudowanych w FogBUGZ wygodnych funkcji do estymacji obliczyliśmy, że potrzeba 20 roboczodni (dwie osoby przez dwa tygodnie), aby naprawić wszystkie błędy. Co równało się $48000 wydanych za $150000 zaoszczędzonych pieniędzy, co jest wielkim zwrotem z inwestycji w redukcję kosztów obsługi technicznej.

Nie zacząłem nawet liczyć zysków z posiadania lepszego produktu, ale mogę zacząć to robić. W lipcu mieliśmy 55 awarii na serwerze demo (gdzie był stary kod), które dotknęły 17 użytkowników. Wyobraź sobie, że przynajmniej jedna z tych osób nie zdecydowała się kupić licencji na FogBUGZ, ponieważ kiedy korzystała z dema pomyślała, że produkt jest przepełniony błędami (chociaż nie ma realnych statystyk, by to poprzeć). W każdym razie te awarie prawdopodobnie kosztowały nas pomiędzy $7000 a $100000 (jeśli jesteś dociekliwy, nie będzie Ci trudno znaleźć prawdziwą kwotę).

Następne pytanie. Czy możesz sprzedawać drożej produkt, który ma mniej błędów? Przypuszczam, że w sytuacjach ekstremalnych liczba błędów wpływa na cenę, ale ciężko mi znaleźć przykład ze świata produktów pudełkowych, gdzie miało to miejsce.

Proszę, nie pobij mnie!

Ludzie czytają eseje jak ten i nieuchronnie dochodzą do niemądrych wniosków: "Joel uważa, że nie powinieneś poprawiać błędów". W rzeczywistości uważam, że poprawianie większości błędów jest ekonomicznie uzasadnione. Ale może jest coś innego, co przyniesie Ci więcej pieniędzy, niż poprawianie kilku ostatnich błędów. I jeśli musisz wybrać pomiędzy poprawianiem błędu dla faceta z OS/2 a dodaniem nowej funkcjonalności, dzięki której sprzedasz 20000 kopii Twojego oprogramowania do General Electric, zignoruj tego faceta. Jeśli jesteś wystarczająco durny, by nadal uważać, że ważniejsze jest poprawienie tego błędu, niż dodanie nowej funkcjonalności, możesz wylecieć z rynku.

Mając to wszystko na uwadze, jestem optymistą i uważam, że produkowanie wysokiej jakości oprogramowania niesie ze sobą wiele ukrytych korzyści, które niełatwo ogarnąć. Twoi pracownicy będą bardziej dumni. Mniej twoich klientów zwróci ci pocztą CD, którą uprzednio potraktowali mikrofalówką i porąbali siekierą. Mam tendencję do przesadzania z dbałością o jakość produktu (faktycznie, naprawiliśmy każdy znany błąd w FogBUGZ, nie tylko te znaczące) i bycia z tego dumnym. Czuję się pewnie, ponieważ dzięki całkowitej eliminacji błędów z serwera demo mamy stabilniejszy i bardziej niezawodny produkt.

Data publikacji oryginału: lipiec 31, 2001

Rejestracja na szkolenie z Ayende Rahien w Polsce została otwarta

Z przyjemnością informujemy, że rejestracja na szkolenie, o którym pisaliśmy w poprzedniej notce, została otwarta. Widocznie odzew ze strony polskiej społeczności programistów był wystarczający, żeby Ayende Rahien zdecydował się poprowadzić ten kurs.

Rejestrować można się na tej stronie: http://www.eventbee.com/v/ayende/event?eid=887726315.

Zachęcamy do porozmawiania ze swoimi przełożonymi o możliwości sfinansowania Wam takiego szkolenia. W wielu firmach zdarza się bowiem, że budżet na takie wydarzenia jest, ale się marnuje, ponieważ nikt się o niego nie prosi :)


Zespół devMedia.pl

Ayende Rahien w Polsce? To możliwe!

Ayende Rahien

Jakiś czas temu jeden z naszych kolegów (Waldemar Walo), skontaktował się z Ayende Rahien w sprawie możliwości zorganizowania szkolenia dla polskich developerów. Jego namowy okazały się skuteczne — Ayende opublikował wczoraj na swoim blogu krótką notkę, z której wynika, że poważnie rozważa przyjazd do Polski, jeśli tylko będzie wystarczające zainteresowanie z naszej strony.

Ayende Rahien to jeden z najbardziej znanych i aktywnych członków społeczności developerów .NET. Jest autorem popularnego frameworka Rhino Mocks; udziela się również w wielu projektach open-source, jak na przykład NHibernate czy Castle.

Osobiście uważamy, że od Ayende można się wiele nauczyć i to nie tylko o technicznych sprawach, ale również na temat dobrych praktyk z zakresu inżynierii oprogramowania. Tak więc jeśli Ayende podejmie tę jedyną słuszną decyzję odnośnie przyjazdu do Polski, zespół devMedia.pl na pewno będzie starał się na tym szkoleniu pojawić :) Was również zachęcamy do zainteresowania się tym tematem i wyrażenia swojej opinii w komentarzach pod wspomnianą wcześniej notką na blogu Ayende.


Zespół devMedia.pl

Nie ignoruj tego błędu!

Opublikowane zostało nowe tłumaczenie z cyklu 97 rzeczy:

  • Nie ignoruj tego błędu! (autor: Pete Goodliffe)

    "Błąd, jaki błąd? Nie będzie poważny. Na pewno. Mogę go zignorować. To nie jest strategia, która prowadzi do solidnego kodu. Tak naprawdę to czyste lenistwo. Nieważne, czy uważasz, że błąd w kodzie jest mało prawdopodobny, powinieneś zawsze się go spodziewać i obsłużyć. Zawsze. Nie oszczędzasz czasu, jeśli tego nie robisz. Odkładasz potencjalne problemy na później."

Zespół devMedia.pl

O pewnym sukcesie

Znacie serwis devPytania, prawda? Wielu z Was zna również konkurencyjną społeczność autorstwa Helionu - 9fingers.pl. Start obu społeczności odbył się mniej więcej w tym samym czasie. Premiera serwisu Helionu odbiła się szerokim echem wśród społeczności - wliczając w to mnóstwo wpisów na blogach (w tym na antywebie) oraz blipie/flakerze. Po paru tygodniach i po konkursie, który odbył się na łamach serwisu konkurencji, zostaliśmy zdeklasowani pod względem liczby pytań i aktywnych użytkowników. Ruch na devPytaniach wyraźnie zmalał i zastanawialiśmy się, czy w ogóle będzie sens prowadzić serwis w cieniu takiego "kolosa".

Po paru miesiącach obserwacji obu społeczności, doszliśmy do wniosku, że warto by było zacząć mierzyć w jakiś sposób ich wzrost. I tak pod koniec września 2010 uruchomiliśmy prostą aplikację, która na koniec każdego dnia zbiera dane na temat liczby pytań w jednym i drugim serwisie. Na podstawie tych danych codziennie uaktualniany jest wykres, na którym porówynwane są obie wartości w czasie. Efekt widać poniżej:

devpytania 9fingers chart

W dniu 29 września 2010 roku, w serwisie 9fingers było 1782 pytania, a na devPytaniach - 1062. Jak dobrze widać, parę dni temu przegoniliśmy konkurencyjny serwis pod względem liczby pytań, jak również przekroczyliśmy granicę 2000 pytań, co niewątpliwie jest pewnym sukcesem. Sukcesem, który nie byłby możliwy, gdyby nie tak zaangażowana społeczność jak Wy.

Nawiązując do przekroczonej granicy 2000 pytań, w serwisie meta padło pytanie, czy nie moglibyśmy udostępnić jakiegoś zrzutu danych z devPytań. W istocie, przy takiej ilości danych można by stworzyć jakieś sensowne statystyki. Pomysł nam się spodobał, więc poniżej znajduje się odnośnik do paczki z najnowszymi danymi z devPytań.

Ściągnij najnowszy zrzut danych

Ciekawi nas, co społeczność będzie w stanie wyciągnąć z tych danych.

Kończąc ten wpis chcielibyśmy podziękować Wam jako społeczności za takie zaangażowanie i liczymy na to, że kolejne granice liczby pytań 5k, 10k, 20k będą osiągane coraz szybciej. ;)


Zespół devMedia.pl

Dobieraj swoje narzędzia z uwagą - Giovanni Asproni (10. z 97 rzeczy)

W tym tygodniu w ramach serii 97rzeczy proponujemy Wam artykuł:
  • Dobieraj swoje narzędzia z uwagą (Choose your tools with care)- Giovanni Asproni

    Współczesne aplikacje rzadko budowane są od podstaw. Składane są z istniejących narzędzi — komponentów, bibliotek i frameworków — z wielu powodów:

    • Rozmiar, złożoność i wyrafinowanie aplikacji wzrasta podczas gdy czas na ich stworzenie staje się coraz krótszy. Czas i inteligencja deweloperów będzie lepiej spożytkowane, jeśli pozwoli im się skupić na pisaniu kodu związanego z logiką biznesową, a nie infrastrukturą.
    • Powszechnie używane komponenty i frameworki najprawdopodobniej zawierają mniej błędów niż te tworzone samodzielnie w firmie.
    • ...

Reszta tłumaczenia dostępna jest na 97rzeczy.devblogi.pl.

Pozdrawiamy,

Zespół devMedia.pl

Rusza staker.pl - rodzina serwisów typu Q&A

Bogatsi o doświadczenia związane z naszymi istniejącymi serwisami Q&A postanowiliśmy dodać kolejne instancje platformy i zarazem zgromadzić je pod jednym szyldem - staker.pl.

Na sam początek, do istniejących serwisów, dołączyły dwa nowe:

Jednocześnie, w przygotowaniach są serwisy poświęcone kolejnym dziedzinom - więcej o tym wkrótce. Natomiast jeśli posiadasz pomysły co do tego, jakie serwisy chciałbyś zobaczyć w rodzinie staker.pl, gorąco zachęcamy do podzielenia się uwagami w naszym serwisie meta. Dla tych, którzy przedstawią najciekawsze pomysły, czeka status moderatora w danym serwisie.

To czego możecie doświadczyć, to wczesne, ale stabilne, wersje platformy Q&A, którą utrzymujemy i staramy się rozwijać - jeśli napotkasz jakieś błędy bądź przyjdzie Ci na myśl jakaś sugestia, podziel się nią również w serwisie meta.

Więcej o samej inicjatywie można przeczytać w dziale O serwisie.

Zapraszamy do dzielenia się wiedzą i zadawania pytań!


Zespół devMedia.pl

Tworzenie oprogramowania jest jak religia

Oryginalny post: Software Development: It's a Religion

Autor: Jeff Atwood

Jest poniedziałek, a Steve Yegge wciąż nienawidzi metodologii Agile. Jak bardzo jej nienawidzi? W przybliżeniu nienawiść ta jest warta 11000 słów. Myślę, iż mógłbym założyć domową wytwórnię poradników opartych na wpisach Steve'a. Oto moja skompresowana wersja ostatniego jego wpisu:

  • Steve nie miał zamiaru promować procesu wytwarzania oprogramowania firmy Google jako tej Jedynej Właściwej Metody. To tylko jedna z możliwych alternatyw metodologii Agile.
  • Metodologia Agile tylko dlatego się sprawdza, ponieważ jakakolwiek metodologia się sprawdza, jeśli posiada się rozsądnie utalentowanych inżynierów, którzy odpowiednio się starają.
  • Nie ma empirycznego czy naukowego sposobu na to, aby udowodnić, że metodologia Agile jest lepsza od jakiejkolwiek innej metodologii wytwarzania oprogramowania. Tak więc, promowanie metodologii Agile jest przesądem.

Kluczowe jest tu kilkukrotne powtarzanie słowa "przesąd". W swoim poprzednim wpisie odniósł się do metodologii Agile jako religii:

Tak więc konsultanci, którzy stracili swoich głównych klientów, byli pewnego dnia w barze i jeden z nich (L. Ron Hubbard) powiedział: "Fuchy opłacane za linie kodu są kiepskie. Wiesz, gdzie leżą prawdziwe pieniądze? Zapoczątkuj swoją własną religię." I tak oto narodziły się Extreme Programming oraz Scjentologia.

Steve przez "religię" rozumie coś złego.

bar code jesus

Ale tworzenie oprogramowania jest i zawsze było religią. Łączymy się w grupy ludzi, którzy wierzą w te same rzeczy, których do końca nie można dowieść. Java kontra .NET. Microsoft kontra Google. Języki typowane statycznie kontra typowane dynamicznie. Możemy oszukiwać siebie, że jesteśmy "informatykami", ale kiedy ostatnio postawiłeś hipotezę i sprawdziłeś ją, aby coś udowodnić? Jesteśmy zbyt zajęci rozwiązywaniem problemów klienta w wybranym narzędziu, niedowiarku!

Podstawowy kulturowy problem z przesądami powstaje wtedy, gdy ludzie nie wiedzą, jak rozróżnić rzetelne źródła weryfikacji od nierzetelnych, więc traktują oni coś nienaukowego jak naukę. Jeśli nie rozpoznają, ani nie przyznają się do bycia przesądnymi, bez skrupułów starają się propagować swoje przekonania względem CIEBIE.

Czy Steve Yegge udowodnił, że metodologia wytwarzania oprogramowania, którą praktykuje Google jest jakkolwiek lepsza od metodologii Agile przez duże A? Nie, ale w głębi duszy wierzy, że tak jest. W tej sprawie można powiedzieć, że jest religijny. Nie ma nic złego w religii, która głosi konkretne zasady inżynierii. Jeśli jesteś fanatykiem metodologii kościoła Google, staniesz się lepszym programistą. Kiedy Steve głosi chwałę metodologii Google w sposób tak wymowny, powoduje, iż inni programiści bardziej entuzjastycznie podchodzą do tego, co robią, co czyni ich lepszymi programistami. Zanim się zorientujesz, cały zespół jest już podniecony, ponieważ wszystko idzie zgodnie ze świetnym planem, w który wszyscy wierzą — niezależnie od tego, czy jest to Agile przez duże A, Google, Scrum, czy cokolwiek innego.

Aby programiści działali efektywnie, muszą wierzyć w to, co robią. To, czy dane przekonanie da się udowodnić naukowo bądź empirycznie jest całkowicie bez znaczenia. Są to podstawy czynnika ludzkiego. Steve tak zapalczywie chce udowodnić własny ateizm metodologiczny, że podważa własną istotę rzeczy. Według Jefa Raskina wszystko jest religią:

Systemy komputerowe wykazują wszelakie zachowania, które sprzyjają powstawaniu przesądów. Próbujesz czegoś i to nie działa, więc próbujesz jeszcze raz — w ten sam sposób — i tym razem działa, albo i nie. Jest to losowe wzmacnianie wiary. Efektywność większości praktyk programowania i zarządzania nie jest zatem mierzalna. Dla przykładu, zasady "extreme programming" są dla mnie rozsądne i używałem ich długo przed tym, jak nabyły tę obecną, absurdalna nazwę. Ludzie, którzy ogłaszają ideę są także tymi, którzy stworzyli paradygmat. Większość znanych wyników nie stanowi nawet ślepej próby, a już na pewno nie podwójnej ślepej próby. Rzadko rozumiemy, w jakikolwiek sposób, procesy zachodzące podczas, gdy pracujemy z komputerami. Używamy megabajtów kodu napisanego przez kogoś innego, który jest nienajlepiej udokumentowany, niewystarczająco przetestowany i używany na sposoby, które nie zostały przewidziane przez twórców.

Religia metodologii nie jest groźna sama w sobie. Zawsze istnieje ryzyko prześladowań na tle religijnym, ale naprawdę groźni ludzie to wariaci religijni, którzy nie zdają sobie sprawy z tego, że nimi są. Nie lubię odwoływać się do przezwisk, ale jak Steve mógł tego nie wiedzieć:

Natomiast zamiast wymieniać wszystkie nie-Agile'owe zespoły i firmy, jako szczególne przypadki, ustanówmy pewną zasadę: większość dobrych programistów z całego świata nie używa metodologii Agile. Po prostu pracują ciężko, pozostają lekcy i tworzą wspaniałe rzeczy. Większość programistów wciąż nie ma pojęcia, czym jest Agile. Pomyśl o tym!

  1. Czym dokładnie "pozostawanie lekkim" różni się od metodologii Agile? Czy Agile nie jest przypadkiem Kościołem Lekkości? Steve może się nie zgadzać z pewnymi doktrynami danego kościoła (programowanie w parach, itp) i to jest w porządku. Nikt nie modli się dokładnie w taki sam sposób, jak również nie każdy jest fanatykiem. Ale zawsze posiadasz pewien zbiór wspólnych, podstawowych wierzeń. A lekkie rozwijanie oprogramowania jest, oczywiście, rdzeniem wiary w Agile.
  2. Prawdą jest, iż większość programistów nie używa metodologii Agile w wytwarzaniu oprogramowania. Ale nie z wyboru. Nie mieli go danego. Zazwyczaj tkwią w organizacjach, które nie pozwalają im na luksus "pozostawania lekkimi". Są robotnikami w fabryce kiełbasek.
  3. Steve mówi o "pozostawaniu lekkim" tak, jakby to była najłatwiejsza rzecz na świecie, jakby to był stan łaski, z którym programiści oraz firmy się rodzą. Mówienie programistom, aby pozostawali lekkimi, to jak mówienie komuś z depresją, żeby się nie martwił.

Nie jestem pewien, dlaczego Steve czuje się niepewny, jeśli chodzi o traktowanie tworzenia oprogramowania jako religii, zbioru wspólnych wierzeń z nikłymi "podstawami naukowymi, czy rozumowaniem". Ponieważ z pewnością jest on jednym z najlepszych ewangelistów, jakiego kiedykolwiek czytałem.

Data publikacji oryginału: 9 października, 2006

Przejrzyj swój kod zanim zaczniesz obwiniać innych - Allan Kelly (9. z 97 rzeczy)

Kolejny artykuł z serii 97 rzeczy jest już dostępny.

Pozdrawiamy,

Zespół devBlogi.pl

Sortowanie dla ludzi - naturalna kolejność sortowania

Oryginalny post: Sorting for Humans : Natural Sort Order

Autor: Jeff Atwood

Domyślne funkcje sortowania w niemal każdym języku programowania są słabo dopasowane do ludzkich potrzeb. Co przez to rozumiem? Cóż, rozważ różnice pomiędzy sortowaniem nazw plików w Eksploratorze Windows, a sortowaniem tych nazw poprzez kod Array.Sort():

Sortowanie Eksploratora Array.Sort()
sortowanie alfabetyczne sortowanie ASCIIbetyczne

Niemała różnica.

Bez przesady mogę powiedzieć, że dokładnie ten problem był czułym punktem każdego projektu, nad którym pracowałem. Użytkownicy ciągle będą narzekać, że ich elementy nie sortują się poprawnie i będą zgłaszać bugi związane z tymi "błędami". Jako iż jesteśmy członkami klubu homo logicus, my programiści, wzdychamy ze znużenia, staramy się trzymać w ryzach wywracanie oczami z oczywistości podczas, gdy cierpliwie informujemy naszych użytkowników, że to nie jest błąd. Elementy sortowane w prawidłowej kolejności. W sensie, prawidłowiej kolejności według ASCII. Miejmy nadzieję, że jak odchodzimy, nie będziesz nas słyszał, jak mamroczemy pod nosem to, co aktualnie myślimy &mdash "Głupi użytkownicy! Nie rozumieją nawet, jak działa sortowanie!"

Zawsze czułem ukłucie żalu, gdy odrzucałem takie zgłoszenia. Szczerze, spójrz na te dwie listy — jaka osoba o zdrowym umyśle chciałaby kolejność według ASCII? Jest to zupełnie bezsensowny porządek dla każdego, kto nie ma zakodowanej tablicy ASCII w umyśle (a tak przy okazji, duże A, to 65). Niemal nigdy nie rozumiałem, że może być inny rodzaj sortowania nawet, gdy sortowanie naturalne, było tuż przed naszymi oczami pod postacią Mac Findera, czy listy plików w Eksploratorze Windows. Miałem nałożone językowe klapki na oczach. Jeśli wbudowana funkcja sort zwracała w porządku ASCII, to musiało to być poprawne. Zostawili to nam w spadku Bogowie Językowi. Czy może być inny sposób?

Kate Rhodes jest lekko oburzona naszą ogólną ignorancją problemu "ASCIIbetycznie kontra Alfabetycznie". Nie mogę powiedzieć, że ją obwiniam. Jestem tak samo winny, jak każdy inny. Okazuje się, że to nie użytkownicy byli głupi &mdash ja byłem.

Niech mnie, liczyłem na to, iż skoro sortowanie alfabetyczne było tak powszechną potrzebą (a sądząc po liczbie ludzi pytających, jak to zrobić, nie mylę się), to nie będę musiał do licha nic pisać. Ale nie zdawałem sobie sprawy z głupiego czynnika. Jezu Chryste. Jesteście programistami. Niemal wszyscy jesteście po studiach i nikt z Was nie wie, co do k***y znaczy "alfabetycznie". Powinno być Wam wstyd. Jeśli ktokolwiek z Was używa domyślnego algorytmu sortowania w swoim języku, który niemal na pewno jest ASCIIbetyczny (z konkretnych powodów), aby zaimplementować sortowanie alfabetyczne, niech uda się przed najbliższe lustro i uderzy kilkakrotnie w twarz przed tym, jak powróci do swojego biurka i naprawi testy jednostkowe, które nie wyłapały tego problemu.

Nie nazywa się to "sortowanie alfabetyczne"; bardziej znane jest jako sortowanie naturalne. Ale ma ona rację, co do jednej rzeczy: trudno jest znaleźć informacje na temat sortowania naturalnego i wielu programistów całkowicie ignoruje ten problem. Żaden z popularnych języków programowania (które znam) nie implementuje niczego innego, niż sortowanie ASCIIbetyczne. Jednakże, istnieje trochę miejsc, gdzie znajdziemy algorytmy sortowania naturalnego:

Nie pozwól na to, aby pythonowy dzięsięciolinijkowiec Neda Cię ogłupił. Zaimplementowanie sortowania naturalnego jest trudniejsze, niż się wydaje i nie chodzi tylko o fajne problemy związane z i18n, o których wspominałem powyżej. Ale implementacje w Pythonie są imponująco zwięzłe. Jeden z komentatorów Neda podesłał swoją wersję, która jest jeszcze krótsza:

    import re 

    def sort_nicely( l ): 
      """ Sort the given list in the way that humans expect. 
      """ 
      convert = lambda text: int(text) if text.isdigit() else text 
      alphanum_key = lambda key: [ convert(c) for c in re.split('([0-9]+)', key) ] 
      l.sort( key=alphanum_key ) 
  

Próbowałem dojść do jakiejś sprytnej, zwięzłej implementacji sortowania naturalnego w C# 3.0, ale bez powodzenia. Nie interesuje mnie żaden jednolinijkowiec, ale wydaje mi się, iż podstawowy algorytm sortowania naturalnego nie powinien wymagać więcej niż 40 linijek kodu tak, jak w przypadku większości języków programowania.

Jako programiści, postaramy się zachować w pamięci lekcję od Kate: ASCIIbetycznie to nie to samo, co alfabetycznie. Sortowanie ASCII jest na potrzeby komputerów i kompilatorów, to co jest w takim razie dla ludzi? Być może naturalne sortowanie, bardziej przyjazne ludziom, powinno być wbudowane w najpopularniejszych językach programowania.

Data publikacji oryginału: 12 grudnia, 2007

Nie bój się psuć - Mike Lewis (24. z 97 rzeczy)

Zgodnie z zapowiedziami, kolejny tydzień oznacza pojawienie się nowego tłumaczenia artykułu z serii 97 rzeczy.
  • Nie bój się psuć (autor: Mike Lewis)

    Każdy w branży bez wątpienia pracował nad kodem, który był conajmniej niepewny. System jest kiepsko zorganizowany, a zmiana jednej rzeczy oznacza zepsucie jakiejś zupełnie innej. Zawsze kiedy dodaje się moduł, pierwszorzędnym celem jego twórcy jest zmiana jak najmniejszej części kodu, a potem wstrzymywanie oddechu podczas każdego wypuszczenia produktu. Jest to programistyczny odpowiednik grania w Jenga kształtownikami w wieżowcu, musi się skończyć katastrofą.

Pozdrawiamy, Zespół devBlogi.pl

Więcej robisz, czy gadasz?

Oryginalny post: Are You a Doer or a Talker?

Autor: Jeff Atwood

Dzisiejsza lekcja sponsorowana jest przez Twój lokalny Wydział Transportu:

Wydział Transportu stanu Utah wydaje $6 milionów na badania odnośnie wykonalności mostu, który miałby iść nad jeziorem. W tym samym czasie Wydział Komunikacji nie ma wystarczającej ilości pieniędzy, aby zamontować kamery video w niebezpiecznych górskich przejściach i kanionach, aby pomóc zmotoryzowanym obierać bezpieczne trasy. Te $6 milionów z powodzeniem wystarczyłoby na kamery i nadal zostałoby trochę na rozsądne analizy odnośnie mostu.

W stanie Washington, pieniądze zabudżetowane na projekt osuszania zostały przeznaczone na badania. Tymczasem, ostatnie podtopienia nawiedziły kilka małych miast, robiąc zniszczeń za miliony i niszcząc życie wielu ludziom. $16 milionów zostało wydane na badania dotyczące przeprojektowania szlaku kolejowego. Te pieniądze wystarczyłyby na wybudowanie nowego węzła na autostradzie, co spowodowałoby, iż nie tracilibyśmy milionów przez opóźnienia związane z zatorami oraz poprawiłoby bezpieczeństwo już dziś.

John Taber, autor powyższego artykułu, jest zawodowo uwikłany w dokładnie tego typu badania. Jego opinia?

Do licha, zarabiam na życie robiąc badania odnośnie transportu i nawet ja twierdzę, że jest w tym wszystkim za dużo badań, a zbyt mało tworzenia.

Jest to prosta pojęciowa wycieczka od budowy mostów do tworzenia oprogramowania. W świecie oprogramowania, niektórzy programiści zasiedlają się na planecie architektury, nieziemskim miejscu, gdzie oprogramowanie jest wiecznie planowane i dyskutowane, ale nigdy w zasadzie nie jest tworzone. Odbywanie niekończących się dyskusji odnośnie oprogramowania w pokoju konferencyjnym bądź na listach mailingowych wydaje się być użyteczną pracą — ale czy tak jest? Dopóki nie wyprodukujesz jakiegoś namacalnego, działającego artefaktu, to czy w ogóle coś zrobiłeś?

Jeden z moich ulubionych cytatów w tym temacie pochodzi od Christophera Bausa. Niestety nie jestem w stanie przytoczyć dosłownego cytatu; wygląda na to, że skasował on ten wpis ze swojego bloga.

Oprogramowanie nie dotyczy metodologii, języków, czy nawet systemów operacyjnych. To co się liczy, to działające aplikacje. W Adobe nauczyłbym się sztuki tworzenia olbrzymich aplikacji, które generują miliony dolarów zysku. Pewnie, PostScript nie był najseksowniejszą aplikacją, i był napisany w starym, dobrym C, ale wykonywał znaczące i użyteczne zadanie, na którym polegały tysiące (jeśli nie miliony) ludzi. Trudno o lepsze miejsce do nauki umiejętności budowania komercyjnych aplikacji, niezależnie od tego jakich narzędzi się wtedy używało. W ObjectSpace natomiast nauczyłem się ważnej lekcji. Diagram UML nie jest w stanie przecisnąć 500 stron na minutę przez RIP.

Mamy w branży dwa typu ludzi. Ci co Gadają i ci, co Robią. ObjectSpace było firmą ludzi gadających. Adobe jest firmą tych, co robią. Adobe zarobiło $430 milionów w poprzednim kwartale. ObjectSpace zbankrutowało.

Tak więc to jest to, o co powinieneś siebie zapytać: więcej robisz, czy gadasz? W idealnym świecie, robiłbyś jednego i drugiego po trochu, tak jak o tym wspominałem. Istnieje pewna wartość w jakimś dyskutowaniu i planowaniu w Twoim zespole. Ale jeśli musisz wybrać między jednym a drugim, staraj się błądzić po stronie, która w efekcie daje użyteczny, działający kod:

Najlepszym sposobem na rozpoczęcie projektu Open Source jest kod. Działający kod. Skleć coś w domu podczas weekendu, może zaproś kilku przyjaciół, aby Ci pomogli i nie publikuj niczego, dopóki nie będziesz miał do pokazania czegoś interesującego, co stanowiłoby podstawę dla innych, aby budować za pomocą tego więcej interesujących rzeczy. Potrzebujesz tego z kilku różnych powodów: ustanawia to dobre zamiary osoby pierwotnie wnoszącej wkład w open-source'owej merytokracji, ucina wszystkie niszczące debaty na temat stylu kodowania i architektury, które mogą zastopować projekt zanim ruszy, i tym podobne.

Działający kod przyciąga ludzi, którzy chcą kodować. Dokumenty projektowe przyciągają ludzi, którzy chcą rozmawiać o programowaniu.

Istnieje wyraźna górna granica pomiędzy tym, co jest czystą, teoretyczną dyskusją a planowaniem w świecie tworzenia oprogramowania. Sztuką jest wiedzieć, kiedy się ją osiągnęło i przekierować wysiłek na tworzenie konkretnego kodu zamiast pozwolić mu się rozproszyć w powietrzu.

Data publikacji oryginału: 10 grudnia, 2007

Nowe tłumaczenie z cyklu 97rzeczy

Opublikowane zostało nowe tłumaczenie z cyklu 97 rzeczy:

  • Ciągłe doskonalenie (autor: Clint Shank)

    Żyjemy w ciekawych czasach. W miarę jak tworzenie oprogramowania rozprasza się po planecie zaczynasz zdawać sobie sprawę, że jest wielu ludzi zdolnych wykonywać Twoją pracę. Musisz ciągle się uczyć, aby zostać na rynku. W przeciwnym wypadku staniesz się dinozaurem tkwiącym na jednym stanowisku aż pewnego dnia nie będziesz już potrzebny albo zostaniesz zastąpiony przez tańszą siłę roboczą.

W kolejce czeka kilkanaście następnych. Mamy nadzieję przywrócić cykl do życia po tym, jak zamarł na dłuższy czas. Planujemy publikować jeden artykuł tygodniowo, więc nie zapomnijcie zapisać 97rzeczy w swoich czytnikach RSS. Będziemy Was informować o nowych tłumaczeniach również na łamach devBlogów.

Zespół devMedia.pl

Pytania i odpowiedzi z zakresu administracji IT

W ubiegłym roku uruchomiliśmy dwa miejsca, na których można w bardzo przyjemny sposób wymieniać się wiedzą, pytając i odpowiadając. Były to serwisy:

Idea serwisu z pytaniami i odpowiedziami w formie w jakiej ją Wam dostarczamy jest niesamowicie pomocna, czego dowodem jest chociażby coraz większa aktywność na devPytaniach. W efekcie postanowiliśmy zacząć zbierać informacje zwrotne od użytkowników w celu ciągłego ulepszania systemu wymiany wiedzy.

Dziś chcielibyśmy wykonać kolejny krok i dodać serwis do istniejącej rodziny. Przedstawiamy Wam sysPytania:

syspytania

Jest to miejsce dla administratorów systemów IT - ludzi, którzy zawodowo pracują z komputerami.

sysPytania są niezależne od platformy - tak samo jak devPytania. Tak więc administratorzy systemów UNIX, Mac oraz Windows są bardzo mile widziani - wierzymy, iż z programistami łączy ich coś poza komputerami: kochamy to, co robimy i chcemy uczyć się od siebie nawzajem!

Pamiętajcie, że sugestie są zawsze mile widziane.

Do zobaczenia na sysPytaniach!


Zespół devMedia.pl

Uwagi zawsze mile widziane - rozwój serwisów Grupy devMedia.pl

Co jakiś czas na devPytaniach pojawiają się pytania o sam serwis bądź o działalność Grupy devMedia.pl. Takie pytania, sugestie, czy zgłoszenia błędów otrzymujemy również na nasz e-mail. Dodatkowo, nie tak dawno temu padło pytanie o kod źródłowy serwisu. W odpowiedziach zostało pokrótce wyjaśnione, iż pracujemy nad uruchomieniem własnej wersji platformy, dzięki czemu będziemy mogli dynamiczniej się rozwijać i dostarczać nowe funkcjonalności użytkownikom.

Śledząc statystyki serwisu wiemy, że coraz więcej zadajecie pytań i coraz szybciej otrzymujecie satysfakcjonujące odpowiedzi. Przez ostatnie 137 dni zostało zadanych 506 pytań, z czego tylko znikoma część pozostała bez odpowiedzi. Przyrost liczby zadanych pytań widać na poniższym wykresie (ostatnie 137 dni):

pytania devPytania

Co więcej, serwis notuje 1000 odwiedzin dziennie z czego 60% pochodzi z wyników wyszukiwania Google.

Niejednokrotnie powtarzaliśmy, że "devPytania to serwis budowany i utrzymywany wspólnymi siłami Twoich kolegów programistów". Naszym celem jest to, aby serwis devPytania stawał się coraz przyjemniejszym miejscem do wymiany wiedzy. Aby tego dokonać, uwagi, o których wspominamy na początku, są dla nas niezwykle cenne.

Wobec powyższego postanowiliśmy podjąć pewne działania i na początek:

  1. Uniezależnić się od platformy StackExchange 1.0 - aby uzyskać możliwość rozwoju serwisu.
  2. Utworzyć jedno centralne miejsce zbierania uwag dotyczących działalności Grupy devMedia.pl, a w szczególności funkcjonowania naszych serwisów.

Na początku roku, korzystając z dobrodziejstw OSS, zaczęliśmy przygotowywać nową platformę, na którą docelowo chcemy zmigrować devPytania oraz antylamę. Na dzień dzisiejszy jest ona na tyle przygotowana, że chcielibyśmy ją opublikować i zacząć testy z prawdziwymi użytkownikami.

Efektem naszych postanowień oraz potrzeb jest nowe miejsce, które dzisiaj Wam prezentujemy:

meta devmedia

Jest to serwis, który działa w oparciu o naszą nową platformę oraz przeznaczony jest do meta-dyskusji.

Co to są meta-dyskusje i dlaczego potrzebujemy dla nich osobnego miejsca? Zostało to opisane na podstronie informacyjnej serwisu:

Meta-dyskusja oznacza dyskusję o samej dyskusji a nie na temat w tej dyskusji poruszany. Przykładowo:

  • styl dyskusji,
  • jej uczestnicy,
  • okoliczności w jakich dyskusja ma miejsce,
  • powiązanie tejże dyskusji z innymi dyskusjami na te same bądź inne tematy.

Etymologia prefisku "meta-" sięga czasów dzieła Arystotelesa zatytułowanego "Metafizyka", które powstało po jego innych pracach z dziedziny fizyki. Podstawowe znaczenie tego prefiksu w języku greckim to po prostu "po".

Gorąco zachęcamy do dzielenia się uwagami, propozycjami oraz krytyką na wyżej wymienionym serwisie. Dodatkowo, udzielając się w serwisie meta, pomagacie testować nową platformę, która będzie niedługo silnikiem m.in. dla devPytań.

Pragniemy zaznaczyć, iż meta ma służyć rozwojowi wszystkich serwisów Grupy devMedia.pl, włączając w to projekty takie jak devBlogi i 97rzeczy.

Uwagi są zawsze mile widziane i jeszcze raz: zachęcamy do wzięcia udziału w testowaniu nowej platformy oraz w tworzeniu jej poprzez wymianę myśli, dyskusję oraz krytykę.

Przejdź do mety.


Zespół devMedia.pl

Rozproszona kontrola wersji to jest to, dziecinko

Oryginalny post: Distributed Version Control is here to stay, baby

Autor: Joel Spolsky

Jakiś czas temu Jeff i ja zaprosiliśmy Erica Sinka do podcastu Stack Overflow i narzekaliśmy na kontrolę wersji, zwłaszcza na modne, nowe rozproszone systemy kontroli wersji, takie jak Mercurial i Git.

W tamtym odcinku powiedziałem "Według mnie to, że tworzenie nowych gałęzi i ich łączenie jest łatwiejsze spowoduje, iż twoi współpracownicy będą częściej wykorzystywać te funkcje, co sprawi, że ciężko będzie się w tym wszystkim połapać."

Wiecie, podcast nie jest wcześniej drobiazgowo przygotowywany. Siedzimy sobie w kilka osób i urządzamy pogawędkę. Z tego powodu zazwyczaj nasze wypowiedzi są, używając technicznego sformułowania, błędne. Zazwyczaj błędny jest ogólny wydźwięk albo tylko szczegóły, lub wydźwięk i szczegóły, ale tym razem były po prostu naprawdę błędne. Jak truskawkowa pizza. Albo bajgiel z jalapeño. BŁĘDNE.

Na długo zanim podcast został wyemitowany, mój zespół zaczął używać Mercurial i ta zmiana naprawdę wszystko mi zagmatwała, więc zatrudniłem kogoś żeby wprowadzał dla mnie kod do repozytorium (żartuję). Walczyłem przez jakiś czas próbując zapamiętać kilka kluczowych komend, wyobrażając sobie, że wszystko działa tak jak w Subversion, ale kiedy coś nie działało tak jak w Subversion nie wiedziałem co mam dalej robić i byłem zmuszony biec po Benjamina lub Jacoba żeby mi pomogli.

Wtedy mój zespół obwieścił mi "Wiesz co? Ten Mercurial jest całkiem niezły i chcemy w oparciu o niego napisać produkt pozwalający na rewizję kodu, a co więcej wydaje nam się, że istnieje duży popyt na komercyjne wsparcie i hostowanie go" (sam w sobie Mercurial jest dostępny dla każdego na licencji GPL, ale wiele korporacji chce mieć jakieś wsparcie zanim zaczną czegoś używać).

Pomyślałem sobie, co ja tam wiem? Jak pewnie wiecie, ja nie mam tutaj ostatniego słowa, ponieważ "zarządzanie to funkcja wspierająca", więc zabrali wszystkich stażystów, wszystkich sześcioro i zaczęli tworzyć aplikację opartą na Mercurial.

Postanowiłem dowiedzieć się, o co chodzi z tą całą "rozproszoną kontrolą wersji" zanim ktoś zada mi pytanie o produkt, który podobno moja firma sprzedaje, a ja nie będę wiedział, co odpowiedzieć i ktoś znowu obsmaruje mnie w blogo-"sferze".

Drążyłem, drążyłem i w końcu coś wymyśliłem. Coś czym chcę się z Wami podzielić.

W rozproszonych systemach kontroli wersji, rozproszenie nie jest najistotniejsze.

Istotne jest to, że te systemy działają w kontekście zmian, a nie wersji.

To brzmi bardzo "zen", wiem. Tradycyjne systemy kontroli wersji działają tak: OK, mam wersję 1. To jest wersja 2. A to jest wersja 3.

Rozproszony system działa tak: Nie mam nic. A teraz wprowadzono te zmiany. A teraz ktoś wprowadził te inne zmiany.

To inny Model Programu, więc model użytkownika też się musi zmienić.

W Subversion myślisz sobie "uaktualnij moją wersję, żeby była taka sama jak główna wersja" albo "cofnij się do poprzedniej wersji".

W Mercurial myślisz "daj mi zestaw zmian Jacoba" albo "zapomnijmy o tych zmianach".

Jeśli podchodzisz do Mercurial z nastawieniem na Subversion, wszystko będzie prawie działać, ale kiedy nie będzie, wszystko Ci się pomiesza, będziesz niezadowolony i go znienawidzisz.

Kiedy uwolnisz swój umysł, ponownie wyobrazisz sobie kontrolę wersji i pojmiesz zen różnicy między zarządzaniem wersjami, a zarządzaniem zmianami zostaniesz oświecony i z radością zdasz sobie sprawę, że właśnie w ten sposób powinna działać kontrola wersji.

Wiem, że to dziwne... od 1972 wszyscy myśleli, że operują na wersjach, a teraz zaskakująco okazuje się, że myślenie przede wszystkim o zmianach samych w sobie rozwiązało bardzo istotny problem: łączenia gałęzi kodu.

Oto najważniejszy wniosek, a właściwie, najważniejsza rzecz, której dowiedzieliśmy się o produktywności deweloperów w ciągu ostatniej dekady. Jest to tak istotne, że zasługuje na to, aby być ostatnią opinią jaką napiszę, więc jeśli zapamiętasz tylko jedną rzecz to zapamiętaj to:

Kiedy zarządzasz zmianami zamiast wersjami, łączenie gałęzi działa lepiej, a przez to możesz rozgałęziać kod kiedy tylko wymagają tego twoje cele organizacyjne, ponieważ ponowne ich łączenie to kaszka z mleczkiem.

Nie potrafię powiedzieć ilu użytkowników Subversion opowiada taką historię: "Spróbowaliśmy stworzyć nową gałąź i to działało dobrze. Kiedy przyszedł czas żeby połączyć ją z powrotem to był absolutny koszmar i musieliśmy praktycznie każdą zmianę wprowadzać ręcznie przysięgając sobie, że nigdy więcej, a nawet wypracowaliśmy specjalny sposób pisania z instrukcjami if zamiast gałęzi."

Czasami są nawet dumni ze swojej inwencji korzystania z pojedynczej głównej gałęzi. Tak jakby było zaletą to, że muszą obchodzić sposób działania ich systemu kontroli, który nie potrafi zrobić co do niego należy.

Z rozproszonym systemem kontroli, łączenie jest łatwe i działa jak należy. Więc naprawdę możesz mieć gałąź stabilną i rozwojową albo tworzyć długożyjące gałęzie dla swojego zespołu kontroli jakości, który wykonuje testy przed wdrożeniem, albo krótkożyjące gałęzie po to, żeby wypróbowywać pomysły i zobaczyć jak będą się sprawować.

To zbyt ważne, żeby to pominąć. Być może jest to największy postęp jaki dokonał się w dziedzinie tworzenia oprogramowania w ciągu tych 10 lat przez które pisałem tutaj artykuły.

Innymi słowy, prędzej wrócę do C++, niż zrezygnuję z Mercurial.

Jeśli używasz Subversion, proszę przestań. Po prostu przestań. Subversion = pijawki. Mercurial i Git = antybiotyki. Mamy teraz odpowiednią technologię.

Z powodu tego, że ludzie nurkują w Mercurial bez pełnego zrozumienia modelu na jakim pracuje program przez co mogą odnieść wrażenie, że jest zepsuty albo złośliwy, napisałem tutorial o Mercurial HgInit.

Dzisiaj, kiedy ktoś pyta mnie o tamten podcast o rozproszonych systemach kontroli wersji, mówię, że był to drobiazgowo planowany podstęp wobec mojego długoletniego przyjaciela i konkurenta Erica Sinka, który buduje nierozproszony system kontroli wersji. Tak jak wtedy kiedy zaczął sprzedawać oprogramowanie do śledzenia błędów i ukaraliśmy go wysyłając mu wypasiony plecak Fog Creek z lipnym oficjalnym listem, z którego wynikało, że idzie nam tak dobrze, że ten drogi plecak był standardowym gwiazdkowym prezentem, który wysyłamy każdemu klientowi korzystającemu z FogBugz.

Chyba kończy mi się czas. To wielki zaszczyt, że czytaliście moje wypracowania przez ostatnie 10 lat. Nie mógłbym prosić o lepszych czytelników. Niezależnie od tego, czy należysz do setek ludzi, którzy poświęcają swój czas, aby tłumaczyć artykuły na ponad 40 języków, czy 22.894 osób, którzy napisali do mnie emaila, czy 50.838 osób zapisanych do newslettera lub 2.262.348 osób, które rocznie odwiedzają stronę i czytają część z 1067 artykułów jakie napisałem, serdecznie dziękuję Ci za uwagę.

Data publikacji oryginału: marzec 17, 2010

Sekret góry lodowej, odkryty

Oryginalny post: The Iceberg Secret, Revealed

Autor: Joel Spolsky

"Nie mam pojęcia, co jest nie tak z moimi deweloperami", myśli CEO. "Wszystko szło tak dobrze, gdy zaczęliśmy projekt. Przez kilka pierwszych tygodni zespół szalał i stworzył świetny prototyp. Od tego czasu jednak wszystko zwolniło do żółwiego tempa. Oni po prostu nie pracują już tak ciężko." Wybiera driver Callaway Titanium i wysyła wózek golfowy po lodowatą lemoniadę. "Może jeśli zwolnię kilku leniwców, to zapali im się grunt pod nogami!".

W międzyczasie, rzecz jasna, deweloperzy nie mają pojęcia, że coś idzie nie tak. W istocie, wszystko jest w porządku. Dotrzymują terminów.

Nie pozwól, by przydarzyło się to Tobie! Zdradzę Ci mały sekret o tych typkach z menedżmentu bez wiedzy technicznej, który spowoduje, że Twoje życie stanie się milion razy łatwiejsze. To naprawdę proste. Gdy poznasz mój sekret, nigdy więcej nie będziesz miał kłopotów z pracą z nie-technicznymi menedżerami (dopóki nie wdasz się w kłótnię o współczynnik restytucji ich kijów golfowych).

Jest całkiem oczywistym, że programiści myślą w jednym języku, a MBA - w innym. Myślałem przez jakiś czas nad problemem komunikacji w zarządzaniu oprogramowaniem, jako że jest dla mnie dość jasnym, że władza i wynagrodzenia gromadzą się przy tych rzadkich jednostkach, które wiedzą, jak tłumaczyć z programistycznego na menedżerski.

[Image]

Odkąd zacząłem pracę w przemyśle informatycznym prawie każde oprogramowanie, nad którym pracowałem było czymś, co można nazwać oprogramowaniem "spekulatywnym". Znaczy to tyle, że oprogramowanie nie było tworzone dla konkretnego klienta - było budowane z nadzieją, że miliardy ludzi je kupią. Wielu programistów nie może jednak pozwolić sobie na taki luksus. Mogą być konsultantami rozwijającymi projekt dla pojedynczego klienta lub wewnętrznymi programistami pracującymi nad skomplikowanym, korporacyjnym czymśtam do księgowości (czy czymkolwiek innym, co Wy, wewnętrzni programiści, robicie; to jest dla mnie raczej zagadkowe).

Czy kiedykolwiek zauważyliście, że w tych projektach dostosowanych do potrzeb klienta, tą najbardziej powszechną przyczyną niedotrzymania terminów, porażek i ogólnej beznadziei jest to, co sprowadza się do "Ten (tu wstaw przekleństwo) klient nie wiedział, czego chciał"?

Poniżej mamy trzy wersje tej samej patologii:

  1. Cholerny klient ciągle zmieniał zdanie. Najpierw chciał architekturę Klient/Serwer. Następnie przeczytał o XMLu podczas lotu w magazynie Delta Airlines i zdecydował, że musi mieć XMLa. Teraz przepisujemy całość tak, by korzystała z flotylli małych robotów Lego Mindstorms".
  2. "Zbudowaliśmy to dokładnie tak, jak tego chcieli. Kontrakt precyzował wszystko w najmniejszych szczegółach. Dostarczyliśmy dokładnie to, co opisywał kontrakt. Kiedy to jednak dostarczyliśmy, byli załamani".
  3. "Nasz nieszczęsny spec od działu sprzedaży zgodził się na kontrakt ze z góry ustaloną kwotą za stworzenie czegoś, co było generalnie niewyspecyfikowane, a prawnicy klienta byli dostatecznie ostrzy, żeby wymóc klauzulę w kontrakcie zwalniającą ich z płatności do czasu "zaakceptowania przez klienta", więc musieliśmy stworzyć zespół 9 ludzi pracujących nad ich projektem przez dwa lata by otrzymać ledwie 800$".
Jeśli jest jedna rzecz, którą należałoby wwiercić w głowy ciężką wiertarką 2500RPM DeWalt'a wszystkim młodszym konsultantom, to to: Klienci Nie Wiedzą, Czego Chcą. Przestań Oczekiwać Od Klienta, Że Będzie Wiedział Czego Chce. To się nie wydarzy. Musisz z tym żyć.

Zamiast tego załóż, że będziesz musiał coś koniec końców stworzyć, a klient bedzie musiał to polubić, choć będzie nieco zaskoczony. TY musisz przeprowadzić badania. TY musisz wymyślić projekt, który rozwiąże problem klienta w zadowalający sposób.

Spróbuj wczuć się w ich sytuację. Wyobraź sobie, że właśnie zarobiłeś 100 000 000$ sprzedając swoją firmę Yahoo! i zdecydowałeś, że już czas na odnowienie swojej kuchni. Zatrudniasz doświadczonego architekta z poleceniem, by zrobił ją "tak odjechaną, jak Kuchnia Will'ego i Grace". Nie masz pojęcia, jak tego dokonać. Nie wiesz, że chcesz kuchenkę Viking'a i lodówkę Subzero - to nie są słowa z Twojego słownika. Chcesz, by architekt zrobił coś dobrego i dlatego go zatrudniłeś.

Goście od programowania ekstremalnego mówią, że rozwiązaniem jest wpuszczenie klienta do pokoju i wciągnięcie go w proces projektowania każdego kroku, jak członka zespołu. Wydaję mi się, że jest to nieco zbyt "ekstremalne". To tak, jakby mój architekt kazał mi się zjawiać podczas projektowania kuchni i pytać mnie o każdy najmniejszy szczegół. To jest dla mnie nieciekawe - jeśli chciałbym być architektem, to zostałbym architektem.

Tak czy inaczej, nie chcesz by klient należał do Twojego zespołu, czyż nie? Osoba wysłana przez klienta może się okazać jakimś biednym debilem z księgowości zesłanym do pracy z programistami ponieważ był najwolniejszym pracownikiem w dziale i ledwie zauważyliby jego nieobecność. Ty za to spędzisz cały swój czas przeznaczony na projektowanie wyjaśniając wszystko za pomocą jednosylabowych słów.

Załóżmy, że Twoi klienci wiedzą, czego chcą. Zaprojektuj to sam, opierając się na Twoim zrozumieniu dziedziny. Jeśli musisz spędzić trochę czasu na nauce dziedziny lub potrzebujesz eksperta by Ci pomógł, to w porządku, ale projekt oprogramowania to Twoje zadanie. Jeśli odrobisz zadanie domowe z dziedziny i stworzysz dobry interfejs użytkownika, klient będzie zadowolony.

Obiecałem Ci zdradzić sekret o tłumaczeniu z języka klientów (czy menedżerów bez zaplecza technicznego) o Twoim oprogramowaniu do języka programistów.

Czy wiesz, że góra lodowa jest w 90% pod wodą? Cóż, większość oprogramowania jest w tej kwestii podobna do góry lodowej - jest tam piękny interfejs użytkownika, bedący jakimiś 10% Twojej pracy, a 90% pracy programistycznej znajduje się pod spodem. Jeśli weźmiesz pod uwagę fakt, że około połowy Twojego życia to poprawianie błędów, to UI zajmie jedynie 5% Twojej pracy. Jeśli ograniczysz się jedynie do wizualnej części UI, pikseli, do tego, co mógłbyś zobaczyć w PowerPoint'cie, to mówimy o mniej niż 1%.

To nie jest sekret. Sekretem jest to, że Ludzie Nie Będący Programistami Nie Rozumieją Tego.

Z Sekretu Góry Lodowej płynie kilka bardzo, bardzo ważnych wniosków.

Ważny Wniosek Numer Jeden. Jeśli pokażesz nie-programiście ekran z interfejsem użytkownika 90% gorszym, ten będzie myślał, że program jest w 90% gorszy.

Nauczyłem się tego jako konsultant, gdy stworzyłem demo ważnego projektu webowego dla zespołu kierowniczego klienta. Projekt był niemalże w 100% zakodowany. Wciąż czekaliśmy na grafika, by wybrał czcionki i kolory i narysował odjechane trójwymiarowe zakładki. W międzyczasie użyliśmy prostych czcionek i czerni i bieli, było sporo paskudnie zmarnowanego miejsca na ekranie, generalnie nie wyglądało to za dobrze. 100% funkcjonalności już jednak było i robiło całkiem niesamowite rzeczy.

Co się stało w trakcie demo? Klienci przez całe spotkanie fascynynowali się wyglądem programu na ekranie. Nie rozmawiali nawet o UI. Po prostu o tym, jak wygląda. "To po prostu nie wygląda spoko", żalił się ich menedżer projektu. To wszystko, o czym byli w stanie myśleć. Nie mogliśmy ich zmusić do myślenia o rzeczywistej funkcjonalności. Oczywiście poprawianie projektu graficznego zajęło około jednego dnia. To było prawie tak, jakby myśleli, że zatrudnili malarzy.

Ważny Wniosek Numer Dwa. Jeśli pokażesz nie-programiście ekran, na którym interfejs użytkownika będzie w 100% piękny, ten będzie myślał, że program jest prawie skończony.

Ludzie nie będący programistami po prostu patrzą na ekran i widzą jakieś piksele. Jeśli piksele wyglądają tak, jakby to był program który coś robi, myślą "o matko, o ile trudniejsze może być sprawienie, żeby to faktycznie działało?".

Dużym ryzykiem jest to, że jeśli najpierw stworzysz prototyp UI, przypuszczalnie po to, by utrzymać dyskusję z klientem, to wszyscy będą myśleć, że już prawie skończyłeś. Gdy Ty spędzasz nastepny rok pracując "pod spodem", że tak powiem, nikt nie będzie widział, że coś robisz i będą myśleć, że to nic.

Ważny Wniosek Trzy. Dotcom z odjechaną, wypolerowaną stroną i jakimiś czterema podstronami dostanie wyższą ocenę niż wysoce funkcjonalny dotcom z 3700 lat archiwów i domyślnym szarym tłem.

Ach, moment, dotcomy nie są więcej warte. Nieważne.

Ważny Wniosek Cztery. Gdy polityka wymaga od różnych menedżerów bez zaplecza technicznego czy klientów "odłączenia" się od projektu, daj im kilka wersji projektu graficznego do wyboru.

Zmień układ niektórych rzeczy, zmień wygląd i działanie i czcionki, przesuń logo i zwiększ je lub zmniejsz. Pozwól im czuć się ważnym, pokazując im nieistotne dekoracje do pobawienia się. Nie są w stanie zaszkodzić Twojemu harmonogramowi w ten sposób. Niezłym pośrednim dekoratorem jest ciągłe dostarczanie próbek rzeczy do wyboru. Nigdy nie zajmą się dyskusją z klientem na temat umiejscowienia zmywarki. Trafi obok zlewu, bez względu na to, czego chce klient. Nie ma sensu marnować czasu na kłótnie o to, gdzie ma stanąć zmywarka, musi stać obok zlewu, nawet nie zaczynaj tematu; pozwól klientowi zająć się robieniem czegoś nieszkodliwego, jak na przykład zmienianiem 200 razy zdania czy użyć Włoskiego Granitu czy Meksykańskiej Dachówki czy Norweskiego Drewna Butcherblock jako blatu.

Ważny Wniosek Pięć. Gdy się popisujesz, jedyną istotną rzeczą jest zrzut ekranu. Spraw, by był w 100% piękny.

Nie myśl - nawet przez chwilę - że będziesz w stanie wykpić się prosząc kogokolwiek o wyobrażenie sobie, jak świetne może to być. Nie myśl, że zwracają uwagę na funkcjonalność. Nie zwracają. Chcą zobaczyć ładne piksele.

Steve Jobs to rozumie. O matko, on to naprawdę rozumie. Inżynierowie w Apple nauczyli się robić rzeczy, które tworzą doskonałe zrzuty ekranu - jak na przykład te nowe, fantastyczne ikony 1024x1024 w doku, nawet jeśli marnują wartościowe obszary. Tłum ludzi od pulpitu Linuksa szaleje na punkcie półprzezroczystych xtermów, które doskonale wyglądają na zrzutach ekranu, ale w rzeczywistości są denerwujące w użyciu. Każdego razu, gdy Gnome lub KDE ogłasza nową wersję, kieruję się prosto w stronę zrzutów ekranu i mówię: "Och, zmienili planetę z Jowisza na Saturna. Fajnie". Nigdy nie przykładam wagi do tego, co zrobili naprawdę.

Pamiętasz CEO z początku tego artykułu? Był nieszczęśliwy, bo jego zespół pokazał mu wspaniałe slajdy w PowerPoint'cie na początku - mocki stworzone w Photoshopie, nawet nie w VB. Teraz, gdy naprawdę pracują nad rzeczami pod maską wygląda na to, że nie robią nic.

Co możesz poradzić? Jak tylko zrozumiesz Sekret Góry Lodowej, łatwo się z tym pracuje. Zrozum, że jakiekolwiek demo pokazywane przez Ciebie w przyciemnionym pomieszczeniu z rzutnikiem będzie dotyczyło tylko pikseli. Jeśli możesz, twórz swoje UI w taki sposób, by rzeczy niedokończone wyglądały na niedokończone. Przykładowo, użyj gryzmołów zamiast ikon na pasku narzędzi zanim zaimplementujesz ich funkcjonalność. W trakcie budowy Twojego serwisu webowego możesz faktycznie rozważyć pominięcie pewnych ficzerów zanim je faktycznie zaimplementujesz. W ten sposób ludzie mogą obserwować, jak Twoja strona domowa rośnie z 3 poleceń do 20, w miarę przyrostu funkcjonalności.

Co ważniejsze, upewnij się, że kontrolujesz to, co ludzie myślą o harmonogramie. Dostarcz szczegółowy harmonogram w formacie Excel. Każdego tygodnia wyślij maila gratulującego sobie tego, że awansowałeś z 32% do 35% ukończonej pracy i jesteś na dobrej drodze do wydania 25 grudnia. Upewnij się, że to fakty dominują każde myślenie nad tym, czy projekt porusza się do przodu z odpowiednią prędkością. I nie pozwól swojemu szefowi korzystać z driver'ów Callaway Titanium. Nie obchodzi mnie jak bardzo chcesz, żeby wygrał. USGA zakazało ich i jest to po prostu nie w porządku.

Środa, Luty 13, 2002

Related Posts with Thumbnails