本周工作思考
- Web 按钮组件升级及UI规范化优化升级
- 目前按钮替换涉及到部分样式的修改和调整，在开发过程中遵守一些开发原则：
- 样式上新增，不减，适当修改
- 代码上保留原来的按钮代码实现，方便出现问题快速定位，等到过2,3个月后再删除
- 风险较大的修改，首先考虑不出bug，宁可不替换原有按钮实现，但必须使用规范的button style，保证样式一致性
- 但凡有修改，必须见到按钮看样式，看点击事件
- 深度隐藏的按钮，同步UI和QA
- 分批修改，分批提测
- 按钮涉及到很多功能的实现，也意味这一定风险，可能出bug的点主要是一些条件控制的功能上，比如在特定小节的按钮，国际化的语言的展示问题，受时间或者自测覆盖的限制可能会有遗漏，不过严格按照 【但凡有修改，必须见到按钮看样式，看点击事件】的原则，出功能问题的概率比较小。
- 按钮替换十一前会完成web页面的一级页面和二级页面的替换，点多面广，工作量比较大，web端的代码从6年前到现在代码都有涉及，按钮写法也不太一致，主要考验耐心认真和代码与功能的映射的熟悉程度，需要对每个修改点都要自测覆盖，仍然会有可能的遗漏，比如按钮再不同条件下class会有不同，动态生成的button等涉及逻辑问题都是需要重点关注的
- 关于小节排序拖动异常的bug排查过程总结
- 小节排序的拖拽排序有一个bug排查前前后后花费了1天多的时间，排查和过程过程让我印象深刻值得思考。
- 场景是这样的，在章节内，反复快速拖拽排序，持续2分钟左后，会出现被拖拽的小节存在两个，原位置有一个，目标位置有一个，持续大概2，3秒后，原位置的消失，恢复正常。
- 刚看到这个问题时，我是觉得有点不可思议，我的第一反应是渲染那出的问题，但是不至于这么慢，这是让我疑惑的点。所以我需要找出渲染在哪慢的。
- 首先是从实现路径上排查，拖拽排序在实现上有三个过程：1 数据的处理，就是数据在数组中的移动，2是拖拽效果的实现，3 是dom的渲染，这个主要是依赖angularjs中ng-repeat指令的渲染，从逻辑上来说这三个点都有可能出现，这种情况下要么依次排查，要么盲猜一个可能性最大的，这种情况下，我相信直觉一些，选择直觉最大的一个可能，就是ng-repeat那慢了，于是我仔细排查了ng-repeat的使用，我发现没有使用track by，这会导致整个小节列表的渲染是全量的，于是我加上track by，修改之中发现问题已久另外还引起了Unique ID重复的问题，由于我还是认为track by可以解决这个问题，但是现在没有生效，有点让我困惑，于是我深入查看了ng-repeat的实现，考察它是如何实现dom渲染的，如何利用track by，它的实现如何受脏检查影响，是否技能存在性能瓶颈，看完之后我的结论是ng-repeat看起来没有性能瓶颈，即便不使用track by。此时陷入僵局，直觉不管用了，只能在看其他的过程。
- 数据处理比较好排查，在删减数据的过程中，分别打上性能log，观察执行时间即可确认是否有问题，通过分析日志发现，数组的变化都是在拖拽动作完成后即时完成的，我反复试了多次，数据都是正常的。从这个结果上看，排除了数据变化和拖拽两个阶段，因为在发生bug的场景下，拖拽完立即有数据变化，拖拽过程和数组变化都是正常的。那么bug就出渲染上了，但是ng-repeat的排查没有发现问题，于是我又想到是不是可能从脏检查入手可以发现点蛛丝马迹，把触发脏检查点，以及脏检查的使用是否合适都检查了一遍，并且在脏检查处打了log观察其执行，发现数组变化会立即触发脏检查，进而执行相应的watcher，这块也没有认为可疑的点。这个bug看起来是没法解决了。这时我突然想到一个关键的点，就是究竟是谁触发了dom的删除操作？通过对dom操作的调试发现，dom的操作竟然在动画服务里，可是我在代码里没有使用动画，这个是啥原因？于是顺着堆栈一行一行代码往前倒腾，终于在茫茫anguarljs源码里找到了一个我熟悉的代码，ng-repeat的实现代码。原来ng-repeat的代码里使用了动画，删除动作会被放入动画队列，因为小节删除的的整个交互和实现比较复杂，影响了动画的性能，所以排在动画队列最后的小节dom删除就会2,3秒之后执行。
- 原因找到了，一般修改基本上很容易了，不过这个原因的层次比较深，出问题的代码再anguarjs里面，所以如何优雅的禁用此处的动画就成了解决的问题关键，在使用上ng-repeat没有关于任何动画的使用的API，只能另寻他途，在深入研究了动画的源码后发现，动画服务里面有个一个customfilter可禁用动画，到此问题也就解决了。
- 通过这个排查过程，我觉得反推法结合第一性原理的应用会比较快的找到问题所在，简单来说直接从病灶出发，其实这个bug的解决的转折点在通过dom删除的代码入手，回到场景上上看要被删除的小节2,3秒后才被删除，这个现象的背后就是dom删除被推迟了或者dom删了渲染慢了，通过现象可以直接排除渲染慢了，因为如果渲染有问题，拖拽过程会很卡顿，实际情况是拖拽很流畅，所以问题在dom删除慢了，以第一性原理的思路，反推为什么dom删除慢了的本质原因，也就找到了了这个问题的修复思路。