【.com快译】在今天的文章中，我们将探讨如何审查别人编写的代码。这意味着我们需要将职位转换为审查者，并期望代码提交者遵循理想的开发原则和最佳实践，从而减少我们的工作量。您可以通过多种方式完成代码审查任务。在此我们将列出一份分发清单，帮助您有效缩短审稿时间，提高审稿效率。Disclaimer每一段代码，每一个项目，甚至每一个团队都有自己的特点，所以这篇文章只是一个指南，而不是必须严格执行的硬性规定。另外请注意，代码审查几乎必然包括代码阅读和审查问题沟通等要素。因此，这里我们主要着眼于提高通信效果，而不是更具体的代码内容。需要根据实际情况判断具体代码内容是否符合要求。1.参与最多的人负责回答问题。假设你没有参与代码编写（只负责代码审查），那么大家需要意识到你不知道代码编写的背景或具体情况。所以，不要轻易把自己不懂的部分当成错误，要知道每个人思考问题的方式都不一样——也就是给别人解释的机会。以此为基础找到以下问题的答案：如果存在问题，请了解它发生的原因。如果您有解决方案，请在与代码编写者沟通时将其作为建议提供，您发现问题的严重影响是什么。如果您没有解决方案，但可以就如何修复它提供指导，请确保沟通到位。如果您认为特定的设计模式可以解决问题，请详细告诉我。如果您认为还有其他函数或部分代码可以用来解决这个问题，您应该指定它。不管你指出什么方案，只要不偏离主题，相信都能对写代码的人有所帮助。如果它不是问题，请不要指出它是问题。如果代码编写者误认为你的表达式是代码有问题，就会修改，而这种修改往往不会详细讨论。具有讽刺意味的是，即使是对代码内容的小改动也会导致新的问题。更糟糕的是，你的建议可能含糊不清或模棱两可，导致开发人员多次迭代代码内容。总之，坦诚地表达自己的观点，可以让现实问题得到重视和纠正，要注意哪些观点只是出于怀疑，而不是真正的错误。让问题成为问题。不要自己去找答案，留给开发者直接解释。具体来说，不要过分修辞地修改问题陈述，也不要引导对方给出你下意识想要的答案。让对方自己研究。开发者对代码越熟悉，对代码的写法和内容就越有发言权。他们可以比您更快地找到更明确的答案。但是，如果您愿意花时间在审查周期之外考虑代码的内部工作原理，那么自己进行调查可能同样有价值。以下是人们经常犯的错误：修改前：1.假设某些代码必须执行得很糟糕。表达的内容不清楚，问题没有说清楚，假设被审核人还没有猜出你想传达的观点。2、为什么表现不好？是否应该修改？3.是否存在性能问题？会有什么影响？（描述。）已编辑：我认为此SQL查询提供了正确的结果集，但我认为它可能正在执行表扫描或未充分使用索引，但我不确定。能不能查看一下它的执行计划，看看数据库有没有性能提升的空间？也许我们可以调整这个查询，或者添加更多索引。请注意，目前的情况意味着用户每次查看主列表时都会受到影响。这承认当前做法的正确部分（即SQL结果是正确的）。1.指的是合理的怀疑，并声明这只是怀疑。（'我不确定'。）2.它表达了问题的可能来源（'表扫描'、'索引未使用'）。3.给出可操作的建议（“检查执行计划”）。4.建议潜在的修改方向（“更改查询”、“添加索引”）。5.它表达了实践中变化的影响（“用户查看列表时的表现”）。2.明确给出怀疑的理由。大家在提供修改建议或者指出问题的时候，要注意把质疑的理由说清楚。这样做可以确保参与对话的其他同事根据我们的陈述或他们自己的理解找到正确的解决方案。这非常重要，尤其是在未明确说明预期解决方案的情况下。仅仅提出问题不足以帮助代码编写者了解潜在的问题根源。这是一个反面例子：这里有一个错字。之所以将其归类为反例，是因为如果对方没有发现拼写错误，很可能对方再次检查时也找不到错误。当然，除非这里的错误非常明显。无论如何，***直接给出正确的拼写。在这里需要提醒大家：“这里”是一个很模糊的表述，除非开发者已经意识到在代码中加入验证过程的意义，否则很有可能直接在这部分代码片段中复制一条验证语句，或者盲目猜测审查者的意图。下面是一个正例，当它应该是“type”时，它被拼成了“typ”。这里纠正反例：指出拼写错误，并给出正确的结果。另一点是代码没有添加认证属性以允许任何未经授权的用户调用。这可能会导致安全问题，包括未经授权的第三方更改系统的内部状态。请添加验证属性以避免此类问题。解释问题的细节，帮助开发者了解影响并防止在以后的开发工作中再次发生，最终给出理想的解决方案。3.需要审核什么在审核过程中，我们需要考虑多方面的问题。但一般来说，如果回答让你觉得不舒服，基本说明我们发现了问题，需要反馈帮助解决。不过，也需要注意的是，大家要适当放弃争论，尤其是在问题不影响产品质量的情况下。显然，坚持不正确的缩进习惯只会让开发人员生气。一般情况下，大家会直接review所有的代码，然后review第二遍或者第三遍；当然，我们也可以用list的方式对每个部分分别进行复习。根据我的理解，我按照重要性对代码的各个部分进行了排序：快速检查清单1.更改是否可行？1.改变会达到预期的效果吗？也许应该与项目的初始要求协同考虑。2.假设和约束是否适用于系统？3、如果对用户有影响，影响是否可以接受？（例如，向Web应用程序添加一个新的大型JavaScript库。）4.更改是否会产生持续成本？（包括服务器、许可，甚至处理器资源利用率。)5.变更是否合法？（是否避免了使用未付费的专利库、其他来源的代码、不兼容的许可甚至未受保护的数据等？2.是否有正确的技术方向？现有设计是否适合以前计划的解决方案？变更是否会引入合理的复杂程度？是否保证将故障点数量保持在最低限度？是否灵活？是否仍为未来的产品开发提供足够的灵活性空间？使用更简单或适当的解决方案时，是否可以避免引入第三方库和代码？3.错误和意外情况能否妥善处理？1.如果是，是否会包含在日志记录中？2.如果是，是否会为用户提供正确的3.如果是，是否放慢开发团队的速度？4.错误和异常是否得到处理？它们是否在正确的代码部分得到处理？4.它们是否包含正确数量的指标？1.它能否指示有意义的数据？5.更改是否安全？1.做是否避免泄露所有应受保护的数据？加密？3.它是否检查或验证输入内容或第三方系统？6.是否避免引入技术债务？1.如果引入了技术债，引入的原因是否在代码中注明了这些债项？2.这些原因是不是用现有的有效方法都解决不了？3.技术债务是否可以接受7.是否经过测试？1.输入数据是否受制于验证/白名单/黑名单机制？2.是否为相关数据使用了正确的变量大小（例如，shortamountOfPeopleInStadium是不合适的。)3.是否包含单元测试？这些测试有效吗？4.它包括集成测试吗？这些测试有效吗？5.它包括自动化测试吗？这些测试有效吗？6.如果要修复一个bug，相关的测试能否重现原来的bug8.代码可读性好吗？1.是否包含拼写错误或拼写错误？2.是否包含奇怪的缩写？3.所写的内容是否通俗易懂？（即在文档和注释中使用适当的语言和表达方式。）4.注释的内容是否有意义和有效9.代码是否可维护？1、如果它在系统中引入了一个新的“概念”，文档中是否体现了这部分概念的定义？2.是否避免了任何奇怪的代码结构？（即“熟练的代码”。）3.更改和方法名称是否符合它们的意思？（你能从它的名字中看出它的意思吗？）10.它是一种正确的编码风格吗？1.变量/方法/类的使用2.缩进3.大括号的使用4.注释密度4.正确阅读代码根据项目类型和所引入变更的具体性质，我们通常可以采用多种方式来实现这个变化。你可以这样想：当我们在寻找一个特定的错误代码片段时，我们通常会在脑海中完成调试过程，包括读取相应的代码从输入到处理，并根据调用顺序理顺其逻辑。这种代码阅读方式可以帮助你理清组件之间的关系和交互，但不适用于其他场景。从上到下阅读代码可以帮助你理解抽象的含义，并弄清楚是否需要使用灵活的代码来支持不同的场景，但这往往不能让我们快速掌握代码之间的冗余或缺乏依赖——因此，这种做法不可取。在查看不同的模块或命名空间时，您可以关注它们的子系统如何交互和组织，这可以帮助您找到常见的设计和架构问题，但往往会遗漏具体的实现细节。总而言之，我们应该确保在审查代码时考虑多个角度，同时迭代地改变位置和排序。5.以不会导致误解的方式讨论反馈作为审阅者，我们的反馈通常可以直接传达给原始开发人员。此外，其中一些评论可能非常具体，而另一些则更为开放，这意味着需要让更多的开发人员参与广泛的讨论。当您的反馈仅仅是大文本形式时，通常很难在不引起误解的情况下对其进行讨论。我个人喜欢GitHub和Bitbucket等服务中的评论功能。这些评论逐行清楚地显示，让用户清楚地掌握他们的相关上下文并讨论反馈的特定部分。更重要的是，如果文件内容发生变化（这在反馈过程中很常见），对之前代码的反馈将被隐藏，这意味着过期的反馈将不再包含在代码审查过程中。GitHub目前的代码审查方法是，我们可以将所有信息排队，作为审查的一部分发送，然后批准或拒绝。微软提供的TFS在线服务也采用了类似的机制。这种方法非常有效。我们总能找到大家对代码错误和改进空间的评论，然后有针对性地进行修改。但是，在采用这种方法时，请务必在发送之前仔细检查所有评论。6.避免“挤牙膏”，需要提供尽可能完整的审核意见，而不是像挤牙膏一样，发现问题就通知开发商修改。无论您是提供单个文本还是拆分评论，一次提供尽可能多的信息可以让开发人员（包括我们自己）更好地利用他们的时间。四处奔走修改代码对开发人员来说从来都不是一种舒适的体验，由此产生的怨恨最终会归咎于你。有时人们通过电子邮件发送代码审查反馈。在这种情况下，邮件的结构就变得非常重要，因为好的格式可以让对方逐行回答，我们也可以在得到合理的回答后删除不需要的部分。7.要有礼貌。永远不要以“这是一个错误”的心态提交反馈——即使是这样。始终保持“这里有改进的余地/这里应该改进”的态度；另外，除非您100%确定，否则请提出问题。请记住，审查的是人，而不是机器；其次，他们已经尽其所能地完成了他们的工作。即使开发者因为技术、知识、经验或时间的限制得出了无法接受的代码结果，也请坚信他们为项目的推进贡献了很多能量。虽然LinusTorvalds式的咒骂和责骂读起来很有趣，但对交流对象却是深深的侮辱和伤害。再说了，为什么非要给自己树敌呢？毕竟，俗话说，和则生财。原标题：如何做好codereview【翻译稿件，合作站点转载请注明原译者和出处.com】
