Robię 4-5 razy więcej punktów fabularnych niż przeciętnie, ale produkuję błędy o połowę szybciej. Wykresy mówią, że to 2x więcej błędów, jak sobie z tym poradzić?

Dlatego ogólnie przyjmuje się, że programiści najwyższego poziomu mogą wytwarzać kod o rząd wielkości większy / lepszy niż ich bardziej przeciętni rówieśnicy.

Powszechnie przyjmuje się również, że częstotliwość błędów w kodzie jest stosunkowo stała dla programistów.

Zamiast tego mają na nią wpływ procesy używane podczas pisania kodu i po napisaniu kodu . (Jak rozumiem) Ludzie mają tendencję do popełniania błędów w dość stałym tempie - lepsi programiści zauważają ich więcej i szybciej je naprawiają.

• Zauważ, że oba powyższe twierdzenia pochodzą z Code Complete autorstwa Steve'a McConnella - więc nie jest to kwestia różnych perspektyw.

Ostatnio zacząłem to widzieć w moim kodzie. Potrafię wydobyć około 4-5 razy więcej kodu niż wielu moich rówieśników (mierzonych przez punkty fabularne oszacowane przez zespół), o wyższej jakości (na podstawie wskaźników wydajności i liczby zmian wprowadzonych po odprawie). Ale wciąż popełniam błędy. Pomiędzy lepszymi testami jednostkowymi, lepszym zrozumieniem tego, co robi kod i lepszym okiem na problemy podczas recenzji kodu, nie produkuję 4-5 razy więcej błędów.

Nadal jednak produkuję około dwa razy więcej błędów wykrytych przez QA niż innych programistów w moim zespole. Jak można sobie wyobrazić, powoduje to pewne problemy z nietechnicznymi ludźmi wykonującymi pomiary metryczne (czytaj: mój szef).

Próbowałem wskazać, że produkuję błędy o połowę szybciej niż moi rówieśnicy (i naprawiam dwa razy więcej), ale jest to trudna sprzedaż, gdy są wykresy wskazujące, że produkuję dwa razy więcej błędów.

Jak więc poradzić sobie z faktem, że wzrost wydajności doprowadzi do zwiększenia liczby błędów?

Myślę, że mieszasz swoje obawy. Po twojej stronie nie ma nic , co musisz zmienić.

Wydajność jest wskazówką, jak szybko projekt zostanie ukończony. Kierownicy projektów i wszyscy inni lubią wiedzieć, kiedy projekt zostanie zrealizowany. Wyższa lub szybsza wydajność oznacza, że ​​zobaczymy, że projekt zostanie zrealizowany wcześniej.

Wskaźnik błędów nie jest związany z produktywnością, ale raczej z rozmiarem projektu. Na przykład możesz mieć Nbłędy w Yliniach kodu. W obrębie tej metryki nie ma nic, co mówi (lub obchodzi!), Jak szybko napisane są te wiersze kodu.

Aby to połączyć, jeśli masz wyższą produktywność, tak, „zobaczysz”, że błędy są pisane szybciej. Ale i tak miałeś mieć taką liczbę błędów, ponieważ jest to związane z rozmiarem projektu.

Co więcej, wyższa produktywność oznacza, że ​​będziesz mieć więcej czasu na zakończenie projektu, aby wyłapać te błędy lub deweloper będzie szybciej znajdował błędy, które stworzyli. ¹

Aby zająć się bardziej osobistymi aspektami pytania.

Jeśli twój szef bacznie obserwuje liczbę błędów, które produkujesz, a nie liczbę błędów, które popełnisz, sesja edukacyjna jest w porządku. Liczba utworzonych błędów nie ma znaczenia bez wskaźnika wsparcia.

Aby maksymalnie wykorzystać ten przykład, powiedz swojemu szefowi, że chcę podwoić twoje wynagrodzenie. Dlaczego? Nie stworzyłem absolutnie żadnych błędów w twoim projekcie i dlatego jestem znacznie lepszym programistą niż ty. Co? Będzie miał problem z tym, że nie stworzyłem ani jednego wiersza kodu na korzyść twojego projektu? Ach Teraz rozumiemy, dlaczego stawka jest ważna.

Wygląda na to, że Twój zespół ma dane do oceny błędów na punkt historii. Jeśli nic więcej, to lepsze niż mierzenie przez liczbę utworzonych błędów. Twoi najlepsi programiści powinni tworzyć więcej błędów, ponieważ piszą więcej kodu. Niech twój szef wyrzuci ten wykres lub przynajmniej rzuci za nim kolejną serię pokazującą, ile punktów fabuły (lub jakiejkolwiek wartości biznesowej mierzysz) obok liczby błędów. Ten wykres opowie dokładniejszą historię.

¹ _{Ten szczególny komentarz przyciągnął o wiele więcej uwagi niż zamierzano. Więc bądźmy trochę pedantyczni (zaskoczenie, wiem) i skupmy się na tym pytaniu.}

_{Podstawą tego pytania jest to, że menedżer patrzy na niewłaściwe rzeczy. Patrzą na surowe sumy błędów, kiedy powinni patrzeć na szybkość generowania w porównaniu z liczbą wykonanych zadań. Nie miejmy obsesji na punkcie mierzenia się z „liniami kodu”, punktami fabularnymi, złożonością lub czymkolwiek innym. To nie jest pytanie, a te obawy odwracają uwagę od ważniejszego pytania.}

_{Jak wskazano w linkach PO, można przewidzieć pewną liczbę błędów w projekcie wyłącznie na podstawie wielkości samego projektu. Tak, możesz zmniejszyć tę liczbę błędów poprzez różne techniki programowania i testowania. Znów nie o to chodziło w tym pytaniu. Aby zrozumieć to pytanie, musimy zaakceptować fakt, że w przypadku projektu o określonej wielkości i metodologii rozwoju zobaczymy określoną liczbę błędów, gdy programowanie zostanie „zakończone”.}

_{Wróćmy więc w końcu do tego komentarza, który niektórzy całkowicie źle zrozumieli. Jeśli przydzielisz dwóm programistom zadania o porównywalnej wielkości, programista o wyższym wskaźniku wydajności wykona swoje zadanie przed drugim. Bardziej produktywny programista będzie miał zatem więcej czasu na końcu okna programowania. Ten „dodatkowy czas” (w porównaniu z innym programistą) można wykorzystać na inne zadania, takie jak praca nad defektami, które będą przenikać przez standardowy proces programowania.}

_{Musimy przyjąć OP na słowo, że są bardziej wydajni niż inni programiści. Nic w tych twierdzeniach nie sugeruje, że OP lub inni bardziej produktywni programiści są wulgarni w swojej pracy. Wskazanie, że błędów byłoby mniej, gdyby spędzili więcej czasu na tej funkcji lub zasugerowanie, że debugowanie nie jest częścią tego czasu rozwoju, pomija to, o co poproszono. Niektórzy programiści są szybsi od innych i wykonują prace porównywalne lub lepszej jakości. Ponownie zobacz linki, które OP podaje w swoim pytaniu.}

Poświęć trochę dodatkowego czasu na czyszczenie, polerowanie i testowanie kodu. Nadal będą błędy, ale będzie ich mniej. To wymaga czasu. Twój wskaźnik wyjściowy kodu spadnie, ale Twój wynik bezbłędny wzrośnie, co przełoży się na lepszą wydajność. Ponieważ błędy są drogie.

Czy potrafisz trzymać kod w oddziale lub środowisku testowym, dopóki go nie przekopiesz i nie złapiesz więcej błędów? Błędy w gałęzi generalnie powodują mniej fal niż błędy w kodzie produkcyjnym.

Ale nie do końca przekopuję twoje twierdzenia, prowadząc do twojego pytania. Być może twój szef też nie jest.

Nie sądzę, że każdy koder powoduje taki sam poziom błędów. Twój drugi link jest w zasadzie całkowicie nie na temat, ponieważ porównuje różne języki, a nie różne poziomy umiejętności programisty. Kompletny kod wspomina o niektórych pomiarach z dużą próbką, które dotyczą procesu, a nie umiejętności programistów. A kiedy mówią, że kodery najwyższego poziomu produkują więcej / lepszy kod, oznacza to, że ma mniej błędów. Zależy od aplikacji. Tak, myślę, że to kwestia innej perspektywy.

Ostatecznie jednak, jeśli szef chce czystszego kodu, daj mu czystszy kod.

Wyjdę na kończynę i będę adwokatem diabła. Nie oznacza to, że nie sympatyzuję z twoją trudną sytuacją, ale cóż, moja sympatia ci nie pomoże. Pozwólcie, że dodam do perspektywy Philipa :

Twój szef dba o jakość produktu, częściowo dlatego , że jego nazwa i reputacja będą z nim związane. Częścią jakości jest postrzegana ilość błędów . Jeśli sprzedajesz niesamowite wiertło, które wierci cztery razy szybciej niż jakiekolwiek konkurencyjne wiertła, ale także psuje się dwa razy częściej, będziesz miał złą reputację. Nawet jeśli można argumentować, że wiertło działa lepiej, ludzie przyzwyczajają się do prędkości, ale zapamiętają awarie.

Z perspektywy czasu większości błędów można oczywiście zapobiec. Gdybyś tylko był trochę bardziej ostrożny, twój szef poczuje, możesz uniknąć tych problemów i wszelkich niezbędnych porządków. Z jego punktu widzenia jest to trywialna, sensowna rzecz, o którą należy zapytać, a wszelkie argumenty, które o to robisz, nie będą działać i sprawią, że będziesz wyglądać źle.

Nie może zmierzyć twojej najwyższej wydajności. Twierdzisz, że produktywność jest wyższa na podstawie weryfikowalnych danych, więc co sądzą o tym twoi koledzy? Czy zgadzają się, być może niechętnie, że jesteś bardziej produktywnym programistą, czy jesteś według ciebie sam? Zrobisz silniejszy punkt, jeśli będziesz popierać swoje twierdzenia innymi ludźmi.

To z perspektywy. Jak sobie radzisz z „naprawianiem” tej frustrującej sytuacji?

Zwolnij trochę. Wyraźnie wspomnij o tym, kto dystrybuuje zadania, które spróbujesz obniżyć wskaźnik błędów (*), aby nie zaskoczyły cię mniejsze spożycie. Jeśli już, spowolnienie zmniejszy liczbę błędów przypisanych do ciebie z powodu braku podaży.

_{(*) Istnieje różnica między, z jednej strony, uznaniem, że w twoim nazwisku występują błędy i że spróbujesz zmniejszyć tę kwotę, a z drugiej strony, przyznaniem, że masz za dużo błędów w swoim imieniu i powinieneś podjąć działanie.}

Nie próbuj przekonywać swojego szefa, ponieważ to nie zadziała. Znów nie oznacza to, że musisz przyznać się do sedna; możesz przedstawić kontrapunkt i podtrzymać swoją opinię, nie odrzucając jego obaw. Ponieważ jeśli argumentujesz, o co ci chodzi i nie możesz w zadowalający sposób udowodnić swojej wyższej wydajności (a nawet jeśli możesz), ryzykujesz obrażeniem swoich kolegów lub pozornym lekceważeniem ich. Nie chcesz być tym facetem .

Zakładając, że wyprodukujesz taką samą „ilość” kodu jak twoi koledzy w 20% ich czasu, możesz wydać 4 razy więcej na naprawdę debugowanie kodu i uczynienie go idealnym, co jeszcze bardziej zmniejszy twój wskaźnik błędów. Wtedy możesz nazwać się dobrym programistą.

Największe pytanie brzmi: dlaczego kodujesz 5 razy więcej niż inne, zamiast dążyć do jakości. Czy to jest coś, co dyktuje ci twoje ego, czy może twój szef cię zmusza?

Musisz także wziąć pod uwagę koszty naprawy błędu. Gdy znajdziesz go wcześnie, wciąż możesz znajdować się „wewnątrz” kodu, aby go szybko naprawić. Jeśli pojawi się dopiero po kolejnym miesiącu programowania, może być trudno znaleźć, a nawet zmusić cię do zmiany dużych części już zaprogramowanego kodu.

Wygląda na to, że masz umiejętności tworzenia kodu i możesz sprawić, że będzie to niesamowite, jeśli skupisz się na jakości zamiast na szybkości. Spróbuj przez chwilę, zgaduję, że ci się spodoba.

Następnym problemem jest zdobycie potwierdzenia (mówienie o pieniądzach) dla lepszej wydajności. Porozmawiaj z szefem i zapytaj go, jak postępować, w końcu to jego firma i pieniądze, a jeśli chce, abyś produkował mniej błędów, powinien również zdecydować, w jaki sposób to się stanie.

Deweloperzy mogą być bystrzy, a nawet genialni, z umiejętnością rozumienia i kodowania solo, nie będąc DOBRYMI programistami. Dobry programista tworzy wysokiej jakości pracę i ulepsza cały projekt.

Nie mówię, że to ty, ale jeden z najbardziej frustrujących programistów, z którymi kiedykolwiek pracowałem, napisał więcej kodu niż ktokolwiek w zespole, a mieliśmy dobrych ludzi w zespole. Śledziliśmy zatwierdzenia za pomocą oprogramowania rankingowego, więc dla niektórych osób była to prawie konkurencja. Wyrzucał pokosy kodu, pozostawiając za sobą dokumentację ZERO, nieprzeniknione lasy, i tak naprawdę utrudnił mi zrozumienie części własnego kodu (mogę to zrobić sam, dziękuję bardzo!). W końcu prawie wykoleił projekt, ponieważ stał się show jednoosobowym. Ludzie nie mogli za nim podążać. Nie byliśmy zsynchronizowani jako zespół. Kilka lat później przepisaliśmy niektóre z jego funkcji, aby odzyskać łatwość konserwacji.

Chciałem od niego zwolnić i spędzić więcej czasu: 1) Poprawić jakość bazy kodów 2) Komunikować się z zespołem 3) Pracować nad rzeczami, które pomogły innym, a także pomóc mu ukończyć funkcje / historie 4) Naprawianie robaki

Nie zgadzam się z pomiarem produktywności za pomocą wierszy kodu, ale jest to kluczowa miara. Czy twój licznik kodu zawiera komentarze? Jeśli tak, istnieje prosty sposób na utrzymanie wyjścia liniowego przy jednoczesnym zmniejszeniu „wskaźnika błędów”; po prostu zwiększ jakość i ilość pisanych komentarzy. Komentarze rzadko zawierają błędy (choć mogą) i ogólnie nie mamy wystarczającej jakości komentarzy. Ja nie akceptowanie kodu-inflację, ale akt komentowania jest jak mini przeglądu kodu, zmusza uważasz, Refactor i poprawić.

Próba oświecenia zarządzania nie jest początkowa. Jest stary klisz: „Czy uwierzysz mi czy swoim kłamliwym oczom?” To, co dotyczy twoich szefów, to liczba błędów. Żadna racjonalizacja nie powie im, że jest to do przyjęcia. To ponad dwa razy bardziej ryzykowne. Ponadto nie tylko ty masz wpływ na liczbę błędów. Kontrola jakości ma dwa razy więcej pracy, niż próbowanie zidentyfikowania twoich błędów, więc zarząd będzie chciał, abyś robił ich mniej.

Najlepszym rozwiązaniem jest zmniejszenie liczby błędów, które produkujesz , kropka. Zarządzanie będzie nie tylko szczęśliwsze, ale i Ty. Nie ty Bo jestem całkiem pewny, jak lubisz chluby ty prześcignąć swoich współpracowników o współczynnik cztery, chcesz kochać znaczy zrobić to czyni tę samą liczbę, lub nawet mniej błędów niż robią.

Jak już wspomniałeś, „… na liczbę błędów popełnionych w kodzie… mają wpływ procesy stosowane podczas pisania kodu i po jego napisaniu”. Jeśli chcesz zmienić częstotliwość, z jaką produkujesz błędy, będziesz musiał zmienić procesy używane do pisania kodu.

Programiści używają metod produkcji do tworzenia kodu, podobnie jak linia montażowa używa metod do produkcji masowo produkowanych obiektów. Okej, praktyki branży oprogramowania są bardziej jak drobne bibeloty z gałęzi znalezionych w lesie. Ale ponieważ produkujemy maszyny, powinniśmy stosować ten sam rygor i dyscyplinę, co w przypadku szybkich maszyn masowej produkcji.

Obejmuje to te same techniki, które są stosowane w masowej produkcji w celu zmniejszenia wskaźnika defektów: analiza przyczyn źródłowych w celu ustalenia, dlaczego błędy są robione, i zmiana procesu, aby nie były. A przynajmniej złapiesz, zanim zrobi to kontrola jakości.

1. Zrób listę swoich błędów. Prawdopodobnie masz już jeden dzięki chłopakom z QA. Prawdopodobnie też podzielone na kategorie. Rodzaj błędu, ważność, punkt, w którym błąd został wstrzyknięty do kodu itp.

2. Wybierz największą kategorię błędów. Ponieważ Twój wolumen jest tak wysoki, najpierw powinieneś wybrać tę kategorię. Inne kategorie obejmują te najłatwiejsze do znalezienia i te najłatwiejsze do wykonania.

3. Wiedząc, gdzie te błędy są wprowadzane do kodu, przyjrzyj się wprowadzaniu zmian na tym etapie (i wcześniejszych), które zapobiegną występowaniu tych błędów, oraz sposobom na łatwiejsze ich złapanie na tym etapie.

4. Pamiętaj, aby zapoznać się z przypadkami niezwiązanymi z programowaniem, ponieważ mogą one mieć wpływ na jakość Twojej pracy. Muzyka w tle, przerwy, posiłki, zbyt długa praca bez przerwy, głód itp.

To, co znajdziesz, może spowolnić. Z drugiej strony może pomóc Ci produkować jeszcze szybciej, ponieważ będziesz musiał mniej przerabiać rzeczy, które już masz za sobą. W rzeczywistości czterokrotnie więcej kodu nie jest bliskie bycia o rząd wielkości lepszym od współpracowników, więc zmiana procesu jest zdecydowanie najlepszym rozwiązaniem.

Zmień swój cel, od produkowania największej liczby kodów do pomocy firmie w dalszym rozwoju.

Ponieważ wygląda na to, że masz wielu współpracowników i dodatkowy czas, największy wpływ na szybsze dostarczanie funkcji i poprawianie błędów ma pomoc kolegom.

Pomóż swoim kolegom przez

• korzystanie z recenzji kodu w celu poprawy jakości kodu i edukacji.
• tworzenie automatyzacji procesów, aby ich praca była szybsza, a ich życie łatwiejsze.
• pisząc z nimi lepsze testy
• atakowanie kodu technicznego w celu ulepszenia bazy kodu
• bycie facetem, który jest zawsze dostępny, aby pomagać innym.
• pisanie / ulepszanie narzędzi, które pomagają zwiększyć produktywność programistów
• uzasadnienie zarządzania lepszymi narzędziami / sprzętem / warunkami pracy dla współpracowników, jeśli masz więcej siły.
• przygotowywanie i prowadzenie sesji edukacyjnych na temat pisania lepszego kodu.
• praktykowanie pokory

Jak więc poradzić sobie z faktem, że wzrost wydajności doprowadzi do zwiększenia liczby błędów?

Twój szef jest jedyną osobą, która może odpowiedzieć na to pytanie w twoim przypadku. Porozmawiaj z nim, wskaż lepszy stosunek i pozwól mu zdecydować. Jeśli jego decyzja nie ma sensu, nadszedł czas, aby poszukać firmy o swoim sposobie myślenia.

Jako profesjonalista powinieneś być w stanie pracować z dowolnymi warunkami klienta, po prostu upewnij się, że rozumieją konsekwencje. Ładna tabela błędów / historii może pomóc twojemu szefowi zrozumieć, ile spadnie twoja produktywność, jeśli poświęcisz trochę czasu na wyprodukowanie mniej błędów.

Musisz także wziąć pod uwagę następujące punkty:

• złożoność historii, na przykład proste owijarki getter / setter kontra obliczenia statystyczne lub programowanie w czasie rzeczywistym, a nawet statystyki w czasie rzeczywistym ...
• dotkliwość błędów, czy to małe literówki na polach tekstowych lub błędne wyniki obliczeń, program ulega awarii
• koszt naprawy błędów, zarówno jeśli robisz to teraz, później, jak i jeśli ktoś inny musi zrozumieć Twój kod, ponieważ odszedłeś

Sytuacja polega na tym, że pracujesz cztery razy szybciej niż przeciętny programista, ale popełniasz dwa razy więcej błędów w danym czasie. W stosunku do ilości pracy, którą wykonujesz, w rzeczywistości popełniasz PÓŁ błędów tyle, ile „przeciętnych”.

Możesz spróbować wskazać swoje niskie błędy w stosunku do pracy, a nawet błędy w gotowym produkcie (które możesz wykonać w jednej czwartej normalnego czasu). Większość szefów to zaakceptuje.

Jest kilku bossów, którzy tego nie zrobią, ponieważ pracują z umysłem „tolerowania” błędów na raz. Następnie możesz spowolnić tempo pracy, wykonując dwa razy więcej pracy niż przeciętnie w danym czasie i popełniając te same (lub mniej) błędy, ponieważ masz więcej czasu na sprawdzenie swojej pracy.

Jeśli twój szef chce, abyś poprawił jakość swojej pracy, to popraw jakość swojej pracy.

Powinieneś dążyć do zera błędów, a nie produkować tylko dwa razy więcej niż kolejny najlepszy programista.

Powinieneś powiedzieć swojemu szefowi, że mierniki, których używa, są dość wadliwe. Jeśli spojrzysz na obroty strażników w NBA, przekonasz się, że mają oni zwykle większą liczbę niż napastnicy. Ale to dlatego, że lepiej trzymają piłkę. Jeśli nierozstrzygający strażnik zagrywa 1/5 tyle co strażnik początkowy i obraca piłkę ponad 3 razy średnio .vs. Strażnik początkowy, który obraca piłkę ponad 7 razy na mecz - na pierwszy rzut oka może się wydawać, że gorszy jest Straż początkowa. Ale jeśli podzielisz liczbę obrotów przez liczbę rozegranych minut, to wyraźnie, że początkowy strażnik ma znacznie lepsze liczby na podstawie rozegranych minut.

Podobnie, masz znacznie lepsze liczby, jeśli liczba błędów jest podzielona przez liczbę ukończonych punktów opowieści. Tak właśnie chciałbym zaproponować twojemu kierownikowi. Zmień metrykę na liczbę błędów podzieloną przez ukończone punkty historii lub przynajmniej dodaj nową metrykę, jeśli potrzebna jest całkowita liczba błędów na programistę. Ale ponieważ niektóre punkty opowieści są znacznie trudniejsze i bardziej złożone niż inne punkty opowieści, może i będzie istniała dość duża wariancja, co również musi zostać wzięte pod uwagę przez kierownika.

To, co nie uważam, że powinieneś zrobić, to zwolnić.

Zmierz wartość dodaną

Argumentuj, że tak naprawdę liczy się wartość, którą dodajesz. Następnie idź i wprowadź przybliżony (ręczny) pomiar tego:

• Oszacuj wartość produkowanej funkcjonalności
• Odejmij swoją pensję
• Odejmij szacunkowy koszt swoich błędów (przynajmniej koszt ich naprawy)
• Odejmij szacunkowy koszt wszystkich innych zadłużeń technicznych, które produkujesz

Pozostała część stanowi twoją wartość dodaną. Podobnie dla wszystkich innych.

Szacunki te są trudne, ale nawet przybliżone mogą mieć sens. Sam proces omawiania tych szacunków jest przydatny dla zespołu i projektu.

Najlepsi programiści mają tendencję do pisania bardzo regularnego kodu, który jest łatwy do debugowania i zrozumienia, wykorzystują dostępne narzędzia (analiza statyczna, błędy kompilatora, kod debugowania) do maksimum. Również najlepsi programiści już nauczyli się wartości testowania jednostkowego poprzez swoje własne trudne doświadczenie.

Więc chociaż początkowa liczba problemów na linię jest taka sama, problemy są usuwane szybciej.