最近一直想抽时间整理下思路，趁假期多写点...
前言（为什么想写）
平常开发，对接不同需求，也会遇到各种问题，尤其是移动端开发（不同端，不同机型上的表现）这个阶段碰到许多情况，也很多知识，想出不同的解决方案，写东西就是想着可以将某个主题整理，归纳，将知识内化。只有知识，没有内化，是很难转化成自己的能力。
内化知识最有效的手段就是输出，用输出倒逼输入。当你准备输出时，会考虑很多，比如怎样将明白，怎样让结构清晰，怎样设计示例等等，所有这些，都会让你进一步思考知识，会让你系统化你的知识，最终会加深你对知识的理解和应用。
业务需求的感想
务代码不同于框架代码、个人项目或者开源项目，它的特点在于逻辑复杂、前后依赖多、可复用性差、迭代周期短。
总结两点：持续重构和合理冗余；
- 持续重构提升代码健壮性，过早重构可能会因需求变化太快白白浪费许多时间；过晚重构会因为代码逻辑复杂、相似代码积压过多导致变更风险太高，难以维护；
- 合理冗余可以简化复杂的场景，让开发变得高效、测试变得容易；拒绝过度抽象
没有最优的方案，只有合适不合适，根据具体业务和应用场景选择:
拿代码复用性来说:没必要一上来就工具库或者组件库，增加不必要的维护成本；避免过早重构；优化是个持续渐进的过程，到一定的量级，对应的优化才有意义；
现在的思路是：子组件=》复用性高的抽成全局组件 =》 自动注册（与业务隔离） =》 等积累到一定的数量抽出成组件库单独维护 =》 按需加载（非必要的依赖），后编译（代码冗余） .....
另一方面任何优化都需要向下兼容：
eg：由于线上服务器压力大，需要将静态资源迁移到cdn上，做好备份，由于项目承载业务较多，服务器上需要备份一份老的资源，防止资源请求不到的情况；
对于框架或库的选择
- 能给项目带来什么收益，解决什么问题;
- 团队现状，学习成本；项目现有状况，改造成本；
- 文档是否完善易读，社区是否活跃，周边插件是否丰富；
遇到问题时排查过程
-
看报错信息，分析错误类型；
-
如果是第三方错误，根据当前版本，浏览文档，查看接口用法是否有误。
还不能解决：
- 2.1 git库里搜索issues
- 2.2 对于用户量大的库，问题一般别人都踩过坑，google关键词搜索
- 2.3 在浏览器里单步调试，不可否认是最直接的方式，能够快速捋顺运行流程；
eg:
在调试summernote.js时，按文档自定义按钮时，获取不到context对象。 在issue中查到版本升级到v0.8.12后，出现的问题。 在浏览器器中调试时，确认在执行时没有传入;
-
如果是业务代码错误
eg:业务留言墙随机选中一张不重复留言背景，当背景只有一张时，不能选中；主要逻辑：
浏览器打断点调试执行过程 最后确认是初始值为零，引起的 -
性能问题
小结：好的代码是调出来的
思维方式
闭环思维主要是两点：
- 第一凡事要 follow through，跟进到底;
- 第二是及时反馈，主动反馈。
推一个流程，不是流程发布了就完事了，如果没有后续的流程宣讲，监督，反馈，改进，就不是闭环，流程就得不到真正落地 开发一个功能，不是提测了就完事了，也不是上线就完事了，还有上线后的功能检查，用户反馈，都做到位了，才是闭环；
大家做事情，如果有遇到你的 leader 或者 peer 主动来问你进度，那你就要反思了，反思自己的主动反馈是不是做得不够。
闭环拆成 2 个维度：
- 以业务为主线，牵涉到产品，开发，运营这条线；
- 以项目架构为主线，牵涉到前端，后端，项目部署，认证体系，鉴权体系，数据库，日志这条线；
尝试从这个两个维度跟进项目，在编程的过程，视角会在一个更高的地方。
持续更新中....
