过度包装
疫情期间每天都是自己做饭吃，隔两三天就要买一次菜，每次买菜光是拆包装盒就要耗费非常多的心力，更别提清洗食材和锅碗，切菜淘米调配料，蒸炒炖炸等工序了，难怪说疫情期间分手的情侣、离婚的夫妻比比皆是，敢情大家平时都是装作很会生活的样子，一旦没了外卖快递都退回到了饮毛汝血的状态。
正如做饭 1 小时，吃饭 10 分钟，洗碗半小时所说的那样，吃这样一个动作在当前都会有无穷的副作用，可以说现代都市生活真的是建立在非常完善的 O2O 服务行业之下的，要吃饭线上下个单线下送来，要保洁自如下个单线下保洁员上门，要 ml 都有 165/90 32C 的家政服务人员上门服务。人的生活变成了只需处理工作，其他时间都可以用钱买到，这样 WFH 所带来的工作时长延长对社畜的身心打击几乎到了极致。扯远了。
网上买菜或者超市买菜，相比于菜市场买菜最大的区别是包装。垃圾桶里丢掉的绝大部分是塑料包装而不是切掉的边角料菜或者剩饭剩菜。就像软件开发里，动辄几十上百层的封装之下，真正工作的是那么一两行代码。
- public
- js
- submit
- works
- manage
- components
- header-actions
- PriceActions
PriceActions.tsx->StartPromotionButton.tsx->StartPromotionForm.tsx
一个页面上小小的组件，被封装在 9 层目录之下，同目录平级之间还有嵌套关系。当然组件化分治思想也是 React 一直火到现在的根本原因，但有时也会想想这种扁平化的目录结构是否真的合适项目的发展，或者说在业务需求猛增前提下如何科学组织目录结构以便修改维护也是门学问了，当然最好的方式是：不组织。根据实际发展来让文件自行组织，见 destiny。
拉扯这么多包装的弊端，但包装实际上是一项很重要的工序，因为不包装带来的风险，往往是看不见的：
小吕去年写了个活动页的接口，因为是第一次办这种活动，小吕本着以产品需求为约束的理念写好了无届数限制的 API 接口，然后前端同学以此接口封装了一个组件给页面加了上去。转眼间一年过去了，活动办了第二届，产品要求有新功能，小吕又哼哧哼哧写了一个第二届活动的 API，但这时候出分歧了：前端觉得接口应该稳定，如果每做一届都要回溯一遍做过的接口映射，太累且容易出错；而后端觉得分离 API 有助于更清晰地业务逻辑。大家说的都没错，怎么办呢？包装一下接口吧！
可以看出是适当的包装有助于分清业务界限，明确各端职责是非常值得提倡的。
但为什么实践中经常分不清这些呢？因为 Python 本质是一个胶水语言，更多起黏合剂作用，而 JavaScript 更想火柴棍，可以飞速搭原型，但两者都不是拥有持续集成性和可维护性的代表。个人以为类型系统以及所有权（或者说内存锁）是一个合格的工业级语言必备的，一个保障 AOT 安全，一个保障 JIT 安全，任何业务逻辑都是对这两个基本原则的封装。
