我如何说服我的共同程序员不要做偏执"只是为了确保编程"？

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

让他们编写单元测试来涵盖每个案例.

Answer 2

强制100%分支覆盖单元测试,或构建失败.他将无法使test1抛出异常,或将test2中的条件评估为false.

Answer 3

巧合编程 http://www.pragprog.com/the-pragmatic-programmer/extracts/coincidence

假设Fred有一个编程任务.Fred在某些代码中键入,尝试它,它似乎工作.Fred在更多代码中输入,尝试它,它似乎仍然有用.经过几周的编码,程序突然停止工作,经过几个小时的尝试修复后,他仍然不知道为什么.弗雷德可能会花费大量时间来追逐这段代码而无法修复它.无论他做什么,它似乎都没有正常工作.

弗雷德不知道为什么代码失败,因为他不知道为什么它首先起作用.考虑到Fred所做的"测试"有限,它似乎有效,但这只是巧合.在虚伪信心的鼓舞下,弗雷德被提前遗忘.现在,大多数聪明人都可能认识弗雷德这样的人,但我们知道的更好.我们不依赖巧合 - 我们呢？

Answer 4

是的,这是一个问题.至少,这种类型的编程使代码难以理解和维护.如果有一个需要检查或捕获的真实案例,那么通常很难看出它是否真的经过了测试.即使像使用调试器单步执行代码这样的简单任务也会变得乏味.

我和一位编写这样的代码的初级开发人员争吵了很长时间.我无法用理智的说法说服他写冗余支票或额外的步骤与防御性编程不同.最终,我找到了一个解决方案:

我告诉开发人员,性能是他的部分代码的优先事项.事实证明,快速提高性能的最简单方法是删除额外的检查并重复重新初始化;-).这个伎俩很有效,他很快就受到了"防守编码"习惯的训练!

Answer 5

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

这只是糟糕的编程.代码审查和培训必须在此处应用.

Answer 6

你的观点是正确的,但据我所知,这些事情也是由于缺乏适当的技术知识造成的.我的意思是,我遇到的代码简直就是愚蠢的.有人怎么写这样的东西 -

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

您给出的两个示例都是相同的.程序员可能不知道每个函数调用的作用(在第一种情况下)或者案例的基本基础是什么switch(在第二种情况下).不是吗？