优秀工程师专题 - 10%,和那背后的 90%

本文导航

  • 作者: 朱赟(点击查看公众号

  • 来源:微信公众号(朱赟) - 阅读原文

  • 转载时间:2016.10.09

  • 备注:我用markdown对排版稍作调整了一下,但没更换任何句子单词的顺序


每个公司代码库里最核心的那几个数据模型,或者说那几个 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% 的人能有些许共鸣、或是在你累的时候给你带来些许陪伴,对我而言,就值了。