概念定义#
完备性：
- 指对当前需求所能提供的服务的覆盖率
架构的目标#
架构是一个比较宽泛的概念
为了某个需求实现的一个或是一系列业务
旨在高效率地解决问题
重构#
重构的本质就是：对当前架构的 完备性 不够充分而 remake 的
重构软件，意味着你可能会对某个模块 / 某个应用，甚至是某个系统进行再次覆写
这种行为一般产生于：
- 原代码存在大量问题，修复成本巨大
- 原系统性能不足以处理业务的不断增长情况
- 新功能无法快速接入系统内
- 架构本身存在缺陷
无论是什么原因，重构肯定是为了解决上一代产品出现的问题
重构无法避免，但是重构的频率一定要在 == 可控制的范围内 ==
否则三天一小改，一周一大改 (这样带来的时间成本和心智负担十分巨大)
- 解决问题的最好方法就是解决出现问题的根源
试想一个情景：
你为某 API（假定是一个天气接口，数据有温度 / 湿度 / 变化情况 / 地区）实现了封装
而你认为目前不需要湿度这一参数，则可能会直接丢弃湿度这一数据
当你某天自己实现的功能需要依赖湿度这一参数时，你要么直接从原代码中补上湿度（这无疑是增加心智负担，尤其是代码在一个系统中），要么就是实现一个新的封装来获取这一参数
上面的两种方法，都会让系统变得更加 复杂
那么如果一开始，你将参数保存在封装的内部（向外输出的数据仍没有湿度），而不是直接丢弃，那么实现新的功能时，只需要调用该 API 拿到湿度参数即可！
- 以上例子显示了一个比较容易出现的情况，与其丢弃数据，不如直接封装在内部供下次使用
- 当然可能会消耗更多的计算资源和带宽（对于稳定性和开发成本来说，这并不是太大，不是吗？）
生活中的实例#
就拿 B 站作为例子，其 Web 端 API 接口中存在多个看起来 "无用" 的参数和重复项（比如 bvid 和 bv_id）
这就是以兼容性换取开发的遍历，用 bvid 和 bv_id 可以减少混淆所带来的 隐式问题 和沟通成本