【外刊IT评论】好代码不值钱

长久以来我一直主张：好代码是廉价的代码。

当我跟做开发的同事说出这话时，他们的第一反应是一种惊愕，然后是将近一个星期的嘲笑，把它当作一个笑话来讲。当他们走近看我的表情、知道我是认真的时，才收敛一点。

当最初的惊愕消退后，他们会用一些这样的话来反驳：“好代码不廉价，好代码是采用经过数十年计算机科学研究和积累得出的最佳实践设计模式和方法论建立起来的精心制作的程序代码。”

我只好继续解释为什么他们给出的好代码的定义有问题的原因是(这是很多开发人员都忽视了的一个原因)：知晓各种设计模式，框架，技术技巧只是事情的一方面，而知道何时该、何时不该应用他们才是更重要的问题。在不知道一种技巧方式如何能对系统的开发有帮助的情况下，这种模式方法极有可能成为一种开发的阻碍，而不是一种有益的帮助。

我还要解释说，我所说的“廉价的代码”是指这些代码只需要很少的人/天数就能开发出来，并不是说是由没有经验的开发人员、在很少的工资报酬下、用6个月封闭式、只有烤白薯和豆腐汤可吃的环境中开发出来的东西。

但是 … 设计模式毕竟是个好东西 … 不是吗？

当然，但它们好在哪里？它们能提供什么好处？

• 容易维护
• 产品更健壮
• 容易理解
• 易于日后的改进提高
• 更好的可跟踪性

你会发现所有的这些最终都落到一点上：从长期的角度看，它们能让你更快的做事情。这事情有可能是系统迁移，或是增加一个新功能，不论是什么，通过运用这些方法模式，你会在时间效率上获得实实在在的好处。

这么说，我们观点一致吗？

怎么说呢，让我给你们说个例子，我们看看实现它的几种方式。

系统

用PHP创建一个发邮件的表单，表单里有几个表单项，用邮件把这些数据发送给某个人。除此之外，表单里的内容还要存入MySQL数据库里。

现在，用什么方式实现它们最好？按照传统的说法，采用最好的实践设计模式，你可能会想到这些：

• MVC
• N-层设计，包括数据库抽象层
• 对象关系映射(ORM)
• 可能用到的框架
• XML配置和相关模型
• 等等.

我可以说，这简直是疯了，客户的这些需求完全可以用10几行代码、一个小时里(包括测试时间)完成，而且所有的那些方法模式所希望达到的效果(诸如可读性，可移植性，稳定性)都有了。如果使用上面列出的那些，反而真正的会达不到这个目标，使代码复杂化，难于理解和维护修改。

那现在，假设客户又来了，要求做一些改动，比如要增加一个管理员的界面。这样的话，你就胜利了，你已经实现了很多很有用处的东西；然而这是因为你在第一次开发这个系统时付出了很大的代价。我要向你声明的是，即使我现在把这些简单的代码进行重构，增加一些简单的业务层，也仍然比按你要求的那种过度技术化的初始实现方案要简单的多。

再说了，如果客户要求的只是在表单里增加一个属性，那你的N-层设计方案会让你痛苦不堪，因为你需要改动各个层，包括那些CRUD代码。

SCRUM

我发现Scrum能吸引我的最大一个原因是它能迫使你敏捷开发；它能迫使你在每个Sprint结束的时候把东西都实现、发布。它不会让你做出目前用不到的多余的东西；它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。

相反，在你需要的时候你才去重构。当然，这会有一定的风险，因为在实现某些功能上你会花去比当初已经做了一些基础工作的情况下要更长的时间。然而，产品开发就像是一个沙漠中四处漂移的沙丘，你永远不可能准确的知道一个产品在将来会做如何的改动。所有的你花在实现这些很有吸引力的各种模式上的时间很可能会成为一种完全的浪费。

复用性

有些人会指出，我所说的方式产生的代码不具有太多的复用性，不能在新开发的一些其它系统中使用。我对这个问题的回复就是，在根本不知道某些东西是否/如何/在哪将会被复用的情况下去设计一个可复用的东西，这就跟去实现一些你根本用不到的功能或你的应用里跟本用不到的功能一样愚蠢而糟糕。如果你有一个清楚的远见，知道什么地方会复用这些东西，这就不同了，因为你确实有一个内部的业务需求在指导你正确的开发方向。

我的最后的思考 …

• 了解你的设计模式，知道它们各自的好处(我一直认为，好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式)；
• 让你的代码廉价：
  • 当模式能够给你带来好处，而且为你省时时才去使用它们；
  • 如果不是这样就不要使用它们(例如：想想你最近的一次为什么要把系统迁移到一个不同的数据库上？)；
  • 当框架能够帮你提高开发速度时才使用它们；
• 在必要的时候重构，不要做一些超前性的开发；

我想，如果你能按照这些指导原则做事，你会发现开发周期变短、实现的代码更简洁，易于调试，易于维护修改。