论术：浅谈防御性编程

WHAT

在防御式驾驶中拥有这样一种思维，那就是你永远也不能确定另一位老司机将要做什么。为了防止在其他人做出危险动作时你也不会受到伤害,你要承担起保护自己的责任，哪怕是其他司机犯的错误，这就是所谓防御性编程的意义所在。
防御性编程是一种细致、谨慎的编程方法。为了开发可靠的软件，我们要设计系统中的每个组件，以使其尽可能地“保护”自己。 我们通过明确地预见在什么地方可能会出现问题，然后创建相对应的处理方式来完成防御性编程
防御性编程更是一种态度，一种提前包容他人错误的态度(做类型转换后使用全等)，一种对项目负责的态度(功能编写时兼顾用户体验)。

防御性编程是提高程序鲁棒性(Robust)的手段

WHY

• 防御性编程可以增强程序的健壮性，在不正常的输入或不正常的外部环境下仍能表现正常的程度，具体表现在我猜到了，所以我做到了
• 防御性编程可以节省大量调试时间。
• 防御性编程可以使生产环境崩溃的概率变小，我们预见并处理了部分可能会导致崩溃的问题
• 防御性编程写的好，闲气生的少
• 在某些高并发场景，任何微小的错误都可能会因为巨大的访问量而被放大无数倍。编写防御性编程是一个求稳的过程。
  ...

HOW

不信任所有输入

输入端用户是不值得信任的！

作为数据注入的第一道防线，我们要抱着最大的恶意对待输入端用户，对于某些重要的表单场景时，多一些精密校验是必要的，有时可能用户本身也不知道自己输入的问题，总而言之：过程无法阻止，不过我们可以通过强校验的方式告知用户输入正确的合法的数据。

要相信需求会变

在写代码时，要时常询问自己：目前代码的实现方式是否方便需求更改

相信经历过的人会懂：

毕竟，代码是死的，人是活的，但是人是可以被气死的

多重校验下优先退出

略略

考虑UI稿的极端情况

作为设计岗，某些图总是会按照设计师心目中最好的样子实现，但在生产场景下作为前端则要考虑的更多，我们并不能保证事态一定向我们(fe+ui)期望的方向发展，基于此我们同样要向UI传递这种可能，也就是极端场景

不要仓促的编写代码

在你完全理解需求之前，永远不要开始编码，一定要先考虑清楚:

• 功能的实现
  1.要先对功能需求深入了解，可以在产品/甲方将需求描述完毕后，将自己对需求的理解复述一次给对方，以确保不会出现认知偏差。这有点像战争开发前各个将领在首脑面前校准时间，抹平差异。

2. 与后端约定的接口的数据格式
   这一点好处多多，我们在约定大致的数据结构后就可以据此mock属于该模块的数据，在此掏出一段用以快速mock的代码：

 new Array(6).fill(null).map((_, i) => ({
    i,
    status: i % 3,
    applicant: ['贾明', '张三', '王芳'][i % 3],
    channel: ['电子签署', '纸质签署', '纸质签署'][i % 3],
    type: ['审批通过', '已过期', '审批失败', '审批中'][i % 4],
    detail: {
      email: [
        'w.cezkdudy@lhll.au',
        'r.nmgw@peurezgn.sl',
        'p.cumx@rampblpa.ru',
        'b.nmgw@peurezgn.sl',
        'd.cumx@rampblpa.ru'
      ][i % 5]
    },
    needed: ['Y', 'N'][i % 1],
    description: ['宣传物料制作费用', 'algolia 服务报销', '相关周边制作费', '激励奖品快递费'][
      i % 4
    ],
    createTime: '2021-11-01'
  }))

当与后端对接后，就可以以此将后端的数据格式再进行map一遍后进行重组，这样则避免了从页面进行大幅改动
3. 项目内是否有可用的公共组件、工具
略

• 组件的拆分

1. 组件拆分的合理性，数据、状态的存放是否符合最小知识原则。
2. 组件的可复用性如何，是否需要可复用性。
3. 数据状态的传递方式是否合理。

• 工具/插件的使用是否合理
  xx插件是否有必要使用，是否可能满足未来项目的预期，为什么

• 其他

1. 异常处理边界行为
2. 处理弱网络处理
3. 用户体验优化
   ...

几点提示

当然 凡事有利有弊，提高健壮性也可能会有以下弊端：

1. 代码臃肿，可能会有更多不必要的判断
2. 过度设计
3. 降低代码模块效率
   ...

约定大于配置，防御性编程不代表我们认可有人可以破坏大家的约定，也不代表我们需要编写大量丑陋的防御性代码。一定要小心设计过度带来的代码臃肿性。健壮性与便利性总是可以讨论的，关键在于如何取舍，而这几点则需开发者认真考量。

以上。