软件工程的意义在于能够快速响应变化。
1. 前言
只看书名就知道这本书属于必读之物，尤其对于像我这种身处传统软件行业技术团队的从业者 —— 多年经历让我明白技术并不是发展的桎梏点，而恰恰相反的是整个公司对于规范化和流程化的重视程度，技术团队对于软件工程的认知以及执行情况，才是作为一家软件公司规模持续扩大，并且走得快、走得稳的关键。
整本书很厚，中版多达570页左右，叠加我这么多年也是阅读了诸如《人月神话》，《构建之法》等多本软件工程经典著作，所以虽然书名让我有着一睹为快的冲动，但实际执行起来发现还是步履维艰，随着年龄的增长，发现很多时候宁可刷刷抖音都不愿意拿起书本。
最后想到个讨巧的办法 —— 把书放在单位，早上8:30 - 9:00的时间，采用蚂蚁搬家的战术，一点点把这本书给磨下来。
最终历经半年多，终于有了这篇读后感。
2. 全书印象
有了多本相关经典的铺垫，以及过往多年来未曾敢放下手上的书籍，所以这本书中的绝大部分知识点对于我而言，并不会感到陌生。
而在翻开这本书之前，我也未曾有过非常高的期待，借着一本有着权威性的书籍，能够结构化，系统、全面地了解相关领域知识，帮助补充完善自己的知识体系，并且将自己对于该领域的总结与业内一流实践和理论进行对照。
看到自己平日里搜肠刮肚，反复迭代的总结被理论化地总结并且详细解答出来时，就会感觉这本书买得值。
整本书以二十五章节，从理论、文化、流程、工具三个方面阐述了三个基本原则，以及Google对此的探索，以及当前的解决方案：
- 时间如何影响软件的可持续性，以及如何使代码随着时间的推移而具有韧性。
- 规模如何影响工程组织内软件实践的可行性。
- 在评估设计和开发决策时，一位典型的工程师需要做出哪些权衡。
3. 部分摘抄
3.1 非职权影响力
让组织之外的人去做你认为需要做的事情。
关于这一点在过往读过的多本书籍中都有谈及。这项能力的构建需要刻意，需要时间，需要持续性地建设。你需要小心翼翼地培育它，如履薄冰地呵护它；等待在某个时刻，你需要在自身权力无法覆盖的范围外推进某些前景尚不明确，但却是你职业生涯必经之路上的计划时，它将是你最大的依凭，而这个依凭完全取决于你的个人魅力 —— 非职权影响力。
3.2 问题分为两个领域
对问题负责，而不是对解决方案负责。
这种现象在公司中很常见，尤其是在面对部分不称职的所谓"高级人才"时 ：
- 他总是跟你就眼前的问题细节掰扯，你说得稍微深入一些，他就给你往旁边拉扯，有时候你真的怀疑他是认知不足，还是根本就是故意的？
- 你希望他能够就着眼前的问题，能够深入研究之后发展为解决一类问题，借着本次问题对整个产品做一次迭代，让产品的新版本中不再出现类似的问题（不仅是同样症状和原因的同类问题，而且是底层逻辑相似的近似问题都应该被杜绝）
- 很可惜，满足这样要求的高级，甚至资深人才，我这么多年的职业生涯里所见甚少，这也许与我这上学期间过于贪玩有关。
针对本小节的解释，书中使用了两个例子：
- 针对Google搜索慢的问题，合格的工程师除了处理延迟症状的工作，还需要处理延迟原因的工作。 解决了前者就觉得万事大吉的，配不上工程师这个称谓。
- 负责一个问题，而不是一个解决方案。例如你负责的是提供"版本控制"这个问题的答案，而不是"管理GIT仓库"这么个解决方案。
3.3 希望不是一种策略
工作或者生活中，总能够在事后听到诸如"我们也是希望把它做好的"，“要是XX就不会出现这个问题了”。
每次听到类似的言论，我心中就有千万只草泥马奔腾而过，你在这里假设有个毛线用？你当时就意识到了这个问题，你采取了哪些措施进行减缓性规避，以及做了哪些提前预警并进行了留痕操作。我一点这样的操作没看到，而你也只有一个我跟xx说过这种无法被证伪的论据，我是真的很怀疑你这所谓的高级职称是怎么升上来的？
3.4 作为领导，你的工作是做那些只有你能做的事情。
这个建议主要针对那些刚刚迈上管理岗位的技术型人才。
他们因为自身能力强而很容易陷入：
教你怎么做还不如我自己上 --> 下属没有成长的机会 ---> 所有的事情都亲自上 --> 下属更没有成长的机会 --> 自己累得半死，下属还觉得没有成长空间。
作为领导，最重要的意识之一就是要学会放权。 你要有"眼睁睁看着下属把事情干砸"的定力，然后在下属失败后再介入告诉他如何才是正确的方式。
作为领导，非常重要的一件事就是学会将精力放在重要的事情上，而不是紧急的事情上，以下是一些方法来帮助你：
- 授权。将紧急但不重要的事情交给下属去做。
- 安排专门的时间。定期抽出两个小时或更长时间安静地坐着，只做重要但并不紧急地事情。例如团队战略，或者你计划如何与周边团队开展合作的事情。
- 找到一个有效的跟踪系统。将TODO LIST负载从大脑中移出来，大脑是用来思考的，不是用来记忆的。关键是你要尝试不同的系统，并确定什么适合你。
3.5 牛 VS 宠物
这里面有两层含义：
- 前者表示稳定性高，不需要投入过多的维护成本。后者则是一点小事就要死要活，一幅要马上断气的感觉。
- 后者往往由个别工程师完成，所以很容易产生个人绑定，对其的质疑会被怀疑是人生攻击；前者则往往规模大，且自动化完成，不在乎小规模损失。
3.6 CI/CD是必备品，而不是奢侈品
这句放在页脚部分的句子真是深得我心。
工作中遇到不少团队，整个产品迭代过程中，如果没有演示需求的话，甚至可以一两个月都不进行一次CICD；还有"因为每天只需要打包一次，所以打包耗时长一点没关系"的论调 —— 我听到这样言论的时候，我是真想当场开除这个货 —— 不是每天只需要部署一次，是每天只能部署一次，就是因为你丫把打包做得这么慢，导致了每天只能打包一次，倒果为因，你小子是何居心？你是认知不够还是故意的？前者是能力问题，后者更严重 —— 态度有问题。
"必需品"是什么意思？就是如吃饭喝水一样。不是正在做，也不是马上开始做，更不是计划要做，而是产品被立项，开始编码那一刻起，就应该同步进行。
3.7 一个组织长期成功的关键
- 任何一个组织长期成功的关键始终在于它能够将想法尽快付诸实施并交到用户手上，并对用户的反馈做出快速响应。
- 不要让"发布成功"成为一个高度人工参与且劳动密集的工作。这一点在中小规模的传统软件行业非常普遍。每次发布都如临大敌，需要大量的前置准备时间，稍微一点预期之外的事情发生将直接导致加班，甚至延期现象的出现。
- 频繁发布使得每次变更的内容少，从而更容易定位和解决问题。
- 更快就是更安全。理由同上。
- 运行处理程序的成本不应该比编写处理程序的成本高。 这一点真是戳到我过去这两年的痛楚了。
3.9 简单的事情要简单处理，复杂的事情要尽可能简单化。
形成鲜明对比的是现实工作中，不少秉承着"简单的问题复杂化"，以此增加个人职位的不可替代性的骚操作。
3.10 可持续性的思想是软件工程的核心。
产品决策时候要谋长远。
即使迫于眼前形势，必须选择那个短视的选项，那也应该是在取得共识的情况下，留下足够的痕迹，让后来者知晓当时为什么这么做？而不是满眼的糊涂账，一切只能归结于历史原因。
如此，才能算得上高级工程师。
3.11 可访问性
对于需要团队内部知晓的信息，应该放在一个公共的位置，其他人可以通过非常便捷的方式访问到 —— 比如浏览器。
以上其实是我个人对这个名词的解释。职业生涯里我也确实发现不少团队，你说它讳莫如深，藏着掖着吧，你问它问题它也如实相告，但就是与它们合作的时候，每次出现点什么问题，都能够给你搞成会诊，刚讨论两句话，就得拉进来另外一个人，因为只有这个人才知道这部分信息，而且这部分信息团队其他成员是无法知晓或者在知识库里找到的。
3.12 精力管理
这本来是书中最开始部分的内容，我特意放在了最后。
- 享受真正的假期。周末不是假期。至少花三天时间"忘记"你的工作，至少花一周时间来彻底恢复精力。这里的意思是你要彻底断开工作的联系，让自己全身心投入到假期中。
- 让切断联系变得轻而易举。 将电脑留在办公室，不要将工作手机带在身边。
- 享受真正的周末。虽然周末不等于假期，但思路是一样的 —— 彻底断开与工作的联系，这样的"充电"才会起作用。
- 白天小憩。大脑是以90分钟为周期在进行运转。你也要遵循这个生理规律，每个间隙里花10分钟做下简单的热身运动 —— 比如散户什么的。
- 如果发现当天无理由地情绪低落，那就给自己放一天假吧。不要为此有心理负担。
4. 后记
长达半年多的阅读时长，等到写下这篇笔记的时候，其实能够留在脑海里的概念基本也没剩下多少了，本篇其实更多是留给未来的自己一个锚点 —— 自己曾经完整地读完这本著作，以及里面的关键信息有这些。
如果你之前没有过相关的理论知识储备，而当下或主动或被动来到了一个团队管理者的角色，那么非常推荐这本书，它会是你一个非常好的起点。
5. 相关
- Software-Engineering-at-Google
- 走出软件作坊 - 文集 - 简书
- 《精益产品开发》读后感
- 《构建之法》读后感
- 《走出软件作坊》读后感
- 《人月神话》读后感
- 《进化——从孤胆极客到高效团队》读后感
- 《精力管理》读后感 - 简书
- 帕金森琐碎定理 --- 大型组织会花费大量时间在讨论无关紧要的琐事，但是真正重大的决议反而可以轻松过关这种现象。
