06年5月9日在拉斯韦加斯举办了ServerSide Java 会议。会上，Gregor Hohpe对一位Java高手说，每个软件开发团队只雇佣最好的最优秀的程序员，这肯定是对的。Google公司软件架构师Hohpe问道:“又有哪家公司会说我们要雇用不聪明的工程师呢?”他认为不好的程序员肯定是在计算机科学领域中受罪。

不过，Hohpe质疑，假如所有的应用开发项目都使用首回合的草案，他如何才能发现代码中的缺陷。当他发现代码中存在“这是个错误”或者“需要进行核查”等注释时，他很不满意。最佳的最优秀的程序员怎么能够写出这样的代码和注释呢?

他一边不断重复着自己的关键词，一边问:“所有漂亮的代码跑哪里去了?”他用开玩笑的语气这样调侃软件开发:“大概是门卫在半夜进来把我们的代码搞得乱七八糟吧。”

就像Hohpe所见到的情况一样，代码很多时候是被很一般的可以防止的原因搞乱的。其中的首要原因就是拙劣的代码引起更多拙劣的代码。他的理论是，如果某个应用程序的最初的开发人员不自己的代码规划清晰，让任何程序员都可以理解，那么潘多拉的盒子就会被打开。

接下来的事情从开发人员编写代码开始，即使代码可以运行，但是代码本身是很难让其他程序员理解的。接着，在应用上马之后，某个程序员要做一年的维护。代码变成了一堆乱七八糟的东西。

所以，可能第二个做维护的程序员在修改时，会对自己说:“我只在这里添加我的代码。它不会坏到哪里去的。”

但经过上面这样的几轮修改后，原先由最优秀的人编写的特性代码，终于变得越来越糟糕。

他向出席ServerSide会议的听众提供了一些避免以上事情发生的几点建议。他说:“被强迫写出的代码不会好到哪里去。要让下一个人觉得你是在花大力气编写优雅的代码。”作为一个架构师，他首先要懂得建模对应用程序的价值。他说，这并不需要很复杂的建模工具，甚至在一张纸上的画模型都可以有很好的效果。

Hohpe反复强调程序员应该是为人写代码，而不是为机器写代码。他说:“要对人们交互行为进行建模。当涉及用户界面时，这一点尤其重要。”他建议向非程序员展示应用程序，来观察程序员对于程序工作的理解对于潜在的最终用户是否正确。

他提醒道，所谓的业务逻辑并非总是和程序员所想的一样。他说:“假如业务逻辑真的和程序员想的一样，那么就不会这么困难了。这也是为什么说找到最终用户究竟如何与应用程序交互非常重要的原因。”

他敦促Java程序员利用Java的经验来编写设计好的代码，让其他程序员觉得优雅。“为人而不是机器编写代码”是Hohpe思想的核心。他建议，如果程序员仅仅只为机器写代码，那么他们就不需要Java，他们可以回到汇编代码的时代。

参考资源:
Gregor Hohpe - Where Did All the Beautiful Code Go?在线视频

Hohpe - Where Did All the Beautiful Code Go?原文下载：[下载文件]