所有程序员都有自己的编程风格。但是,有些样式可以说...让我们不要说。因此,您需要进行代码审查,以便为好的设计和良好的编程技术强加某些规则。

但是大多数程序员都不喜欢代码审查。他们不喜欢别人批评他们的工作。

他们认为谁会认为自己比我更好,并告诉我这是不好的设计,所以可以用另一种方式来完成。工作正常吗?问题是什么?他们可能会说这句话(或想想却不说,如果不是更糟的话,那同样不好)。

你怎么能说服他们这是一件好事;这样只会提高他们的编程技能,而后又省去了很多工作来修复和修补成百上千倍的问题,嘿嘿……“行之有效”? (对等编程,正式检查等)在代码审查中寻找的内容,已经进行了研究以显示在软件投入生产之前可以发现的缺陷数量等。但是,您如何说服程序员接受代码审查? ?

评论

这是一个奇怪的问题。代码审查是这项工作中非常重要的一部分。一个积极与之抗争的程序员根本不是一个好的程序员。我的意思是,如果人们也不喜欢空格和换行符怎么办?您如何说服他们使用空格和缩进代码是一个好主意?..

所以您认为我只能选择与优秀的程序员一起工作?还是您认为我应该不在乎?

您不必与优秀的程序员一起工作。您只需要强迫他们成为更好的程序员即可。即使是最好的程序员,仍然需要提高他们的技能。这是工作说明的一部分,好的程序员将花费至少半天的时间学习新技术。 (顺便说一句,顺便说一句。在私人时间学习的任何内容都只是为了个人的进步。)

您必须“强迫他们成为更好的程序员”吗?也许……您想成为一个好的榜样,并成为一个指导他们成为更好的程序员的管家。企图“强迫”人们通常会完全导致错误的结果。

您如何“使”人们做任何事情?暴力威胁的工作。另一方面,如果您希望与他人合作并建立合作文化,我建议您不要试图“让”任何人做任何事情。

#1 楼

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

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

评论


“人们太亲自进行代码审查” +100

– rahul
09年8月21日在9:33

+1是人类条件的学生,我承认我对最后一句有罪

–user1274
09年8月21日在10:58

好吧,我必须不同意,评论总是个人的,但真正的诀窍是要意识到做错事没有问题。人们过分坚持自己的观点,因为他们认为做错事是无能为力的。我认为,不明智,承认错误,学习并继续前进是很薄弱的。

–中午丝绸
09年8月21日在11:00

@silky:这不是个人的意思,“我不是说你是一个坏人,而是你的代码有问题。”攻击代码和攻击人员之间有很大的区别。如果您进行代码审查时说:“您在想什么?您是愚蠢的还是什么?”那是个问题:)

–乔恩·斯基特(Jon Skeet)
09年8月21日在11:02

的确:)我敢肯定我们大体上同意。我主要是说我认为问题出在虚假的骄傲上。为您的学习能力而自豪,不仅是您的了解能力。

–中午丝绸
09年8月21日在11:05

#2 楼

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

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

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

评论


避免代码/设计审查的开发人员也往往在维护方面很糟糕。

–sal
09年8月21日在13:33

我认为这根本不是一个明确的信息。不接受代码审查的人也没有进行自我审查,以致意识到自己已经被淘汰,这是他们自己行动的结果。最多他们会意识到自己已经被淘汰,但是他们不知道为什么,他们只会感到受迫害。在这种情况下,他们可能会离开公司,这可能是一件好事,但是,如果这是目标,似乎直接将其解雇会更快。

–幻想家
09年8月22日在7:16

SO是一个全球站点,在美国境外解雇人员要困难得多。将能力较低的员工分配给不太重要的项目OTOH已被广泛接受。对于未意识到为什么要重新分配工作的员工,mgmt有责任明确沟通。这也不例外。开发人员无需进行“自我审查”即可了解mgmt为什么要执行其操作。

– MSalters
09年8月24日在7:16

“你干你的工作”不是可燃的罪行吗?

–菲利普
2012年10月11日15:44

@菲利普:令人惊讶的是,这对核心的资本家来说可能不是。那就是试用期。如果公司未能将试用期用于其预期目的,那么后果将不可避免。

– MSalters
2012年10月12日上午8:26

#3 楼

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

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

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

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

评论


+1很好的答案。我一定会同意你的。关于一致性和最佳实践的学习。这对于塑造您的风格和学习好的新想法很重要。

–bastianneu
09年8月21日在7:44

我们的代码非常不一致,令人尴尬。

–Wayne Werner
2012年10月12日,下午1:48

由于缺乏更好的单词,更好的代码紧随一致性之后。我意识到这很模糊。我的意思是,指导原则通常是某些调查的结果,该结论得出结论,通常以一种方式(无论以何种方式)都比另一种方式更好。

–丹尼斯
2014年6月16日19:57

#4 楼

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

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

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

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

评论


“代码得到了改进,我们可能都变得更聪明了”。我完全同意。我从代码审查中学到了很多东西。如果检查了我的代码,我可以看到我做错了什么,请从中学到东西,并尽力避免将来发生。但是我也从执行代码审查中学到了很多东西,因为我看到了做事情的更好方法。通过从他人那里“窃取”技能,我的经验得到了提高(我无法想象我应该读多少本书,或者我应该花多长时间练习才能获得比别人更好的技能。)

–user7197
09年8月21日在8:27

+1最重要的论点:相互学习的好方法!

– Emile Vrijdags
09年8月21日在11:04

“如果唯一的输入代码审查提供的东西可以通过使用工具轻松完成,那么代码审查就是浪费时间。”但是,如果您不使用工具,则仍应指出轻微违反准则的情况。当然,如果可以的话,最好使用一种工具,没有人愿意成为那个总是会指出一些小矛盾之处的家伙。

–丹尼斯
2014年6月16日19:59



#5 楼

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

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

#6 楼

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

#7 楼

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

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

评论


如果有人说“我是唯一需要了解它的人”,则代码肯定需要进行审核;-)

– Benedikt
09年8月21日在7:38

如果有人说“我是唯一需要了解它的人”,则该人需要熟悉职业介绍所的电话号码。

–麦克·伍德豪斯(Mike Woodhouse)
09年8月21日在7:44

即使只有一个人需要理解代码,大多数开发人员也应该能够理解它。我最喜欢的一句话是:“调试是一开始编写代码的两倍。因此,如果您尽可能聪明地编写代码,那么就定义而言,您不够聪明,无法对其进行调试。” -布赖恩·克尼根(Brian Kernighan)

–古法
09年8月21日在8:11

#8 楼

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

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

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

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


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

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

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

#9 楼

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

评论


匿名评论仅在大多数程序员彼此不认识的大型团队中有效。如果您是一个由5个程序员组成的小团队的成员,并且必须检查团队代码,则通常很容易检查样式并确定是谁编写的。

–十个边缘饮料
09年8月21日在10:09

我不同意“匿名很重要”这一点。代码审查的全部重点是承认每个人都会犯错,因此,如果他们发现有人犯了错,那么没人应该有问题。另一方面,如果某人犯了很多错误并且将其纳入代码库,则该人将承担责任。确定负有责任的人比让他们隐瞒匿名更好吗?

–幻想家
09年8月22日在7:27

“通常很容易检查样式,从而发现是谁写的”。是的我同意。但是由于名称不明确,开发人员会更容易接受。

– chiesa
09年8月23日在2:53

#10 楼

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

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

评论


或者,它需要开发负责人或经理,他们不会让员工推动他们前进。

–外壳
09年8月22日在4:14

#11 楼

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

#12 楼

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

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

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

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

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

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

评论


@贝丝:你怎么知道他不对别人的工作负责?

–yairchu
09年8月21日在17:36

#13 楼

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

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

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

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

#14 楼

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

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

评论


如果“领导”代码审查的人是一个完整的傻瓜怎么办?到过那里。一些人(许多?)通过欺骗自己无能的老板来取得成功。

–xcramps
09年8月21日在16:51

代码审查总是会引起讨论的,但是审查代码的人不应该是同时更改代码的人!我也去过那里,一个白痴不喜欢我的作品,希望我根据他的极坏设计对其进行重写。我只是拒绝进行这些更改,并告诉他他可以进行这些更改,但是他还要对之后的所有错误负责!他很快支持了oof。 (是的,我还告诉他,我认为他是个提出这样愚蠢建议的傻瓜。)

–十个边缘饮料
09年8月21日在18:44

#15 楼

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

#16 楼

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

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

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

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

#17 楼

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

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

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

#18 楼

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

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


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

评论


好的,那么当您查看他人的代码时,您将如何发挥更大的影响力?

–user7197
09年8月21日15:30

@Leon:您是说“让人们接受事物”是不可能的吗?如果是这样,大学如何“让”学生接受参加考试?

–yairchu
09年8月21日在17:34

+1您可以通过使人们的生活变得艰难来使他们做某些事情,如果他们不这样做,那么您将无法控制他们的想法(至少使用当前技术)。

–幻想家
09年8月21日在19:18

实际上,您可以通过在代码通过代码审查之前不允许他们提交代码。

–HLGEM
13年4月30日在21:27

#19 楼

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

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

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

评论


这是一个非常有趣的方法。

–杰夫·戴维斯(Jeff Davis)
09年8月21日在23:16

这没有足够的支持。尝试切换到第三人称。 :)

–杰里米·斯坦(Jeremy Stein)
09年10月1日在16:51

#20 楼

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

#21 楼

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

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

#22 楼

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

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

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

评论


因此,我就是不想进行代码审查的人之一。审阅者的态度真的很糟糕,在我开始工作时,我对自己的代码感到非常不好。我确实想提高自己的水平,并认为代码审查是与长者一对一进行此工作的绝佳机会。问题是,长者没有提供解释为什么不好的东西,或者我如何改善,而只是说“这真的很糟糕”,“改变这一点”而没有给出任何线索或建议。

–章
17年9月28日在9:05

#23 楼

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


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


#24 楼

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

#25 楼

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

#26 楼

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

#27 楼

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

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

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

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

#28 楼

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

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

(或者,如果它不是合适的工具,人们就有机会解释原因。)

#29 楼

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

#30 楼

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