Nie pamiętam dokładnie, kiedy po raz pierwszy natknąłem się na blog Joela Spolsky’ego Joel on Software, ale było to w pewnym momencie w szkole średniej.
Nie wiedziałem wystarczająco dużo o całym procesie tworzenia oprogramowania, aby uzyskać wiele z tego, o czym naprawdę mówił, ale podobał mi się jego styl pisania i podobało mi się to, co miał do powiedzenia.
W rzeczywistości byłem takim fanem, że po ukończeniu studiów kupiłem jego książki (które były zbiorami artykułów na jego stronie) i czytałem je od deski do deski. Trzymałem ich kopie na biurku w pracy i korzystałem z jednej z jego książek – Smart and Gets Things Done – kiedy byłem kierownikiem zespołu.
Jednak najbardziej utkwiły mi w pamięci artykuły, które dotyczyły pisania lepszego kodu. Oto jednak rzecz: te artykuły nie zawierały nic na temat pisania kodu.
Pisanie lepszego kodu
Zamiast tego chodziło o procesy związane z lepszym kodem. I natknąłem się na artykuł – mimo wszystko mający 16 lat – i nadal uważam go za tak samo aktualny, jak wtedy, gdy go znalazłem.
Z wyjątkiem tego, że sam zastanawiam się, jak to się ma do mojej obecnej pracy programistycznej.
Test Joela
Po pierwsze, artykuł, o którym mowa, to taki, który czytam co najmniej raz w miesiącu – jeśli nie przynajmniej raz w tygodniu – i wszyscy kręci się wokół tego, co on nazywa testem Joela. To dwanaście pytań, które zadajesz swojemu obecnemu zespołowi programistycznemu.
- Czy korzystasz z kontroli źródła?
- Czy potrafisz wykonać kompilację w jednym kroku?
- Czy codziennie budujesz?
- Czy masz bazę błędów?
- Czy naprawiasz błędy przed napisaniem nowego kodu?
- Czy masz aktualny harmonogram?
- Masz specyfikację?
- Czy programiści mają ciche warunki pracy?
- Czy korzystasz z najlepszych narzędzi, jakie można kupić za pieniądze?
- Czy masz testerów?
- Czy nowi kandydaci piszą kod podczas rozmowy kwalifikacyjnej?
- Czy przeprowadzasz testy użyteczności korytarza?
Biorąc pod uwagę, że te pytania zostały napisane 16 lat temu i są w dużej mierze oparte na skompilowanym kodzie, niektóre terminy mogą wymagać dostosowania.
Fajną rzeczą w teście Joela jest to, że łatwo jest szybko odpowiedzieć tak lub nie na każde pytanie. Nie musisz ustalać liczby linii kodu na dzień lub średniej liczby błędów na punkt przegięcia. Daj swojemu zespołowi 1 punkt za każdą odpowiedź „tak".
Na przykład, zamiast pytać, czy możesz wykonać kompilację w jednym kroku, być może powinniśmy zapytać, czy możemy wykonać wdrożenie w jednym kroku. Wiesz, co mam na myśli – wprowadzanie poprawek do takich rzeczy.
Po drugie, niektóre pytania muszą być dostosowane do zdalnych zespołów, ponieważ nie jesteśmy już wszyscy w tym samym biurze. Oznacza to, że zamiast przeprowadzać testy użyteczności na korytarzu, być może będziesz musiał złapać kogoś, kogo znasz online, wysłać go do swojego środowiska testowego i zapytać o projekt.
Test Joela dla WordPress
Być może dla tych z nas, którzy używają WordPressa jako podstawy rozwoju, nasz zestaw pytań będzie wyglądał mniej więcej tak:
- Czy korzystasz z kontroli źródła?
- Czy możesz wykonać wdrożenie w jednym kroku?
- Czy wykonujesz codzienne wdrożenia?
- Czy masz bazę błędów?
- Czy naprawiasz błędy przed napisaniem nowego kodu?
- Czy masz aktualny harmonogram?
- Masz wymagania i makiety?
- Czy programiści mają ciche warunki pracy? Lub, jeśli jest zdalny, czy programiści mogą przejść w tryb „Nie przeszkadzać”?
- Czy korzystasz z najlepszych narzędzi na rynku, albo czegoś darmowego i open source, czy czegoś premium?
- Czy masz testerów? (I mogę zapytać, czy budżet projektu pozwala na pisanie testów jednostkowych również do testów automatycznych)?
- Czy kandydaci mają próbki kodu dostępne w serwisie GitHub, blogu lub publicznie dostępnej lokalizacji, które można przejrzeć?
- Czy masz grupę ludzi, z których możesz wyciągnąć, aby przetestować swoją pracę w toku?
Ponownie, jest to w dużej mierze oparte na idei małego, zdalnego zespołu, a nie dużej firmy lub agencji produktowej na poziomie korporacyjnym. Ale jest to coś, do czego wciąż wracam od czasu do czasu i zastanawiam się, jak inne sklepy wypadają naprzeciw siebie.
Och, a cała sprawa z punktacją?
Wynik 12 jest doskonały, 11 jest znośny, ale 10 lub mniej i masz poważne problemy. Prawda jest taka, że większość organizacji zajmujących się oprogramowaniem działa z wynikiem 2 lub 3 i potrzebują poważnej pomocy…
Wszyscy mamy coś, do czego możemy dążyć, prawda?
Na następną dekadę?
Nie chodzi o to, że myślę, że to konkurs, ale wiem, że na większość tych pytań chciałabym odpowiedzieć twierdząco dla siebie i dla tych, z którymi pracuję.
Ale w czasie tego artykułu mogę powiedzieć, że nie mogę powiedzieć tak wszystkim tym wszystkim, nie mówiąc już o może połowie z nich. Być może do końca roku zdołam.
A może reszta z nas pracujących w branży może ocenić nasze zespoły pod kątem tych pytań. Chociaż Internet i związane z nim technologie szybko się rozwijają, pytania te utrzymują się dobrze od ponad dekady.