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

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

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

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

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

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

1. Чтобы убедиться, что он не чувствует себя выделенным, это должно быть установлено для всей вашей команды. Требуйте, чтобы все написали автоматические модульные тесты для нового кода или кода, который они изменяют.
2. Требовать, чтобы названия модульных тестов были описательными в отношении случая, когда они тестируют.
3. Покройте автоматизированные модульные тесты в обзоре кода на высоком уровне. Попросите рецензентов искать пропущенные тестовые примеры (то есть те крайние случаи, которые он постоянно пропускает). После некоторого количества отзывов его команды о пропущенных крайних случаях он, вероятно, научится рассматривать их перед проверкой.
4. Примените это правило для всей команды: если QA обнаружит ошибку, ответственный разработчик должен провести автоматический тест, который подтверждает сбой, а затем доказывает, что он исправил его. (прежде чем они сделают какую-либо другую работу)

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

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

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

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

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

Хорошо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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