Работа с разработчиком постоянно игнорирует крайние случаи в его работе

25

У меня есть интересная, довольно распространенная, наверное, проблема с одним из разработчиков в моей команде. Парень отличный разработчик, работает быстро и продуктивно, выдает довольно качественный код и все такое. Хороший инженер. Но с ним есть проблема - очень часто он не рассматривает крайние случаи в своем коде.

Мы говорили с ним об этом много раз, и он пытается, но я думаю, он просто так не думает. В итоге QA обнаружит множество проблем с его кодом и вернет его для разработки снова и снова, что в конечном итоге приведет к несоблюдению сроков, и все в команде будут недовольны.

Я не знаю, что с ним делать и как помочь ему преодолеть эту проблему. Возможно, кто-то с большим опытом мог бы посоветовать?

Алекс Н.
источник
11
Попросите кого-нибудь прикрыть свой код юнит-тестами.
Работа
8
Лучшим специалистом для проверки кода является его автор.
16
@Developer Art: Полностью не согласен. Худший человек, который сделает любое тестирование кода - это человек, который разработал этот код. У всех есть слепые пятна, но у человека, создающего, есть самая большая слепая точка по отношению к его коду.
Джеймс П. Райт
2
@Developer Art: Я считаю, что написание автоматических тестов - довольно распространенная роль. Как правило, это то, что вы делаете в течение года или двух, если вы не совсем готовы к прайм-тайм в компании, в которой вы находитесь. Это своего рода чистилище.
Морган Херлокер
19
Вы описываете его как «великого разработчика», «продуктивного», «хорошего инженера» и создающего «качественный код». Но QA продолжает находить проблемы с его работой. Вы бы действительно использовали эти термины, чтобы описать кого-то, кто регулярно и последовательно Внедряет дефекты в свой код? Мне интересно, есть ли еще что-то в этой истории, поскольку описание личности как профессионала и работы, которую они выполняют, не совпадают вообще
Томас Оуэнс

Ответы:

29

Требуйте от него написания автоматических модульных тестов для своего кода. Написание юнит-тестов заставляет задуматься над крайними случаями.

Некоторые подробности:

  1. Чтобы убедиться, что он не чувствует себя выделенным, это должно быть установлено для всей вашей команды. Требуйте, чтобы все написали автоматические модульные тесты для нового кода или кода, который они изменяют.
  2. Требовать, чтобы названия модульных тестов были описательными в отношении случая, когда они тестируют.
  3. Покройте автоматизированные модульные тесты в обзоре кода на высоком уровне. Попросите рецензентов искать пропущенные тестовые примеры (то есть те крайние случаи, которые он постоянно пропускает). После некоторого количества отзывов его команды о пропущенных крайних случаях он, вероятно, научится рассматривать их перед проверкой.
  4. Примените это правило для всей команды: если QA обнаружит ошибку, ответственный разработчик должен провести автоматический тест, который подтверждает сбой, а затем доказывает, что он исправил его. (прежде чем они сделают какую-либо другую работу)
Мэтью Родатус
источник
Аминь, даже лучше, требует, чтобы каждый писал свой код в первую очередь. Использование структуры BDD обычно уменьшает боль от этого
Джордж Мауэр
@ Джордж Хорошая идея. TDD поможет еще больше здесь.
Мэтью Родатус
3
Модульное тестирование не о поиске ошибок - blog.stevensanderson.com/2009/08/24/...
Дайниус
1
@ Дайний, я согласен. Модульное тестирование облегчает разработчику продумывать крайние случаи, которые могут предотвратить (но не выявить) ошибки.
Мэтью Родатус
After some amount of feedback from his team about missed edge cases, he will probably learn to consider thoseРазработчики, у которых есть плохие практики, часто утверждают, что дополнительные усилия необходимы для хорошей практики (потому что они не видят выгоды от этого). Хотя разработчик может согласиться, если вы добавите дополнительные крайние случаи, это не значит, что он считает это актуальным или собирается ли он добавить их сам.
Флатер
23

Дайте ему контрольный список, например,

  • нулевые входы
  • входы в крайнем большом диапазоне
  • входы в крайнем малом конце диапазона
  • комбинации
  • входные данные, нарушающие предполагаемые инварианты (например, если x = y)

QA люди могут помочь разработать контрольный список

Раздайте контрольный список всем разработчикам, а не только этому.

Стивен А. Лоу
источник
1
Хороший момент, что все разработчики должны использовать контрольный список, выделение одного разработчика может вызвать плохие чувства. И это может помочь улучшить качество кода каждого .
FrustratedWithFormsDesigner
Хорошая идея, хотя мне любопытно, как это можно рассматривать с точки зрения разработчиков. Я никогда не сталкивался с такой практикой в ​​своей карьере разработчика, поэтому довольно сложно оценить реакцию. Есть идеи?
Алекс Н.
@ Алекс: контрольные списки - рутинная практика для одних разработчиков и ужасное оскорбление для других. Попробуйте и посмотрите, что получится. Если он выйдет, то качество вашего кода улучшится ;-)
Стивен А. Лоу,
4
Ваши разработчики не будут использовать контрольные списки? Если контрольный список может спасти жизни, будут ли они их использовать? Многие врачи этого не делают, а пациенты страдают. Читать это: newyorker.com/reporting/2007/12/10/071210fa_fact_gawande
Барри Браун
1
@ Барри, я не сказал, что они не будут. Контрольные списки в этом случае звучат, ИМХО, как средство от симптомов проблемы, а не самой проблемы. Проблема заключается в дисциплине и усердии в этом случае. Когда проблема заключается в сложности системы, которая требует неотложного обслуживания с высокой степенью ответственности и стресса, что приводит к снижению уровня внимания к деталям, тогда да, контрольные списки (пилоты, врачи и т. Д.) Но это больше о философских дебатах, я думаю, вне рамок этого вопроса.
Алекс Н.
17

Хороший инженер.

Хорошо.

Но с ним есть проблема - очень часто он не рассматривает крайние случаи в своем коде.

Это качество, которое хорошие инженеры не разделяют.


Наблюдение за крайними случаями является характеристикой, которая либо присутствует, либо отсутствует у людей. Это не имеет никакого отношения к тому, чтобы быть инженером или программистом. На развитие этой характеристики влияют культурный фон, среда обитания, детские события и жизненный опыт. Тогда отношение просто применяется к любой работе, которую делает человек.

Что вам нужно, это выяснить, относится ли ваш парень к тому типу, у которого не развито это определенное чувство (возможно, пока). Также очень вероятно, что он просто не заботится по той или иной причине. Вам нужно проанализировать всю ситуацию, счастлив ли он в своей работе. Если нет, то, возможно, вам следует сначала чем-нибудь помочь ему.

Если он хорошо справляется с работой, но еще не сталкивался с опасностью крайних случаев, вы можете начать его обучать. Если он воспринимает это всерьез, он может со временем изменить свои методы. Хотя я скептически отношусь к этому, вы все равно можете попробовать.

Однако, если он окажется тем человеком, который не очень хорош в крайних случаях, у вас может не остаться ничего, кроме как удалить его из команды. Эта характеристика важна для практического программирования. К сожалению, без этого даже великий человек не смог бы сделать хорошую работу.


источник
6
+1 Это навык , который у некоторых людей есть некоторые люди должны научиться быть хорошим программистом. Тем не менее, я хотел бы отметить, что существует два типа граничных случаев: граничные случаи бизнес-требований («Если мы заказываем 27 левых и 28 правых тренеров, этот порядок, вероятно, неправильный»), которые следует учитывать в требованиях проекта, и фактические крайние случаи кодирования (работа с недопустимыми входами, постоянная итерация по спискам, когда хэш-набор будет более разумным по скорости, когда набор становится больше, чем x и т. д.), о которых вам просто нужно узнать.
Эд Джеймс
Спасибо за ваше понимание. Действительно ценю это. Вы совершенно правы на всех фронтах, хотя мне любопытно, если он великий человек, но ему просто не хватает того, что делает великих инженеров великими, как я могу заставить его заниматься другой работой и удерживать его в организации, может быть, переход в другую команду или что-то ... Хотя, я думаю, только я могу ответить на этот вопрос :)
Alex N.
Я думал об этом, но я не уверен. Другая роль, которая должна стать приемлемой для такого человека, не должна требовать внимания к деталям, и их не так много в софтверной компании.
Мир не такой черно-белый, как предполагает твое первое предложение. Я считаю, что существуют разработчики, которые могут определить некоторые крайние случаи, но не все.
Майк Партридж
5

Не могли бы вы сделать обзоры кода или обзоры дизайна ранее в процессе?

PSU_Kardi
источник
4

Научите его сначала программировать тест. Спариться с ним. Вы напишите тестовые случаи, а он напишет код для прохождения тестов.

Кевин Клайн
источник
3

Может ли вовлечение QA на ранних этапах в разработку возможностей помочь ему предоставить список крайних случаев в самом начале? Хотя некоторые могут воспринимать это как ожидание того, что разработчик будет охватывать все, это может быть способом обойти это, если он стремится пропустить те граничные случаи, которые тестировщик вполне может поймать изначально.

Другая идея, которая у меня возникла, заключается в том, как он видит эту проблему. Действительно ли он раздражен и помечен на себя за эту модель или он просто видит это как нормальное явление, а не то, что ему стоит волноваться при решении? Конечно, это требует большого доверия и того, чтобы он был открыт для своей перспективы, но я думаю, что здесь есть некоторая степень сочувствия, которая может помочь, если вы видите вещи с его точки зрения.

JB King
источник
3

Существует бесконечное количество краевых случаев, охватить их все невозможно. Что делать, если кто-то делает #define TRUE FALSE? Это добавляет крайние случаи, вы тоже будете их проверять?

Кроме того, я бы не стал защищать каждую функцию частного класса или внутренней функции.

Подход, который я выбрал для кода, который должен быть очень надежным и стабильным:

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

Таким образом, вы получаете надежные дампы приложений в QA, и к моменту выхода релиза приложение становится надежным и безопасным.

Обойти ошибки - плохо. Хорошо, вы можете сохранить функцию, если дескриптор файла имеет значение NULL и возвращает значение NULL, но в большинстве случаев где-то возникает ошибка проектирования, и сбой приложения - лучший способ заставить вас найти причину. Большинство крайних случаев просто маскируют ошибку, скрывая проблему, скажем, кнопка перестала работать. Crash говорит вам, что некоторые предположения о продукте неверны, и вы должны пересмотреть логику, которая вызвала сбой.

кодировщик
источник
#define TRUE FALSE - это не крайний случай, это оскорбительное преступление.
gnasher729
1

Если это крайний случай, нужно ли его вообще рассматривать? Если пограничные случаи важны, то пограничные случаи должны быть включены в требования / функцию / историю пользователя.

Если пограничные случаи были рассмотрены как часть работы, и устройства должны быть установлены на месте, то они должны быть частью рабочего элемента, и по определению рабочий элемент не завершен, пока не будет создан механизм обработки пограничного случая. на месте.

Это дает вам, как руководителю группы, что-то, с чем можно проверить после завершения работы во время обсуждения после работы, и это дает разработчику возможность что-то проверить, когда он завершит работу.

Bronumski
источник
Всегда есть крайние случаи. Если кто-то утверждает, что крайние случаи никогда не будут встречаться, это не правильные крайние случаи.
Барри Браун
1
@ Барри Браун Я согласен, что всегда есть граничные случаи, но есть разница между важными граничными случаями, которые заинтересованные стороны считают важными, которые мы можем назвать сценариями, и граничными случаями, которые разработчик считает важными. Если заинтересованная сторона считает, что что-то важно, то это следует обсудить на сессии планирования и включить в качестве сценария в историю пользователя, а не оставлять на усмотрение разработчика, это должно быть надлежащим требованием для выполнения задачи. Это очень трудоемкий и не обязательный, но пустой контроль всех параметров для каждого не публичного метода.
Бронумски
1

Поймать крайние случаи, почему QA существует. Программисты несут ответственность за своевременное выполнение работы. Тратить все свое время на поиск крайних случаев очень неэффективно. Если у вас достаточно быстрый итеративный цикл, тогда это не должно быть проблемой. Краевые случаи близки к бесконечному числу. Если бы это была проблема с «основными» случаями, я бы немного обеспокоился. Как разработчики являются экспертами в разработке, так и тестер должен быть экспертом в тестировании. Когда тестировщик обнаруживает проблему, он отправляет ее обратно в разработку. Разработчик решает проблему. Проблема решена. Время для разработчика отследить каждый крайний случай намного дольше, чем должен пройти цикл итеративного тестирования. Также обратите внимание, что когда я говорю о тестировании, я имею в виду не тесты белого ящика, а строго тесты черного ящика.

Морган Херлокер
источник
1
Это действительно не правильный ответ. Быть вознагражденным за выдачу наполовину качественной работы - плохая практика. Команда разработчиков должна в целом отвечать за качественную работу.
Дэвид
Приличный разработчик не должен искать крайние случаи. Некоторый код написан так, что он не имеет крайних случаев, в других случаях очевидны крайние случаи. Код, не обрабатывающий крайние случаи, является неполным кодом.
gnasher729
0

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

Биллаль Бегерадж
источник