Как я могу убедить своих co-программистов не делать параноидальный “только, чтобы быть уверенными программирование”?

• Если они так чем-то обеспокоены не сработает в первый раз, тогда они должны переписать это что-то пока они не будут уверены, что это БУДЕТ работать.

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

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

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

Я бы ждал, пока не обнаружится ошибка, которая напрямую связана с таким кодом, а затем снова буду аргументировать свою позицию. Гораздо проще с доказательствами.

Некоторое время назад я немного писал о защитном программировании:

http://www.francisfish.com/what_defensive_programming_is_and_isnt_logging_the_right_t.htm

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

Это действительно досадная проблема, с которой я сталкивался несколько раз. Попытки убедить кого-то, представляя им различные принципы или аргументируя это, оказались разочаровывающими и бесплодными. В итоге я использовал два подхода:

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

1. Пусть они напишут модульный тест
2. Представьте обзоры кода (возможно, вы сможете обсудить такие фрагменты кода и показать им, как они работают лучше)
3. Представьте правило DRY (не повторяйте yourselfe)

Причины, по которым чрезмерная осторожность - это плохо, включают:

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

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

y = Abs (x); если y> = 0, то

совершенно разумно. помните -> MIN_INT == abs (MIN_INT)

Программирование по совпадению http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidence

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

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

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

Варианты 2 и 3 просто глупы в большинстве контекстов, если только они не являются тестовыми примерами для какого-то бета-языка программирования или чего-то, в котором реализация ABS и логических значений может иметь неопределенное поведение.

Ваша точка зрения верна, но, как я заметил, такие вещи ТАКЖЕ вызваны отсутствием надлежащих технических знаний. Я имею в виду, что я наткнулся на код, который просто глуп. Как можно написать что-то подобное -

private bool IsValid(bool isValid)
{
    if(isValid == true) return true;
    else if(isValid == false) return false;
}

То же самое и в обоих приведенных вами примерах. Программист МОЖЕТ не знать, что делает каждый вызов функции (в первом случае) или каковы основные основы случая переключателя (во втором). Не так ли?

Принудительное 100% покрытие ветвления для модульных тестов, иначе сборка завершится неудачно. Он не сможет заставить test1 создать исключение или оценить условие в test2 как false.

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

Я долго боролся с младшим разработчиком, который писал такой код. Я не мог убедить его здравыми аргументами, что написание избыточных проверок или дополнительных шагов - это не то же самое, что защитное программирование. В конце концов, я нашел решение:

Я сказал разработчику, что производительность является приоритетом для его части кода. Оказалось, что самый простой способ быстро улучшить производительность - это удалить лишние проверки и повторные инициализации ;-). Этот трюк сработал как лакомство, и вскоре он избавился от своих привычек «защитного кодирования»!

Сыграйте в их собственную игру:

• Объявите, что каждое выделение кучи должно помещаться в блок try..catch для проверки ошибок OutOfMemoryException, которые регистрируются на диск / отправлено на сервер системного журнала / и т. д.
• Проверяйте распределение каждой переменной, чтобы убедиться, что она «занимает» - выделите дважды, если необходимо.
• Циклам For не следует доверять, потому что, как только вы увидели один «промах» шаг »- так что делайте все ваши циклы с использованием gotos.
• Храните хэши SHA1 каждой строки. Сравните / обновите хэши при изменении строковых значений в «безопасных» частях программного обеспечения, чтобы убедиться, что строка не была изменена случайно.

 Repaint ();
Перекрасить ();
ProcessMessages (); 
Перекрасить ();

Это просто ужасное программирование. Здесь необходимо применить проверку кода и обучение.