亿级流量的 c 端项目。主体是多个小程序，并且分化为多个版本。除了扯皮拉扯之外，总想聊一聊，不吐不快。
保持技术栈的单调性
因为各种原因，我们的技术栈百花齐放，uniapp，herbjs，内部小程序框架，vue(h5)，react(h5)，苦不堪言。对于新人进来，只能快速熟悉一块内容，熟悉其他的小程序需要重新学习框架，成本比较高，如果框架本身还出现一些bug，简直酸爽。
少有人走的路
《少有人走的路》是本挺好的描述亲密关系的书，然而，技术上要小心。少有人选择的技术，那么就是坑多，因为部分业务是继承项目，所以框架沿用的原来的框架，没有文档，没有支持，吭哧吭哧，埋头苦干。没有人问，没有人解释，各种写法奇绝诡异。
再给我一次机会，我会毫不犹豫的选择使用熟悉的框架去重构，后续的维护成本会很低，对于长期项目，收益很高。
选择大路货
技术选型，选择大路货。虽然 v2ex 把 uniapp 喷的不要不要，然而开发效率，工程化，市场占有率，uniapp 是非常好的，能够让一般开发快速完成工作。
然而，uniapp 的 bug 也是有的，我们在开发过程中有遇到，我们选择给 uniapp 提交 mr，一般很快就会被合入。有人维护，有人讨论的技术，不用担心，一定可以找到比较快速的解决办法，没有就完善它，让它变得更美好。
内部框架是个p
见过太多的内部库，内部框架了，没有一个，是的没有一个，给我比较好的印象。
- 你的同事水平不一定比你强，见过大量错别字的内部库 :(
- 内部框架服务于特定领域，有它自身的局限
- 内部框架往往公司的人事变迁，就没有人维护了，很多内部框架都是一两个人维护，有的内部看源码都很麻烦，单点风险太高。
- 没有银弹，多少库，框架，只是拿着开源的改改，就是内部库了
保持核心方法的单调性
http
在我的项目里面，http 方法是比较核心的方法，初始状态下，有使用全局 http 的，也有直接使用 wx.request 方法的。后续做 token 校验的时候，困难重重，线上总是有大量的失效的 token。所以对所有 http 方法做了要求，全部使用我自己的库 @aocoding/mini-axios，集中处理token更新机制，后续异常逐渐降下来了。
合理封装，保持简单
很多按钮点击时候，需要用户高级授权，而高级授权又对应着判断是否已经授权，获取 code，和后端交互等复杂交互。
这里我们做了一个全局状态去存储授权，并封装成装饰器，按钮等行动点，可以直接使用装饰器去校验。进入页面时候，也可以使用装饰器去做一定的授权防御。
正确使用组件
一般项目其实很难过度组件化，一个页面也就十几个组件。但是我接盘的一个项目，组件的划分匪夷所思。
- 外层组件：起初我以为是复用，但是完全没有复用，基本都使用一次，原生小程序，不涉及业务逻辑
- 内层组件：涉及业务逻辑，引用外层组件，内部框架
这样的结果就是你需要在小程序里面跳来跳去，一个页面，组件应该有上百个….虽然业务确实比较复杂，但是咱真的至于这样么…
整洁代码
- 严禁大量的注释（调试）代码存在，必须删除，现在不能和过去告别，以后也会纠缠不清，想看以前的记录，请使用 git
- 使用 ts，我们的项目基本都切换到了 ts，http 部分必须要有严格的类型定义，后续很少出现数据层面的bug。ts 不需要学的多深入，去做类型体操，花一周时间认真去学习，就能够应对项目中的绝大部分内容。随着 ts 越写越多，更多的场景也会推着你去学习新的知识。
重构
- 不要怕，甩开膀子就是干！信心比能力更重要，面对屎山，要有不破楼兰誓不还的决心，小步迭代，长期推进，屎山也能变金山。
- 长期项目，如果没有一定的重构机制，那一定是屎上堆屎。必须有完善的 review 机制，不合格代码不能因为任何原因合入，必须修改完所有的问题，把这养成习惯，去推动团队的运行。
- 重构从主干代码开始，聚合项目中的各种通用方法，业务包装，主干代码串起项目骨架，其他的更多的是业务的填充。业务方面，保持各模块的解耦，公用方法的抽离，一个相对健壮的项目就出来了。