language-agnostic - 我如何说服我的共同程序员不要偏执 “just to be sure programming”？

Question

我经常发现，当程序员或分配任务的人不能真正理解解决方案的工作方式时，他们会随机添加一些东西，直到它起作用为止。

示例:

重新绘制由于某种原因未按程序员希望绘制的窗口:

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;

尽管特别谨慎的编码实践在大多数语言中都会导致编译器警告，但实际上我已经在生产代码中看到了以上所有内容!

在大多数情况下，这种编码是由程序员和/或老板捍卫的。原因总是归结于此响应:

好吧，如果再次检查，会不会很痛？比后悔更安全!

这是防御性编程，他们不是在大学教书的吗？

不幸的是，我没有充分的理由不这样做，尽管我仍然相信这真的是很糟糕的风格，可能会产生不良影响。

我是否有确凿的事实证明这种风格最终会产生不良影响？

编辑:感谢您提供摆脱该样式的好建议。但是我仍然对 原因感兴趣，我可以介绍给我的同事解释并可能说服他们， 为什么这很不好，并且出于他们的最大利益，不要偏执。

Answer 1

让他们编写单元测试以涵盖每种情况。