编者按：原文作者Phil Haack 从1997年开始从事软件开发，目前担任微软的ASP.NET MVC框架的高级项目经理，另外也负责ASP.NET的部分特性。Phil认为： 开发人员能够获得的最大赞扬，就是其他开发人员的给予的赞扬。 即：同行的赞扬！

作为软件开发人员，有一个小秘密：不管你写的代码有多么优秀，对另外一位开发人员来说，都毫无用处。

如果代码足够“干净”，你都可以吃代码上面的寿司，这没什么。如果每次代码显示在屏幕上时，约翰·卡马克（John Carmack）和Linus Torvalds都对这些代码都佩服的五体投地，这也没什么。但一些开发人员称这些代码是垃圾，而这些人通常就是你离开之后接手你代码的人。

原因有很多，而且比较琐碎：

• 在方法/函数中，你使用了字符串串联，而不是StringBuilder类。所以，如果这种情况发生，那么做出这样的决定就是有意的，因为一般这样的算法只会串联3到4个字符串。下一个开发人员才不关心这些。

• 没有按照规定把花括号放到应该放置的那一行，而是放到了同一行（反之亦然）。

• 使用了switch语句，但大家（包括下一个开发人员）都认为应当将其替换为状态或者策略模式。难道你没读过《设计模式》这本书吗？不要因为只有一个switch语句导致没有代码重复而担心。

• 在依赖注入（Dependency Injection）技术上，你采用Spring.NET，但下一个开发人员更喜欢使用Windsor。他们认为只有白痴才使用Spring.NET（反之亦然）。

• 或者你自始至终一直都在采用依赖注入技术。依赖注入到底是什么鬼东西？现在我完全看不懂代码！:(

尽管我们为完美代码而努力，但在真正的项目开发中，这是很难实现的。因为代码会受诸如时间压力之类的约束限制。 不幸的是，从代码中看不出约束来， 看到的只是这些约束造成的影响。 当下一个开发人员阅读你的代码时，他们是看不出这些代码是在项目发布前的剩余1小时内完成的。

然而我承认，在被误导性评论中伤之前，很难不先对这类评论采取一些措施，比如通过注释在代码中添加一些约束。

  public void SomeMethod()
  

  {
  

  /*
  

  程序中至多有4到5个foo，所以，在这种情况下使用字符串串联是可行的。这里有5篇有关性能讨论的帖子的链接。
  

  让我休息一下，现在是凌晨3点了，我一直忙于Jolt，这个项目已经逾期3个月了，现在我一点社交生活都没有。放我一马吧！...
  

  */
  

  string result = string.Empty;
  

  foreach(Foo foo in Foos)
  

  {
  

  result += foo;
  

  }
  

  return result;
  

  }
 

 

 

 

这样的防卫看起来有点过分，不过分？在注释中说明为什么制定一个特殊的、不明显的设计方案，这没什么问题。 事实上，这也正是注释的作用所在，而不是为了简单地重述一下代码做了什么。

然而问题是，开发人员有时候彼此之间的制约很大，你用绿色写论述（或者你的集成开发环境中注释对应的任何一个颜色）来标明每一行代码，因为你不知道对下一个开发人员来说，什么才算是明显的。

这也是为什么前几天收到一个开发人员的电子邮件我非常高兴的原因。这个开发人员继承了我写的一些代码，并在邮件中评价了我的解决方案，在这里我引用他的原话：“写的非常棒”。

真的？你不是在愚弄我吧？Ashton，你究竟躲在哪？

这很可能是你从别的开发人员那得到的最高称赞。而且我认为这不是因为我真的是这样一个卓越的开发人员。我认为真正应该赞扬的人是那位给出称赞开发人员。

我的意思是，当我继承别人的代码时，我的反应很有代表性，他们到底为什么要这样写代码！？难道他们没有学过如何编程么！？除了刚刚离开的那位前任开发人员，还有谁更适合做替罪羊？

幸好我比较机智，能将这些想法藏在心里。今后，我会在理解事情上更下功夫。当我继承别人代码时，我会假设这些代码是开发人员在72小时内一次编码完成 的，他魔兽世界中的角色身边到处都是蜜蜂和劫持的人质，在一切真正开始变糟之前，他只有1个小时，并且是在一台386的机器上来完成编码。

鉴于那些情况，难怪那个笨蛋不使用IDisposable实例附近的代码块。

来源

I'm so happy that I am not a programer!