设计软件有两种方法：一种是简单到明显没有缺陷，另一种复杂到缺陷不那么明显。 —— 托尼·霍尔（1980年图灵奖获得者）
在开发过程中，我的口头禅是： Your code may be elegant, by mine f**king works。（你的代码或许很漂亮，但我的代码能运行！）我为此而常常受到质疑，也有人反驳我“你不会使用最优方法！”“你在逃避测试！” 为了避免一次又一次地重复解释，我决定阐述下我的观点，仁者见仁，智者见智。
首先，我认为“项目可能会延期，但是代码会更好或更容易维护或更简洁”这句话是有问题的。项目延期，就是未完成，不应该用代码质量会更高作为借口。如果客户要在圣诞节进行推广活动，但你在 12 月 29 号才完成项目，即使提供了史上最好的产品，也是毫无价值的。
其次，我们来谈谈“最优方法”这个问题，“最优”是否意味着要写出更易于维护的代码需要更长的时间呢？其实除了大家都知道的《101个最优方 法》以外，“最优”的标准是各种各样的。无论你对其进行怎样的定义，“最优方法”对所有程序员来说，应该是一种自然的编程标准。举个最简单的例子，经验丰 富的程序员会自然地将变量命名为：$a、$b、 $c等，也能正确地缩进代码行。说得再深入一点，有经验的开发者知道在什么时候、如何提高效率以使得项目能如期完成。虽然 “最优方法”的标准有很多，但这些标准不会令你因此而延长项目时间。这引出我将谈到的下一点——Over-engineering（过度设计，指设计出来 的系统比恰到好处要复杂臃肿的多，过度的封装、一堆继承、接口和无用的方法，以及超复杂的 xml 配置文件）。
像任何经验丰富的程序员一样，我了解那种想为每个项目搭建最好、最灵活、最耐用的系统的心态。但我也了解每个项目都有的商业限制：时间和资金。 大多数项目都有明确的截止日期和项目预算，开发者要有意识地去控制项目规模以按时达到目标。你没有任何理由花一周时间，来为一个 20 行的 table 表上的数据库查询设置“恰当的”缓存层。多了解实用案例，如果只是为了实现一个页面访客计数器的功能而构建支持多种同时响应请求的 XHR 框架，是不现实的。要有眼界，这是我最强调的一点，最好的程序员不是精通如何构建最棒的系统的人，而是了解系统不需要的是哪些功能的人。
另外，在软件开发领域，上市时间是商业驱动力，在 web 应用开发领域，由于其动态性，这点更为明显。当时间成为关键，“最优方法”就是最简单的解决方案。
最后，我们来讨论一下技术债务（指为了匆忙实现一个功能，破坏了现有的程序库，在实现的过程中污染了代码库的设计）。如果在开发过程中，你在某 个地方偷工减料了，那么就会产生无法解决的长期存在的技术债务，而且在之后的开发中，任何一个决定，都会受该债务的影响。事实上，在接手商业项目时，明白 何时、如何对代码进行简化的能力是很关键的，这也是区分老手和菜鸟的标准。解决技术债务的办法有很多，但应尽量做到不产生技术债务。同样地，过度设计也不 可避免地会产生技术债务。
通常人们在谈到技术债务的危险时，并没有包含商业影响。但其实技术债务与实际投资回报率是相对的，因为在许多情况下，早日上市更具成本效益。也 有种情况是技术债务与收益同时存在，那么你可以慢慢偿还债务，但这会延长你的项目时间，很可能当你解决完技术债务时，你也失去了市场机会。
作为软件开发人员，我们常常认为自己的工作就是开发软件，但其实这只是一种手段，我们的目的是令开发商达到他们的商业目标，你的代码也许很优雅很简洁，但如果不能达到目的，就丝毫没有意义。
