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

25

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ć?

code-quality

— Alex N.
źródło

11

Poproś kogoś o pokrycie jego kodu testami jednostkowymi.

— Job

8

Najlepiej wykwalifikowaną osobą do testowania kodu jest jego autor.

16

@Developer Art: Całkowicie się nie zgadzam. Najgorszą osobą do testowania kodu jest osoba, która go opracowała. Każdy ma martwe punkty, ale osoba tworząca ma największą martwą stronę w odniesieniu do swojego kodu.

— James P. Wright,

2

@Developer Art: Wierzę, że pisanie automatycznych testów jest w rzeczywistości dość powszechną rolą. Zazwyczaj jest to coś, co robisz przez rok lub dwa, jeśli nie jesteś jeszcze gotowy na najlepszy czas w firmie, w której się znajdujesz. To rodzaj okresu czyśćcowego.

— Morgan Herlocker

19

Opisujesz go jako „świetnego programistę”, „produktywnego”, „dobrego inżyniera” i produkującego „kod dobrej jakości”. Ale QA ciągle ma problemy z jego pracą. Czy naprawdę użyłbyś tych terminów, aby opisać kogoś, kto regularnie i konsekwentnie wstrzykuje defekty do swojego kodu? Zastanawiam się, czy jest coś więcej w tej historii, ponieważ opis osoby jako profesjonalisty i wykonywanej przez nią pracy w ogóle się nie zgadzają

— Thomas Owens

29

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:

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ą.
Wymagaj, aby nazwy testów jednostkowych były opisowe w odniesieniu do testowanego przypadku.
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.
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ę)

— Matthew Rodatus
źródło

Amen, jeszcze lepiej, wymaga, aby każdy napisał swój kod w pierwszej kolejności. Korzystanie z frameworka BDD zwykle zmniejsza ból z tego powodu

— George Mauer

@George Dobry pomysł. TDD pomogłoby tutaj jeszcze bardziej.

— Matthew Rodatus

3

Testy jednostkowe nie polegają na wyszukiwaniu błędów - blog.stevensanderson.com/2009/08/24/…

— Dainius

1

@Dainius Zgadzam się. Testowanie jednostkowe ułatwia programistom przemyślenie przypadków skrajnych, co może wykluczyć (ale nie zidentyfikować) błędy.

— Matthew Rodatus,

After some amount of feedback from his team about missed edge cases, he will probably learn to consider thoseProgramiści, którzy stosują złe praktyki, często twierdzą, że dodatkowy wysiłek wymagany do dobrych praktyk jest nieistotny (ponieważ nie widzą korzyści z takiego postępowania). Chociaż programista może się zgodzić, jeśli dodasz dodatkowe przypadki skrajne, nie oznacza to, że uważa, że jest to istotne, lub czy sam je doda.

— Flater

23

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.

— Steven A. Lowe
źródło

1

Dobrze, że wszyscy programiści powinni skorzystać z listy kontrolnej, wyodrębnienie jednego programisty może powodować złe odczucia. I może pomóc poprawić jakość kodu każdego .

— FrustratedWithFormsDesigner

Dobry pomysł, chociaż ciekawi mnie, jak można to postrzegać z perspektywy deweloperów. W praktyce nigdy nie spotkałem się z tą praktyką jako programista, więc ciężko jest mi ocenić reakcję. Jakieś spostrzeżenia?

— Alex N.

@Alex: listy kontrolne są rutynową praktyką dla niektórych deweloperów i okropną zniewagą dla innych. Spróbuj i zobacz, co się stanie. Jeśli zrezygnuje, poprawi się jakość twojego kodu ;-)

— Steven A. Lowe

4

Twoi twórcy nie będą używać list kontrolnych? Jeśli lista kontrolna mogłaby uratować życie, czy by z nich skorzystali? Wielu lekarzy tego nie robi, a pacjenci cierpią. Przeczytaj to: newyorker.com/reporting/2007/12/10/071210fa_fact_gawande

— Barry Brown

1

@Barry, nie powiedziałem, że nie. Listy kontrolne w tym przypadku brzmią, IMHO, jak remedium na objawy problemu, a nie na sam problem. Problemem jest dyscyplina i staranność w tym przypadku. Gdy problemem jest złożoność systemu, który wymaga konserwacji awaryjnej z dużym zaangażowaniem i stresem, skutkuje to obniżeniem poziomu dbałości o szczegóły, to tak, listy kontrolne ftw (piloci, lekarze itp.) Ale to więcej debaty filozoficznej, jak sądzę, poza zakresem tego pytania.

— Alex N.

17

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.

6

+1 Jest to umiejętność, że niektórzy ludzie mają niektórzy ludzie muszą nauczyć się być dobrym programistą. Chciałbym jednak zauważyć, że istnieją dwa rodzaje przypadków skrajnych: przypadki skrajnych wymagań biznesowych („Jeśli zamówimy 27 lewych trenerów i 28 prawych trenerów, to zamówienie prawdopodobnie będzie złe”), które powinny zostać uwzględnione w wymaganiach projektowych, i faktyczne kodowanie przypadków krawędzi (radzenie sobie z niepoprawnymi danymi wejściowymi, ciągłe iterowanie list, gdy zbiór wartości byłby bardziej sensowny pod względem prędkości, gdy zbiór staje się większy niż x itp.), które są czymś, o czym po prostu musisz się nauczyć.

— Ed James

Dziękuję za wgląd. Naprawdę to doceniam. Masz rację tutaj na wszystkich frontach, chociaż jestem ciekawy, czy jest świetną osobą, ale brakuje mu czegoś, co sprawia, że wspaniali inżynierowie są wspaniali, jak mogę w dalszym ciągu zlecać mu wykonywanie innych zadań i utrzymywać go w organizacji, być może przeprowadzka do innej drużyny czy coś w tym stylu… Chyba tylko mogę odpowiedzieć na to pytanie :)

— Alex N.

Myślałem o tym, ale nie jestem pewien. Inna rola, aby stać się akceptowalną dla tego rodzaju osób, nie powinna wymagać zwracania uwagi na szczegóły i nie ma ich wielu w firmie produkującej oprogramowanie.

Świat nie jest tak czarny i biały, jak sugeruje twoje pierwsze zdanie. Sądzę, że istnieją programiści, którzy potrafią zidentyfikować niektóre przypadki krawędzi, ale nie wszystkie.

— Mike Partridge

5

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

— PSU_Kardi
źródło

4

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

— Kevin Cline
źródło

3

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.

— JB King
źródło

3

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ę.

— Koder
źródło

# zdefiniować PRAWDZIWĄ FAŁSZ nie jest przewagą, jest przestępstwem zwolnienia.

— gnasher729

1

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.

— Bronumski
źródło

Zawsze są przypadki krawędzi. Jeśli ktoś twierdzi, że przypadki brzegowe nigdy nie zostaną napotkane, nie są to przypadki właściwe brzegowe.

— Barry Brown

1

@Barry Brown Zgadzam się, że zawsze są przypadki skrajne, ale istnieje różnica między ważnymi przypadkami skrajnymi, które interesariusze uznają za ważne, które możemy nazwać scenariuszami i przypadkami skrajnymi, które deweloper uważa za ważne. Jeśli interesariusz uważa, że coś jest ważne, należy to omówić na sesji planowania i dołączyć jako scenariusz do historii użytkownika, a deweloper nie powinien o tym myśleć, powinno to stanowić odpowiedni wymóg wobec zadania. Jest to bardzo czasochłonne i nie jest konieczne sprawdzanie wartości zerowych parametrów dla każdej niepublicznej metody.

— Bronumski

1

Ł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.

— Morgan Herlocker
źródło

1

To naprawdę nie jest właściwa odpowiedź. Nagradzanie za pracę o niskiej jakości stanowi złą praktykę. Zespół programistów powinien jako całość odpowiadać za pracę wysokiej jakości.

— David

Przyzwoity programista nie musi szukać skrzynek. Część kodu jest napisana, więc nie ma przypadków krawędzi, w innych przypadkach przypadki krawędzi są oczywiste. Kod nieobsługujący przypadków skrajnych jest niekompletnym kodem.

— gnasher729

0

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.

— Billal Begueradj
źródło