一. Algorithms
本周做了 349.Intersection of Two Arrays 数组求交集相关的题目。
Easy 难度的，中间虽然遇到一些问题，主要是思路不够开阔导致的。其重点就是不允许有重复元素。有两种实现: 在构建 result 时每次添加元素执行一次判断，但比较麻烦并且影响性能。
最直接的方式是通过 Python 的 set 元素不可重复的特性执行一次过滤即可。最终代码如下:
class Solution:
def intersection(self, nums1, nums2):
numbers1 = set(nums1)
numbers2 = set(nums2)
result = [i for i in numbers1 if i in numbers2]
return list(set(result))
在这里不得不再次点赞 Python 的易用性。四行代码搞定。
每次最花时间的始终是 算法部分，做完一道简单题后做 medium 级别的题目没做完，希望下周搞定吧，伤不起。。
二. Review
本周读了耗子哥练级攻略推荐的一篇 Code Review 相关的文章: inkedin-code-review/
作者介绍了 LinkedIn 在进行 Code Review 时的一些建议:
1. 理解源代码的意图
为达到该目的，每一次提交开发人员都要对这次代码改动添加一个概述简要说明其意图。这样可以避免只能从代码中推测其改动意图，防止出错，必要时需要去询问相关的开发人员。
其实将每一次代码提交都尽量的描述清楚本次提交的目的，不仅在将来进行 Code Review 时有所帮助，而且还非常有助于我们理清开发思路，改进开发与提交粒度。
2. 给予正反馈
当进行 Code Review 时，如果发现其中某些代码写的非常简洁优雅，则要尽量反馈给开发人员和团队，并给出其优雅的理由。好的代码是可以传染的，这样做可以激励开发人员，并且为团队提供了经验借鉴，有助于提高整个团队的编码水平。
3. 清晰的 review 注释
当进行 Code Review 时，重构人也需要将自己的改动提交解释清楚，这样便于后来者更容易的理解代码，另外注释可以是简单的 “减少重复”、"改进测试"等，这样可以提高整个团队的编码规范
4. 向重构人表示感谢
作者提到无论结果怎样，都要对努力工作的人以正反馈，这样可以提高整个团队的积极性。在 Code Review 中，有时候完成的并不是很好可能需要我们再次返工，但此时我们还是要尽可能的向重构人表示感激，并简单解释下在此基础上还可以进行的改进。
5. 去掉无用的注释
可以多问自己几遍: 这段注释对我有用么，如果没有则删除。Code Review 是协助开发的工具，而不是徒增工作复杂度的琐事。
举个栗子, 如果 Review Code 的注释是类似代码格式说明性质的，则应当删掉，格式应当有自动化工具识别并规范。
6. 保证充分的测试
每当 Review 有新的改动时，要强制性的对其单元测试、自动化自测。对于一些复杂的或者自动测试无法覆盖的地方，还需要进行手动测试并给出测试场景和测试结果。当程序更改了输出时，将新的输出结果记录到 test done 提交中是非常有用的方法
7. 有清晰的预期
在进行 Code Review 时要有清晰的预期和示例是团队文化非常重要的一部分，这样可以减少杂音，保证最需要改进的地方得到修改，减少不必要的时间损耗和团队人员之间的摩擦
简单来说，一个非常规范的 Review 有可以带来两点好处:
- 我知道我写的代码会被别人看到，因此可以激发开发人员写出更好的代码，并且为了减少后续的 review 评论，我也会尽可能的一次性写出更好的代码，减少后续修改的时间 (谁都不想被别人吐槽嘛 = = )
- 当 Code Review 变成每天的习惯，整个团队每天都会收到正向的反馈，这样整个团队也成长的更快
三. Technique
分享一个 vim 的小技巧，在使用 VIM 的时候加上如下配置可以让 vim 显示行号:
.vimrc 文件
set number
但这样会造成一个问题，在复制 Vim 的文本时也会将行号带上，所以在复制前必须先去掉行号显示，但直接修改配置文件未免太过麻烦，可以通过下面一个命令临时将行号去掉:
:set nonu
执行完成后就发现左边的行号不见了。当然也可以通过下面命令进行恢复:
:set nu
四. Share
认真读文档，认真读文档，认真读文档, 认真读文档 重要的感受要说好几遍。。。
最近在使用 ELK 搭建公司内部的系统与应用监控系统，在使用 MetricBeat 进行系统指标收集的时候出现一个非常奇怪的问题，在自己机器上测试的时候收集的指标数据可以正常展示在 kibana 中的，但在正式环境中始终不行。经检查后原因是: MetricBeat 收集数据写入到 ES 索引中时，如果直接连的 ES 其会自动创建一个 索引模板，DashBoard 中的各个监控图表都是根据该索引模板确定的字段信息来进行展示的。而在生产环境中，因为 MetricBeat 连得是 Kafka 而不是直接连 ES，因此没有自动创建索引模板，导致最终生成的 Index 数据并不符合 DashBoard 的要求因此展示不成功，在手动导入后才会生效。其实这条信息在 MetricBeat 文档中已经有所说明，但当时自己在环境中试验时并没有认真读这里的文档，从而后续浪费了非常多的时候找问题，最后回到文档重新读了一遍才解决。
很多人应该都有类似的浮躁，学习时非常的求快。比如一个开源组件，很多时候奔着要实现的功能就去探索了，虽然往往可以针对性的解决问题，但往往因为遇到的问题有限，我们并没有对组件整体有一个较为熟悉的把握，后面一旦遇到问题就很容易不知所措，这时候答案往往在文档中写明了，一般来说认真读过文档后可以解决大部分的问题，解决不了在考虑通过搜索和读源码解决即可。记得耗子哥也说过推荐的学习开源组件的方式是认真阅读其文档。认真跟着文档阅读、理解、思考一遍，相当于对整个开源组件有了一个整体性的理解和把握，将一个个的知识点连成线。如果只是一味求快，只关注有限的几个问题，虽然开始时可能进展很快，但只是了解了一个一个的点，后面遇到问题时以前留下的坑仍然需要一个个去填，并且更加的碎片化以及耗费时间，看似快，实则慢。
