论术：浅谈防御性编程
WHAT
在防御式驾驶中拥有这样一种思维，那就是你永远也不能确定另一位老司机将要做什么。为了防止在其他人做出危险动作时你也不会受到伤害,你要承担起保护自己的责任，哪怕是其他司机犯的错误，这就是所谓防御性编程的意义所在。
防御性编程是一种细致、谨慎的编程方法。为了开发可靠的软件，我们要设计系统中的每个组件，以使其尽可能地“保护”自己。 我们通过明确地预见在什么地方可能会出现问题，然后创建相对应的处理方式来完成防御性编程
防御性编程更是一种态度，一种提前包容他人错误的态度(做类型转换后使用全等)，一种对项目负责的态度(功能编写时兼顾用户体验)。
防御性编程是提高程序鲁棒性(Robust)的手段
WHY
- 防御性编程可以增强程序的健壮性，在不正常的输入或不正常的外部环境下仍能表现正常的程度，具体表现在
我猜到了，所以我做到了 - 防御性编程可以节省大量调试时间。
- 防御性编程可以使生产环境崩溃的概率变小，我们预见并处理了部分可能会导致崩溃的问题
- 防御性编程写的好，闲气生的少
- 在某些高并发场景，任何微小的错误都可能会因为巨大的访问量而被放大无数倍。编写防御性编程是一个求稳的过程。
...
HOW
不信任所有输入
输入端用户是不值得信任的！
作为数据注入的第一道防线，我们要抱着最大的恶意对待输入端用户，对于某些重要的表单场景时，多一些精密校验是必要的，有时可能用户本身也不知道自己输入的问题，总而言之：过程无法阻止，不过我们可以通过强校验的方式告知用户输入正确的合法的数据。
要相信需求会变
在写代码时，要时常询问自己：目前代码的实现方式是否方便需求更改
相信经历过的人会懂：
毕竟，代码是死的，人是活的，但是人是可以被气死的
多重校验下优先退出
略略
考虑UI稿的极端情况
作为设计岗，某些图总是会按照设计师心目中最好的样子实现，但在生产场景下作为前端则要考虑的更多，我们并不能保证事态一定向我们(fe+ui)期望的方向发展，基于此我们同样要向UI传递这种可能，也就是极端场景
不要仓促的编写代码
在你完全理解需求之前，永远不要开始编码，一定要先考虑清楚:
- 功能的实现
1.要先对功能需求深入了解，可以在产品/甲方将需求描述完毕后，将自己对需求的理解复述一次给对方，以确保不会出现认知偏差。这有点像战争开发前各个将领在首脑面前校准时间，抹平差异。
- 与后端约定的接口的数据格式
这一点好处多多，我们在约定大致的数据结构后就可以据此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. 项目内是否有可用的公共组件、工具
略
- 组件的拆分
- 组件拆分的合理性，数据、状态的存放是否符合最小知识原则。
- 组件的可复用性如何，是否需要可复用性。
- 数据状态的传递方式是否合理。
-
工具/插件的使用是否合理
xx插件是否有必要使用，是否可能满足未来项目的预期，为什么 -
其他
- 异常处理边界行为
- 处理弱网络处理
- 用户体验优化
...
几点提示
当然 凡事有利有弊，提高健壮性也可能会有以下弊端：
- 代码臃肿，可能会有更多不必要的判断
- 过度设计
- 降低代码模块效率
...
约定大于配置，防御性编程不代表我们认可有人可以破坏大家的约定，也不代表我们需要编写大量丑陋的防御性代码。一定要小心设计过度带来的代码臃肿性。健壮性与便利性总是可以讨论的，关键在于如何取舍，而这几点则需开发者认真考量。
以上。
