不要忽视代码审查的重要性
在学校里没有教给你的一项本领就是怎样做一个好的代码审查(CR)。你学习了算法、数据结构、编程语言的基础知识，但没有人会坐下来对你说:“下面是如何确保你能获得很好的反馈的方法。”代码审查是创建优秀应用的关键过程。经过审查的代码往往质量更高，bug更少。
如果电脑能决定并执行一条规则，就让电脑去做吧。在空格和制表符之间争论并不是对人类时间的有效利用,相反把时间花在就规则应该是什么达成一致上。这些机会可以让你看到你的团队，在低风险的情况下如何处理“不同意和承诺”。
现代的编译语言工具和语言可以开启语法检测功能，并反复使用它们。在Ruby中，有Rubocop；在JavaScript中，有eslint；在CSS中，有stylelint。找到你需要的语法检测工具，并将其插入到构建工具中。
如果你发现现有的语法检测工具动力不足，可以尝试写你自己的！
每个人都是代码审查者
将所有代码审查工具责任都交给Shirley，咋一听来是很有诱惑力的。
虽然，在编写代码方面，Shirley是一个奇才，她总是知道什么是最好的，她了解公司制度的来龙去脉，而且她在公司工作的时间比你们团队的集体任期还要长；
然而，Shirley理解了这些事情，并不意味着她的团队中的其他人也都理解。年轻的团队成员可能会犹豫是否要在Shirley的代码评审中指出一些问题。
我发现将评审分发给团队的不同成员会产生更健康的团队动态和更好的代码。一个初级工程师在代码评审中最有力的一句话是：“我觉得这很混乱”。这些都是使代码更清晰、更简单的机会。
推广这些评论。
增强可读性
我们使用GitHub来管理我们的代码项目。几乎每个GitHub上都支持Markdown，这是一种向评论添加html格式的简单方法。
拥抱Markdown是让代码变得更加可读。GitHub或你选择的开发工具可能有语法高亮显示功能，这对于插入一些代码片段非常有用。对于内联代码使用单回勾()或者对于代码块使用 （``）可以更好地交流思想。
熟悉标记语法，特别是在注释中编写代码时。这样做将有助于使你的评论更加具体和集中。
至少留下一句积极的评论
代码审查本质上是负面的。在把代码发送之前，告诉代码的作者这个代码有什么问题，这是基本。但有些人在这这个代码上面花了时间，他们希望你能指出怎样才能做得更好。
因此，至少留下一句正面的话。让它有意义和个性化。如果了解到他们一直在努力的解决问题，那就大声喊出来，这可以简单 👍 或 “Love this.”
在每个代码评审上留下一些积极的内容，可以微妙地提醒我们，我们是在一起的。如果我们创建更好的代码，我们都会受益。
提供替代方案
我常常尝试着去提供一个可替代的实现方案。对那些只学习了一门语言或框架的人更应该如此。
当要注意表达的方式。如果表述不正确，可能会让人觉得你傲慢或自私。“尽量保持客观，并讨论你所提供的备选方案的利弊。”如果做得好，这将有助于扩展每个人的技术知识。
审查延迟
保持一个极快的代码审查速度非常重要的。(实现这个规则很简单：保持审查代码足够小。)
长时间的代码审查延迟会扼杀生产力和士气。如：“3天前，你被分配去审查一份xxx的任务”，这听起来很刺耳。
如果你希望减少自己的审查延迟，我建议遵循以下规则：在编写任何新代码之前审查代码。
作为一种直接处理延迟的策略，尝试在代码评审上进行配对。启动一个屏幕共享来浏览和讨论评论。对解决方案进行配对，使代码达到批准的状态。
对于发件人来说：保持内容尽量小
你在代码评审中收到的反馈质量将与拉请求(Pull Request)的大小成反比。
为了最大限度地保持反馈的尖锐和建设性，要知道较小的请求会让读者更容易接受。
如果你的拉请求（Pull Requests）很小，怎么办？这时你需要有一个不同的地方来进行详细的描述。如：这个单一的拉请求（Pull Request）如何适合本周或本月的工作？我们要去哪里，这个拉请求是如何让我们到达那里的？这种对话类型的方式在表现效果方面是很好的，因为对于较小的Pull请求，你很难记住它的编写上下文。
这个概念会因语言的不同和团队的不同而不同。对于我自己来说，我试图让Pull请求总数少于300行。
希望这8个技巧能帮助你和你的团队有更好的代码审查。通过改进代码审查过程，你将拥有更好的代码、更快乐的团队成员，带来更好的业务。
代码评审的还是比较少 :) 代码审查还是很重要的，但是这部分需要专业的团队去做了
页:
[1]
