📖 Google 软件工程 读后感 Part I
date
Sep 20, 2022
slug
software-engineering-at-google-impression.html
status
Published
tags
tech
reading
software-engineering
google
summary
有趣的比喻集合
type
Post
总的来说，这本书值得所有软件开发从业者阅读。一些观点可能不至于奉之圭臬，但也可以提供另一种处理问题的视角。
它将很多存在于意识而尚未落成语言的软件工程共识，用简单易读的方式总结表达了出来，相信对于大多数软件工程师都会有帮助。
分享书中一些有趣的说法，如果你也觉得有意思，那么就买来读一读吧。
（如果你的「洋文🤓」够好，也可以直接免费阅读 英文原版）
海勒姆定律（Hyrum’s Law）
当一个 API 有足够多的用户时，在约定中你所承诺的已不重要：所有在你系统里面被观察到的行为都会被一些用户所依赖。
我从中读出来的关键点：拒绝侥幸心理。当用户体量足够大时，任何改动都需要通过测试来收尾，侥幸心理自认为某些逻辑人畜无害，一两次可能可以省事儿，但总有一天会翻船。
巴士系数（Truck Factor）
指多少关键开发者被巴士撞了会让项目停摆。
开发者被巴士撞了虽然有点残忍，但确实是一个很形象的表述——当成员突然不参与工作或失去通讯能力。可能在很多团队中，开发者的突然离职是更贴近这种场景的情况。想要尽量避免因为关键人物的离开而导致项目停摆，书中也列举了基础的预防措施：备份或者结对编程，“每一个人在工作时都需要第二双眼睛的监督”，最重要的是 “拒绝隐藏”。
就我个人的经验而言，在项目开发过程中保持良好的文档记录习惯是一种“美德”，在一些更有追求的团队，更应该是“义务”。良好的文档可以一定程度上保持当“巴士”袭来时，团队能够依靠文档维持相当程度的稳定。
当然以上都是从 “团队最优” 的角度来说，并不是所有公司都有 Google 的优秀风气，我还在别的团队听过”教会徒弟，饿死师傅“的说法。
这其中孰对孰错，是分享还是私藏，很难在这篇读后感中用几百字讨论清楚。
我们需要保持清醒：互联网从业有它的特殊性——知识获取门槛极低，任何领域都可以通过网络资源轻松入门，但同时也有其他行业相似的普遍性——在资本逐利的背景下，行业失去高增长，更低成本的人力总是会更有竞争力。
左移思想（Left Shift）
在开发人员工作流的早期发现问题通常会降低成本。
配合此图，还是非常容易理解的。从开发人员的角度来看，可能存在的问题在越前端解决付出的成本肯定是越小的。举个小例子，陶文在 《不要以 DRY 之名，发明低代码 DSL 去残害你的同事》提到过，缺乏与上游（比如产品、策划）的沟通，只是在开发侧 “一厢情愿” 的抽象可能是一个误区：“先要把需求的源头给按住了。而不是在需求的下游，用可复用抽象代码来兜底”。
类似地，在敏捷开发和 DevOps 开发理论中也提到过 ，同时还有一个 “测试右移” 的概念，在测试或者是性能检查时，尽量从贴近用户端出发来保证整个产品流程的质量。
经理人炎症（Manageritis）
对于处于进步边缘的有抱负的或者那些刚刚晋升的领导者，存在一种高度危险的自我炎症，称为“管理炎”。
更简单说法是 “刻意管理”，这种症状多数出现在从个人贡献者 → 管理者身份转变期。很大的原因是，作为技术开发者，我们已经很习惯于在专业技能上投资，并有着合适的回报预期：比如定期在某个领域深入学习，你就能立马获得该领域的技能提升。但是转变到“经理”时，这个回报周期变得不一样了（通常会更长），带领团队向上提升，个体的技能成长反而不容易被感知，会导致做出更高频次的“投资”动作，更加”努力管理”，更容易显得刻意。
还有一个方面的原因，从个人贡献者到管理者后，将会面临很多抉择的场景：自己动手，快速解决问题 vs 交给他人，更慢更困难地解决问题，及时从更长尺度上来看，后者收益会更高，但在这个抉择面前，没有经验的管理者还是会显得非常犹豫。
碧昂丝规则（Beyoncé Rule）
“如果你喜欢它，你就应该测试它”。
原型是："If you liked it then you shoulda put a ring on it”，来自于碧昂斯 Single Lady(Put a Ring on It) 歌词（我感觉关联性不大，我猜是碧昂斯粉丝的私货 🤣）。
意思是“所有不想被破坏的东西”都应该被测试。当你的项目依赖于某些外部系统时，如果想确保一些特性能够符合预期，那么唯一的办法就是在自己的项目编写测试。
这一点容易被泛化到外部系统的所有特性，我的理解是需要妥善处理依赖的外部系统常见的重点场景出现异常的情况，而不是全部，也不应该关注全部。
在 Google 内部常有一种说法：“如果一个产品由于基础设施的变更出现中断或其它问题，但是在我们的持续集成(CI)系统中的自动化测试用例并没有发现这个问题，那么就不应该由负责基础设施的团队承担责任。”
在我们日常的工作场景中，大家普遍是没有这个意识的，如果基础设施出问题，无论我们是否有预料，黑锅都可以毫无负担的甩下去，也造成基础设施部门普遍承受了过多压力 xD。
Fin
书中还有一些更大值得讨论的话题，以后或许有机会可以结合自己的项目经历写出来聊聊（典型的挖坑不埋）。