程序员迷思：代码优先还是业务优先？

世界上有两种程序员，一种更看重代码本身而另一种更看重产品业务。

我们简称前一种程序员为“代码优先”程序员。他们着重于如何编写优雅的代码、使用哪种便捷的工具或者语言、代码的测试覆盖率是多少和其他类似的事情。“代码优先”程序员会为自己编写的完美函数、使用语言新特性、或者删掉糟糕的代码而欣喜雀跃。

代码优先的程序员热爱自己编写的代码本身，对他们来说，代码本身就是他们的事业。

而“产品优先”的程序员也会注意上面提到的这些东西，但是点到为止，将它作为实现目标的一种手段。对于这样的程序员来说，代码就像楼宇的脚手架、钢筋等结构，它是重要的组成部分而非一个完整的建筑，所以他们认为最终的产物应该是一个用来解决问题的产品而不只是代码。他们会在乎最终的产品，或者说建成的“大楼”，是否坚不可摧？电梯、空调等电器运转正常吗？人们喜欢住在这栋楼里吗？

产品优先的程序员热衷于建造一栋“大楼”，同时也在意用户是否享受他们建造的“大楼”，所以带来了怎样的产品才是他们真正在乎的事情。

曾在类似google一类的公司工作过的人，都会遇到一大堆“代码优先”的程序员。他们总是在重构代码、对你代码注释的错别字指指点点，他们会在茶水间对“垃圾代码”和“技术债务”喋喋不休，然后说其他团队的代码审查一点儿也不严谨。你应该已经发现了，我确实不是“代码优先”程序员队伍里的一员。

每次我面试别人的时候，我总会感到有点吃惊，因为有太多的“代码优先”或者以为我想要找“代码优先”的程序员了。我看出来他们想给我留下好印象，他们会问我：“你们的代码覆盖率怎么样？”（好吧基本是0）;然后会问我“你用有没有用到最新的某某技术？”（好吧，也没有），难道那东西能让我更快地产出好产品吗？再然后他会问我：“你们有很多技术上的欠债吗？”我们会重写所有东西的，但不是现在。因为我们还没有确定我们真正需要什么样的产品。

我可以理解，他们有一种最基本的误解——代码就是全部。代码是实现产品和帮用户解决途径的工具，而不应该是写好看代码然后取悦自己的东西。

而且我必须明确一点，无论是对哪种技术栈的程序员都是如此。无论是你的用户是行外人，第三方开发者，或者API的调用者，他们在乎的是你的代码好不好用，而不在乎好不好看。

但这并不意味着我鼓励写垃圾代码。也不意味着我不在乎我们使用的工具或者代码架构。正相反，我非常在乎这些！但是我在乎他们是因为代码工程中正确的选择最终会带来更好的产品。

最近我手下一个程序员问我他的代码写的咋样。我用两个问题作为回答：“各个功能都很好地实现了吗？”和“你写完的速度快不快？”，“这些东西才是我真正在乎的”我如是对他说。

显然，如果对于这两个问题的回答都是肯定的，那他的代码很可能（不是一定）写的就很好了，因为好的产品通常就意味着好的代码。顺带一提，我的这个定义不会存在相反的情况，即好的代码不可能出现在坏的产品上。

我称之为好代码定律：

如果产品很难用，那么背后的代码肯定很垃圾

换句话说，抽象的好代码是不存在的；好代码只存在于好用的产品（重申一遍，对所有级别的产品来说都是如此。）

每每我看到程序员快速地完成一个好的产品后，再去看他的代码，通常都会是干净利落且不耦合的。这很合理，毕竟想用架构糟糕，高度耦合又没测试的代码去快速地完成一个产品可太难了。

相反的，当我看到程序员不能快速完成新功能时，问题通常是过度设计。或者他完成的很快但是产品质量很糟糕，那么问题通常就是设计不足或代码写的草率。

代码优先和产品优先并非是零和博弈：你应该通过努力编写好代码，快速生产，从而完成一个伟大的产品。这才是伟大的程序员要做的。

我认识的最强程序员都是那些拥有比“代码优先”程序员更多代码知识的“产品优先”程序员。他们知道什么时候该用什么样的工具。相比于糊弄过去他们可以知道什么才是真正的解决方法（通常在栈的底层）。当写一个普通的for循环比写一个迭代器更合适的时候，能否合理的权衡利弊才能决定你是否是一个伟大的程序员，而这些最终又会反馈道你的产品上，让他表现更好。

原文链接：thezbook.com/code-first-…

=======================================

写在后面： 这篇文章表达了一个观点，代码不能脱离产品单独存在，因为代码只是解决问题的一个手段。我觉得刚开始做程序员的时候，我就没有想明白这个问题。但是随着工作时间越来越长，我意识到产品经理给我带来的麻烦远比其他开发的同事给我的多，同时从产品的层面解决问题也比代码上找补要干脆彻底的多。所以结论是不要钻牛角尖，只关注代码不能解决所有的问题。