程序员「开发者成长」1x程序员五年总结出的经验法则( 四 ) |软件工程|人生第一份工作|美好，一直

但我不是那种认为每一行和每条分支都必须覆盖的人。如果你不相信自己（或他人）能够很好地计算上面的预计影响方程，那么可以考虑采用这种策略。
规则 13：何时编写集成测试
我将集成测试定义为调用不属于自己的代码的测试，而不是模拟它。
只要我无法信任不属于我的代码时，就会试着写一个集成测试。特别是，如果它可以在我不知道的情况下进行变更时。
规则 14：何时编写端到端测试
我将端到端测试定义为使用我的产品模拟完整的“用户会话”的测试。用户可以是一个人，也可以是另一台计算机，它试图通过与我的代码进行多次交互来完成某些事情。这些通常是规则 12 中定义的集成测试的超集。
1、当我不完全理解产品是如何工作的，以及不能对一个变更进行充分的单元测试时，我希望有一种方法可以让我更有信心认为我没有破坏任何东西，就像“冒烟测试” 。
2、当我需要一些回归测试用例来验证未来重构的功能时。
3、当很难提前预知结果的时候，例如，在做一个复杂的计算时，我想测试一些代码对它们的影响。
第一种情况应该想办法避免，但第二种和第三种情况实际上真的没有办法。
DevOps规则 15：何时需要一个专门的支持工程师
在亚马逊，默认是由你们自己支持自己的代码，因此如果系统中出现严重错误，你们之中的一位同事将被找来日以继夜地工作，直到问题得到解决。
它可能很残酷。但是亚马逊（例如，我现在的团队）和其他公司中都有专门的部门，他们聘请了一名站点可靠性工程师（SRE），由他负责在正常工作时间之外在线解决严重的生产环境问题。
多年在这方面的经历让我开始相信，作为一名程序员，如果实际上还存在下班后要被找来工作的风险，应该始终提倡使用专门的 SRE 。一个最好的例子是，如果你“继承”了其他人的代码，还得对里面已有的缺陷负责。
可以在不同的时区找些人，通过培训使他们能够支持你的系统，这件事并不难。关键是，要找到给人家的钱。团队中的工程师们需要共同努力向管理层明确表达这一诉求。
安全规则 16：如果你把你所有的 IT 安全委托给信息安全部门，他们会想出非常严苛的规则
信息安全是一项棘手的工作。在某种程度上，博弈论说的是对的，他们必然会因为过于谨慎而犯错。所以我想的这条规则是，你是否至少可以做一些你自己的安全，以避免受到过于严格的限制。
一个典型示例是亚马逊内部 wiki 迁移的灾难。早在 2015 年，亚马逊的信息安全团队就禁止在公司内使用 PHP 了。我们内部的 wiki 使用的是 MediaWiki ，而 MediaWiki 又是用 PHP 编写的。
Facebook、WordPress 和 Slack 都在使用 PHP ，而 Facebook 正在构建简化后的 Hacklang 来取代它，内部的 wiki 团队未对这个决定提出任何质疑，只是把这个信息安全指令当成了一条命令来执行。
他们将 MediaWiki 替换为基于 java 的替代品 XWiki ，最终为这个团队花费了 4 年多的时间，共计 24 个开发人员，在这些页面不断迁移的过程中，亚马逊几乎所有其他团队都还经受着中断的困扰，而这些损失并未统计在内。如果他们对 PHP 的禁令有所抵制，或者对 Hack 做了更多的研究，可能就能避免这场灾难。
设计和白板规则 17：设计会议是寻求建议，而不是请求批准
有很多会议的目的是“得到批准”或“得到投入” 。你应该予以避免，只有在万不得已的情况下才同意这么做。你希望得到的不是“签字盖章” 。你希望能够自己做决定，确定需要与其他人达成什么程度的协议。
相反，设计会议或交流应该是寻求建议和回答问题的。
项目管理规则 18：估算更多地用于制造压力，而不是项目规划