Na ile z pytań odpowiesz twierdząco?
Czy używasz repozytorium dla swoich źródeł?
Jeśli nie masz kontroli nad kodem źródłowym, będziesz się stresować, próbując zmusić programistów do wspólnej pracy. Programiści nie mają możliwości dowiedzenia się, co zrobili inni ludzie. Błędów nie da się łatwo naprawić.
Czy możesz wykonać kompilację w jednym kroku?
Rozumiemy przez to: ile kroków potrzeba, aby utworzyć kompilację zdatną do działania, z najnowszej migawki źródła? W dobrych zespołach istnieje pojedynczy skrypt, który można uruchomić na każdej wersji kodu źródłowego, a który wykonuje pełne pobranie od podstaw, przebudowuje każdą linię kodu, tworzy pliki EXE we wszystkich ich różnych wersjach i wreszcie przygotowuje pakiet instalacyjny czy paczkę gotową do deploy’a.
Jeśli proces wymaga więcej niż jednego kroku, jest podatny na błędy. A kiedy zbliżasz się do deploymentu, chcesz mieć bardzo szybki cykl naprawiania „ostatniego” błędu, tworzenia końcowych plików EXE itp. Jeśli kompilacja kodu wymaga 20 kroków, uruchomienia kreatora instalacji itp. szybko oszalejesz i popełnisz głupie błędy.
Czy tworzysz codzienne buildy?
Kiedy używasz kontroli źródeł, czasami jeden programista przypadkowo robi coś, co psuje kompilację. Na przykład doda nowy plik źródłowy i wszystko dobrze się kompiluje na jego komputerze, ale zapomniał dodać ten plik źródłowy do repozytorium kodu. Więc zamyka komputer i wraca do domu, nieświadomy i szczęśliwy. Ale nikt inny nie może pracować, więc oni też muszą iść do domu, już nieco mniej szczęśliwi, albo muszą zostać w pracy – zdecydowanie bardziej nieszczęśliwi ;-)
Czy masz bazę danych błędów?
Jeśli tworzysz kod, nawet w jednoosobowym „zespole”, bez zorganizowanej bazy danych zawierającej wszystkie znane błędy w kodzie, otrzymasz kod niskiej jakości. Wielu programistów myśli, że potrafią trzymać listę błędów w głowach. Nonsens, koniecznie musisz formalnie śledzić błędy.
Minimalna użyteczna baza danych błędów musi zawierać następujące dane dla każdego błędu:
- pełne kroki w celu odtworzenia błędu
- spodziewane zachowanie
- zaobserwowane, niewłaściwe zachowanie się programu
- do kogo błąd jest przypisany
- czy zostało to naprawione, czy nie
Czy naprawiasz błędy przed napisaniem nowego kodu?
Kiedy kierownicy projektów za bardzo nalegają na dotrzymywanie „harmonogramu”, programiści po prostu pośpiesznie pracując, piszą bardzo zły kod – dzieje się tak gdy faza naprawiania błędów nie jest częścią formalnego harmonogramu. Coś jak programista, który musiał napisać kod obliczający ilość wierszy tekstu, ale po prostu napisał „return 12” i czekał, aż nadejdzie raport o błędzie dotyczący tego, że jego funkcja nie zawsze jest poprawna – bo nie miał czasu jej poprawnie zaimplementować.
Aby rozwiązać ten problem, firma Microsoft powszechnie przyjęła coś, co nazywa się „metodologią zero defektów” (tak, śmiesznie brzmi). Zasada oznaczała, że w dowolnym momencie najwyższym priorytetem jest wyeliminowanie błędów przed napisaniem nowego kodu. Ogólnie rzecz biorąc, im dłużej czekasz z naprawieniem błędu, tym droższa jest naprawa.
Czy masz aktualny harmonogram?
Jest wiele decyzji dotyczących planowania, które firma musi podjąć z dużym wyprzedzeniem przed wysłaniem kodu: prezentacje, targi, reklamy itp. Jedynym sposobem na to jest posiadanie harmonogramu i aktualizowanie go. Inną kluczową rzeczą w posiadaniu harmonogramu jest to, że zmusza Cię on do podjęcia decyzji, jakie funkcje zamierzasz zrobić, a następnie zmusza cię do wybrania najmniej ważnych funkcji i wycięcia ich zamiast popadnięcia w obłęd.
Czy masz specyfikację?
Pisanie specyfikacji jest jak nitkowanie zębów: wszyscy zgadzają się, że to dobra rzecz, ale nikt tego nie robi. Na etapie projektowania, gdy odkryjesz problemy, możesz je łatwo naprawić, edytując kilka wierszy tekstu. Po napisaniu kodu koszt naprawiania problemów jest znacznie wyższy. Oprogramowanie, które nie zostało zbudowane na podstawie specyfikacji, zwykle kończy się źle zaprojektowanym harmonogramem i proces jego tworzenia wymyka się spod kontroli.
Czy programiści mają ciche miejsce pracy?
Zapewnienie pracownikom umysłowym przestrzeni, ciszy i prywatności jest niezbędne dla wydajnej pracy. Programiście muszą być w pełni skoncentrowani na swojej pracy i całkowicie oderwani od otoczenia. Tracą wtedy poczucie czasu i produkują świetne rzeczy dzięki absolutnej koncentracji.
Czy korzystasz z najlepszych narzędzi, jakie możesz mieć?
Pisanie kodu w skompilowanym języku jest jedną z ostatnich rzeczy, które chcesz robić na starym sprzęcie. Jeśli proces kompilacji trwa dłużej niż kilka sekund, zakup najnowszego i najlepszego komputera pozwoli Ci zaoszczędzić czas. Jeśli kompilacja zajmie nawet 15 sekund, programista będzie się nudzić podczas gdy kompilator będzie mielił kod i przełączy się na czytanie TeamQuesta (co nas akurat będzie cieszyło ale jego pracodawcę może nieco mniej).
Sprawdź oferty pracy na TeamQuest
Czy masz testerów?
Jeśli Twój zespół nie ma dedykowanych testerów, co najmniej jednego na dwóch lub trzech programistów, albo tworzysz wadliwe produkty, albo marnujesz pieniądze, zlecając programistom pracę, którą mogą wykonać testerzy za ułamek pensji programistów.
Czy nowi kandydaci piszą kod podczas rozmowy kwalifikacyjnej?
Czy zatrudniłbyś maga, nie prosząc go o pokazanie ci magicznych sztuczek? Oczywiście nie. Jednak każdego dnia programiści są zatrudniani na podstawie imponującego CV lub dlatego, że ankieter lubił z nimi rozmawiać. Albo zadają im pytania o ciekawostki, na które można odpowiedzieć, przeglądając dokumentację. Rób co chcesz podczas rozmów kwalifikacyjnych, ale każ kandydatowi napisać jakiś kod.
Czy przeprowadzasz test korytarza?
Test korytarza polega na tym, że chwytasz pierwszą lepszą osobę, która przechodzi korytarzem i zmuszasz ją do użycia napisanego kodu. Jeśli zrobisz to pięciu osobom, dowiesz się 95% tego, czego można się nauczyć o problemach z użytecznością w swoim kodzie.
