1. 写在前面

        在图书馆瞎逛，偶然瞄见一本《Google 软件工程》Titus Winters, Tom Manshreck, Hyrum Wright 著。主要是在这一排的书架上就这本书看着挺新的（不知道为什么有一种喜欢看新书的情节），而且最近被领导老批评，怀疑是自己能力不足，所以就借回家翻一翻，总比刷小视频好吧。

2. 软件工程

        “软件工程就是随着时间而不断集成的编程。”实话说，被这个定义震撼到了。很简洁的一句话，并且把软件工程和编程的关系说清楚了。

        联系着软件工程和编程的一个关键参数是时间，而影响时间的关键因素则是变化，时间又影响软件的成本，成本是决策的一个关键参数，决策可能导致质量的衡量和改变。因此软件工程就是把时间、成本、质量的因素强加于编程行为的一项工作。呃，扯到了3要素有点熟悉的感觉。

        PS海勒姆定律：当一个API有足够多的用户时，在约定中你所承诺的已不重要：所有在你系统里面被观察到的行为都会被一些用户所依赖。后面这一句是我自己加的：无论这些行为是你故意为之还是失误所致！

3. 团队合作

        写下这段话之前，一直以为组织里面的每个人都按照制定好的规则做出行为就是合作。原来“合作”，并不是行为层面上体现，而是心里和行为的共同作用。真正的合作，应该是队友们在相互坦诚的前提下，互相补位，向着共同的目标干活。在一个优秀的团队中，MVP其实可有可无，尊重和信任才是关键。

3.1. 拒绝隐藏

        不要隐藏自己的不足和弱点，只有把自己的不足暴露出来，你的队友才知道怎么给你补位。这一项我以前也一直做不到，总是怕被别人知道自己的缺点，总是想在队友面前表现完美，以至于害怕失误，害怕尝试。Google的理念是，世界上没有那么多天才，绝大多数人都是凡人，都有自己的长处和短处，只有互补的团队，没有完美的天才。

        PS巴士系数：多少关键开发者被巴士撞了会让项目停摆。记得在前东家的时候，貌似全领域只剩下一个人都不会让项目停摆。

3.2. 谦虚、尊重和信任

        我接触过大部分的团队，谦虚一般是表面上的，大家在内心的深处其实并不那么愿意接受批评。从另一个角度来看，批评并不代表指责，回顾问题是为了解决问题，指责只会把问题复杂话，甚至会把借口误判为原因。

3.3. 无指责的回顾文化

        事情是如何发生的->事情是如何解决的->事情发生的原因是什么->以后如何避免事情的发生。

        再理性的问题回溯，都无法避免心理上的影响。在回溯这件事上，要求团队成员对当事人的尊重，也要求当事人的心理承受能力。“你越开放地接受影响，你就越有能力去影响别人；你表现得越脆弱，就显得越强大。”

        示弱和容错，是一个团队日趋强大的表现。

4. 知识共享

4.1. 提问

        提问是需要勇气的，帮助提问者提问的一个好方法则是营造一种提问文化。当发现身边的人随时无所忌惮的提出自己不知道的问题时，你还会对提问存在畏惧吗？当然营造提问的文化并不是一件简单的事情，可以从小团体开始。例如设立导师制，建设论坛，或者提问机器人等等，一切都是为了体现团队的厚脸皮提问文化。

4.2. 共享

        有厚着脸皮提问题的，就需要有耐心回答问题的人。然而对于无私奉献这一说恐怕不是所有人都能接受，毕竟大家只是打工混口饭吃。所以激励是一种很好的放促进方式，毕竟在积分奖励的刺激下，我才会坚持在CSDN上水。

4.3. 制度

        当每个人都进入了自己的舒适圈，谁还会在意那些微不足道的奖励机制呢。通过管理制度的要求，可以保证最低限度的文档交付，虽然这种方式下的文档成果一般是质量低下甚至更新不及时的。怎么说呢，每个人在一篇水文上修改一句话，终将也能打造一篇高质量文档吧。

5. 团队领导

        如果书上写的都是真的，那在谷哥干活真是一种享受，我情愿一辈子当码农。。。

        “谦虚、尊重和信任”，已经记不清楚这是第几次在书上看到了，这3个词概括了团队领导的核心要领。

        抛弃自我意识（谦虚、信任）、成为一名禅师（淡定、提问）、成为催化剂（建立共识）、移除障碍（争取资源）、成为老师和导师（共享知识）、设定清晰的目标、坦诚、追踪幸福感（你需要什么？）。不要用传统意义上的“管理”，要注重领导力、影响力和为团队服务。尽可能委派，不要自己动手。尤其要注重团队的焦点、方向和速度。

6. 大规模团队领导

        话说连小团队都怎么认真领导过的我，居然还在写大规模团队的领导学习笔记，真是讽刺！呃，好像曾经领导过将近30人的团队，不过当了逃兵。。。

        书上说优秀的领导者要满足“三个总是”，总是在做决策，总是不在场，总是在扩展。

总是在做决策：识别盲点，识别关键的权衡，决策然后迭代。

总是不在场：划分问题空间，子问题授权给领导者，调整与迭代。

总是在扩展：螺旋式解决问题，授权和安排专门时间，学会放弃，保护你的经历。

7. 度量工程生产力

7.1. 鉴别是否值得度量

        通过问题的形式开始：你期待什么结果，为什么？如果数据支持你的预期，将采取什么行动？如果得到一个负面结果，会采取行动吗？谁将决定对结果采取行动，他们将何时采取行动？

7.2. 根据目标和信号来选择有意义的指标

• 目标：期望达成的最终结果。
• 信号：用来判断我们是否已经得到了最终结果的东西。
• 指标：信号的代理，这是可以度量的东西。

7.3. 采取行动并跟踪结果

        提供建议，并将这些建议内置于开发人员的工作流程和激励结构当中。

8. 规则、评审和文档

        大多数工程组织都有管理代码库的规则，关于源文件存储位置的规则、关于代码格式的规则、关于命名、模式、异常和线程的规则。应用规则一是为了让别人能看懂你的代码，二是减少出错的几率。规则的落地可以通过工具，另一种方式是通过流程，也就是评审。

        代码评审有三个方面（另一位工程师、代码所有者和“可读性”认证人）。书上有一点是我从来没有意识到的，“对于经过了代码评审后的代码就不是你自己一个人的代码了，而是一个集体企业的一部分”。这种认识让我感觉到了团队的力量。(Critique)

        文档的类型包括：参考文档，包括代码注释，设计文档，概念文档，着陆页面。文档令人讨厌的地方在于，需要和对待代码一样对待文档，及时更新，否则文档的有点将会被过时带来的痛苦统统掩盖。

9. 测试

        测试是软件开发不能逃避的一环，特别是书上写到谷歌采用单一的代码库，并且没有使用任何代码分支，所有人的变更都是提交到代码库头部！关于测试的好处和测试粒度这里不详细展开，但是关于推广测试的故事却挺有意思——把测试宣传贴在厕所！让测试文化迅速在公司内蔓延。。。

9.1. 单元测试

        编写代码的同时编写测试，努力做到代码不影响已有的测试，新的功能用新的测试来覆盖。通过公共API来进行测试，而不是调用实现细节。测试行为，而不是方法。DAMP(Descriptive and Meaningful Phrases) 而不是 DRY。

9.2. 测试替身

        测试替身（test double）是一个对象或函数，它可以在测试中代表那个真实的是是实现，类似于特技替身演员替代电影演员的情况。测试替身的技术包括伪造、打桩、交互测试以及实际实现。

9.3. 较大型测试

        嗯，除了单元测试剩下的就是较大型测试。较大型测试的类型包括：一个或多个二进制文件的功能测试，浏览器和设备测试，性能、负载和压力测试，部署配置测试，探索性测试，A/B差异（回归）测试，用户验收测试，探针和金丝雀分析，灾难恢复与混沌工程，用户评估。

10. 弃用

        弃用是一个沉重话题，而且是一个艰难的决定，然而万物皆有终结时，该舍弃的终将要舍弃。正如书上说的，有两种处理问题的方法：一种是已经过时的，另一种是还没开发出来的。。。

         弃用的流程管理要素：流程负责人，里程碑，弃用的工具（发现、迁移和防止倒退）。

11. 版本控制和代码搜索

        单一版本规则：单一源，单一代码库以及绝不能让开发人员选择“我应该依赖这个组件的哪个版本？”，尽管单一版本规则并不是普世的。（Monorepos）

        代码搜索工具能够帮助开发人员理解代码，进而极大地提高工程生产力。(Google Code Search)

12. 构建工具

        虽然所有事情都可以通过编译器和脚本来实现，但是对于一个大规模代码和团队来说，构建工具的作用无可替代。构建工具包括基于任务型的和基于构件行的，基于构件的构建系统能够提供分布式构建能力和依赖管理。（Bazel）

13. 静态分析

        静态分析指的是分析源代码的程序，用以发现潜在的问题，如缺陷、反模式等，在不执行程序的情况下就能诊断出问题。

        静态分析工具需要集成在开发者工作流中，作为预编译的一部分。（Tricorder）

14. 依赖管理

        说实话这章没看懂，只记住了一句话：如果能使用源代码管理，就不要做依赖管理。

15. 大规模变更

        大规模变更(LSC)是逻辑上相关但实际上不能作为单个原子单元提交的任何一组变更。大规模变更是由系统的基础设施团队负责执行大部分工作。

        大规模变更需要的基础设施包括：：政策与文化，代码库分析，变更管理，测试和语言支持。

        大规模变更流程如下：

1. 授权：写一份简短的文档解释变更的原因，对代码库的影响，以及潜在评审者可能提出的问题的答案，向专家委员会申请授权。
2. 变更创建：变更过程应该尽可能自动化，以便当用户退回到旧的版本。
3. 切片与提交：Rosie根据项目边界和所有权规则将一个大的变更分解为可以原子提交的变更。然后将每个对立切片的变更放入单独的测试-邮件-提交管道。

16. 持续集成

1. 定义：对我们整个复杂而快速演进的生态系统的持续组装和测试。
2. 快速反馈循环：编码/编译-》预提交-》提交后构建-》发布候选-》版本测试-》生产测试

17. 持续交付

1. 将部署分解为可管理的单元；
2. 特性开关；
3. 力求敏捷；
4. 只发布有用的功能；
5. 更早地做出数据驱动的决策：如果全面性测试实际上不可行，则以代表性测试为目标。灰度发布。自动化的A/B发布。
6. 建立发布规则；

18. 计算即服务

         嗯，这章也没看懂。

19. 水在最后

        每天晚上看一章到两章，终于把这本书看完了，其中依赖管理和计算及服务这两张确实是没看懂，主要是工作经理上对这两章的内容并没有涉猎。看了也不知所以然。。。

        好吧，接下来看点没那么大局观的书，把思想收一收