这周用uniapp写了个微信小程序，有点感触，可能今晚睡一觉就忘了，赶紧记下来：
- 原型和设计不可靠
- 前端开发依赖后端接口
- 界面布局效率较低
- 编译速度慢很烦人
- 对接后端接口效率较低
距离上次开发微信小程序估计有1年多了吧，这次是到新公司之后的第一个开发任务，第一次使用uniapp，第一次使用蓝湖看设计图，第一次使用swagger看接口...
最后算是勉强完成任务了，下周提测。
优化工作流程
这周的工作流程是这样的：
- 拿到原型和设计之后，随便看了看，心不在焉地看不出什么问题
- 凭借多年踩坑经验，粗略评估了开发时间
- 技术选型，久闻uniapp的大名，赶紧上
- 搭建了几个uniapp的模板项目，发现果然还是最简单的那个hello world适合我这样头脑简单的人
- 对着设计图就写代码，布局没做完就写逻辑，逻辑没写完又继续写布局
- 用新的框架总是会遇到一些坑，并且总会吐槽一些写法，并想着自己改变一下架构
- 写着写着就会发现这个原型、设计有问题，然后各种沟通
- 后端下班了，也没有开发服务器继续跑着，也没有模拟的接口，工作没法开展了
- 因为同时进行界面布局、熟悉设计、对接接口，所以虽然接口不多，但是也是到了最后一天也还在对接口、界面布局、熟悉设计
- uniapp编译+微信小程序编译=慢得让人有些烦躁，甚至想喝奶茶
如果再让我重来，我会这么优化我的工作流程：
尽快和工作的上下游对接清楚
因为你向上下游反馈的问题，他们需要时间配合你解决问题，你越晚反馈问题，你的工作风险越高。
- 拿到原型和设计之后，光看是看不出什么的，整理出一份业务思维导图，尽快把发现的问题反馈给产品经理和UI设计
- 开发时间的评估一般要给得比较早，所以我还是会在拿到原型之后向项目经理提供开发计划
- 如果这时接口已经出来了，那么就先想办法调试接口。印象中postman可以把请求过的接口保存起来，以后可以直接用来当作本地调试数据。
优先解决界面布局
不要同时写界面布局和界面逻辑，编译慢不说，思维跳跃效率也不高。优先做好页面布局的话，也可以进一步熟悉设计，更早地发现问题，反馈问题。
- 技术选型时着重考虑配套的UI组件，结合设计尽量找到成熟的UI组件，毕竟界面布局什么的很烦
- 先一口气把所以html代码写了，先不管样式
- 印象中chrome控制台不仅可以临时调试样式，还可以把样式直接同步到源代码中，的空得把这个技能弄到手
写逻辑
这一块没什么要优化的，我写代码心中一直谨记着：这份代码得让实习生也能看得懂才行。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。