你好，我是尉刚强。

到这里，这门《性能优化高手课》就要和你说再见了。在前面的课程中，我一直在和你讨论软件系统性能优化的各项技术手段，不过到了最后一讲，我想再给你分享一些跟技术相关的，但也不局限于技术的话题，希望能通过我以往在工作或生活上的一些体会和感悟，给你带来一点点启示。

简单是正确的向导

我刚开始创业的时候，有段时间一直在加班加点，给公司研发的智能聊天机器人添加各种功能，但问题是用户量一直上不去，导致了团队长时间处于低谷之中。然后，有一次我在与投资人聊天的时候，讲到我们如今创业的处境太艰难了，我的投资人当时就说了一句话：通往成功的路，往往是一条最简单容易的道路。你们之所以做得太艰难，恰恰是因为没有找到那条简单的路而已。

这句话对我简直就是当头一棒，而且我之所以会记忆得如此深刻，一个很重要的原因其实是一直以来，我也在秉持这种做事方式，但是却没有悟出这个道理的真谛所在。就比如说：

  1. 在对软件进行架构设计的时候，如果给出的设计方案过于复杂，其实大概率是因为我没有深入理解业务背后的领域模型；
  2. 在定位分析一个性能问题时，如果整个分析和定位的过程很繁琐，很可能只是我没有找到简单的分析方法，所以才久久不能发现具体的性能瓶颈。
  3. 针对一个现成的软件，我需要添加过于复杂的业务特性时，很有可能是因为软件在最初设计的时候，并没有做好简单设计，现在只是还之前欠的债。

所以我想告诉你的是，不要忽视简单的价值，才能在工作中更容易获得成功。

要知道，很多啰啰嗦嗦、洋洋洒洒都说不清楚一件事的人，其实是能力不够造成的。而能一语道破本质、能轻松应付难题、甚至是工作效率比你高的人，实际上是因为他比你更早地养成了简单做事的思维习惯。

我以前参与过一个软件项目，团队需要给一个嵌入式软件开发一个组件级的测试框架，支持用户开发特性级别的测试用例。由于这个嵌入式系统是一个复杂的并发系统，底层有线程、进程、定时器、消息通道等各种机制，所以当时我就提出了两种方案。

  1. 方案 1：尽量真实地仿真底层并发机制，期望在特性测试中可以发现并发问题；
  2. 方案 2：尽量简单地仿真底层并发机制，主要聚焦于业务特性测试，而不会测试并发场景。

当时，在项目的开始阶段，我是比较倾向于方案 1 的，不过在开发推进了两个月之后，我们却逐渐发现，因为测试框架太复杂，导致测试用例开发困难，而且还很不稳定。所以最后，我们不得不完全废弃方案 1，改用方案 2，结果不到一个月的时间就完成功能开发并上线，最后也取得了非常不错的测试防护效果。

你要注意，凡事都坚持复杂化的人，恰恰是对那些情况不怎么熟悉的人，因为复杂只是冗余的堆加，是一种简单的缺失。而把简单作为做事的标准之一，让大脑建立一种认知和行为的常规模式，你在做任何事情的时候，甚至都不需要耗费很多精力。

细节是成败的关键

接下来想分享给你的一个要点，是细节。

细节是什么呢？我觉得细节是起关键作用的小事。因为很多时候，细节好像都是我们经常会忽略的一个问题，比如在编写代码的时候，一不注意就会埋入一个小小的 Bug，结果导致好几天的努力都付诸东流。

所以这里我想强调的，就是**你对细节的态度，可能在无形中就决定了做一件事情的成与败。**如果持有“差不多就行”的思想，其实很容易在后面吃大亏。

就拿我自己来说，我曾经做过一个百万表单的性能优化项目，当时为了提升数据的查询分析速度，我有了一个比较大胆的想法：将所有数据都进行一次编码操作来压缩数据，然后记录到分析数据库中。不过这样，我就需要把所有原来的业务请求，都转换成基于编码之后的数据上的查询分析请求。

因此接下来，我先进行了原型验证，发现这个性能优化思路确实可以取得很大程度上的性能提升（执行速度提升了几十倍）。

不过只做原型验证还不够，所以接下来还有一个很重要的环节是可行性验证。在深入验证这个方案是否可行的过程中，我需要针对业务中的每一种字段类型来设计编码方式，而且要确保不同字段的编码和解码规则不冲突，还要验证各种组合场景下的功能是否能够满足要求。因为如果中间任何一个字段编码规则出现问题，都会导致整个方案不可行。

这样，为了进行充分的验证，我就前后验证分析了 30 多种字段类型在多种编码规则下的组合场景。最后才保证了性能方案可以正常落地实施，并获得了很好的性能提升效果。

所以我才说，细节是魔鬼。如果你设计了一个软件方案，从各个角度来看，貌似都很完美地解决了所有问题，那肯定是还有些细节问题没有被挖掘出来。

另外，你也不要觉得把握细节，好像就意味着你要事必躬亲。其实最重要的是你要知道什么才是关键点，然后更细粒度地来思考和分解问题。

走出舒适区，成长才更快

最后，我还想分享给你一句对我现在工作帮助很大的话：只有让自己待在非舒适区，才能成长得更快。

我从事嵌入式领域研发工作已经有好些年了，在这个领域的技术积累和沉淀，也已经足够让我比较安逸地在这个行业工作到退休了。不过后来，我选择了进入一个全新的行业领域，也就是大数据领域。我现在依稀还记得，当时所面临的各种困难和挑战，比如要丢掉头上专家的光环、需要从 0 开始学习各种新知识，等等。

但是，在深入这个新领域一段时间后，我渐渐发现不同领域间的软件设计与实现过程中的底层原理是相通的，是可以互相借鉴学习的。比方说，大数据平台调度器 YARN 的调度器中，与无线空口资源的调度器中的一些算法原理是相似的，我们在优化配置时就可以借鉴；而大数据领域的并行设计，以及计算和数据分离的解决方案，我们也可以用在嵌入式领域的性能优化上。

所以，当有一天你可以成为新领域的专家时，你会发现自己比只从事一种领域的专家具备更广阔的认知视野，以及更多维度的问题解决思路和方法。我也是因为在好几个技术领域上所积累的经验，才帮助我现在能够更快地融入新的软件咨询项目中，并找到解决思路和方向。

当然，我这里说的非舒适区，并不是说你一定要切换一个计算领域，甚至要换一份工作。可能只是在工作或生活中，你可以及时地识别出哪些方面的技术或者能力相对比较薄弱，主动寻找机会来锻炼和提升，从而可以取得事业上更大概率的成功。

就比如说我之所以写这个专栏，其中一个很重要的原因就是：在平时参与项目中的模式经常是，快速解决问题然后就结束了，事后总结和提炼得非常少，所以给别人讲东西的时候会不太系统。而写专栏恰好也是挑战一下自己的非舒适区，来锻炼提升自己。并且，通过写专栏，我能够系统化地把性能优化的理论、方法和实践经验分享出来，让你有所思考、有所收获、有所成长，也带给了我足够大的动力，所以这里也非常感谢每位同学的支持与同行。

最后我还想说的是，千里之行，始于足下，课程结束并非是终点，我们还可以在留言区互动交流，也祝你享受成长，学有所成。另外，我准备了一份毕业问卷，希望你能花两三分钟填写一下，我也非常期待听到你对这门课的反馈。

好了，就到这里，我们再会。