Я заробляю на 4-5 разів більше очок історії, ніж середній показник, але створюю помилки на половині ставки. Графіки кажуть, що це 2 рази більше помилок, як з цим боротися?

Тому загальновизнано, що програмісти верхнього рівня можуть виробляти на порядок більше / кращий код, ніж їхні середні однолітки.

Загальновизнано також, що частота помилок, допущених у коді, є відносно постійною для програмістів.

Натомість на неї впливають процеси, що використовуються при написанні коду та після написання коду . (Наскільки я це розумію) Люди схильні робити помилки з досить постійною швидкістю - кращі програмісти просто помічають більше з них і швидше їх виправляють.

• Зауважте, що обидві вищезазначені твердження походять від Code Complete від Steve McConnell - тому справа не в тому, щоб розглянути різні точки зору.

Тому я нещодавно почав бачити це у своєму коді. Я можу приблизно приблизно в 4-5 разів збільшити кількість кодів, як і багато моїх однолітків (вимірюється балами історії, оціненими командою), з більш високою якістю (на основі показників ефективності та кількості змін, внесених після реєстрації). Але я все одно помиляюся. Між кращими тестовими одиницями, кращим розумінням того, що робить код, і кращим оглядом для питань, коли роблю огляди коду, я не отримую 4-5 разів кількість помилок.

Але я все-таки випускаю приблизно вдвічі більше помилок, знайдених QA, ніж інші розробники в моїй команді. Як ви можете собі уявити, це спричиняє деякі проблеми з нетехнічними людьми, які роблять метричні вимірювання (читайте: мій начальник).

Я намагався зазначити, що я створюю помилки з половиною швидкості моїх однолітків (і виправляю вдвічі більше), але це важко продати, коли є графіки, які говорять про те, що я створюю вдвічі більше помилок.

Отже, як боротися з тим, що підвищення продуктивності призведе до збільшення кількості помилок?

Я думаю, ви змішуєте свої проблеми. І нічого з вашого боку не потрібно змінювати.

Продуктивність - це натяк на те, як швидко проект буде завершений. Керівники проектів і всі інші хочуть знати, коли проект буде здійснено. Більш висока чи швидша продуктивність означає, що ми швидше реалізуємо проект.

Кількість помилок не пов'язана з продуктивністю, а швидше з розміром проекту. Наприклад, у вас можуть бути Nпомилки в Yрядках коду. У цьому показнику немає нічого, що говорить (або піклується!) Про те, як швидко записуються ці рядки коду.

Щоб зв’язати це разом, якщо ви маєте більшу продуктивність, так, ви швидше "побачите", що помилки записуються. Але ви все одно матимете таку кількість помилок, оскільки вона прив’язана до розміру проекту.

Якщо що-небудь, то вища продуктивність означає, що ви будете мати більше часу в кінці проекту на пошук цих помилок, або розробник буде швидше знаходити створені вами помилки. ¹

Щоб вирішити більш особисті аспекти вашого питання.

Якщо ваш начальник суворо дивиться на кількість помилок, які ви створюєте, на відміну від кількості помилок, які ви виробляєте, навчальний сеанс в порядку. Кількість створених помилок безглуздо без резервного копіювання.

Щоб взяти цей приклад до крайності, скажіть, будь ласка, своєму начальникові, що я хочу подвоїти вашу зарплату. Чому? Я не створив жодних помилок у вашому проекті, тому я набагато кращий програміст, ніж ви. Що? У нього виникне проблема, що я не створив жодного рядка коду на користь вашого проекту? Ага. Тепер ми зрозуміли, чому важлива ставка.

Схоже, ваша команда має показники для оцінки помилок за точкою історії. Якщо нічого іншого, це краще, ніж вимірювати необробленою кількістю створених помилок. Ваші найкращі розробники повинні створювати більше помилок, оскільки вони пишуть більше коду. Запропонуйте вашому начальникові викинути цей графік або принаймні кинути за ним ще одну серію, де відображається кількість точок історії (або будь-якої ділової вартості, яку ви вимірюєте) разом із кількістю помилок. Цей графік розповість більш точну історію.

¹ _{Цей конкретний коментар привернув набагато більше уваги, ніж було призначено. Тож давайте будемо трохи педантичні (сюрприз, я знаю) і відновіть нашу увагу на цьому питанні.}

_{Корінь цього питання полягає в тому, що менеджер дивиться на неправильні речі. Вони дивляться на загальну кількість помилок, коли вони повинні дивитися на швидкість генерації та кількість виконаних завдань. Давайте не будемо нав’язуватися щодо вимірювання "рядків коду" чи сюжетних точок, складності чи будь-чого іншого. Це не питання, і ці турботи відволікають нас від важливішого питання.}

_{Як зазначено в посиланнях ОП, ви можете передбачити певну кількість помилок у проекті виключно за розміром проекту. Так, ви можете зменшити цю кількість помилок за допомогою різних методик розробки та тестування. Знову ж, це було не в цьому питанні. Щоб зрозуміти це питання, нам потрібно погодитись, що для конкретного проекту та методології розробки ми побачимо задану кількість помилок, як тільки розробка буде "завершеною".}

_{Тож давайте, нарешті, повернемось до цього коментаря, який кілька повністю не зрозуміли. Якщо ви присвоїте завдання порівняно великого розміру двом розробникам, розробник з більшою швидкістю продуктивності виконає своє завдання перед іншим. Тому більш продуктивний розробник матиме більше часу в кінці вікна розробки. Цей "додатковий час" (порівняно з іншим розробником) може бути використаний для інших завдань, таких як робота над дефектами, які виникнуть через стандартний процес розробки.}

_{Ми маємо сприймати ОП, що вони більш продуктивні, ніж інші розробники. Ніщо в рамках цих заяв не означає, що ОП або інші більш продуктивні розробники просуваються у своїй роботі. Вказуючи, що помилок буде менше, якби вони витратили більше часу на функцію або припустили, що налагодження не є частиною цього часу розробки, пропускає запитання. Деякі розробники швидше за інших і виробляють порівнянні або якісніші роботи. Ще раз дивіться посилання, які ОП викладає у своєму питанні.}

Витратьте частину додаткового часу на чищення, полірування та тестування вашого коду. Помилки ще будуть, але їх буде менше. На це потрібен час. Швидкість виводу коду знизиться, але вихід без помилок на код збільшиться, а це призведе до підвищення продуктивності. Бо клопи дорогі.

Чи можете ви зберегти свій код у гілці чи тестовому середовищі, поки не натиснете його та не наздоженете більше помилок? Помилки у гілці зазвичай викликають менше хвиль, ніж помилки у виробничому коді.

Але я не точно копаю ваші твердження, що ведуть до вашого питання. І, можливо, і твій начальник не такий.

Я не думаю, що кожен кодер видає однакову кількість помилок. Ваше друге посилання насправді зовсім поза темою, оскільки воно порівнює різні мови, а не різні рівні навичок кодера. Повний код згадує деякі великі вибіркові вимірювання, які дивляться на процес, а не на майстерність кодерів. І коли вони кажуть, що кодери верхнього рівня виробляють більше / кращий код, частина цього означає, що в ньому менше помилок. Залежить від програми. Так, так, я думаю, що це питання різної точки зору.

Зрештою, якщо начальник хоче більш чистий код, дайте йому чистіший код.

Я вийду на кінцівку і буду захисником диявола. Це не означає, що я не співчуваю твоєму становищу, але, ну, моя співчуття не допоможе тобі. Тож дозвольте мені додати до точки зору Філіпа :

Ваш начальник піклується про якість товару, частково тому, що його ім'я та репутація будуть пов'язані з ним. Частиною якості є сприйнята кількість помилок . Якщо ви продасте дивовижне свердло, яке свердлить у чотири рази швидше, ніж будь-яке конкуруюче свердло, але також виходить з ладу вдвічі частіше, у вас буде погана репутація. Навіть якщо сперечається, що свердло працює краще, люди звикають до швидкості, але вони запам'ятають поломки.

За оглядом більшість помилок, очевидно, можна запобігти. Якби ви були трохи обережнішими, ваш начальник почуватиметься, ви могли б уникнути цих проблем та будь-якої необхідної прибирання. З його точки зору, це дрібниця, чутлива справа, і будь-яке сперечання, що ви робите з цього приводу, і не буде працювати, і змусить вас виглядати погано.

Він не може виміряти вашу чудову продуктивність. Ви стверджуєте, що вища продуктивність ґрунтується на метриці, яку можна перевірити, і як ваші колеги ставляться до цього? Чи згодні вони, мабуть, з крихіткою, що ви більш продуктивний програміст, чи ви самотні на вашу думку? Ви зробите більш вагомий момент, якщо у вас будуть інші люди, які підкріплюють ваші твердження.

Це на перспективу. Тепер, як ви йдете про «виправлення» цієї розчарованої ситуації, в якій ви знаходитесь?

Трохи сповільнюйся. Явно згадуйте того, хто поширює завдання, які ви намагаєтесь знизити рівень помилок (*), щоб вони не здивували вашому меншому споживанню. Якщо що-небудь, уповільнення зменшить кількість помилок, призначених вам через нестачу пропозиції.

_{(*) Існує різниця між тим, що, з одного боку, визнає, що у вашому імені є помилки, і ви спробуєте зменшити цю суму, а з іншого - визнати, що у вашому імені занадто багато помилок і слід вжити заходів.}

Не намагайтеся переконувати свого начальника, бо це не вийде. Знову ж таки, це не означає, що ви повинні поступатися своєю точкою; ви можете представити контрапункт і утримувати свою думку, не відкидаючи його занепокоєння. Тому що якщо ви все-таки сперечаєтесь з цим і не зможете задовільно довести свою чудову продуктивність (і навіть якщо зможете), ви ризикуєте образити своїх колег або виявите їх зневажливими. Ви не хочете бути таким хлопцем .

Якщо припустити, що ви створили б таку ж "кількість" коду, що і ваші колеги, за 20% свого часу, ви могли витратити в 4 рази більше на дійсну налагодження коду та зробити його ідеальним, що ще більше знизить ваш рівень помилок. Тоді ви могли б назвати себе хорошим програмістом.

Найбільше питання - чому ви кодуєте в 5 разів більше, ніж інші, а не прагнете до якості. Це щось, що вам диктує ваше его або чи примушує вас ваш начальник?

Також потрібно врахувати витрати на виправлення помилки. Коли ви знайдете його рано, можливо, все ще будете "всередині" коду, достатнього, щоб швидко його виправити. Якщо вона з’явиться лише через ще один місяць розробки, може бути важко знайти або навіть змусити вас змінити великі частини вже запрограмованого коду.

Здається, у вас є набір навичок для створення коду, і ви могли б зробити його приголомшливим, якщо зосередити увагу на якості замість швидкості. Спробуйте деякий час, я думаю, вам це сподобається.

Наступною проблемою є отримання визнання (говорити гроші) за кращу роботу. Порадьтеся з вашим начальником і запитайте його, як діяти, адже це його компанія і гроші, і якщо він хоче, щоб ви робили менше помилок, він також повинен вирішити, яким чином це відбувається.

Розробники можуть бути яскравими, навіть геніальними, здатними до розуміння та кодування соло, не будучи ДОБРИМ розробниками. Хороший розробник створює якісну роботу і робить весь проект кращим.

Я не кажу, що це ви, але один із найстрашніших програмістів, з якими я коли-небудь працював, написав більше коду, ніж хтось із команди, і в нас були хороші люди. Ми відстежували комісії за допомогою рейтингового програмного забезпечення, тому для деяких людей це було майже конкуренцією. Він викручував частинки коду, залишаючи після себе документацію про ZERO, непрохідні ліси, а насправді важко зрозумів мені якийсь власний код (я можу це зробити самостійно, дуже дякую!). Врешті-решт, він майже зірвав проект, тому що став шоу для чоловіків. Люди не могли слідувати за ним. Ми не були синхронними як команда. Ми фактично переписали деякі його особливості через роки, просто щоб відновити ремонтопридатність.

Я хотів від нього сповільнити та витратити більше часу: 1) Покращення якості кодової бази 2) Спілкування з командою 3) Робота над речами, які допомогли іншим, а також допомогти йому закінчити функції / історії 4) Виправлення клопи

Я не згоден з вимірюванням продуктивності за рядками коду, але це ключовий показник. Чи містить ваш лічильник кодів коментарі? Якщо це так, є простий спосіб зберегти вихідну лінію, зменшивши при цьому "коефіцієнт помилок"; просто підвищити якість та кількість написаних коментарів. У коментарях рідко є помилки (хоча вони можуть), і загалом у нас недостатньо якісних коментарів. Я не поблажую інфляцію коду, але акт коментування - це як огляд міні-коду, він змушує задуматися, відкоригувати та вдосконалити.

Спроба освітити управління - це неперспективна робота. Є старе кліше: "Ти віриш мені чи вашим брехливим очам?" Що стосується ваших начальників - це кількість помилок. Жодна кількість раціоналізації не скаже їм, що це прийнятно. Це більш ніж удвічі ризиковано. Крім того, ви не єдиний, на кого впливає кількість ваших помилок. QA вдвічі більше намагається ідентифікувати ваші помилки, тож керівництво хоче, щоб ви їх робили менше.

Найкраще рішення - зменшити кількість помилок, які ви створюєте , періодично. Не тільки управління буде щасливішим, але і ви будете занадто. Не будеш? Тому що я впевнений , що так само , як ви любите хвалитися ви випереджати своїх колег по чотири рази, ви любите , щоб сказати , що ви робите це робить те ж саме число, або навіть менше, ніж помилки вони роблять.

Як ви сказали, "... на кількість помилок, допущених у коді ..., впливає процес, який використовується під час написання коду та після написання коду". Якщо ви хочете змінити швидкість, з якою ви створюєте помилки, вам доведеться змінити процеси, які ви використовуєте для написання коду.

Програмісти використовують методи виробництва для виготовлення коду, настільки ж, як складальна лінія використовує методи для створення деякого масового об'єкта. Гаразд, практика індустрії програмного забезпечення більше нагадує вибивання рукоятки з гілок, знайдених у лісі. Але оскільки ми виробляємо машини, ми повинні використовувати ту саму суворість і дисципліну, що застосовуються для швидкісних машин масового виробництва.

Це включає ті самі методи, що застосовуються у масовому виробництві для зменшення частоти дефектів: аналіз причин, що визначають, чому робляться помилки, та змінюють процес, щоб вони не були. Або принаймні те, що ви ловите до того, як це зробить QA.

1. Складіть список ваших помилок. Ви, мабуть, вже отримали одне спасибі хлопцям із QA. Можливо, і категоризовано. Тип помилки, ступінь тяжкості, точка, в яку було введено помилку в код тощо.

2. Виберіть найбільшу категорію помилок. Оскільки ваш обсяг настільки високий, вам слід орієнтуватися на цю категорію спочатку. До інших категорій належать найпростіші та найлегші для виготовлення.

3. Знаючи, де ці помилки вводяться в код, погляньте на внесення змін на цій фазі (і раніше), яка запобігає їх виникненню, та способи полегшити їх пошук на цій фазі.

4. Не забудьте поглянути на випадки, пов'язані з непрограмуванням, а також вони можуть змінити якість вашої роботи. Фонова музика, перерви, час їжі, робота надто довго без перерви, голоду тощо.

Те, що ви знайдете, може призвести до того, що ви йдете повільніше. З іншого боку, це може допомогти вам зробити ще швидше, оскільки вам буде менше необхідності переробляти речі, які ви вже помістили за собою. Насправді це чотири рази більше коду, не близького до того, щоб він був на порядок кращим, ніж ваші колеги, тому зміна процесу - це, безумовно, шлях.

Змініть свою мету: створивши найбільше коду, щоб допомогти компанії просуватися вперед найбільше.

Оскільки, здається, у вас є багато колег, а також наявний додатковий час, найбільший ефект, який ви можете мати на швидше надання функцій та виправлення помилок, - це допомогти колегам.

Допоможіть своїм колегам

• використання оглядів коду для покращення якості коду та освіти.
• створення автоматизації процесів, щоб зробити їх роботу швидшою та простіше їх життя.
• написання кращих тестів з ними
• атаку технічного коду для вдосконалення бази коду
• будучи хлопцем, який завжди може допомогти іншим.
• інструменти для написання / вдосконалення, які допомагають підвищити продуктивність розробника
• зробити справу з керівництвом щодо кращих інструментів / обладнання / умов праці для ваших колег, якщо у вас є більше можливостей.
• підготовка та проведення навчальних сесій з написання кращого коду.
• практикуючи смиренність

Отже, як боротися з тим, що підвищення продуктивності призведе до збільшення кількості помилок?

Ваш начальник - єдина людина, яка може відповісти на це у вашому випадку. Поговоріть з ним, вкажіть ваше краще співвідношення та дайте йому рішення. Якщо його рішення не має сенсу, настав час шукати компанію зі своїм способом мислення.

Як професіонал, ви повинні мати можливість працювати з будь-якими умовами клієнта, просто переконайтеся, що вони розуміють наслідки. Приємна діаграма про помилки / історії може допомогти вашому начальникові зрозуміти, наскільки знизиться ваша продуктивність, якщо ви витратите час на створення менше помилок.

Вам також потрібно врахувати ці моменти:

• складність сюжетів, наприклад, прості обгортки для геттера / сетера порівняно зі статистичними розрахунками або програмуванням у режимі реального часу або навіть статистичними в реальному часі ...
• тяжкість помилок, невеликі помилки на текстових полях або неправильні результати обчислення, збої програми
• варто виправити помилки, як якщо ви це зробите зараз, то пізніше або якщо хтось інший повинен зрозуміти ваш код, тому що ви пішли

Ситуація така, що ви працюєте в чотири рази швидше, ніж середній програміст, але ви робите вдвічі більше помилок за певну кількість часу. Відносно обсягу роботи, яку ви виконуєте, ви фактично робите НАЛІНЮ стільки помилок, скільки «середніх».

Ви можете спробувати вказати на ваші низькі коефіцієнти помилок до роботи або навіть на помилки в готовому продукті (який ви можете виконати за одну четверту звичайного часу). Більшість начальників це приймуть.

Є кілька начальників, які цього не зроблять, оскільки вони працюють з "придумливим" настроєм помилок за раз. Тоді ви можете уповільнити робочий темп, зробивши ДВОХ стільки ж роботи, скільки в середньому протягом заданого часу, і зробити ті самі (або менше) помилок, оскільки у вас є більше часу на перевірку роботи.

Якщо ваш начальник хоче, щоб ви поліпшили якість вашої роботи, тоді поліпшите якість своєї роботи.

Ви повинні орієнтуватися на нульові помилки, не прагнучи виробляти лише вдвічі більше, ніж наступний найкращий програміст.

Ви повинні сказати своєму начальникові, що показники, які він використовує, є досить хибними. Якщо ви подивитеся на обороти охоронцями НБА, то виявите, що вони, як правило, мають більшу кількість, ніж форварди. Але це тому, що вони більше поводяться з м'ячем. Якщо гвардійці, які не стартують, грають на 1/5 стільки, скільки стартовий караул, і повертають м'яч у середньому 3 рази .vs. стартовий охоронець, який повертає м'яч понад 7 разів за гру - на перший погляд може здатися, що стартовий гвардійці гірше. Але, якщо поділити кількість оборотів на кількість відіграних хвилин, то, очевидно, стартовий гвардій має набагато кращі цифри на основі відіграних хвилин.

Так само ви маєте набагато кращі цифри, якщо кількість помилок ділиться на кількість виконаних точок історії. Отже, саме це я б запропонував вашому менеджеру. Змініть показник на кількість помилок, поділених на завершені точки історії, або принаймні додайте для цього новий показник, якщо потрібна загальна кількість помилок на розробника. Але оскільки деякі сюжетні моменти набагато складніші та складніші, ніж інші сюжетні моменти, тут може бути і буде небагато різниці, і це потрібно враховувати і менеджеру.

Що я не думаю, що ти повинен робити, - це гальмувати.

Виміряйте додану вартість

Аргументуйте, що те, що насправді рахується, - це значення, яке ви додаєте. Потім перейдіть і введіть грубі (ручні) вимірювання того:

• Оцініть значення функціоналу, який ви виробляєте
• Віднімайте зарплату
• Відніміть орієнтовну вартість ваших помилок (принаймні вартість їх виправлення)
• Віднімайте орієнтовну вартість всього іншого технічного боргу, який ви виробляєте

Залишок - ваша додана вартість. Так само і для всіх інших.

Ці оцінки важкі, але навіть грубі оцінки можуть судити. І сам процес обговорення цих оцінок корисний для команди та проекту.

Топ-програмісти мають тенденцію писати дуже регулярний код, який легко налагодити і зрозуміти, вони використовують наявні інструменти (статичний аналіз, помилки компілятора, код налагодження) до максимуму. Крім того, топ-програмісти вже дізналися значення тестування одиниць через власний нелегкий досвід.

Отже, хоча початкова кількість проблем на рядок однакова, проблеми усуваються швидше.