Joel on Software

Joel on Software   Joel o programowaniu

 

Inne artykuły serwisu "Joel on Software" po polsku

Inne artykuły serwisu "Joel on Software" po angielsku

Napisz do autora (tylko po angielsku)

 

Test Joela: 12 kroków ku lepszym programom


Joel Spolsky
Przełożył Andrzej Kocoń
Korekta Andrzej Swędrzyński
9 sierpnia 2000

Czy kiedykolwiek słyszałeś o SEMA? Jest to dość ezoteryczny system pomiaru sprawności zespołu programistycznego. Stop, zaczekaj! Nie zaglądaj tam! Samo zrozumienie tego materiału zajmie ci ze sześć lat. Dlatego wypracowałem sobie mój własny, swobodny i wysoce nieodpowiedzialny test do oceny jakości zespołu. Jego wielką zaletą jest to, że zabiera około 3 minut. Czas, jaki zaoszczędzisz, wystarczy na studia medyczne.

 

Test Joela

  1. Czy stosujesz system kontroli wersji?
  2. Czy możesz zbudować wersję w jednym kroku?
  3. Czy stosujesz codzienne budowanie wersji?
  4. Czy używasz system zarządzania błędami?
  5. Czy usuwasz błędy zanim napiszesz nowy kod?
  6. Czy masz harmonogram aktualizowany na bieżąco?
  7. Czy masz specyfikację?
  8. Czy programiści mają komfortowe warunki pracy?
  9. Czy używasz najlepszych dostępnych narzędzi?
  10. Czy masz testerów?
  11. Czy kandydaci piszą programy podczas rozmowy kwalifikacyjnej?
  12. Czy praktykujesz korytarzowe testy wygody użytkowania?


Do zalet Testu Joela należy to, że łatwo można uzyskać krótką odpowiedź tak lub nie na każde pytanie. Nie trzeba wyliczać liczby-linii-kodu-na-dzień, czy średniej-liczby-błędów-na-punkt-zwrotny. Przyznaj swojemu zespołowi jeden punkt za każdą odpowiedź „tak”. Pewien niedostatek Testu Joela polega na tym, że naprawdę nie należy go stosować do oceny bezpieczeństwa oprogramowania dla elektrowni atomowej.

Wynik 12 jest doskonały, z 11-tką da się wytrzymać, lecz 10 lub mniej punktów znamionuje duże kłopoty. Prawda jest taka, że większość przedsiębiorstw programistycznych działa z wynikiem 2 lub 3. Potrzebują one poważnej pomocy, gdyż firmy takie jak Microsoft działają na okrągło na poziomie 12.

Oczywiście nie są to jedyne czynniki, które determinują sukces lub porażkę. Jeśli nawet masz wspaniały zespół, ale tworzy on nikomu niepotrzebny produkt, wtedy cóż, nikt go nie kupi. Można też sobie wyobrazić zespół „rewolwerowców”, który nie stosuje się do żadnej reguły, lecz mimo to jest w stanie wytworzyć niezwykłe oprogramowanie, zdolne zmienić oblicze świata. Pomijając  jednak wszystko inne, jeżeli tylko dopilnujesz tych dwunastu spraw, będziesz miał zdyscyplinowany zespół, zdolny do systematycznej produkcji oprogramowania.

1. Czy stosujesz system kontroli wersji?
Używałem komercyjnych systemów kontroli wersji, stosowałem też darmowy CVS i pozwolę sobie stwierdzić, że CVS jest niezły. Jeśli jednak nie masz systemu kontroli wersji, zamęczysz się próbując zapewnić współpracę programistów. Nie mają oni wtedy sposobu, aby dowiedzieć się, co zrobili inni. Nie da się łatwo wycofać z pomyłek. Inną sympatyczną zaletą systemów kontroli wersji jest to, że cały kod źródłowy pobierany jest na dysk każdego programisty — nigdy nie słyszałem o projekcie stosującym system kontroli wersji, który by stracił większą ilość kodu.

2. Czy możesz zbudować wersję w jednym kroku?
Rozumiem przez to: ile kroków potrzeba do wyprodukowania kompletnej wersji produktu na podstawie ostatniej migawki kodu? W dobrych zespołach istnieje jeden skrypt do uruchomienia, który pobiera pełną wersję źródłową, kompiluje każdy wiersz kodu, produkuje pliki EXE we wszystkich swoich wersjach, językach i kombinacjach #ifdef, generuje pakiet instalacyjny i tworzy docelowe medium — strukturę CDROM, stronę umożliwiającą pobieranie czy jeszcze coś innego.

Jeśli proces ten wymaga więcej niż jednego kroku, to jest podatny na błędy. A kiedy zbliża się termin wypuszczenia produktu, zależy ci na szybkim cyklu usuwania „ostatniego” błędu, tworzenia plików EXE itd. Jeśli kompilacja kodu, uruchomienie generatora pakietu instalacyjnego itp. zabierają 20 kroków, zwariujesz i popełnisz niepotrzebne, głupie błędy.

Z tego właśnie powodu ostatnia firma, w której pracowałem, odeszła od WISE na rzecz InstallShield: wymagaliśmy, aby proces instalacyjny mógł być uruchamiany ze skryptu, automatycznie, w nocy, przy użyciu dyspozytora NT, a ponieważ WISE nie dawał się uruchamiać nocą z dyspozytora, zrezygnowaliśmy z niego. (Mili pracownicy WISE zapewniają mnie, że ich ostatnia wersja daje już możliwość nocnego uruchamiania).

3. Czy stosujesz codzienne budowanie wersji?
Gdy stosujesz system kontroli wersji kodu źródłowego, to zdarza się, że programiści przypadkowo wprowadzą do niego coś, co uniemożliwia zbudowanie produktu końcowego. Na przykład dodali nowy plik źródłowy i wszystko się ładnie kompiluje na ich maszynie, ale zapomnieli przesłać zawartość pliku do repozytorium. Zamykają więc swoją maszynę i idą do domu, szczęśliwi i nieświadomi tego, co się stało. Tymczasem pozostali nie mogą kontynuować pracy, więc, nieszczęśliwi, także muszą iść do domu.

Zaburzenie procesu budowy wersji jest tak groźne (i tak powszechne), że warto uruchamiać ten proces codziennie, aby upewnić się, że żadna taka sytuacja nie przechodzi niezauważona. W dużych zespołach dobrą metodą zapewnienia, że nieprawidłowości są usuwane natychmiast, jest uruchamianie procesu budowy wersji każdego popołudnia, powiedzmy w przerwie obiadowej. Do tego czasu każdy wprowadza tyle zmian, ile to możliwe. Po przerwie proces generowania powinien się zakończyć. Jeżeli się powiódł, świetnie! Wszyscy pobierają ostatnią wersję źródłową i kontynuują pracę. Jeśli coś poszło nie tak, trzeba to naprawić, ale każdy może kontynuować pracę z poprzednią, poprawną wersją źródeł.

W zespole Excela mieliśmy zasadę, że ten, kto zaburzył proces generowania warsji, „za karę” był odpowiedzialny za opiekę nad tym procesem, aż nie wybawił go inny członek zespołu. Był to dobry bodziec do dbania o poprawność procesu i dobry sposób na to, aby każdy zapoznał się z jego przebiegiem.

Więcej o regularnym budowaniu wersji przeczytasz w moim artykule Pożytki z codziennego generowania wersji.

4. Czy używasz systemu zarządzania błędami?
Nie dbam o to, co powiesz. Jeżeli zajmujesz sie pisaniem programów, nawet w jednoosobowym zespole, bez zorganizowanej bazy danych zawierającej informacje o wszystkich znanych błędach w kodzie, wydasz produkt niskiej jakości. Wielu programistów mniema, że taką listę błędów mogą mieć zawsze w głowie. Nonsens. Nie są oni w stanie spamiętać więcej niż dwa, trzy błędy naraz, a następnego dnia lub w gorącym okresie i one ulegną zapomnieniu. Bezwzględnie musisz prowadzić formalny rejestr błędów.

Bazy danych do rejestrowania błędów mogą być proste lub skomplikowane. Najmniejsza użyteczna baza powinna zawierać następujące dane o każdym błędzie:

  • pełny wykaz kroków potrzebnych do odtworzenia błędu,
  • oczekiwane zachowanie programu,
  • obserwowane (błędne) zachowanie programu,
  • nazwisko osoby odpowiedzialnej za poprawienie błędu,
  • informację, czy błąd został już usunięty.

Jeżeli złożoność oprogramowania do rejestracji błędów jest jedyną przeszkodą, jaka powstrzymuje cię od stosowania go, po prostu utwórz prostą, 5-kolumnową tabelę z tymi ważnymi polami i zacznij jej używać.

Więcej na ten temat w Bezbolesnym tropieniu błędów.

5. Czy usuwasz błędy zanim napiszesz nowy kod?
Najwcześniejsza wersja programu Microsoft Word dla Windows była uważana za przedsięwzięcie skazane na porażkę. Trwało ono w nieskończoność. Ciągle były poślizgi. Cały zespół pracował wariackimi godzinami, projekt ślimaczył się i ślimaczył, a stres przekraczał granice wytrzymałości ludzi. Kiedy wiele lat później feralny produkt w końcu się ukazał, Microsoft wysłał cały zespół na wakacje do Cancun (słynna plaża meksykańska), po czym usiadł do poważnego rachunku sumienia.

Okazało się, że szefowie projektów do tego stopnia nalegali na dotrzymywanie „harmonogramu”, że programiści pracowali w wielkim pośpiechu, produkując wyjątkowo kiepski kod, ponieważ oficjalny harmonogram w ogóle nie uwzględniał fazy poprawiania błędów. Nie było żadnych wysiłków, aby utrzymywać liczbę błędów na niskim poziomie. Wręcz przeciwnie, wieść niesie, że jeden z programistów, który miał napisać fragment programu do obliczania wysokości linii tekstu, napisał po prostu return 12; i czekał, aż wpłynie raport o błędzie dotyczącym nie zawsze poprawnych wartości funkcji. Harmonogram był w istocie spisem funkcji programu, oczekujących na przekształcenie w błędy. W analizie post-mortem określono to „metodologią nieograniczonej liczby defektów”.

Aby temu zaradzić, Microsoft powszechnie przyjął coś, co nazwano „metodologią zerowej liczby defektów”. Wielu programistów w firmie podśmiewywało się, gdyż brzmiało to tak, jak gdyby kierownictwo sądziło, że może obniżyć licznik błędów przy pomocy dekretu. W rzeczywistości „zero defektów” oznaczało, że w dowolnym momecie najwyższym priorytetem jest usunięcie błędów przed pisaniem nowego kodu. Oto dlaczego.

Ogólnie rzecz biorąc im dłużej zwlekasz z usunięciem jakiegoś błędu, tym więcej kosztuje czasu i pieniędzy jego naprawienie.

Przykładowo, jeżeli popełnisz literówkę lub błąd składniowy, który wyłapie kompilator, dokonanie poprawki jest trywialne.

Jeżeli błąd w twoim programie ujawnia się zaraz po próbie uruchomienia, będziesz w stanie go naprawić niemal natychmiast, gdyż odpowiedni kod masz wciąż świeżo w głowie.

Jeżeli wystąpi błąd w programie, który napisałeś parę dni temu, wyśledzenie go trochę potrwa, jednak przeczytawszy na nowo odnośny fragment programu, wszystko sobie przypomnisz i będziesz w stanie naprawić błąd w rozsądnym czasie.

Jeśli jednak odkryjesz błąd w programie, który napisałeś miesiące temu, to zdążyłeś prawdopodobnie zapomnieć masę szczegółów i usunięcie błędu będzie o wiele trudniejsze. Akurat możesz być zajęty poprawianiem cudzego programu, podczas gdy autorzy spędzają wakacje na Arubie (Antyle). W tym przypadku próba usunięcia błędu przypomina uprawianie nauki: musisz postępować powoli, metodycznie i skrupulatnie, nie mając żadnej pewności, jak długo potrwa wykrycie lekarstwa.

Wreszcie, jeśli znajdziesz błąd w programie, który już został wypuszczony na rynek, naprawienie go będzie cię drogo kosztowało.

To jeden z powodów, dla których warto usuwać błędy natychmiast: oszczędność czasu. Jest jeszcze inny powód, związany z faktem, że łatwiej jest przewidzieć ile potrwa napisanie nowego fragmentu programu, niż jak długo zajmie naprawienie istniejącego błędu. Gdybym cię na przykład poprosił, żebyś określił, ile czasu zajęłoby napisanie programu sortującego listę, zapewne potrafiłbyś podać przyzwoite oszacowanie. Gdybym jednak zapytał, ile czasu przewidujesz na usunięcie błędu, przez który twój program nie działa, jeśli jest zainstalowany Internet Explorer 5.5, nie byłbyś w stanie nawet zgadnąć odpowiedzi, gdyż z definicji nie wiesz, co powoduje błąd. Wyśledzenie przyczyny mogłoby zająć 3 dni lub 2 minuty.

Oznacza to tyle, że harmonogram przewidujący dużą liczbę błędów do usunięcia jest wątpliwym harmonogramem. Jeśli natomiast poprawiłeś wszystkie znane usterki i zostało jedynie pisanie nowego kodu, to twój harmonogram będzie nieporównywalnie bardziej dokładny.

Kolejną wielką zaletą utrzymywania licznika błędów na poziomie zero jest to, że możesz o wiele szybciej reagować na konkurencję. Niektórzy programiści nazywają to utrzymywaniem produktu w stałej gotowości do wypuszczenia na rynek. Wówczas gdy twój konkurent wprowadzi jakąś zabójczą nowość, która podbiera ci klientów, możesz zaimplementować tę właśnie cechę i z marszu wypuścić nową wersję, nie tracąc czasu na usuwanie dużej liczby nagromadzonych błędów.

6. Czy masz harmonogram aktualizowany na bieżąco?
Co nas wprowadza w harmonogramy. Jeśli twój program w ogóle ma jakąś wartość komercyjną, to z wielu powodów dla całego przedsięwzięcia ważna jest wiedza o terminie ukończenia programu.

Programiści nagminnie nie znoszą układać harmonogramów. „Będzie zrobione, jak będzie zrobione!” — odcinają się ludziom od marketingu.

Niestety, to nie załatwia sprawy. Zbyt wiele jest decyzji, które firma musi podjąć na długo przed wprowadzeniem produktu na rynek: wersje demonstracyjne, pokazy, reklama itp. Jedyne wyjście, to posiadanie harmonogramu i aktualizowanie go na bieżąco.

Kolejną ważną rzeczą związaną z posiadaniem harmonogramu jest to, że zmusza on do zadecydowania, które funkcje należy zrealizować, a to z kolei zmusza do wybrania i odrzucenia najmniej istotnych funkcji pod groźbą popadnięcia w featuritis (albo inaczej pełzanie zakresu1).

Utrzymywanie harmonogramów nie musi być trudne. Przeczytaj mój artykuł Bezbolesne harmonogramy, który opisuje prosty sposób na sporządzanie doskonałych harmonogramów.

7. Czy masz specyfikację?
Pisanie specyfikacji jest jak czyszczenie zębów nitką dentystyczną: każdy przyzna, że to dobra rzecz, ale nikt tego nie robi.

Nie jestem pewien, czemu tak się dzieje, ale pewnie dlatego, że większość programistów nie znosi pisania dokumentów. W rezultacie kiedy zespoły złożone tylko z programistów zabierają się za jakiś problem, wolą przedstawić rozwiązanie w postaci kodu, a nie dokumentów pisanych w naturalnym języku. Znacznie bardziej wolą dać nura w kod i programować, niż najpierw sporządzić specyfikację.

Błędy wykryte w fazie projektowania można łatwo naprawić zmieniając kilka linijek tekstu. Koszt usuwania błędów po napisaniu programu jest dramatycznie wyższy, zarówno w wymiarze emocjonalnym (ludzie nie lubią bowiem wyrzucać fragmentów programu), jak i czasowym. Usuwanie błędów napotyka więc na opór. Oprogramowanie, które nie było wytworzone na podstawie specyfikacji, okazuje się w końcu źle zaprojektowane, a harmonogram wymyka się spod kontroli. Zdaje się, że to właśnie miało miejsce w przypadku Netscape Navigatora, którego pierwsze cztery wersje rozrosły się do takiego chaosu, że szefowie podjęli niemądrą decyzję o porzuceniu całego kodu i rozpoczęciu pracy od nowa. Następnie popełnili ponownie ten sam błąd z Mozillą, tworząc monstrum, które nie dawało się opanować i potrzebowało kilku lat, by dojrzeć do stadium alfa.

Według mojej ulubionej teorii można temu zaradzić ucząc programistów, by stali się mniej opornymi autorami, wysyłając ich na intensywny kurs sztuki pisania. Innym rozwiązaniem jest zatrudnianie rozgarniętych szefów projektów, którzy są w stanie napisać specyfikację. W każdym przypadku powinieneś wdrożyć prostą zasadę: „żadnego programowania bez specyfikacji”.

Dowiedz się wszystkiego o pisaniu specyfikacji z mojego 4-częściowego cyklu.

8. Czy programiści mają komfortowe warunki pracy?
Istnieje bardzo wiele dowodów na to, że zapewnienie pracownikom umysłowym przestrzeni, spokoju i prywatności przynosi zyski. Klasyczna już książka o zarządzaniu wytwarzaniem oprogramowania, Peopleware (Czynnik ludzki, WNT 2002, ISBN 83-204-2718-5), obszernie omawia korzystny wpływ tych czynników na produktywność.

Oto, w czym rzecz. Wszyscy wiemy, że pracownicy umysłowi najlepiej pracują wtedy, gdy wpadną w rodzaj „transu” (inaczej nazywanym „wejściem w strefę”), kiedy to są w pełni skoncentrowani na zadaniu i całkowicie oderwani od otoczenia. Tracą poczucie czasu i osiągają wspaniałe rezultaty poprzez absolutną koncentrację. To właśnie wtedy wykonują najbardziej twórczą pracę. Pisarze, programiści, naukowcy a nawet koszykarze mogą wam coś o tym powiedzieć.

Kłopot w tym, że nie tak łatwo „wejść w strefę”. Z prób pomiaru wygląda na to, że potrzeba średnio 15 minut, aby osiągnąć poziom maksymalnej wydajności. Gdy jesteś zmęczony lub gdy w danym dniu dość się już twórczo napracowałeś, to zwyczajnie nie jesteś w stanie „wejść w strefę” i resztę dnia spędzasz plącząc się, przeglądając strony internetowe lub grając w Tetrisa.

Z drugiej strony bardzo łatwo jest wypaść ze strefy. Hałas, telefon, wyjście na obiad, konieczność 5-minutowej jazdy na kawę w Starbucks, a także przerywanie ze strony współpracowników — zwłaszcza przerywanie ze strony współpracowników — wszystko to wybija cię z transu. Jeśli kolega zadaje ci pytanie powodując jednominutową przerwę, lecz przy okazji wytrąca cię ze stanu koncentracji na tyle mocno, że potrzebujesz pół godziny, aby znów osiągnąć pełną wydajność, twoja ogólna produktywność jest poważnie zagrożona. Jeśli pracujesz w hałaśliwych zagrodach, w rodzaju tych, które szczególnie upodobały sobie dotcomy, z facetami od marketingu wrzeszczącymi do telefonu tuż obok programistów, twoja produktywność weźmie w łeb, gdyż pracownikom nieustannie się przeszkadza i nie ma mowy o „wejściu w strefę”.

Jest to szczególnie trudne w przypadku programistów. Wydajność zależy tutaj od zdolności do żonglowania w pamięci podręcznej dużą liczbą drobnych szczegółów naraz. Każde przerwanie może spowodować rozsypanie się tej piramidy. Kiedy wznawiasz pracę, nie pamiętasz już tych wszystkich detali (jak nazwy lokalnych zmiennych lub miejsca, w którym przerwałeś implementację algorytmu sortującego) i konieczność odszukania ich znacznie hamuje twój powrót do pełnej szybkości.

Oto prosty rachunek. Powiedzmy (co dane zdają się potwierdzać), że jeśli przeszkodzimy programiście choćby na minutę, to w rzeczywistości tracimy 15 minut pełnej wydajności. Dla potrzeb tego przykładu umieśćmy dwóch programistów, Piotra i Pawła, w sąsiednich, otwartych przegrodach standardowej farmy-tuczarni Dilberta. Paweł nie może sobie przypomnieć, jak nazywa się odpowiednik funkcji strcpy w Unicode. Może poszukać, co potrwa 30 sekund, lub zapytać Piotra, co zajmie sekund 15. Ponieważ siedzi zaraz koło Piotra, pyta go. Piotr odrywa się i traci 15 minut pełnej wydajności (aby zaoszczędzić Pawłowi 15 sekund).

Przenieśmy ich teraz do oddzielnych biur, z drzwiami i ścianami. Gdy Paweł nie przypomina sobie nazwy funkcji, może jej poszukać, co potrwa 30 sekund, lub zapytać Piotra, co zajmie teraz 45 sekund i będzie wymagało wstania z miejsca (niełatwe zadanie, zważywszy na przeciętną krzepę programistów!). Wybiera zatem szukanie. W ten sposób Paweł traci 30 sekund, lecz zaoszczędzamy 15 minut Piotra. Ha!

9. Czy używasz najlepszych dostępnych narzędzi?
Tworzenie programów w języku kompilowanym jest jedną z ostatnich rzeczy, których wciąż nie da się robić błyskawicznie na pospolitym komputerze domowym. Jeśli proces kompilacji zabiera więcej niż kilka sekund, zakup najlepszego i najnowszego sprzętu pozwoli zaoszczędzić na czasie. Jeśli kompilacja zabiera choćby 15 sekund, programiści będą się nudzić i zaczną czytać The Onion, co wciągnie ich kosztem całych bezproduktywnych godzin.

Szukanie błędów w kodzie interfejsu graficznego (GUI) w systemie jednomonitorowym nie należy do przyjemności, o ile w ogóle jest wykonalne. Jeżeli zajmujesz się programowaniem interfejsów graficznych, dwa monitory znacznie ułatwią ci życie.

Prędzej czy później większość programistów ma do czynienia z mapami bitowymi ikon i pasków, lecz jednocześnie większość nie ma dostępu do dobrego edytora takich obiektów. Próba użycia w tym celu programu Microsoft Paint zakrawa na żart, jednak to właśnie musi robić większość programistów.

W mojej ostatniej pracy administrator systemu zasypywał mnie automatyczną pocztą uskarżając się, że zajmuję więcej niż... 220 megabajtów pamięci na dysku serwera. Zwróciłem więc mu uwagę, że zważywszy na dzisiejsze ceny dysków, koszt tego obszaru jest znacznie mniejszy, niż koszt zużywanego przeze mnie papieru toaletowego. Poświęcenie choćby 10 minut na porządkowanie mojego katalogu byłoby spektakularnym marnotrawstwem produktywności.

Najlepsze zespoły nie dręczą swoich programistów. Nawet najmniejsze frustracje spowodowane używaniem nie dość dobrych narzędzi sumują się, wprowadzając programistów w zły humor i niezadowolenie. A niezadowolony programista, to programista niewydajny.

Żeby dodać do tego wszystkiego... programiści dają się łatwo przekupić zmyślnymi zabawkami. To w rzeczywistości o wiele tańsza metoda motywacji niż wypłacanie im konkurencyjnych zarobków!

10. Czy masz testerów?
Jeżeli w twoim zespole nie ma osób zajmujących się tylko testowaniem, przynajmniej jednej na każdych dwóch lub trzech programistów, to albo wypuszczasz oprogramowanie z błędami, albo marnujesz pieniądze, każąc drogim programistom wykonywać pracę testera, wartą trzy razy mniej. Oszczędzanie na testerach jest tak źle pojętą ekonomią, że doprawdy nie mogę zrozumieć, dlaczego ludzie tego nie dostrzegają.

Przeczytaj Pięć głównych (fałszywych) powodów, dla których nie masz testerów, jeden z moich artykułów na ten temat.

11. Czy kandydaci piszą programy podczas rozmowy kwalifikacyjnej?
Czy zatrudniłbyś sztukmistrza nie poprosiwszy go o zaprezentowanie kilku numerów? Oczywiście, że nie.

Czy wynająłbyś kucharza na swoje wesele bez skosztowania jego wyrobów? Wątpię. (Chyba że chodzi o ciocię Marynę, a ta znienawidziłaby cię na zawsze, gdybyś jej nie pozwolił przyrządzić jej „słynnego” ciasta z siekaną wątróbką).

A jednak każdego dnia zatrudnia się programistów na podstawie imponującego resumé lub dlatego, że przeprowadzającemu wywiad miło się z nimi gawędziło. Albo też stawia im się niedorzeczne pytania ("jaka jest różnica między CreateDialog() a DialogBox()?"), na które można odpowiedzieć sięgając do dokumentacji. Nie jest ważne, czy kandydat wyuczył się na pamięć tysiące błahostek dotyczących programowania, lecz to, czy jest on w stanie napisać program. Jeszcze gorsze jest zadawanie zagadek typu "Aha!", tzn. takich, które wydają się łatwe, gdy zna się odpowiedź, lecz wcześniej są nie do rozwiązania.

Po prostu skończ z tym, proszę. Rób, co uważasz za stosowne podczas rozmowy kwalifikacyjnej, lecz każ kandydatom napisać kawałek programu. (Więcej znajdziesz w moim Partyzanckim poradniku rekrutacji).

12. Czy praktykujesz korytarzowe testy wygody użytkowania?
W korytarzowym sprawdzianie łatwości użytkowania bierzesz pierwszą z brzegu osobę, jaka nawinie się na korytarzu i zmuszasz ją, aby spróbowała skorzystać z programu, który właśnie napisałeś. Zrób tak z pięcioma osobami, a odkryjesz 95% tego, co jest do odkrycia, jeśli chodzi o kwestie wygody użytkowania twego programu.

Projektowanie dobrego interfesju użytkownika nie jest aż tak trudne, jak mógłbyś sądzić, za to jest bardzo ważne, jeśli chcesz, by użytkownicy polubili i kupowali twój produkt. Możesz przeczytać moją darmową książkę online o projektowaniu interfejsu użytkownika, krótki zarys dla programistów (przekład polski MIKOM 2001, ISBN 83-7279-179-1).

Jednak najważniesze, co można powiedzieć na temat interfejsów użytkownika (UI) to to, że jeśli pokażesz swój program grupce ludzi (w rzeczy samej, wystarczy pięć, sześć osób), szybko odkryjesz, co sprawia użytkownikom największe kłopoty. Przeczytaj artykuł Jakoba Nielsena wyjaśniający dlaczego. Nawet jeśli brak ci umiejętności projektowania UI, to usilne stosowanie korytarzowych testów wygody użytkowania — co nic nie kosztuje — sprawi, że twój interfejs będzie o niebo lepszy.

Cztery sposoby wykorzystania testu Joela

  1. Oceń swoją własną firmę i powiedz mi, jak wypadła, abym mógł to rozgłaszać.
  2. Jeśli jesteś kierownikiem projektu, potraktuj test jak listę kontrolną, aby upewnić się, że twój zespół pracuje tak dobrze, jak to tylko możliwe. Gdy zaczniesz osiągać 12, możesz pozostawić programistów w spokoju i skupić się na ich ochronie przed zanudzaniem ze strony ludzi od biznesu.
  3. Jeśli zastanawiasz się, czy podjąć daną pracę w charakterze programisty, zapytaj przyszłego pracodawcę jak wypada w tym teście. Jeśli zbyt słabo, upewnij się, że będziesz miał prawo to zmienić, w przeciwnym razie grozi ci frustracja i nieproduktywność.
  4. Jeśli jesteś inwestorem próbującym ocenić wartość pewnego zespołu programistów lub gdy twoja firma rozważa fuzję z inną, ten test może dostarczyć szybkiej wskazówki.


Oryginał ukazał się w wersji angielskiej pod nazwą The Joel Test: 12 Steps to Better Code  

Joel Spolsky jest założycielem Fog Creek Software, małej firmy programistycznej w Nowym Jorku. Ukończył Uniwersytet Yale i  pracował jako programista i menedżer w Microsofcie, Viacom i Juno.


Zawartość tych stron wyraża opinie jednej osoby.
Cała zawartość prawnie chroniona. Copyright ©1999-2005 by Joel Spolsky. Wszelkie prawa zastrzeżone.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky