您如何使人们接受代码审查？ [重复]

#1 楼

我发现，不喜欢代码审查的人会尽最大努力解决您放置的任何内容。是在某个将其视为常规编码方式的地方工作，并且只雇用可能很适合该环境的开发人员。

如果您不能更改与谁合作的人，则可以如果您先给出自己的代码进行审查，那就会成功。鼓励他们发现错误（敢于建议我添加一些故意的错误吗？），以便您可以证明这并不意味着批评所涉及的开发人员。这是IMO的主要问题：人们过于个人地进行代码审查。

#2 楼

简单：将重要项目分配给接受代码审查的程序员。这是一个明确的信息：这个项目太重要了，不能留给业余爱好者。

不合作的程序员可以进行维护工作。如果没有广泛进行代码审查，您的公司将拥有很多。弄清楚这是一条死胡同。这些产品的重要性将降低，下降或被经过代码审查的较新产品替代。将接受代码审查的新员工分配给新项目。

总体而言，这将告诉您的开发人员该公司正在采用代码审查。他们可以选择：走还是走。公司中没有任何人会与公司抗争。

#3 楼

好吧，如果有人完全拒绝并且您不是他们的老板，您真的不能做到。

但是采用另一种风格的主要原因是...一致性

我认为，无论存在什么疯狂的风格，都必须是一致的。因此，如果以这种风格构建项目，则除非有特别令人信服的理由进行更改，否则通常必须保持这种风格。因此，如果他们的风格不匹配；这是事实，应该使它匹配。毫无疑问。

还有其他一些值得注意的问题，完全是错误的。安全性，一般的“错误”等。这些都是毫无疑问的，应予以更改。风险和问题如何解决，我认为您需要自己决定如何采取行动。但是您希望您不要与如此无理的人一起工作。

#4 楼

我是程序员，并且喜欢代码审查。根据我的经验，进行良好代码审查的关键是使代码更好。

当我与一位同事进行代码审查时，他/她指出了潜在的改进或潜伏的错误，我感到很高兴。代码得到了改进，我们可能都变得更聪明了。为什么我不喜欢呢？

确保进行代码审查的人员可以并且会提供有用的信息。如果唯一的输入代码审查提供的内容可以使用工具轻松完成，那么代码审查就是浪费时间。

确保代码审查不会浪费时间，并且大多数开发人员会喜欢他们的。

#5 楼

在管理项目时，如果我说我们要进行代码审查，那么我们将进行代码审查。我当然会提供这样做的充分理由，但归根结底，这是我的责任和决定
实施它们。

如果程序员不喜欢它，他们可以找到替代工作。无论如何，通过淘汰一半的开发人员，可以有效地改善大多数失败的项目，而根据我的经验，最贫穷的开发人员最反对代码审查。

#6 楼

我加入代码审查流程的唯一原因是，大约一年前，试图强加他们的人拔出了优势卡，并让我们针对给定项目审查彼此的代码。在该项目结束时，我可以看到巨大的好处，现在我尝试对我的项目进行代码审查。

#7 楼

“有效”还不够。代码不仅是为机器执行而编写的，而且是供人们阅读，修改和改进的代码。如果人们找不到代码的方式，那么他们就无法完成编程中最重要的部分。

如果Joe Programmer说：“别看我的代码，我“是唯一需要了解它的人”，我对此表示怀疑。仅在极少数情况下，只有一个人才能触摸代码。即使是这样：乔在下周，下个月，下一年也能理解自己的代码吗？可能不是。

#8 楼

几乎在每个商业机构（以及大多数非商业机构）中，程序员都不拥有自己编写的代码，而雇主却拥有。

在几乎每个商业机构（以及大多数非商业机构）中，因此）大多数程序员似乎都认为自己拥有编写的代码。

由于接受代码审查作为一种设计改进技术，这引起了很多问题。

减少阻力的方法可能包括：


引入配对编程：除非有两个程序员正在看，否则不会编写任何代码。即时代码实时审查。确保两人定期轮换。
找到一种使代码审查“匿名化”的方法，这样就可以不进行个人的
小块审查，这样就不会有人面临长长的清单。改进
在对代码进行审查（以及实施和审查行动要点）之前，不允许签入任何代码
根据代码审查的接受程度，决定酌情决定支付哪些费用

我不建议您特别推荐上述任何内容。

重要的是要真正了解真正反对评论的内容，而不是您的反对内容在表面上听到。也许适用5个为什么要更深入？

#9 楼

我不喜欢在开发人员时进行代码审查。
但是，如果我是领导者，我真的很想进行代码审查。我们知道为什么。
但是，有些开发人员一定会像我一样不喜欢代码审查。
如何进行匿名代码审查？
我们可以编写示例代码段或技巧经过代码审查以找出更好的方法。
一个简单的例子： br />在某些项目中，我们遇到了..原因引起的问题...
始终检查...
我们可以将其放入Wiki或其他地方，然后讨论在每周的团队会议上。
技术负责人会这样做，并鼓励高级开发人员和每个团队成员也这样做。代码。
人们可能不喜欢代码审查，但想知道哪种更好的方法。

#10 楼

我在结对评论方面经验丰富。当两个人坐在同一台显示器前时，两个人正在检查彼此的源代码。我们确保并非总是同一个人，并且已经明确并事先商定他们俩都在寻找什么。

但是，仍然需要进行开放的代码审查，他们要乐于接受批评。

#11 楼

拥有较高权限的机构应进行审查。甚至那些一开始反对该想法的人也应该希望看到它的好处。如果他们做不到...很好，那就真的帮不上忙。但是，这两种情况下的关键都是使受审者了解这不是对他们技能的个人攻击，而是团队努力更有效地消除每个人的错误。

#12 楼

您如何使人们接受您的代码审查？

您不能，所以您不这样做。在要求您承担任何责任之前，您不对任何其他人的工作负责。

您可以进行“审核”，因此更像是“反馈”。不是您是老板在寻找别人做错的事情，而是两个专业人员在讨论解决同一问题的不同方法。

IMO，任何两个程序员都会想出不同的方法来解决问题，并且他们俩都是对的。

问被审核者，“您认为采用这种方法的好处是什么？还提供您看到的缺点和替代方法的优点。请求您已经指出的DA的确认-“您是否同意这可能与您的代码有问题？”

我认为大多数编程冲突都来自于价值差异，并猜测可能会发生什么在将来。人们可以花几个小时争论完全不确定的事情。现在专注于实际问题，减少（但不能避免）以后可能发生的事情。

#13 楼

最好的方法是让做出决定的程序员做出决定。

我建议使用一些人际交往能力，并从讨论如何确保小组能够一起工作开始，我还将讨论确保程序员的工作场所技能保持最新状态的方法。

当然，一种前进的方法是进行代码审查，但是还有其他一些可能成功的方法，例如阅读和讨论有关如何编程的书。我建议使用“清洁代码：敏捷软件技巧手册”（http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882）。

另一件事是让每个程序员在完成某项工作后在团队面前展示自己的项目。这自然会确保最丑陋的东西不会被写成，每个人都会为自己取得的成就感到自豪。

#14 楼

就个人而言，我认为不喜欢代码审查的程序员只是一个非常糟糕的程序员。如果您编写好的代码，则无需担心审查。您实际上可能会对您的风格赞不绝口。但是，如果您养成编写不良代码的习惯，那么我可以想象为什么有人会不喜欢评论。但是让别人指出您的风格中的错误对改善您自己的体验很有用！您应该从评论中学习，而不是回避它。这极大地提高了代码质量。

进行代码审查时，请明确说明您这样做是在提高代码质量，而不是惩罚不良的开发人员。请确保您的程序员将这些评论视为具有教育意义的方法，而不是衡量其性能的一种方法。对其他人来说有点复杂。资深的程序员确实认为我非常擅长于我的工作，并且只喜欢阅读我的代码，因为它具有教育意义。当然，偶尔他们的确会在我的代码中发现一些小错误，但是总的来说，这些代码审查正在提高审查代码人员的工作质量！

#15 楼

我们使用ReviewBoard进行评论。在我们公司，审阅是自愿的：如果您有任何感兴趣的事情（大量的添加或更改），我们希望您创建一个审阅请求，以由团队中的同事完成。然后，选定的团队成员可以批准审阅或请求进一步的更改。接受之前被检查为标记为已批准的评论ID。

#16 楼

不要总是认为问题已经到了尽头。

找出他们为什么不喜欢它，而不是自动假设他们是“坏程序员”，而是首先考虑他们是否有观点，并且您可能成为不好的代码审查者，或者干脆沟通不好。

如果您的代码审阅/样式规则不是主观的，任意的或疯狂的，那么很容易向任何有能力的专业程序员解释它们的原理。如果做不到，那么也许您需要重新考虑您在做什么或如何做。

否则，如果问题仅在于一个或两个人，则可能是与这些人有关的更深层的HR问题，而与代码审查无关，代码审查只是一个症状更大的问题。

#17 楼

如果您从一开始就负责项目，或者是首席开发人员，则应该能够通过将代码审查作为项目方法的一部分来进行代码审查。如有必要，请确保由领导亲自进行评审。如果您是负责人，有些人不会效法您，那么您需要说服他们加入该计划，或者由愿意的人代替。

如果您不是负责人，那么您必须说服团队成员进行代码审查对他们是有益的。首先，说服其他团队成员检查您的代码。记录您的设计和接口，并逐步介绍您的代码。然后为您自己编写一个帖子审阅摘要和操作项，并将其分发给您的团队成员。如果从中受益，那么它将很快对团队显而易见。

如果有阻力，您需要找出人们的反对意见。它们可能是有效的。例如，项目可能足够小，整个团队可能经验丰富，即使没有正式的审查，项目中的每个人也可以有效地同行审查项目中的所有代码。在非常大的项目中，一个人不可能真正掌握所有代码，没有经验的开发人员需要反馈以开发其编码和分析技能，或者团队中有非编码成员必须了解设计和代码。我发现，如果有法律后果，或者如果代码失败（例如飞机飞行控制系统），情况更糟，则审查必不可少，甚至是强制性的。在与经验丰富的程序员合作时，我发现它们是多余的，团队中的每个人都编写代码，项目很小，团队成员始终都在阅读和评论代码。

#18 楼

您需要接受不能让人们“接受”代码审查的条件。 >

“当我
查看别人的代码时，我怎么能更有影响力？”


...这完全是另一个问题。 />

#19 楼

1-3-2原则在这里适用（我依次说第一人称，第三人称，第二人）。说“我”需要代码审查（并执行）。

然后，只有当气氛不适合代码审查时，我才开始说“人们”需要代码审查（和清单）很好的理由）。

此后，如果其他所有方法都失败了（并且我处于权威状态：）），我将制定法律并说“您”需要进行代码审查。这是人们已经正确枚举的部分，但是只有在第三人称思维不持久时，我才会抽搐。如果我不讲第一人称的拳头并且不实践我的讲道，那么我不仅是一个“无效”的说服者，而且我真是个混蛋。请注意，我是如何以第一人称说这些的:)

#20 楼

为了提供另一种观点，我有时发现代码审查陷入甚至讨论都没有意义的事情。就像我让这个家伙检查我的代码时说的那样，我在代码中添加的注释之一中的标点符号不正确（停止）。尽管这件事是否重要是主观的（例如，如果您正在编写将被嵌入发布的文档中的内联文档，则可能很重要），但就我而言，这显然并不重要。认为代码审查是强制性的，几乎总是得到代码审查评论的帮助，并且有时新团队成员需要一点时间来理解它们为什么很重要。但是，保持客观性也很重要，每个建议都应有客观的理由，而不应由于审阅者的主观偏好而提出。新团队成员在可能会听取的阶段，讨论代码审查的重要性和目的。并且通过经验，他们将了解到它不是个人的。同样重要的是，让合适的人担任审稿人，而不是将主观意见强加于他人的人。

#21 楼

我认为代码审查的最大问题是某些人做得不好。例如，将final放在类/方法/参数/任何内容的前面，这无关紧要，不应在代码审查中进行。另一个示例使用错误的循环，因为只有foreach可以。需要评论所有内容。字符串+ / StringBuilder / StringBuffer优化。如果我对其中的任何内容进行了代码审查，我会认为那个家伙是个白痴，如果我没有被迫更改代码，我也不会。

有时候代码检查工具有时是错误的，例如默认的PMD（Java）喜欢说类有太多方法，所以我要做的是创建抽象父类并在其中推送一些方法。我可以将类分为2个类，但是我认为API将更易于在一个类中与所有这些方法一起使用（这是一个小的lib和我的设计决定）。有些人将始终只使用默认值，因此它不会太糟。

#22 楼

用问题而不是命令进行审查

我认为，审查过程中的一个基本问题是您认为您需要强加任何措施。取而代之的是，问诸如“您为什么决定采用X方法而不是Y？”之类的问题。

这将使他们考虑自己的编码过程，而不是强迫他们接受您的编码过程。嘿，您可能也会学到一些东西。

#23 楼

首先，与所有问题一样，您自己开始解决这个问题。确保您已尽一切努力使代码审查尽可能高效且无争议。


在可以使用某种形式的自动化时，请勿使用代码审查来实施最佳实践。可以使用标准库来完成最常见的任务：加密，数据库访问等。使用AOP和策略注入来处理标准化的日志记录，审计，安全性约束等。 ”的方式，只需使其变得更容易即可。我们很懒惰，所以我们只会选择阻力最小的方法。
不要审查变量名，标准化注释块和其他挑剔的细节。除非变量名难以理解，否则就可以。 “一致性”只是行使权威的借口，每个人都可以看到它。或者，请注意不要让有性格冲突的人查看彼此的代码。每个人都喜欢小吃和饮料。

#24 楼

我从来没有机会参与代码审查，但是我认为这绝对是一种绝妙的做法。
要使代码审查受到广泛接受，您可以组织一些有关如何进行“积极批评”的培训。 br />
，顺便说一句，这样的培训也可能是一个提醒人们公司/项目开发原则并进行团队建设的机会。

#25 楼

以我的经验，结对编程的好处远不止评论。它不仅会发现更多的错误，而且还会鼓励更多的创造性解决方案，知识共享，团队建设，开放式沟通，并使团队能够不断完善自然的编程风格。曾经在尝试过评论的团队中工作，这会引起对抗，然后在艰难的最后期限迫在眉睫时消失了。势头真的加快了。尝试几个星期，看看它是否对您有用。

#26 楼

尝试在学习方面出售它们。我遇到的几乎每个程序员都喜欢学习，而且我个人在每次代码审查时都学到了一些东西（无论我是审查者还是被审查者）。确保它们值得。不要陷入琐碎的格式化参数中（不要离线）。使用静态分析工具（例如FindBugs for Java），搜索TODO，查看每个编译器警告，检查文档的完整性等。 be。

#27 楼

代码审查是及早预防重大灾难的重要部分。许多主要的开发公司都要求对其项目进行代码审查。

为了使人们更容易接受，应该有相应的指南供审查者遵循。如果个人觉得自己被挑出来，或者审稿人可能有怨恨，他们可能不愿意进行审阅。如果提前告知所有人有关指南以及审阅者的要求，您可能会得到更好的接待。当人们对自己的职业或表现进行反思时，没有人会喜欢主观性。

从经验上来讲，我曾与许多开发人员合作，进行了反代码审查的知名政府合同。那是从哪里得到的？落后于计划，超出预算。隐瞒某些东西的开发人员将对人们的工作经历产生抵触感，因为他们很清楚自己的缺点。评论也是那些不愿意学习和使自己的思维方式适应当前问题的人，当该人担任决策角色时，这可能是项目的一个滑坡。

还有其他需要考虑的地方；如果预算和公司可以提供预算，则请专人负责代码审查，甚至请其他项目的人员来进行审查。如果没有先前的关系，则对双方都可能会更容易。恭敬地发给上级。追随某人或指出他们的短处将对您不利，并可能引起您对自己工作的注意。

#28 楼

另一种选择：我们与项目中的所有程序员一起定期对过程进行“反思”。这种做法的一部分是对最近出现的错误进行“根本原因分析”。是什么原因造成的？这是回归吗？是否缺少IE6测试？请问乔对此有帮助吗？目的是弄清楚我们为什么会有这些错误，以及我们可以进行哪些更改以防止它们发生。

如果代码审查是合适的工具，那么它将在讨论期间提出。它将由程序员自己介绍，因此从一开始您将获得更多的支持。我们同意所有代码都需要在签入之前进行检查。开发人员通常会要求这样做，但是如果忘记了，他们会令人毛骨悚然地承认它……他们知道他们不仅在违抗“管理”，而且违反了团队的协议。 。

（或者，如果它不是合适的工具，人们就有机会解释原因。）

#29 楼

我有不同的情况。由于我不是一个非常有经验的开发人员，因此我想在每个版本之前对我的代码进行代码审查。但是在大多数情况下，代码审查并不适合我们的严格计划。或者，我的公司认为提出理由不够重要。测试驱动的开发也是如此。如果确实有疑问，我将请一位高级开发人员查看我的代码。不理想，但是这样做确实有助于我提高编码技能。

#30 楼

如果他们不进行代码审查，那么简单...就把他们解雇。显然，他们并不太在意改进。无需保持自重。