开发人员能够得到的最好赞扬

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

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

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

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

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

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

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

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

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

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

例如：

代码:

public void SomeMethod()

{

  string result = string.Empty;

  foreach(Foo foo in Foos)

  {

    result += foo;

  }

  return result;

}

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

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

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

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

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

我的意思是，当我继承别人的代码时，我的反应很有代表性，他们到底为什么要这样写代码！？难道他们没有学过如何编程么！？除了刚刚离开的那位前任开发人员，还有谁更适合做替罪羊？（编注：伯乐在线在前段时间编译的《程序员：你的代码为谁而写》一文中就说到：“要评判很久以前写出的代码是优是劣很不容易，因为现在已经不知道当时为什么编写这些代码，也不知道为谁编写了这些代码。”所以，这种替罪羊事情比较常见。）

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

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

原文链接：http://haacked.com/archive/2007/10/07/

呵呵，代码人员很辛苦的。

累。

确实，因为对于代码人员来说，去理解别人的一段代码，还不如直接重新写一段代码省心省力， 这是客观的事实

在这里，也对Kingcms提一个可能不中听的建议，，
建议以后kingcms可以在易用性方面专研更深，因为要理解kingcms确实不是一件容易的事情。理解后固然是使用得得心应手，但对于很多新手来说，根本没有耐心去慢慢理解这款好的程序，，
就好比是：酒香！但巷子太深！
Kingcms有这么多的忠实用户，，这一点可以很好地体现Kingcms的强大魅力，，，希望，，，Kingcms可以走得更远，，，，