У меня есть интересная, довольно распространенная, наверное, проблема с одним из разработчиков в моей команде. Парень отличный разработчик, работает быстро и продуктивно, выдает довольно качественный код и все такое. Хороший инженер. Но с ним есть проблема - очень часто он не рассматривает крайние случаи в своем коде.
Мы говорили с ним об этом много раз, и он пытается, но я думаю, он просто так не думает. В итоге QA обнаружит множество проблем с его кодом и вернет его для разработки снова и снова, что в конечном итоге приведет к несоблюдению сроков, и все в команде будут недовольны.
Я не знаю, что с ним делать и как помочь ему преодолеть эту проблему. Возможно, кто-то с большим опытом мог бы посоветовать?
code-quality
Алекс Н.
источник
источник
Ответы:
Требуйте от него написания автоматических модульных тестов для своего кода. Написание юнит-тестов заставляет задуматься над крайними случаями.
Некоторые подробности:
источник
After some amount of feedback from his team about missed edge cases, he will probably learn to consider those
Разработчики, у которых есть плохие практики, часто утверждают, что дополнительные усилия необходимы для хорошей практики (потому что они не видят выгоды от этого). Хотя разработчик может согласиться, если вы добавите дополнительные крайние случаи, это не значит, что он считает это актуальным или собирается ли он добавить их сам.Дайте ему контрольный список, например,
QA люди могут помочь разработать контрольный список
Раздайте контрольный список всем разработчикам, а не только этому.
источник
Хорошо.
Это качество, которое хорошие инженеры не разделяют.
Наблюдение за крайними случаями является характеристикой, которая либо присутствует, либо отсутствует у людей. Это не имеет никакого отношения к тому, чтобы быть инженером или программистом. На развитие этой характеристики влияют культурный фон, среда обитания, детские события и жизненный опыт. Тогда отношение просто применяется к любой работе, которую делает человек.
Что вам нужно, это выяснить, относится ли ваш парень к тому типу, у которого не развито это определенное чувство (возможно, пока). Также очень вероятно, что он просто не заботится по той или иной причине. Вам нужно проанализировать всю ситуацию, счастлив ли он в своей работе. Если нет, то, возможно, вам следует сначала чем-нибудь помочь ему.
Если он хорошо справляется с работой, но еще не сталкивался с опасностью крайних случаев, вы можете начать его обучать. Если он воспринимает это всерьез, он может со временем изменить свои методы. Хотя я скептически отношусь к этому, вы все равно можете попробовать.
Однако, если он окажется тем человеком, который не очень хорош в крайних случаях, у вас может не остаться ничего, кроме как удалить его из команды. Эта характеристика важна для практического программирования. К сожалению, без этого даже великий человек не смог бы сделать хорошую работу.
источник
Не могли бы вы сделать обзоры кода или обзоры дизайна ранее в процессе?
источник
Научите его сначала программировать тест. Спариться с ним. Вы напишите тестовые случаи, а он напишет код для прохождения тестов.
источник
Может ли вовлечение QA на ранних этапах в разработку возможностей помочь ему предоставить список крайних случаев в самом начале? Хотя некоторые могут воспринимать это как ожидание того, что разработчик будет охватывать все, это может быть способом обойти это, если он стремится пропустить те граничные случаи, которые тестировщик вполне может поймать изначально.
Другая идея, которая у меня возникла, заключается в том, как он видит эту проблему. Действительно ли он раздражен и помечен на себя за эту модель или он просто видит это как нормальное явление, а не то, что ему стоит волноваться при решении? Конечно, это требует большого доверия и того, чтобы он был открыт для своей перспективы, но я думаю, что здесь есть некоторая степень сочувствия, которая может помочь, если вы видите вещи с его точки зрения.
источник
Существует бесконечное количество краевых случаев, охватить их все невозможно. Что делать, если кто-то делает
#define TRUE FALSE
? Это добавляет крайние случаи, вы тоже будете их проверять?Кроме того, я бы не стал защищать каждую функцию частного класса или внутренней функции.
Подход, который я выбрал для кода, который должен быть очень надежным и стабильным:
Таким образом, вы получаете надежные дампы приложений в QA, и к моменту выхода релиза приложение становится надежным и безопасным.
Обойти ошибки - плохо. Хорошо, вы можете сохранить функцию, если дескриптор файла имеет значение NULL и возвращает значение NULL, но в большинстве случаев где-то возникает ошибка проектирования, и сбой приложения - лучший способ заставить вас найти причину. Большинство крайних случаев просто маскируют ошибку, скрывая проблему, скажем, кнопка перестала работать. Crash говорит вам, что некоторые предположения о продукте неверны, и вы должны пересмотреть логику, которая вызвала сбой.
источник
Если это крайний случай, нужно ли его вообще рассматривать? Если пограничные случаи важны, то пограничные случаи должны быть включены в требования / функцию / историю пользователя.
Если пограничные случаи были рассмотрены как часть работы, и устройства должны быть установлены на месте, то они должны быть частью рабочего элемента, и по определению рабочий элемент не завершен, пока не будет создан механизм обработки пограничного случая. на месте.
Это дает вам, как руководителю группы, что-то, с чем можно проверить после завершения работы во время обсуждения после работы, и это дает разработчику возможность что-то проверить, когда он завершит работу.
источник
Поймать крайние случаи, почему QA существует. Программисты несут ответственность за своевременное выполнение работы. Тратить все свое время на поиск крайних случаев очень неэффективно. Если у вас достаточно быстрый итеративный цикл, тогда это не должно быть проблемой. Краевые случаи близки к бесконечному числу. Если бы это была проблема с «основными» случаями, я бы немного обеспокоился. Как разработчики являются экспертами в разработке, так и тестер должен быть экспертом в тестировании. Когда тестировщик обнаруживает проблему, он отправляет ее обратно в разработку. Разработчик решает проблему. Проблема решена. Время для разработчика отследить каждый крайний случай намного дольше, чем должен пройти цикл итеративного тестирования. Также обратите внимание, что когда я говорю о тестировании, я имею в виду не тесты белого ящика, а строго тесты черного ящика.
источник
Это один из случаев, когда я считаю, что разработка, управляемая тестами, приходит на помощь, потому что она помогает мыслить с точки зрения крайних случаев и всего, что может нарушить код.
источник