代码评审旨在增进团队协作，提高代码质量。建议每次评审200-400行，作者提前注释代码，设定检查清单，保持评审过程简洁无痛苦。通过GitHub PullRequest进行审查。定期进行，关注代码功能、可读性和风格，促进团队知识共享，提高系统可维护性，及早发现和修复问题。代码评审应视为学习和反馈的机会，而非批斗，保持趣味性。
代码评审的目的不是为了去刻意批斗某个Coder，而是为了团队成员之间相互了解学习，加深成员对系统的理解，使团队成员的代码更加健壮，提早发现代码缺陷。
那么应该如何做代码评审呢？
1 - 保持简短，对开发人员来说，一次只检查少于200-400行的代码(半小时左右)，超过 400 行将需要更多时间，并且会使评审者感觉疲倦，如果代码审查过程需要超过一个小时，您可以将其分成几个较小的模块。
2-作者应在开始审核之前注释源代码：通知同事应检查哪些文件，防止再次评审以前审查过的代码。
3 - 做一个要检查的清单：在代码审查过程中，清单上应该有预期需要检查代码的目标(代码的安全性，业务逻辑实现和用户访问权限等等 在评审的过程中可)和代码的作者和评审者，问题的安全级别 需要何时修复，修复确认人和确认时间
4 - 让它无痛苦。始终确保代码易于理解，不需要额外的评论。还为审阅者提供背景。我们通过GitHub上的Pull Request功能提交我们的代码进行审查。
5 - 定义你的目标。您可以专注于代码所需功能的表示; 避免代码味道; 关于代码与风格指南的相关性。但是要始终专注于对你最重要的事情，并尽力写出最好的代码。
代码评审的好处
提升系统的可维护性
•及早发现潜在缺陷与BUG，降低事故成本。
•促进团队内部知识共享，提高团队整体水平。
•评审过程对于评审人员来说，也是一种思路重构的过程，可以帮助更多的人理解系统。
•交叉审查代码，类似于结对编程，彼此都能熟悉对方模块业务，降低因人员流失的运营成本及风险。
后记：
代码审查建议每半月一次或一月一次，审查追求的是质量而不是数量。
不要过分要求程序员做代码审查。如果你强迫他们每天做一小时的代码审查，他们很快就会痛恨它，
把它当成一种无趣的任务。代码审查是针对代码，不是针对人。代码审查是一种学习，是表扬，是获得反馈，
是一种十分社交性的活动。代码审查应该是有趣的，不要让它变的无聊。
扫一扫
1543
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
