以下是个人对程序员写的代码分为10%和90%的见解，当然也适用于其它行业

一

每个公司代码库里最核心的那几个数据模型，或者说那几个 Class，直接相关的代码，可能都有成千上万行。我也曾经遇到人问我：“我觉得这个 XX 类不就是用来做什么什么的吗？怎么代码量这么大？这么复杂？”

是因为代码质量造成很多垃圾代码吗？不可否认，不同的公司的代码臃肿，或多或少和代码质量有着一定的关系。但是如果细想，你也会发现：当一个公司发展到一定阶段后，其实 90% 情况下用到的的主业务逻辑，只用到其中 10% 的代码；而剩下的 90% 的代码，是为了覆盖和处理另外 10% 情况下才会用到的非典型业务流程。

当然，这个百分比只是个约数。随着有些业务变得越来越重要，有些代码被重构，有些产品性能被砍掉，这个相对百分比也在动态地变化着。

二

最近看了篇文章，《给别人家产品提建议的时候我在想什么》（见文末｛阅读原文｝）。虽然说的是不同的事，但是让我想到一个相关的话题：“给别的工程师的系统设计提建议的时候我们在想什么”。

工作中，很少会遇到系统设计从根本上完全不合乎逻辑的情况。而更多的时候，这些设计在 90% 的情况下都是正确的，或者说是没有大问题的。但就是对剩下的那 10% 的思量和考虑，才真的是工程师功力见高低的地方。这样的 10% 包括系统的扩展性和并发的处理；包括对系统某部件失效（尽管失效概率仅为 0.001%）的处理；包括业务逻辑里某非典型流程和业务的处理；包括和别的项目组系统交互的考虑；包括一些系统遗留下来的 Legacy Issue 的处理，包括新老系统切换和兼容的处理……

有时候，那 10%，甚至是 1%，如果你没有考虑到，系统后期实现和执行的时候遇到才想起来，就真的傻眼了。所以工作中，那些对于在早期设计中总能给你提出这些建议的老司机，看似简单的一句话，那可能省下的，是几个、甚至十几个工程师的生产力。

市面上有些技术产品之间也是如此。90% 的时候，基本功能的实现，相差并不会太大。而正是那 10% 的细节上的处理，才体现出匠心，让产品可以脱颖而出。

三

我们这个年代的人，一生下来，就有那么多的道理和知识需要学习和掌握。是幸、也是不幸。很多和我差不多年龄的人，在过去的人生里，一大半都是在学校里的。学的东西不计其数，很多回想起来，如果从来没学习过，对我们现在的影响也不会太大。就拿我自己来说，你说我学过编译器、学过嵌入式系统、学过生物信息学，这些和我做支付、写程序有关系吗？目前看来，并没有。

我们学到的，不论是专业技术，还是非专业的知识，现在看来，大概用的上的，仅仅有 10%，而用不上的，可能高达 90%。但是没有人可以完全预见哪些会是我们用得上的 10%。所以我们付出 100%、200% 的努力，就是为了那有用的 10%。而正是这些 10%，让我们不断积累、不断成长，让我们做成我们想做的事。

最近很多留言，一些初入职场的人问我什么火，自己花很多精力去研究学习什么技术会不会划不来。从概率上来说，确实有些技术短期内可能让我们获益更大，但是长远的事，谁也说不准。听说乔布斯学习过画画，在很长一段时间，连他自己可能都不知道，这个技能对苹果的成功又有多大的影响。

在职场的后期，确实更多的时候我们会是用什么的时候去学什么。但正是很多之前的无形的积累，打下的基础，才让这种 “应急式” 的学习成为可能。比如，前一阵很多人对机器学习感兴趣，开始学习。而因为每个人的数学等功底的不同，能速成的机率，以及能学得多深，就会有很大的不同。

四

我的公众号每篇的阅读量会是订阅量很小的一个百分比，可能仅有 10-20%。听说很多公众号的阅读量都差不多在这个比例。而留言和互动中，觉得一篇文章有益的读者，又是很小的一个百分比，可能远远不到 10%。

虽如此，我还是会用 100% 的真诚去对待每一篇文字，尽我可能坚持周更。因为，只要有 10%、甚至是 1% 的人能有些许共鸣、或是在你累的时候给你带来些许陪伴，对我而言，就值了。