引言

我成为技术主管已经超过一年半的时间，在日常工作中，我会持续召开回顾会议来总结学到了什么，以及如何在将来有所提高。我一直都觉得这些事情对我个人和职业生涯都非常有价值。因此我决定大概每周做一次这些相关内容的分享，同时也便于某些读者发现其中可能的价值。另外我也经常致力于自己的专业发展，这是巩固以艰难方式获得的所有知识的一个方法。

经验教训

耐心是领导所需的最大技能之一

我挣扎了很久的事情是，有时我对团队的开发工作没有足够的耐心。我的团队绝对棒极了，他们每周都超额交付，每个人都非常专注于尽力而为。然而，有时我完全错误地期望他们应该更快地交付，只是因为“我可能会做得更快”。

首先，我甚至不确定这（自己做的更快这件事）是不是真的。与业内任何其他开发人员一样，我本人拥有糟糕的估算技能。
其次，我之所以可能能够做到这一点，是因为我在公司待的时间更久，或者我就是构建模块的人，所以我有更多的背景，或者只是我编码的时间更久。

授权并不容易，我需要做得更好，不仅在授权行为上，而且也要在更好地理解和管理期望方面。^(委派工作并不容易，我需要在这方面做得更好，不仅在委派的行为上，而且在理解和更好地处理期望方面。)^

影响力是经理最好的工具

影响力从概念上讲是某个特定的行为或动作能够成为一个团队、部门、甚至整个组织的催化剂。

回应电子邮件可能对接收方产生很大的影响，但这只影响了一个人。然而如果我正确地优先考虑一个功能，它可能会影响数百甚至数千名客户。

下周我打算做的事情之一就是评估我的各种行为的影响力，以便于我才能更高效的工作。当然主要是因为我的精力非常有限，想避免倦怠。

本周阅读/学习的内容

《^(可以用四级标题)^​****​》^(可以用四级标题)^

到目前为止，这可能是今年最好的软件工程类读物。这本书需要一周多的时间才能读完，下面是我阅读完前半部分的要点：

1. 软件工程和编程随着时间推移而逐渐融合
2. 海勒姆定律：“有了足够数量的API用户，您在合同中承诺什么并不重要：因为总有某个用户会依赖系统中所有可见的行为。”
3. 停滞是一种选项，但常常不是高明的那一个选择。
4. 独自工作本质上比与他人一起工作更危险。这被称为公共汽车因素，即”在你的项目完全注定要完成之前需要被公共汽车撞倒的人数“。^(独自工作本质上比与他人合作风险更大。他们称之为“巴士因子”，即“在项目彻底失败之前，需要被巴士撞到的人数”。)^
5. 编程可以单人进行，但软件工程是一项团队努力。
6. 谦逊，尊重和信任。不要低估社交的力量。
7. 人际关系比项目更长久。
8. 总是提问，总是学习。
9. 切斯特伦栅栏原理：除非您知道最初为什么立起来的栅栏，否则不要移除它。
10. 成为专家且保持友善这两者并不冲突，笨蛋不会成为好的领导。
11. 领导不该做的：不要妥协雇佣标准；不要像孩子一样对待您的团队；不要成为每个人的朋友；不要忽视人为造成的问题；不要雇佣老好人；不要忽视表现不好的人。
12. 领导该做的：减少自尊心；成为一个禅师；排除障碍；成为一个老师和导师；设置清晰的目标；保持诚实；追求幸福。
13. 导师的职责最终归结到三件事件：使用团队流程和系统的丰富经验；向他人解释事情的能力；以及衡量学员需要多大帮助的能力。
14. 当从情感上很难那样做事的时候，要快速进行处理。^(在情感上越难处理的事，越需要迅速采取行动。)^
15. 管理精力和管理时间同等重要。
16. 近藤麻理惠规则：专注于20%的高优先级任务。
17. 代码审查是知识共享的绝佳工具。
18. 把文档视为代码，可以极大提高可维护性，质量和主人翁精神。
19. 您不应该成为写文档的技术作家，您只是需要英语，并像对待代码一样谨慎对待它。
20. “如果我有更多的时间，我会给您写一封更短的信”。
21. 测试在代码检查时应该是显而易见的。
22. 测试对编写它的开发人员非常有用。但应该文档化，为读者编写（阅读代码的比编写的要多得多）^(测试对编写它的开发者非常有用。代码被阅读的次数远多于被编写的次数，应该为读者编写关于代码的文档。)^
23. 与其为每个函数编写测试，不如为每个行为编写测试。
24. 行为是系统对在特定状态下如何响应一系列输入做出的任何保证。
25. ”Given，When，Then“。或者AAA框架，不管使用哪一个，最好用至少一个空格分割，这样读者就能更容易理解测试结构。Cucumber 或者 Spock 直接可以做到这些。
26. 在被测试的行为之后命名测试。^(在完成测试行为之后命名测试。)^
27. 共享测试初始化既可以是祝福，也可以是诅咒。仅仅为了DRY（不要重复自己）而写它时要小心。
28. 务实要高于隔离，因为模拟（mocking）太多会导致脆弱的测试 （我亲身体验过这一点）

和前一本书一样，一周的时间很难消化如此庞大的信息，但这本书对所有使用 node.js 的人员来说是非常棒的读物。

Lucas da Costa是您希望来教自己如何测试JS程序的工程师，因为他是 sinon.js和chai.js 的核心维护者，同时也为Jest做出了贡献。本书里大量有用的技巧，清晰的定义以及各种实践示例，因此我强烈推荐本书。

下面是我目前为止整理的一些要点：

1. 唯一有用的测试是当您的应用程序无法工作时会失败的测试。
2. 测试就像先进的科学，它们不能证明软件是有效的，他们只能证明软件不起作用。
3. 编写代码和接收反馈之间的距离越小，开发过程就越可预测。
4. 良好的测试代码就是开发能有的最好的文档
5. 项目周期越长，测试就变得越关键
6. 测试代码的目标是在应用程序运行没有按期望运行时失败^（编写测试的目标是当应用程序没有按照你的预期运行时，测试能够失败。）^

7. 当应用程序代码出现问题时，编写更严格的断言会使您的测试更难通过，因此更容易发现错误。比如：

   ``​^(使用下面的代码块)^

   ​expect(result).ToBe(2); // now a single value is accepted, tight and better for catching bug bugs​​

   js expect(typeof result).toBe("number"); // loosely coupled, there are a TON of unexpected results that this test won't catch ​` expect(result).ToBe(2); // now a single value is accepted, tight and better for catching bug bugs` 8. 如果对于相同的输入代码总是产生同一输出，那么就认为代码是确定性的（deterministic） 9. 尽可能避免写否定的断言。 10. Jest-extended 包含一些非常酷的断言。 11. 测试是反馈机制。 12. 循环断言要严格禁止，与其重复使用同一个函数，不如使用重复或者硬编码字符串来校验。 13. 一些真实的定义:

   • Spy：观察行为。
   • Stub：观察行为，并以某种方式更改数据或实现。
   • Mock：一个带有预期的 stub
   • 您应该只测试您编写的软件。
   • 如果模拟一个依赖关系过于复杂，那就不要模拟了。

其他：当文章中没有插图时候，尽量找张或者AI生成一张主题相关的图片

​​

‍