本来以为是一本偏软技能的普通书籍，同事推荐的书，感觉可以看下，另外还有一本是《卓有成效的管理者》，最近看短视频看到个观点，当你看一本书的时候，如果当时你对它的感触不够深，但是后面当你重新翻看的时候，你会惊喜发现为什么当初都没有注意到书中的观点是那么精辟一针见血。其实是因为你当时自我所处的现状和书中的内容无法匹配，所以无法深入去理解到书中作者站的位置去读懂作者想要表达的意思。所以对于这两本书，我选择了先看工程师篇，毕竟还没达到管理者的境界，不过感觉也可以抽空看下，也许也会了解到一些工作上的处事方法论。作为一名测试工程师，书中的部分理论其实对工程师的要求还是通用的，可以学习一下。

最近写了些技术相关的文章的时候才觉得，很多观点其实我只是了解了基本的一些概念，可能脑子里知道这个东西是做什么的，例如这两年公司一直推行的卓越工程文化，其实和这本书很多观点都是相似的，但是如果让我总结说一些卓越工程例如像代码CR ,单测覆盖，自动化覆盖等这些基本的要求，其实我能想到的东西并不是很全面。 所以，其实总结很重要，也许一开始很难用自己的话去把一些观点说的比较全面，但是也可以参考别人的观点先输出，还有一个问题就是，我自己了解到的一个观点，例如像CR 的要求，最近也会去看一些开发的CR 记录，感觉也是一个学习的角度，我第一反应应该是需要每个开发认真去对待，多方交叉评审，注重代码的可读可扩展性，但是如果用123点简明扼要的概述去总结，好像就有点写不出来了。所以从多输入到多输出，是一个不断积累的过程，后面想写一篇关于公司卓越工程文化的总结。

回到这本书的主旨，作者埃德蒙.刘其实是一位谷歌优秀的工程师，然后到后面自主创业，从书中其实可以看到在软件工程，项目交付的过程中，很多理念其实还是和国内一致的，好像没有特别新颖的点，但是看完其实也会有一些感触，优秀的工程师其实在项目中不断创新实践，长期学习，注重杠杆率（ROI）,将有限的时间投入到最有价值的工作上。好像有点老生长谈，道理都懂，实践起来却很难，但是有时候我们就是需要潜移默化去改变我们做一件事情的习惯。总结一下书中一些让我印象深刻的地方，其实核心主题是从端正态度-->执行-->构建长期价值。

 

01

杠杆率

 

杠杆率=产出的影响/投入的时间 ， 其实书中很多部分都提到了这个杠杆率，其实就是投资的回报率（ROI）,另外还有一种对杠杆率常见的解释就是帕累托原则或80-20原则 ：就是对于大多数工作而言，80% 的产出源于20%的工作。这20%的工作就是高杠杆率的工作。所以，提升杠杆率要么减少时间，要么增大分母，要么转向其他更高杠杆率的工作。工作不一定有产出，而且许多工作并不直接贡献有用的产出。所以对高杠杆率工作进行优先排序的方法是关注直接创造价值的工作，但是有时候我们也需要抽出时间去投入那些重要但不紧急的事情，这里面往往会对后续产生大的提效，而不是一直被重要且紧急的事情搞的分身乏术。适时调整工作优先级，少并发处理多件事情。要不大脑的能量就耗费在多件事情的来回上下文切换了。

02

复利效应

 

心理学家卡罗尔.德韦克研究发现：我们看待自身效率的方式会影响我们在提升效率的投入。书中有个关于学习复利的解说还挺印象深刻的，何为复利效应，来源金融行业概念，就是一旦利息被加到存款的本金中，就会在未来产生复利。当你学习的东西积累到一定程度的时候，后面就会出现拐点，由平滑向指数型增长。其实就是知识为我们奠定了基础，能够让我们更快的学习更多的知识。越早对学习进行优化，我们的学习就有越长的时间去产生复利，并且微小的变化其实对增长率长远看来十分重要。所以我们需要将时间花在更有挑战性的工作和学习上，才能产生复利效应。例如每天抽出一两个小时学习会比每周抽出一整天更有效。对积极心理学的研究表明，持续学习与幸福感提升密不可分，数据统计，人们在看电视的平均情绪是轻度抑郁的。这个统计让我蛮惊讶的。

 

03

项目投入估算

 

这一部分总结的几点感觉很精辟，如果按我自己第一时间的观点，项目估算要合理评估时间，任务细分，让执行者去评估所需时间，并预留buff ,好像除此外，能想到的点就没有了，那么看下作者的总结，明显完善太多。

• 将项目分解为细粒度的任务
• 根据任务需要的时间进行估算，而不是根据自己或别人希望花多长时间进行估算
• 将估算结果视为概率分布，而不是最佳情况。（ 一般估算结果是最乐观的估测，其实现概率大概为0）
• 让执行实际任务的人来做估算
• 谨防锚定偏差 （就是随意或者快速依据经验估算一个值）
• 使用多种方法估算同一个任务
• 根据历史数据验证估算结果
• 使用时间盒限制任务范围
• 允许他人质疑估算结果

 

04

代码审查

Facebook前工程总监鲍比.约翰逊声称："从对与错的角度思考，并不是一个非常准确或者有用的的观察世界的角度，与其说对错，我更愿意从有效或者无效的角度看待事情，这样更能够帮助我理清思路，更有效的做出决策。" 这里作者举了个例子，谷歌里面有一套完善的工程实践，提交的代码有严格的审核流程，这样一方面有利于后续的代码维护，但是这也会做成对代码质量的过度投资，ROI 变小。所以，不是所有的公司都适用于谷歌的流程，记得之前团队内推行过主干开发，大库提交代码，但是后面也进行不下去了。这或许就是有效和无效的决策方式。

作者提到一个关于代码质量的点还蛮不常见，代码质量其实也具有传播效应，新入职的软件工程师以他们看到的优秀代码为榜样，来改进自己的代码，从而形成一个正反馈。那么CR 有什么好处呢？我自己的理解就是提前发现问题，提前暴露风险。作者关于这个写了几点：

• 尽早发现错误或者设计上的缺陷
• 增加做代码变更时的责任心 （有人监督和无人监督的区别）
• 为如何写好代码进行积极的示范
• 分享代码库知识 （当你分身乏术的时候，有人因为熟悉这块代码可以帮忙解决）
• 增加长期的敏捷性 （代码质量越高，改起来就越快）

 

05

代码抽象

 

这个听的不算特别多，但是原来这个也是属于软件设计十分重要一part. 抽象是如何提升工程生产力的 ：

• 抽象可以将原始问题的复杂性简化为更易于理解的原语
• 抽象降低了应用程序的维护成本，使未来的改进更容易应用
• 抽象一次性解决难题，且解决方案可以多次使用

 

上面是一些比较印象深刻的观点，其实的一些看的过程中感觉还蛮精辟的，但是不太有比较鲜明的印象，基本上很多方法论其实核心点自己是知道的，但是如何用文字或者语言表达出来，还是要多写多总结，才能融汇贯通