# 周月总结

以下内容按日期排序。

# 2018.08.21

这里主要记录调试有一个 bug 时候，找大佬同事解决 bug 的一些记录和思考。 问题描述：代码在本地 development 开发没有问题，但是发到线上访问就会页面卡死。这是其中一个比对，另一个对比是：微信未绑定前，页面访问正常；微信绑定后，页面访问卡死。

1. 刚接到问题反馈是在一周前，初步分析问题后，看到返回访问状态码为 200，但没有返回内容。但在终端 curl 是正常返回的。页面分别有两个请求，代码如下： 

怀疑是使用了 await 阻塞了线程运行。 便将问题抛给了后端，让他们看一下是否返回有问题。

后记：实际上这里的判断是有问题的，第一，请求是有 timeout 的；第二，其次 await 如何阻塞也不会导致页面卡死；第三，页面卡死大概率是因为有 死循环 导致，应该往这个方向考虑。

2. 几天后，后端反馈表示没有发现问题。认为既然能够 curl 成功，那后端可能没有多大问题。问题又抛给了我。
3. 于是，我又找了同事（代码是他写的）来一起排查 bug。分析我的问题之后，同事觉得是哪里造成了死循环，尤其重点关注 forEach。对上面的两个请求进行了挨个的 debugger。这一步是非常费时间的，每次注释代码后发布到测试环境。结果定位到只要注释了 commit(’setBindResult’, bindResult)页面就不会卡死。这很奇怪。所以我们又查看哪些地方用到了 bindResult。接下来就发现只要注释掉 <kw-popover> 页面同样不会卡死。所以，我们怀疑是组件的用法不对。怀疑是不是 <kw-popover> 的 :is-show.sync 和 trigger 的默认值为 click 导致的冲突。后面发现，并不是这个原因。最后结论归结于组件可能有bug。

 4. 下午快五点的时候，又找了组件开发的同事询问这个问题。同事表示相同的代码，bug 无法复现，他怀疑我的代码存在死循环，开始调试我的代码。

• 第一步：他给我的代码加上了 console.log 和 断点。

结果：正常输入结果，之后页面卡死。

• 第二步：查看 console 面板。发现下面这个错误。

• 第三步： 另开一个页面相同的写法，看是否还是这种情况。

结果：还是同样的报错。

• 第四步：展开 warn 信息。挨个判断哪里出现了问题，同时查看了项目代码和组件库代码。 

• 第五步：怀疑组件嵌套使用 <Transition> 的原因造成，查看组件库代码。

• 第六步：google 搜索报错信息。得到 https://github.com/ElemeFE/element/issues/8652 用户使用 element 时同样的错误。

• 第七步：查看项目 vue 版本。  结果：没有查到 vue 版本。

• 第八步：查找有关vue的仓库。  结果：没有安装 vue

• 第九步：查看 index.html，发现 vue 是通过 script 引入的。版本是 2.2.4。

• 第十步： 更新 vue 版本到 2.5.2 ，vuex 版本到 2.5.0

结果： 问题解决

思考：

1. 最开始就要看 console 面板是否有 error 和 warn 信息，有非常大的价值。但是因为有时候在开发环境可能有很多报错信息，所以自己以前的做法是选择 clear console，导致没有没有看到，也不关心 error 和 warn 信息。这不是好的 debugger 习惯。
2. 学会比较 bug 产生和不产生之间的差别。在这里，是因为有个线上没有响应和开发响应正常的一个干扰，导致我们没有把重点放在收到数据后，会触发 <kw-model> 和 <kw-popover> 这一结果。
3. 尽早 google 看不懂的 error 和 warn 信息。
4. 关注库和框架的版本。

命令：

1. ls node_modules | grep vue
2. cat node_modules/vue/package.json | grep version

# 2018.08.24

1. 写代码前，理清业务需求、信息结构和内在逻辑。
2. 写代码前，理清和后端每一个接口和接口逻辑。
3. 确定风险。
4. 用 20% 的时间完成 80% 的需求。
5. 过早的性能优化是万恶之源。

# 2018.09.14 周五

1. 脑子反应太慢，跟不上别人的思路 - 如何加强锻炼？
2. 提问前，要仔细调研过(Google 之类的...)，再将问题列一个提纲。

# 2018.09.21 周五

1. 尽可能有效地管理自己的时间
2. 尽可能提高工作效率
3. 浏览科技文章放在一天工作的结束前
4. 当众分享收货：

• 不一定要多深，但是一定每一句话自己都能很好地解释清除。这样，才不会感到怂。
• 不要恐惧这种分享，不要恐惧质疑。

# 2018.10.01 周日

主要是来自语雀两篇文章的总结。一篇是 芩安 的 「动力×思考力×性格秉性」。另一篇来自 蔡志忠 的访谈 「努力是没有用的」。

想强调的一点是，读一篇文章的时候，要能自己归纳总结出主要的内容。

1. 人生的结果 = 行动力 * 思考力² * 性格秉性³

• 结果由这三项乘积，短期的结果通常由行动力主导，中期的结果常常由思考力主导，长期的甚至一生的结果往往由性格秉性主导。
• 如果其中任何一项太低或者接近 0，那么结果也接近于 0。
• 这可能就是我们人生的三类瓶颈。缺乏行动力，缺乏思考力和不友好的性格和秉性。当我们遇到瓶颈的时候，就可能需要往这三个方面思考。
• 这三类，不会是与生俱来的，都可能需要得到锻炼。
• 思考的力量。

2. 单纯的努力是没用的

• 倘若人生遇到了瓶颈，再怎么努力也是在瓶颈之下跳。只有克服了瓶颈，才能进一步往上走。
• 要懂得思考、发问以及自己解决问题。
• 改变观念 - 有时候这很难。
• 要有自己的人生方向，避免在岔口迟疑。迟疑是非常浪费时间的。

# 2018.10.19 周四

有关前后端数据校验的思考：

1. 前端校验是为了用户体验，后端校验是为了数据安全。
2. 前后端的相互不信任是系统稳定的因素之一，即是说：前端不应该相信后端的数据来源，主动 try...catch 错误。后端不应该相信前端返回的数据，主动进行数据校验。

# 2018.10.22 周一

有关网页设计的思考：

1. Stop building websites with infinite scroll。
2. 可以采用分页，下一页，用户主动加载等方式规避。

# 2018.11.04 周日

“一旦到了舒适区，就赶紧往前走，去学习更高的东西，千万不要做舒适区里边炫技的猴子”。

# 2018.11.30 周五

当我们设计某一个功能时候，尤其是重大的调整，需要思考一下我们和用户之间的一个问题：

是我们去养成用户的习惯，还是根据用户习惯进行开发？分界点在哪里。

# 2018.12.07 周五

当遇到问题的时候，脑子很乱，就去休息。

当你不清楚原理的时候，就不要反复地去尝试(尤其是重复的尝试)。应当静下心来，好好理一理，原因和源头。

要利用好 google，包括报错和 warning。

# 2018.12.10 周一

1. 一定要先看一看 console 面板的打印信息，有些 bug 或问题会直接展示在这个面板上呀。而且，而且，有时候这个信息是折叠的，要点开排除一下是不是问题根节坐在呀。

2. 给别人反馈问题的时候，不要一下子就发图，别人搞不懂你想表达什么。准确描述自己的问题。

# 2019.01.18 周五

平生最厌烦听别人说：这个不是很简单吗，巴拉巴拉...

也厌烦自己说这话。如果学了点皮毛，不深入就不能这么说。深入了，全了解了，有能够抽象出来让别人听明白了吗？

厉害的人永远谦逊。

# 2019.04.10

1. 当忙的时候，调整好自己的心态。
2. 当遇到一个问题的时候，先要分析问题，找到解决途径，最后再寻求帮助。比如今天遇到的问题：自己负责的以前团队的一个库，很久没有业务需求，今天突然来了需求，但是这个应该移交出去。

• 分析问题：现在这块业务属于哪个组？，问产品、后端
• 方案：找对应的负责人，合作推进。
• 体会：如何形成有效的思考！！！！