Zaawansowany przegląd kodu i praktyka testowania jednostek

Jako lider zespołu zarządzający grupą programistów, którzy nie mają doświadczenia (i nie widzą potrzeby) w przeglądzie kodu i testowaniu jednostkowym, w jaki sposób możesz usprawnić przegląd kodu i praktykę testowania jednostkowego?

Jak zamierzasz stworzyć sposób, aby przegląd kodu i testy jednostkowe naturalnie pasowały do ​​przepływu programisty?

Jednym z oporów tych dwóch obszarów jest to, że „zawsze jesteśmy ściśle związani z linią danych, więc nie ma czasu na przegląd kodu i testowanie jednostek”.

Innym oporem dla przeglądu kodu jest to, że obecnie nie wiemy, jak to zrobić. Czy powinniśmy sprawdzać kod przy każdej odprawie, czy sprawdzać kod w określonym dniu?

Czy członkowie zespołu rzeczywiście zgadzają się, że recenzje kodu i testy jednostkowe są dobre, po prostu nie ma na to czasu?

Czy może po prostu próbują odrzucić ten pomysł za pomocą tej wymówki?

W pierwszym przypadku rozwiązaniem jest zacząć robić to teraz . (OK, jeśli jesteś w ostatnich dniach przed kamieniem milowym, może możesz poczekać do później - ale nie więcej.) Mieliśmy taką sytuację w moim poprzednim miejscu pracy, gdzie byłem Inżynierem ds. Jakości, odpowiedzialnym za poprawę praktyk kodowania i ogólna jakość. Odkładaliśmy rozpoczęcie recenzji kodu na następny tydzień. Pewnego dnia zdałem sobie sprawę, że robimy to od około miesiąca i prawdopodobnie będzie to trwało do końca czasów, chyba że spróbuję czegoś innego. Więc ogłosiłem pierwszą recenzję kodu w tym tygodniu. Powiedziałem chłopakom: „nie ma problemu, jeśli będzie niedoskonały lub jeśli jeszcze nie wiemy dokładnie, co robić - zaczniemy to robić, zobaczymy, jak to będzie i poprawimy sytuację w miarę uczenia się”. Działało, przynajmniej dopóki nie opuściłem firmy.

W drugim przypadku możesz potrzebować więcej edukacji i otwartej dyskusji z zespołem. Omów zagadnienia jakości kodu, zapytać ich, co oni zobaczyć jak problemy w procesie rozwoju (lub jej brak) / kod / testowanie itd. A Brainstorm razem o tym, jak rozwiązać te . Ostatecznym celem niekoniecznie jest dokonywanie przeglądów kodu - są one po prostu środkami, podczas gdy celem jest poprawa procesu rozwoju i jakości jego wyników. Może się okazać, że istnieją inne, bardziej bolesne problemy, które można łatwiej poprawić, przynosząc więcej korzyści szybciej; następnie weź je najpierw. Mogą to być nawet trywialne zmiany w środowisku lub procesie; wszystko to poprawi morale zespołu, zbuduje wzajemne zaufanie i pomoże w zespole.

Najważniejsze jest to, że nie możesz narzucać jakości nikomu - możesz jedynie usunąć przeszkody w tworzeniu jakości . Egzekwując surowe zasady i obowiązkowe praktyki bez uprzedniej zgody zespołu , możesz zrazić zespół i ostatecznie zapobiec poprawie jakości, do której dążysz. OTOH poprzez otwartą dyskusję i dążenie do porozumienia co do najpilniejszych problemów zespołu i jak poprawić sytuację, jest większe prawdopodobieństwo uzyskania wsparcia zespołu. Będzie to miało decydującą różnicę w utrzymaniu dążenia do poprawy jakości w długim okresie.

Klasyczny problem. Nigdy nie ma wystarczająco dużo czasu, aby zrobić to dobrze, zawsze wystarczająco dużo czasu na ponowne wykonanie pracy. Dopóki ludzie nie zaczną stosować najlepszych praktyk, nigdy nie będzie czasu na ich stosowanie. Zwłaszcza, że ​​wygrane są niewidoczne dla osób spoza rozwoju.

Kluczem do przeglądu kodu jest to, że chcesz przejrzeć jak najmniej kodu, tak szybko jak to możliwe. W ten sposób łatwiej jest znaleźć czas na jego przejrzenie, kod jest świeży w umyśle ludzi, a wdrażanie sugerowanych ulepszeń będzie łatwiejsze. W skrajności chcesz przejrzeć każde pojedyncze zameldowanie. Dobrym narzędziem do automatyzacji tego jest http://code.google.com/appengine/articles/rietveld.html . Jest to wariant narzędzia, którego Google używa wewnętrznie, aby wymusić sprawdzenie kodu przy każdym zameldowaniu.

Wyzwanie związane z przeglądem kodu opisano kilkadziesiąt lat temu w klasycznym The Psychology of Computer Programming . Problem polega na tym, że programiści łączą swój wizerunek z umiejętnościami programistycznymi. Co oznacza, że ​​za każdym razem, gdy programiści mają do czynienia z dowodami, że ich umiejętności nie pasują do tabaki, istnieje tendencja do przyjmowania ich osobiście. Może to powodować poważne konflikty. Jeśli wybierzesz klasyczny szybki rozwój Steve'a McConnella, zaoferuje on szereg sugestii, jak skonfigurować proces przeglądu kodu, który zmniejsza prawdopodobieństwo takiego konfliktu. (Kluczowym elementem jest upewnienie się, że kierownictwo nigdy nie bierze udziału w procesie.) Należy pamiętać, że zmniejsza to prawdopodobieństwo konfliktu, ale nie zapobiega wystąpieniu konfliktu.

To powiedziawszy, korzyści znacznie przewyższają koszty. Cytując tylko jedną miarę, IBM stwierdził, że przegląd kodu to dolar za dolara, który jest najbardziej skutecznym sposobem na znalezienie i wyeliminowanie błędów. Nie zastępuje to w żaden sposób twojego działu kontroli jakości. Ale powoduje to o wiele mniej problemów do znalezienia. I to zanim osiągniesz korzyści związane z tym, jak bardzo przyspiesza naukę, rozpowszechnia wiedzę itp.

Nie dawaj im opcji. Obowiązek testowania i recenzji. Jeśli nie będą współpracować, możesz zastosować twarde taktyki, takie jak odmawianie niesprawdzonych lub niesprawdzonych promocji. Jeśli wszystko jest naprawdę złe, zwolnij swojego najgorszego przestępcę.

Widziałem przypadki, w których zespół jest zawsze opóźniony, ponieważ zawsze naprawiają błędy, które powinny zostać wykryte przez testy i recenzje. Trochę więcej pracy z przodu pozwala zaoszczędzić znacznie więcej w dłuższej perspektywie, a im wcześniej ustawisz swój zespół w szeregu, tym lepszy będzie Twój zespół.

Niestety uzyskanie wyników może zająć trochę czasu. Aby zachęcić do praktyki, możesz rozpocząć tworzenie wykresu częstości zgłoszeń błędów, średniego czasu do naprawienia błędów i tempa wdrażania funkcji. Zwykle stwierdzam, że po około sześciu miesiącach testów i przeglądów te parametry poprawią się i twój zespół w końcu je dostanie.

Wprowadzenie tdd wbrew woli programistów jest trudne. To trudny sposób, aby nauczyć się kochać TDD.

Ponieważ tdd jest najskuteczniejszy na zielonym polu (lub trudnym, kosztownym, nieefektywnym, jeśli testy są popsute), zacznę od małego zespołu, który wdraża coś nowego. Jeśli znajdziesz dwóch develloppers w drużynie, którzy są mniej przeciwni tdd niż inni, jest to dobry punkt wyjścia. weź pod uwagę, że produktywność programistów tdd ucierpi, gdy nie będą mieli doświadczenia z tdd.

Ten rozwój TDD jest dobrym punktem wyjścia do przeglądania kodu. Omów, w jaki sposób tdd wpłynął na architekturę programu i jak ułatwia konserwację oprogramowania.