Radzenie sobie z deweloperem stale ignoruje przypadki krawędzi w swojej pracy

Mam ciekawy, dość częsty problem z jednym z programistów w moim zespole. Facet jest świetnym programistą, działa szybko i produktywnie, produkuje dość dobrej jakości kod i tak dalej. Dobry inżynier Ale jest z nim problem - bardzo często nie zajmuje się przypadkowymi przypadkami w swoim kodzie.

Rozmawialiśmy z nim wiele razy, a on próbuje, ale myślę, że po prostu nie myśli w ten sposób. Ostatecznie dzieje się tak, że QA napotka wiele problemów z jego kodem i zwróci go z powrotem do rozwoju, co ostatecznie spowoduje niedotrzymanie terminów i wszyscy w zespole będą niezadowoleni.

Nie wiem, co z nim zrobić i jak pomóc mu pokonać ten problem. Być może ktoś z większym doświadczeniem mógłby doradzić?

Wymagaj od niego pisania automatycznych testów jednostkowych dla jego kodu. Pisanie testów jednostkowych zmusza do przemyślenia przypadków skrajnych.

Niektóre dane:

1. Aby upewnić się, że nie czuje się wyróżniony, należy to ustalić dla całego zespołu. Wymagaj od wszystkich pisania automatycznych testów jednostkowych nowego kodu lub kodu, który modyfikują.
2. Wymagaj, aby nazwy testów jednostkowych były opisowe w odniesieniu do testowanego przypadku.
3. Obejmują zautomatyzowane testy jednostkowe w przeglądzie kodu na wysokim poziomie. Poproś recenzentów o wyszukanie pominiętych przypadków testowych (tj. Przypadków skrajnych, których odwiecznie tęskni). Po uzyskaniu pewnej ilości opinii od swojego zespołu na temat przypadków nieobecności na krawędzi prawdopodobnie nauczy się je rozpatrywać przed przeglądem.
4. Egzekwuj tę regułę dla całego zespołu: jeśli QA znajdzie błąd, odpowiedzialny programista jest winien automatyczny test, który potwierdza awarię, a następnie udowadnia, że ​​ją naprawił. (zanim wykonają jakąkolwiek inną pracę)

Daj mu listę kontrolną, np

• zerowe dane wejściowe
• wejścia na bardzo dużym końcu zakresu
• wejścia na ekstremalnie małym końcu zakresu
• kombinacje
• dane wejściowe naruszające zakładane niezmienniki (np. jeśli x = y)

Pracownicy QA mogą pomóc w opracowaniu listy kontrolnej

Daj listę kontrolną wszystkim programistom, nie tylko tej.

Dobry inżynier

W porządku.

Ale jest z nim problem - bardzo często nie zajmuje się przypadkowymi przypadkami w swoim kodzie.

Jest to jakość, której nie udostępniają dobrzy inżynierowie.

Obserwowanie przypadków skrajnych jest cechą występującą u ludzi lub nie. Nie ma to nic wspólnego z byciem inżynierem lub programistą. Na rozwój tej cechy wpływ ma pochodzenie kulturowe, środowisko życia, wydarzenia z dzieciństwa i doświadczenia życiowe. Następnie podejście to jest po prostu stosowane do każdej pracy, którą wykonuje osoba.

Musisz dowiedzieć się, czy twój facet jest tego rodzaju, który nie rozwinął się w tym sensie (być może jeszcze). Jest również bardzo prawdopodobne, że z jakiegoś powodu go to nie obchodzi. Musisz przeanalizować całą sytuację, czy jest szczęśliwy w swojej pracy. Jeśli nie, być może najpierw powinieneś mu pomóc.

Jeśli dobrze sobie radzi z pracą, ale nie doświadczył jeszcze niebezpieczeństwa przypadkowych przypadków, możesz zacząć go uczyć. Jeśli weźmie to na poważnie, z czasem może zmienić swoje postępowanie. Chociaż jestem sceptyczny w tej sprawie, nadal możesz spróbować.

Jeśli jednak okaże się, że jest osobą tego rodzaju, która nie jest dobra w ostrych przypadkach, możesz nie mieć nic innego, jak tylko usunąć go z drużyny. Ta cecha jest niezbędna do praktycznego programowania. Niestety bez niego nawet świetny człowiek nie dałby dobrej pracy.

Czy mógłbyś wcześniej napisać recenzje kodu lub projektu?

Naucz go programować jako pierwszy. Sparuj z nim. Będziesz pisać przypadki testowe, a on napisze kod, aby przejść testy.

Czy zaangażowanie QA w opracowywanie funkcji wystarczająco wcześnie może dostarczyć mu listę przypadków skrajnych na początku do omówienia? Chociaż niektórzy mogą uznać, że nie oczekuje od programisty pokrycia wszystkiego, może to być sposób na obejście tego, jeśli ma tendencję do przeoczenia tych przypadków granicznych, które tester może początkowo złapać.

Innym pomysłem, jaki tu mam, jest sposób, w jaki postrzega ten problem. Czy naprawdę jest zirytowany i cyknął na siebie za ten wzór, czy po prostu uważa to za normalne i nie ma się czym martwić w rozwiązaniu? To prawda, że ​​wymaga to dużego zaufania i zmuszenia go do otwartości na swoją perspektywę, ale myślę, że jest tu pewien stopień empatii, który może pomóc, jeśli widzisz rzeczy z jego perspektywy.

Istnieje nieskończona liczba przypadków brzegowych, obejmowanie ich wszystkich jest niemożliwe. Co jeśli ktoś to zrobi #define TRUE FALSE? Dodaje przypadki krawędzi, czy je też sprawdzisz?

Ponadto nie rozważałbym, aby głupio sprawdzać każdą funkcję klasy prywatnej lub funkcję wewnętrzną.

Podejście, które wybrałem dla kodu, który musi być bardzo solidny i stabilny, to:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

W ten sposób uzyskuje się rzetelne zrzuty aplikacji w ramach kontroli jakości, a do czasu premiery aplikacja jest solidna i bezpieczna.

Obejście błędów jest złe. Ok, możesz zapisać funkcję, jeśli uchwyt pliku ma wartość NULL i zwraca NULL, ale w większości przypadków występuje gdzieś błąd projektowy, a awaria aplikacji to lepszy sposób na wymuszenie znalezienia przyczyny. Większość przypadków krawędzi tylko maskuje błąd, ukrywając problem, powiedzmy - przycisk przestał działać. Awaria mówi ci, że niektóre założenia dotyczące produktu są błędne i musisz zrewidować logikę, która spowodowała awarię.

Jeśli jest to przypadek skrajny, czy w ogóle należy go wziąć pod uwagę? Jeśli skrzynki krawędziowe są ważne, skrzynki krawędziowe należy wprowadzić do wymagań / funkcji / historii użytkownika.

Jeśli przypadki krawędziowe zostały uznane za część pracy, a urządzenia muszą zostać zainstalowane, to powinny one być częścią przedmiotu pracy, a z definicji przedmiot pracy nie jest kompletny, dopóki mechanizm obsługi skrzynki krawędziowej nie zostanie w miejscu.

To daje zespołowi jako dowódcy coś, z czym warto się sprawdzić po zakończeniu pracy podczas dyskusji po pracy i daje deweloperowi coś, z czym może się sprawdzić po zakończeniu pracy.

Łapanie skrajnych przypadków jest powodem, dla którego istnieje kontrola jakości. Na programistach spoczywa odpowiedzialność za terminowe wypychanie pracy. Spędzanie całego czasu na poszukiwaniu skrzynek jest bardzo nieefektywne. Jeśli masz dość szybki cykl iteracyjny, nie powinno to stanowić żadnego problemu. Liczba przypadków na krawędziach jest prawie nieskończona. Gdyby to był problem ze sprawami „Core”, byłbym trochę zaniepokojony. Tak jak programiści są ekspertami w programowaniu, tak tester powinien być ekspertem w testowaniu. Gdy tester znajdzie problem, odsyła go z powrotem do programowania. Deweloper rozwiązuje problem. Problem rozwiązany. Czas, w którym programista może wyśledzić każdy przypadek krawędzi, jest znacznie dłuższy niż powinien zająć iteracyjny cykl testowania. Zauważ też, że kiedy mówię o testowaniu, nie mam na myśli testów jednostkowych białych skrzynek, ale ściśle czarnych skrzynek.

Jest to jeden z przypadków, w których uważam, że rozwój oparty na testach przychodzi na ratunek, ponieważ pomaga myśleć w kategoriach przypadków skrajnych i wszystkiego, co może złamać kod.