软件测试中码审查有哪些方法，如何更有效的实施代码审查_百度知道不做代码审查又怎样？ - 开源中国社区
当前访客身份：游客 [
当前位置：
不做代码审查又怎样？
从一次回顾会议开始“要不……我们不做……代码审查了……试试？”还记得当有人抛出这个建议时周围同学的表情，那种表情用两个字加两个标点符号就可以形容：“什么？！”对了，先介绍一下背景，这是项目一次普通的，我们正在讨论的是如何让更有效率和效果。我们做代码审查的方式比较简单直接，就是后，大家围在一台开发机周围，逐一轮换讲解昨天所有提交的内容，就像下图中的那样。还有，这是一个已经超过了7年的比较大型的项目，代码审查是我们从项目开始就坚持的一个实践，所以当有人提议废除它的时候，这在很多同学心里是想都没想过的事情。代码审查是一个很好的实践，可以帮助团队里的同学了解其他同学在做什么，可以分享项目的上下文，可以分享技术上的一些小魔法，可以发现很多潜在的代码缺陷，可以提高代码质量，还可以有很多很多好处……但是，在真正的实施过程中，很多情况下并不像想象的那般美好，经常出现例如有些同学由于跟不上其他人讲解的速度（毕竟不是自己写的）或是没有相关的上下文（例如刚加入项目的新成员），或是由于提交没有被很好的切分和组织，导致整个过程都处于游离状态（就像下图中的我……毫无摆拍痕迹），而代码审查的效果也打了折扣，渐渐的变成了一个流程，一个过场， 一个习惯。于是团队里就有人站了出来，引导大家去发现背后的问题，也就引来了这样一场激烈的讨论。在讨论中，有些同学坚持在说代码审查还是很有用的，有这样那样的好处，需要保持下去；有些同学则非常实际地指出了执行上的各种困难和问题。讨论异常激烈，直到有人小心翼翼地提出了文章开头的那个建议，一片哗然后大家都陷入沉寂：是啊，不做代码审查了，我们会失去或是得到什么呢？沟通的收益和成本在我看来，代码审查所暴露出的问题本质上就是如何权衡沟通的成本和收益的问题。在软件开发过程的发展中，无论是从一开始的瀑布，后来的敏捷，还是当下的精益。都有很大一部分篇幅是在强调沟通或者说是强调沟通方式的演进，都是为了解决已有沟通方式所带来的各种限制和问题。例如在我们自己的项目中就采用以下的实践来促进团队内外的沟通，包括：迭代计划会（Iteration Planning Meeting），每日站会（Daily Standup），代码评审会（Code Review），回顾会议（Retrospective Meeting）；还有XP中的结对编程(Pair programming)，现场客户 ( On-site Customer )等。而沟通的好处是可以得到快速的反馈，无论是80年之前就出现的还是前两年大热的精益创业，都是在强调快速反馈和基于反馈的快速迭代，通过这种方式来消除生产和创业过程中造成的各种浪费。但是（对，又是但是……），沟通也是有成本的，而且成本一般都还不低，相信这点也不需要多解释，大家肯定都经历过各种各样效率极低令人抓狂的讨论或是会议。在沟通的成本和收益同时摆在我们面前，如何做出选择？如何才能设计一套刚刚好的沟通体系，平衡收益与成本，来满足团队和项目的需要呢？沟通金字塔在读《重构》的时候，我深深地体会到：这个世界上没有什么是不变的，包括变化本身。所以要想得到解脱，我们就需要从简单的对与错，好与坏的漩涡中跳脱出来，用变化的眼光来看待周围的事物，并做好一直变化的准备。而面对沟通成本与收益的选择困境时，我第一个想到的就是。了解测试金字塔的同学肯定都知道，测试金字塔是一个很好的工具，它帮助我们从单一的测试选择困境中跳脱出来，将各种不同类型的测试建立起关联、纳入一个统一的体系，从而让我们可以在一个更高的维度来系统的思考和审视每一种测试的策略，关注点也从简单的“该不该”变为了“如何变化”。至于“如何变化”？我们可以通过在金字塔上添加一层新的测试种类来弥补整体测试策略中粒度太粗的问题；也可以根据项目情况通过移除一层测试种类，用其上层或是下层的测试来覆盖其测试用例，来减少成本；也可以通过将某个测试用例在金字塔中向上层或是向下层移动来寻找收益与成本的平衡。举个实际点儿的例子，例如我可以将一些基于UI的集成测试用例下移，用成本更低的单元测试来覆盖从而减少成本，加快反馈速度；也可以将一个单元测试用例上移，用基于UI的测试来增加其稳定性的和体现的业务价值。看，我们讨论的内容从简单的要不要写UI测试，需要写多少单元测试测试已经被转换到对于整体策略的变化和调整上来了。那对于代码审查的问题能否也通过金字塔这个工具转换到更大的空间上寻求突破呢？这就是沟通金字塔。相比于测试金字塔中的“UI－－Service－－UT，“Iteration Planning Meeting（见上图）－－ Code Review（见上上上图）－－ Pair programming（见下图）”就可以类比成沟通金字塔，和测试金字塔一样更靠近金字塔顶端的（例如迭代计划会）沟通频率越低，成本越高，但越接近业务；越靠近金字塔底端的（例如结对编程）沟通频率越高，成本越低，越接近实现。这几种不同的沟通方式所沟通的内容肯定也会有所重叠，通过将各个层次的沟通方式进行组合来保证我们团队的整体沟通质量，就像通过金字塔中的各种测试层次的组合来保证产品质量的一样。如果可以这么类比的话，那我们对于沟通质量的管理也应该是动态的、系统的、从整体上出发的。例如就可以通过在沟通金字塔中添加一层新的沟通机制来弥补沟通粒度过粗的问题，例如QA Team现在在做的每周例会就是一个好的例子；也可以将一些沟通内容通过层次（上下）的调整，甚至是通过直接减少一层沟通方式来优化我们的整体沟通效率，例如我们可以通过增加结对编程的Switch频度来替换掉成本更高的代码审查。而目标就是通过不断地动态调整和优化沟通结构，试图寻求一个沟通成本，沟通收益，沟通效率平衡的沟通环境。回到问题上来如果沟通金字塔的理论说的通，那代码评审就不再是一个：“必须要做的敏捷实践”，而只是沟通金字塔上的一层而已。那它的存在必然是为了弥补上下层沟通之间的空隙，那这个空隙到底是什么呢？是什么样的沟通是结对编程所不能覆盖，而用类似于迭代计划会这种更高层的沟通机制覆盖又不太经济的呢？为了让团队重新找回这个答案，我们最终决定试一试：停止代码审查一个月，在这一个月的时间我们去体会没有代码审查的得与失，在一个月之后重新举行回顾会议再来讨论是否要继续做代码审查。在一个月后如期进行的回顾会议上，团队又重新讨论了这个议题，最终觉得通过这一个月的尝试，在还无法做到更频繁地Switch Pair的情况下，代码审查还是很有必要的。例如在这个月中，大家对于其他人在做的工作了解变少，集成出现了很多冲突；缺陷的数量也有所增加，其中有些是很明显的错误，很容易通过代码审查的方式发现并在前期消除；代码质量也有明显下降，出现了测试的缺失和很多代码坏味道。而另一方面为了让代码审查能够真正的发挥其作用和价值，经过讨论我们也优化了代码审查的方式，让大家更有参与感，更有效率，也更有乐趣（见下图抓拍）。交付价值 Over 遵循实践日本剑道有个心诀，叫:1.“守”：最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界。2.“破”：基础熟练后，试着突破原有规范让自己得到更高层次的进化。3.“离”：在更高层次得到新的认识并总结，自创新招数另辟出新境界。守固然重要，但如果不能在守得基础上寻求突破，领会其中的奥秘和背后的道理，则始终无法达到离的新境界。在中国的武术中也有“无招胜有招”的说法，这里的无招就是指在将招数融会贯通之后，能够运用招式背后的原理，打破招数的限制，随机应变，自由应对。而反观我们自己，是不是已经慢慢的不知不觉的被困在“守”的围城之内，变成了中最后的那群猴子，只知道去拿香蕉会被打，也会跟着其他猴子去打那些试图拿香蕉的新猴子，但是为什么要这么做？我们已经忘了，或从来都没有知道过。所以，不要以为遵循了敏捷提倡的一些实践我们就是敏捷的，不要以为遵循了精益的实践我们就是精益的。在我们没有理解并追求其背后真正价值的时候，只不过是平添了另外一份成本而已，不如不做。出处：
想通过手机客户端（支持 Android、iPhone 和 Windows Phone）访问开源中国：
旧一篇： 4个月前
新一篇： 4个月前
你也许会喜欢
可以考虑都放在年会上统一审查，事关年终奖 :laughing:
2楼：jorneyr
我们的代码不做的结果就是有人到处调用 System.gc() 尽量防止程序内存不够奔溃，疯了
3楼：noonoo 来自
4楼：neo-chen
日本剑道有个心诀，叫守 破 离:1.“守”：最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界。2.“破”：基础熟练后，试着突破原有规范让自己得到更高层次的进化。3.“离”：在更高层次得到新的认识并总结，自创新招数另辟出新境界。
5楼：叫我刀刀
这是什么公司啊
6楼：cooleone
最后一张苹果开会够霸气
7楼：neo-chen
很多工作，可做可不做，做与不做相应微呼其微，很多时候是给上面看的。同时刷存在感。不开会如何体现你的管理呢？
8楼：第五郎
全是苹果。
9楼：excepiton
CTO说要做，然后都得加班做
10楼：KevinJen
为毛要打码
11楼：花仲马
引用来自“叫我刀刀”的评论这是什么公司啊ThoughtWorks
12楼：叫我刀刀
引用来自“叫我刀刀”的评论这是什么公司啊引用来自“花仲马”的评论ThoughtWorks哦
13楼：花仲马
引用来自“KevinJen”的评论为毛要打码涉及公司的东西吧
14楼：loki_lan
力推结对编程
15楼：差不多先生
16楼：12叔
引用来自“jorneyr”的评论我们的代码不做的结果就是有人到处调用 System.gc() 尽量防止程序内存不够奔溃，疯了这种人谁 招的
17楼：fir01
好个积极。如果项目跟久了还跟不上同事的讲话，理解不了核心人员的讲解。只能说明没能力，团队能力要相互配合得上才行。却说是代码审查的问题，扯淡。 代码审查我们目的很多，其中很重要的是保持这个项目中的编程文化的一致。要求所有人主动沟通，学习，不行滚蛋。
18楼：一如当初
引用来自“loki_lan”的评论力推结对编程那你得把工资分一半和你结对的人。
19楼：loki_lan
引用来自“loki_lan”的评论力推结对编程引用来自“一如当初”的评论那你得把工资分一半和你结对的人。你有把你的工资扣除修复BUG的工资吗 :)
20楼：changnet
引用来自“jorneyr”的评论我们的代码不做的结果就是有人到处调用 System.gc() 尽量防止程序内存不够奔溃，疯了我们的gc都是放到底层事件主循环中根据空闲时间、内存占用情况自动调用。逻辑代码中怎么会有这样的api呢？
与内容无关的评论将被删除，严重者禁用帐号
本周热点资讯
本站最新资讯本文由&– 小峰原创翻译，转载请看清文末的转载要求，欢迎参与我们的！
好的代码审查器可以大大地帮助提高代码质量，减少错误几率。
虽然现在市场上有许多可用的，但如何挑选也是一个艰巨的任务。在咨询过有关专家的建议和意见之后，我们罗列出了以下17款最佳的代码审查工具。
1）CodeStriker
CodeStriker是一个免费&开源的Web应用程序，可以帮助开发人员基于Web的代码审查。它不但允许开发人员将问题、意见和决定记录在数据库中，还为实际执行代码审查提供了一个舒适的工作区域。
官方网站：http://codestriker.sourceforge.net/index.html
2）RhodeCode
RhodeCode是另一款非常棒的代码审查工具，能让你发现代码中的bug和问题，并在检查过后删除它们。
官方网站：/
3）Codebrag
Codebrag是一款简单轻巧，提高进程作为的代码审查工具。它能帮助我们解决不少问题，如非阻塞代码审查、智能邮件通知、联机注释等等。
官方网站：/
4）Phabricator
Phabricator是一个和web应用，包括代码审查、托管GIT /Hg/ SVN、寻找bug、浏览和审计源代码等功能。
官方网站：http://phabricator.org/
5）Codifferous
Codifferous是一款免费的代码审查工具，能为我们提供更快的代码审查服务。无论你在何时何地，Codifferous能让你的团队协作审查工作变得更容易。你忘记了一个pull请求？没事。Codifferous允许你检查任意分支上的代码，无论何时你都可以留下注释、获得反馈。
官方网站：/
6）Getbarkeep
Barkeep是“非常友好的代码审查系统”——让你用一种快速又有趣的方式来检查代码。你也可以用它翻阅Git存储库的提交，看diff文件，写注释，并且你还可以将这些注释通过电子邮件发送给下一位提交者。
官方网站：http://getbarkeep.org/
7）Crucible
Crucible是另一款超级受开发人员欢迎的代码审查工具，可以审查代码、讨论修改，通过Crucible灵敏的审阅流程来确定缺陷。Crucible能够使得Subversion、CVS、Perforce等版本控制软件的代码审查变得简单起来。
官方网站：/software/crucible/overview
8）Code Review Tool
Code Review Tool允许团队成员通过一种简单而有效的方式来协作审查代码。它提供了正式代码检查的所有优势，而且相比而言，所需的精力和时间更少。它既支持正式，也支持轻量级的代码审查进程。
官方网站：/
9）Malevich
用Malevich审查代码真的很简单。审查人员在同一个浏览器中，既可以看文件的原始版本，也可以看它的新版本。如果想要给某一行代码添加注释，只需要点击那一行，直接打字就可以了。提交注释之后，其他代码审查人员都可共享。
官方网站：/
10）SmartBear
SmartBear是一个有助于团队通过共同的开发、测试和管理工作以便能生产出高质量代码的代码审查工具。它允许团队在一个透明、协作的框架下进行同行代码审查、用户故事和测试计划——即时保持整个团队知晓对代码所做的更改。
官方网站：/product/collaborator/overview/
11）Review Assistant
Review Assistant是一款支持Visual Studio的简单又优秀的代码审查工具。
1）在审查级别、特定的源代码块或源代码条上添加你的注释。
2）在预定会议之外启动与团队成员之间就代码的讨论。
3）标记需要修正的注释和缺陷之处。
4）在代码编辑器显示审查注释。
5）在审查注释和代码之间进行即时切换。
官方网站：https://visualstudiogallery./9ef817b4-2c6d--5be48f9d91b9
12）Review Board
Review Board是程序员节约时间、资金和精力的代码审查好工具。语法高亮的代码，可便于更快读取。
13）Peer Review Plugin
此款插件通过提供基于Web的友好的审查环境，来节省开发人员在代码审查会议上所需要浪费的时间。
官方网站：http://trac-hacks.org/wiki/PeerReviewPlugin
14）Code Reviewer
Code Reviewer是一款免费的、简单的又易于部署和使用的代码审查工具，由SmartBear开发——也是Collaborator的发明者，业界第一家推出商用代码审查工具的公司。
官方网站：/
15）Code Analysis Tool
CAST代码分析技术着眼于解决两个基本问题。首先，最现代化的IT系统是由成千上万的组件构成，由多个团队和许多开发人员构建的。其次，测量这些系统的软件质量需要涉及多种技术和代码工具。
官方网站：/products/code-analysis-tools
16）jArchitect
JArchitect可简化复杂Java代码库的管理。你可以使用JArchitect分析代码结构、指定设计规则、执行高效的代码审查，以及通过比较不同版本的代码掌握作出的改进。
官方网站：/
17）Reviewale
Reviewale是市面上新出来的代码审查工具，它的功能包括语法高亮、发现bug/问题、改进代码、干净的用户界面、自定义代码字体等等。
官方网站：https://reviewable.io/
译文链接：
英文原文：
翻译作者：&– 小峰
[&转载必须在正文中标注并保留原文链接、译文链接和译者等信息。]
在文章中找不到问题答案？您还可以
热门栏目订阅开发者需做代码审查的五大原因_单元测试方法_领测软件测试网
开发者需做代码审查的五大原因
发表于：来源：酷勤网作者：不详点击数：
开发者需做代码审查的五大原因.每个人都承认代码审查的花销大，而且又耗时，特别是当大家忙完成软件项目又把它送去软件测试部门时。对一些开发人员来说，它更是会引发更多的办公室政治和流言蜚语。
　　每个人都承认代码审查的花销大，而且又耗时，特别是当大家忙完成软件项目又把它送去软件部门时。对一些人员来说，它更是会引发更多的办公室政治和流言蜚语。
　　一次代码审查可能会使代码逐渐得到改进。如果你认为你从有效的代码审查中只是稍微改进了一下软件，那你需要再想一想。以下五点易忽视的原因会给你些许启发。
　　1. 开发人员若得知他们的代码会被评估，他们会更加努力工作。
　　对代码审查最有用的是让编码人知道他编写的代码会被审查。这就像一次内容为400级运算的期末考试。参加考试与否并不重要，因为考试的目的是学会运算。
　　这个道理也适用于代码审查。计算机程序员对自己编写的代码总是相当自信。程序员之所以熬夜工作，是因为他们真正热爱自己的其工作，而不是出于金钱或其他目的。因此，代码审查可以直接影响开发人员的成就感。
　　编码人不希望有任何针对他代码的批评，所以一旦知道代码将被审查，就会采取额外的努力做好工作。实际上，代码审查通常不能发现什么的。但是，如果知道有人要审查编码，那么在编辑过程中程序员就会尽可能做好。
　　2. 代码审查可以改进开发人员的技术
　　在你的心里，你可能不会太在意某一特定软件项目的成功。但是，大多数程序员想要改善他们的技术，这意味着向其他人学习。没有比代码审查更好的学习机会了。
　　例如，从一个优秀的开发人员的编码中，你能更清楚地了解编程语言可以做什么，你将学会编写更有效的代码，并找到更多可用于组织代码的模式。
　　代码审查能帮助团队成员从彼此的错误中汲取经验，并成为更好的程序员。通过简单的反馈意见，公司可以提高了其开发员的水平。开发员重视审查，因为他们知道这将帮助他们成长。当代码审查以小组为单位进行时，整个团队都得以提高。但更好的是，代码质量也得到提升，并易于维护。
　　3. 代码审查有利于导师制度，程序员们会学到更多
　　代码审查有助于新的开发人员并使他们熟悉其他同类模块。审查过程有助于促进思想交流，使代码可重复利用。
　　代码审查有一个系统的方法，可以为程序员分享团队领导们的经验提供平台。当领导重写某些程序，使程序运行效率在3分钟内提升50倍时，是十分令人振奋的事情!编写其他程序时，你或许就可以找到一些新的方法或创造一种新的解决方案了。
　　4. 代码审查可以实现优质文化的传承
　　代码审查的目的是提供巨大的机会。代码审查让代码库和编码团队都有机会发展一种连贯性和可靠性。它把有经验和专业知识的团队作为整体加以利用，程序员可以磨炼他们的专业技能和经验，同时以他们的经验和专业知识为公司和团队服务。这使该公司的投资得到有形的回报：愉悦的程序员以及工作代码的能力和一致性不断获得提升。
　　代码审查有助于创造一种微妙的变化，因此，管理好和做好代码审查可以很大程度上改善软件质量。开发人员会对审查中有出错的数据的判定迅速给出抱怨，但我们必须改变规则，要将优质高效发展作为衡量过程的尺度而不仅是价值传递的里程碑。
　　5. 代码审查可以激发团队凝聚力
　　人们认为代码审查仅仅是寻找漏洞，但它却能把人团结在一起，它可以提供的远远超过你所预期的。
　　又很多这样的例子在执行代码审查时发生，但是最好的成功模式是在一个团队成形时就开展审查。你从事某个项目的时间越长，所创建的代码质量就越好。这是因为所有的代码审查过程和管理在项目开始时就开始了。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）}