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

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

<сильные > Примеры:

Перекрашивание окна, которое по какой-то причине не раскрашено, как хотелось бы программисту:

Invalidate();
Revalidate();
ProcessMessages(); 
Update();    
Repaint();
Repaint();
ProcessMessages(); 
Repaint();

Чрезмерная настороженность:

function test1(x: boolean) 
begin
  select case x
    true: // do something
    false: // do something else
    else
      raise Exception.Create("Invalid value.") // just to be sure
  end;
end;

function test2(x: Integer);
var
  y: Integer;
begin
  y = Abs(x);
  if y >= 0 then
  begin
    // do something
  end;
end;

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

В большинстве случаев этот вид кодирования защищается программистом и/или боссом. Причины всегда сводятся к этому ответу:

Хорошо, это больно, если мы дважды проверяем? Лучше быть в безопасности, чем сожалеть!
Это защитное программирование, разве они не учили этому в университете?!

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

Есть ли серьезные факты, которые я могу представить, что этот стиль имеет плохие последствия в конце концов?

EDIT: Благодарим вас за хорошие предложения, чтобы избавиться от этого стиля. Но меня все еще интересуют причины. Я могу представить своим сотрудникам объяснение и, возможно, убедить их, , почему это плохо, и в их интересах быть параноидальным.

Ответы

Ответ 1

Попросите их написать модульные тесты для каждого случая.

Ответ 2

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

Ответ 3

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

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

Фред не знает, почему код терпит неудачу, потому что он не знал, почему он работал в первую очередь. Казалось, это сработало, учитывая ограниченный "тест", который сделал Фред, но это было просто совпадением. Фред обвинил фальшивую уверенность в забвении. Теперь самые умные люди могут знать кого-то вроде Фреда, но мы знаем лучше. Мы не полагаемся на совпадения - не так ли?

Ответ 4

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

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

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

Ответ 5

Repaint();
Repaint();
ProcessMessages(); 
Repaint();

Это просто страшное программирование. Здесь следует применять обзоры и тренинги кода.

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

Пусть они пишут Unit Test
Ввести обзоры кодов (возможно, вы можете обсудить такие фрагменты кода и показать им, чтобы они делали это лучше).
Ввести правило DRY (не повторяться самостоятельно)

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

Есть только одно решение: Огоньте его.

Если он не умеет правильно программировать, зачем ему продолжать тратить драгоценное время и расходы? Стрельба по нему - единственный способ заставить его пересмотреть свои привычки. В бизнесе вы не можете проявить сочувствие или сочувствие. Вы не должны дружить. Вы там за зарабатываете деньги.

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

Ответ 13

Играйте в свою игру:

Объявите, что каждое распределение кучи должно быть помещено в блок try..catch для проверки ошибок OutOfMemoryException, которые записываются на диск/отправляются на сервер syslog/etc.
Проверяйте каждое распределение переменных только для того, чтобы убедиться, что оно "берет" - при необходимости выделяйте два раза.
Для циклов нельзя доверять, потому что как только вы увидели один "пропустить шаг" - так что все ваши циклы с использованием gotos.
Хранить SHA1 хэшей каждой строки. Сравните/обновите хэши при изменении строковых значений в "защищенных" частях программного обеспечения - чтобы убедиться, что строка не была изменена непреднамеренно.
Выполнение целочисленных тестов равенства путем отбрасывания на float и сравнения с использованием epsilon, потому что вы когда-то слышали историю, где большое значение 2 вызвало крупный инцидент в [вставьте ближайшую атомную электростанцию здесь].

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

Ответ 14

Я немного писал о защитном программировании:

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

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

Ответ 15

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

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

Ответ 16

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

Ответ 17

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