ARTS 是 左耳朵耗子 提出来的一个打卡任务。每周一个 Algorithm，Review 一篇英文文章，总结一个工作中的技术 Tip，以及 Share 一个传递价值观的东西！我希望这个事可以给大家得到相应的算法、代码、技术和影响力的训练。
这是我的第十周打卡。这周在做二叉树的算法时，对 Leetcode 里 JavaScript 实现的二叉树结构比较感兴趣，自己也实现了一下。
🤖 Algorithm
📖 Review
LinkedIn’s Tips for Highly Effective Code Review
这篇文章讲的是 LinkedIn 的高效代码复查技巧，在他们内部实践的 Code Review 有以下特点：
- 强制要求每次代码更改都必须由另一位团队成员正式审查，才能投入到生产。也就是说，Code Review 是作为开发过程中必不可少的一部分。它的目的是为了尽可能平稳地扩展快速发展的工程团队。良好的代码审查以及有意义且有用的注释可以真正帮助提升整个工程组织的水平。
- LinkedIn 上的每个团队都使用相同的工具和过程来进行代码审查，这意味着任何人都可以帮助审查或为另一个团队的项目贡献代码。
- 每个提交的代码更改都应该包括设计概述，以简要说明更改背后的动机。
- 审查者应该给予正面的反馈。代码审查反馈往往只关注代码中存在的问题，这是非常不幸的。大多数人需要积极的反馈才会更有动力。所以，看到有好的代码设计时应该喊出来并给予积极的反馈。这有利于改善团队的动力，并且这种反馈通常具有传染性。
- 代码审查注释应该尽可能的详细，不要让人产生疑问。
- 某些代码更改的质量不是最高的，因此需要进行重新处理。这种情况，即使他们的代码需要重新编写，仍然必须承认作者为此付出的努力。
- 忽略无关紧要的 Review 评论。像跟代码格式相关的评论我们应该忽视它。代码的格式应该由自动化工具而非工程师验证。
- 每次提交，不应该只包含代码，还应该包括测试部分。比如：单元测试、手动测试的方案和输出的信息。
- 对 Code Review 应该有一个明确的范围，不要过分关注细枝末节。
对于以上的特点，对比了一下自己团队目前的实现。虽然我们也一直都在做 Code Review，但是感觉不足的地方还是有很多。比如，大部分的 Code Review 都是我和对项目熟悉的同事来完成，并没有做到所有的人参与进来。这样导致一个 MR 停留的时间过长，经常会出现代码冲突。对于每次 MR 的提交，基本上都只有代码，这个 MR 是干什么的，怎么去测试都没有说明，导致 Review 的成员工作是比较难的。
💡 Tip
Linux jq 插件的使用
在做 Elixir 项目时，经常要在命令行使用 curl 来访问一些接口，返回的数据格式不太直观。linux 的 jq 插件刚好可以完美地解决这个问题。比如，我使用 curl 访问一下 cnodejs 的接口，它返回的结果是下面这个样子：
加上一个 jq的管道操作，就会变得美观多了。
当然，它的功能不止于此。我们可以用它来完成切片、过滤、映射等等操作。
在 shell 脚本里，发现有时需要获取接口的值，可以利用它的 .[]获取响应中返回数组的每个元素。
iid=$(curl --header "${token}" "${api_url}/projects/${project_id}/merge_requests?source_branch=${current_sprint_branch}&target_branch=master&state=opened" | jq '.[0].iid')
我们还可以使用jq -Rr @uri来处理 url 的 encode
current_sprint_branch_encode=$(echo "${current_sprint_branch}" | jq -Rr @uri)