引言
我成为技术主管已经超过一年半的时间，在日常工作中，我会持续召开回顾会议来总结学到了什么，以及如何在将来有所提高。我一直都觉得这些事情对我个人和职业生涯都非常有价值。因此我决定大概每周做一次这些相关内容的分享，同时也便于某些读者发现其中可能的价值。另外我也经常致力于自己的专业发展，这是巩固以艰难方式获得的所有知识的一个方法。
经验教训
应对风险
作为团队里的技术负责人，我的主要任务是客户维持（或者用最新时髦语言来说就是“客户至上”）。这意味着我们要处理高度加剧的客户投诉和请求，紧迫的截止日期，有时我们不断被要求在巨大的压力下进行交付。
这很容易理解，因此，在处理此类关键问题时，要考虑风险。这不是我所要说的，因为在这种情况下没有必要过分夸大风险。
我要说的是在日常工作中如何应对风险。我见过和必须处理的最灾难性事故是发生在粗心大意、“无害”的小任务之后。例如一个小代码优化破坏了核心的、关键的、未经测试的功能，由此造成的数据混乱完全毁坏了每个客户账户；还有一个标志里面的拼写错误导致了一次彻底的服务中断；或者开发人员在小功能上自以为是的没有和产品或设计人员确认，等等。
我们绝对不应该低估我们正在改变的事情的风险。这是了解我们的测试应该如何进行、最坏的情况和缓解策略，甚至确定在现有资源下是否值得改变的最佳方法。
如果责任方能够恰当的理解他们实现部分的风险，许多导致整个团队熬夜加班或“整周工作”（我只遇到过一次，当时我不得不每周轮班超过 14 小时，在那时，我一生中从未对决定成为一名软件工程师感到如此遗憾），本都是可以避免的。
异步工作和同理心
曾经与我们团队的项目经理有过一次谈话，顺便说一下，他绝对是个摇滚明星。我们讨论了我们目前在处理的产品方面的分歧问题，这已经成为项目就绪的阻碍，还讨论了未来几个月需要完成的工作量，以及这如何真正的影响团队之间的沟通问题。
因为我们是一家完全远程工作的公司，所以我们几乎没有时间在午餐或者下班后了解项目进度相关情况。由此我们唯一能够使工作继续进行的方法只能是反复的沟通我们的任务，碰到的问题等等。
那次谈话的主要收获是：要富有同理心，所以我们都尽最大努力使用更多的slack即时消息、Jira 评论、邮件等等各种可能的办法，同时去了解其他团队成员正在面对的压力，并试图提供各种帮助，即使这样做是“烦人”或者繁琐的。
本周阅读或学习的内容
如果您看了我上周的分享，您可能记得我从上周开始就开始阅读两本大部头书籍：《谷歌的软件工程》和《测试JavaScript程序》。本周我基本上全部都已经读完了。下面是我的一些想法。
《谷歌的软件工程》 - Winters, Manshrek & Wright
这本书的后半部分更多的关注工具，以及谷歌那种规模的公司面临的真正具体问题。书中提到大量充满智慧的黄金法则，但我艰难的只是理解了一点。前半部分写的非常棒，谈论了很多文化相关和更广泛适用的建议。
尽管如此，但由于本书大量的主题都是按照章节划分，所以我将要点分为不同的部分：
弃用规则（Deprecation）
- 作为软件工程师群体，我们在构建新项目时从来没有考虑过弃用规则。但是这就意味着我们要么需要构建某些能够持续整个组织生命的东西，要么就要开始弄清楚在适当的时候如何最终结束某个项目。
- 建议性弃用：不是要求有意的立即终止旧代码，只是鼓励用户迁移到新系统。为了达到此目的，需要有一个彻底的改进的更新过程，即便如此，您依然会面对各种阻碍。
- 强制性弃用：它附带了一个最后期限，用来移除淘汰的系统。
- 各种弃用规则需要是可执行的，并且要有关联性。可执行的意思是需要有务实的指南来指导如何迁移到新系统；关联性的意思是要显露一个用户实际完成了指示的步骤。
- 要弃用的项目应该有对应的负责人和一组定义好的里程碑。如果您唯一的里程碑是移除项目，那么这不会产生太大的动力；如果没有负责人，这基本可能就意味着您将不得不永远继续维护老旧系统。
版本控制
- 单独的 VCS 是不够的，一个健康的系统包含一个复杂庞大的 VCS（集中式或分布式）和复杂健壮的策略。
- 超长时间的 dev 分支会成为维护的巨大负担。
- 当使用 VCS 的时候，一个版本规则是最好的策略。继承克隆（Forking）或者多个版本是相当难以处理。
构建系统
- 限制软件工程师的灵活性和权力能够极大地提高他们的生产力。
- 谷歌对第三方组件也强制采用严格的单版本策略，这样可以规避多个编译依赖同一组件的多个版本的问题。
静态分析
- 主要关注点是开发人员的幸福感。他们是最终用户，提高开发者体验（DX）应该是主要优先级
- 开发此类系统最重要的指标是有效发现假性正反馈。
- 通过授权用户做出贡献，这样您就构建了一个可维护和可扩展的系统。
其他要点
- “我让它工作了”和“它在以一种辅助的方式工作”有着巨大的区别。在进行依赖管理时，海鲁姆定律是非常需要深入考虑的事情。
- 公共 API 的教训：一个 API 的外部用户群比内部用户需要更多的维护开销。
您可以从这里获得本书。
《测试 JavaScript 程序》 - Lucas da Costa
本书的后半部分大量的关注了 UI/React/E2E 等生态系统。我发现了几个特别有用的建议，而且最后关于 CI/CD 的部分是非常好的读物，尤其是对那些没有怎么用过 CI/CD 的人们。
我写了带有很多实际例子的文章，本书就是主要的参考。如果您感兴趣，可以在这里找到这本书。
下面是我记录的一些要点：
- nock 是模拟 http 调用和请求的一个很好选择。
- 如果您不相信测试，那么它们运行的如何快或者多么容易更新就不怎么重要了。
- 测试应该始终是确定性的。我们甚至可以说，非确定性测试是无用的，因为测试的全部意义在于给您的开发过程带来信心。
- 经验法则：您应该模拟您无法控制的一切（在进行小规模测试的时候）。但这不是一张免费通行证，可以让您模拟您项目中的一切，比如并发或时间依赖代码。
- 为了使测试具有确定性，它们总是需要被赋予相同的初始状态。
- 关于测试金字塔：不要将您的组件与React隔离，仅仅只是为了将测试标记为“单元测试”。React用于渲染和更新组件的逻辑是应用程序工作的必需的组成部分。
- 安装文件可以节省您每次编写大量样板代码。这可以是请求拦截器，甚至是JSDom中缺少的全局属性。
- Jest的快照测试功能被低估了。有了它，您可以对数据进行序列化并对其进行测试，而不是写一堆复杂的断言。
- 用户场景故事是实现 UI 工业化的重要步骤。
- 关于TDD：通过在修复错误之前添加一个测试，这样您就可以确定这个测试能够检测此特定错误是否存在。一旦您在解决错误后编写了测试，您就不太确定测试通过是因为缺陷已经解决，还是因为您的测试没有发现这个错误。
- 构建正确的软件与正确构建软件同等重要。
- 尽早交付，并经常将重点从编写尽可能多的代码转移到提供尽可能多的价值。
- 自动化测试是团队能够进行连续交付的最重要技术，因为它允许您以几乎零成本（准确地说是亚线性成本）增加交付频率。
- 代码审查旨在捕捉机器无法发现的问题。
- 产品发布功能的请求应该是非常清晰的对话。
