2016年7月9号深夜，11点31分。
工作
负责了一个内部的管理系统开发，起初并不紧张的安排。用了一套前后端分离架构，spring boot+webpack+vuejs，spring boot微服务大法，一桶天下没得说。vuejs的技术栈，可能还是没有完全掌握用法，挖了踩了或大或小的坑。
- vuetable列表插件
分页的支持不完善，固定的格式，与后端交互不方便。（后端自定义注解解决）
大列表渲染，全部前端可能不行。（后端渲染+v-html或可解决）
参数配置不通用导致每个compoments都要重复配置。(定义外层组件+mixin或可解决)
自定义一个列表插件可解决这些问题(没时间。) - vue router
路由模式html5，后端配置不便，hash模式不直观(url太丑)。
视图权限: 前端判断要在钩子函数每次请求。直接一次加载也不能动态授权。元素的显示与否又要异步校验。(没有太好的前端权限解决方案)
动态的路由跳转又不渲染href属性，不能右键打开链接(这倒是小问题。)
切换路由时，组件的状态／实例没有销毁，状态依然保留，每个页面都要加入hook来刷新(增加了复杂度)。(要深入了解route view的生命周期，vuex或可解决) - js
弱类型，隐藏了转换。数组，字符串，数字等在参数传递频繁的情况下容易出错。(ts的强类型可能会规范这个问题)
异常，完善的框架是会有try的（这是个笑话吧。还是先避免出错吧)
组件化大法好，提高了模块化和复用，但aop方案没找到(mixin太弱)，可能vuex,redux可以完美解决这种问题，又看到了反应式编程！
ts或许会避开很多问题，回到熟悉的后端编程。 - 需求
催的太紧，没有冷静思考，本来是AABB的方案，折中后用了ＢCAB(就是乱了)，结果还没很好解决问题。快速方案往往得不偿失，反复的修改又混乱了思路，很好的思考可能会很早的变换方案或者真正解决问题。
有种需求叫和AA一样就行，结果往往是>AA*2。
todo list还是自己定好点，别人给的往往不能定位到问题。(先后顺序，重要程度)
其实这种管理系统也很简单，有一点流程的东西没有好好沟通，导致反复更改。 - 引入新的解决方案时还是要深入了解，本地开发挺high的，也没什么问题，到了生产环境，就不行了，在整体设计上压力和复杂度的考虑不够。(魔法流酷炫华丽，伤害不俗，操作和技术少不了。物理流一板一眼，前期笨重，成型慢，后期稳定刚正面)
- 解决
如何秒变freemarker
组件化－宏 (同样强大)
渲染－查询型应用，基本无dom 变更造成的repaint(v8引擎1.4G内存不谈了。)
权限－spring security
页面列表－jquery大法
后端的成熟到不用自己出手，框架完美解决。
感悟
- 掌握反应式和函数式，就打开了一扇大门
- 领会不如贯通，全栈不如无栈，程序还是程序，思想还是思想。
- 知道很多道理，依然过不好这一生
- どんだけ
