不仅仅是写代码，而是完成作品

近来有人问起，现在似乎真得变成了码农，日出而作，日落而息。整天不停的写代码，开发业务需求，周而复始，日子长了，感到厌倦。有时回想，应该在过去的某个时期我也曾陷入过这样的循环中，后来又是如何脱离的呢？

代码与缘由

这要回归到从写代码这件事上开始。写代码是因为有需求，需求来自业务的发展需要，需求经过产品经理再传递到程序员。

刚开始，作为一个新手程序员，不停的为各种需求写代码。开发完一个，接着又是下一个，生生不息，循环不止。一开始也许会感觉有些累，但并没有产生太多的厌倦。这是一个从不熟悉到熟悉再到熟练的过程，这里有太多的新东西可以去探索和尝试，让你在疲惫中依然获得了好奇心的满足，因此不会感觉厌倦。

但从不熟悉到熟练需要多久呢？现在成为专家的要求已经有了共识：一万小时的刻意练习。但达成熟练要不了那么久，也许两三年足以。有句俗语叫：条条大道通罗马。罗马，一个城市，包罗万象，对于程序员就像一个个需要完成的业务需求。几年过去，每一条通往罗马的大道都被你走过了，再去往罗马时，自然找不到新鲜感了，困倦油然而生。

继续在罗马的循环往复，已无法让你继续成长为专家。罗马也许在中世纪曾是一个伟大的城市，但时代在发展，未来会有更丰富的城市超越他。跳出循环的路无非就是走出熟悉的罗马，不再去走那条条通往罗马的大道，而是选择一条离开罗马的路，走向未知与未来。

在一万小时的刻意练习中，罗马已是过去的熟悉熟练区，离开罗马便是要进入下一个陌生的学习区。

产品与作品

写代码，开发需求无非都是为了完成产品。产品作为一个整体，包含了一份份零碎的需求和代码。

有时我们会把一个产品作为整体当作一件作品，但并非所有的产品都能称为作品。维基百科上对作品的定义是：

作品，亦称创作、创意、著作，是具有创作性，并且可以通过某种形式复制的成品。

从这个约定俗成的定义看，作品最重要的特质是：创作与创意。所以，只有包含了创意（作）性质的产品才能叫作品。那么像 iPhone 这样的商品就既是好产品也是好作品了。

那么对于程序而言呢？代码是作品么？可以是的，小到一段函数，一个类，大到一个服务，一个系统，在你编写程序时都可以把它们当作一件作品来完成。就像一本书是作品，书里的每一篇文章也是作品。

吴军曾在文章里写过：完成一件事，做到 50 分靠常识和直觉，做到 90 分要靠科学和技艺，而要做到 90 分以上则要靠艺术。我是认同这个观点的，完成作品的目标是 90 分以上，这是作品的特性决定的，因为创作就是艺术的核心所在。

如果写代码仅仅是完成需求，即便是完美无瑕的完成了需求，也只是 90 分的标准。经过了科学地学习和训练的程序员们，自然是超越了 50 分，但却还达不到 90 分。你想做到 90 分，也许需要一个比 90 分更高的标准。iPhone 作为一个 90 分以上的作品，就是 90 分的工程技术加上几分的艺术，相比差几分的同类，在市场上的价值和价格却是相距甚远。

为什么要把条条通往罗马的大道都要走完，甚至反复走。具体到编程写代码，无非就是不停的重构，打磨作品。成长的路上，写过的代码最终也许会烟消云散，但完成的作品会成为你点亮的勋章。

显性与隐性

梁宁以前写过一篇文章《在腾讯的第一堂产品课》，其中提到了产品的显性与隐性特征。显性的东西容易看到和体验到的，所以文中说到：

过分强调显性特性的，菜鸟之中的最初级。过去，我最怕的就是听谁说，我们要改版了，新版哪天…显性特性很重要，但是显性特性救不了你。把核心资源与时间，放在一次次优化显性特性上，基本上是互联网初级从业者的狂热症。

这是指产品的显性和隐性，初级的产品经理更容易关注到显性特征的体验变化和改进，但更高级的产品经理会关注和产品相关的服务、流程与成本等隐形特性。但产品经理关注的这些特性，无论是显性的还是隐性的，到了程序员这里的技术方案将全部是显性特性。

有个说法，要做好技术需要懂业务和产品，大体没什么问题。但需要提的细节是，是懂的方向。技术不需要了解业务产品的每一个显性特征，一个足够大的业务产品，有无数的显性特征细节，这些全部的细节可能分散在一群各自分工的产品经理们中。技术需要懂得是产品提供的核心服务和流程，并清晰地将其映射到技术的支撑能力与成本上。

另外，技术不仅仅需要支撑满足产品的全部显性和隐性服务特性，这些都是技术的显性服务特性。但技术还有自己的隐性服务特性，这一点恰恰也正是高级和资深技术或程序员需要重点关注的。所谓技术的隐性特性，通俗点就是程序员常说的非功能性需求，它的产生与来源都是源自程序和程序员本身。

用一段新算法实现的函数取代了旧函数，那么多余的旧函数就变成了负债而非资产，是需要去清理的。重构代码变得更简洁和优雅，可读性增强，节省了未来的维护成本。一个能同时服务一万人的程序实例，你知道你没法加十个实例就能简单变成能同时服务十万人的系统。这些都是技术冰山下的隐性特征，显性的错误会有测试、产品甚至最终用户来帮你纠正，但隐性的错误却很难有人能帮你发现并纠正。

一旦隐性的错误爆发，就像泰坦尼克号撞上了冰山，一切外显的繁华最终都将沉入海底。初中级的程序员都在关心能否完成这些显性的功能，而更高级的程序员则需要更多关注这些隐性的技术特征带来的风险和代价。

…

用正确的方式做正确的事，而那些隐藏在冰山下的正确的事，表现型的人是不愿做的，而进取型的人才会去做，得到的奖赏是自己的进步与成长。

大部分的技术“火灾”，都是隐性风险的爆发。一场大火过后，救火的英雄会站在聚光灯下，而你的系统隐藏于一片繁祥安宁的黑暗中。不深藏一点功与名，谁又愿意去推动这样一些默默无闻但正确的事情呢。

让正确的事情相继发生，你的成功或默于悄无声息，但你的失败却震于惊天动地。