2009-09-21 51 views
7

我经常被发送到需要对我没有参与的系统进行代码审查的站点,并且一旦审查完毕后将不再涉及。我花时间在通常的工具测试中寻找模式,但在某些时候您只需要阅读代码。在代码审查期间保持专注的提示

在第一个5000左右的线后,就不可能专注于代码,特别是因为它是商业工具,因此不是最有趣的解决方案。那么,在代码审查期间,他们为了让代码专注于代码有哪些提示?

+9

咖啡,咖啡,咖啡 – 2009-09-21 14:02:52

+5

超过2每天杯咖啡,不建议 - 对健康也不好。 – 2009-09-21 14:05:05

+5

@新的镇:审查其他人的代码也不利于健康。 – MusiGenesis 2009-09-21 14:14:53

回答

17
  • 如果涉及到运行代码,它不是代码审查。
  • 如果它超过1000行代码,它不是代码审查。
  • 如果需要20多分钟的准备工作,则不是代码审查。
  • 如果审核本身需要一个多小时,则不是代码审查。

也许你的公司应该修复代码审查过程...

3

到目前为止,我使用以下

  • 检查我的电子邮件& RSS经常饲料每 - 然而,这增加了更多的代码审查。
  • 咖啡 - 喝越来越多
  • 将StackOverflow上回答问题或提出问题;)
+2

+1 _去StackOverflow回答问题或发布问题;)_ – 2009-09-21 14:05:42

1

这是一个非常棘手的问题。我想我的问题是:你能做些什么来使得你看起来的前5000行代码更有可能是正确的?

换句话说,当你的注意力最高时,获得最大的回报。您必须从鸟瞰视图中查看代码才能了解这一点。

对于之后的代码,请对其进行简要概述,然后写下您想要回答的问题。当你看到只有在你写下问题时才会出现的代码的时候,你可能会有些担心。然后看看代码以回答问题的意图。

1

该策略应该让他们遍历代码,解释他们看到它在做什么。目标是a)产生可靠的,可维护的,正确的代码和b)从中学习。你会惊讶于你学习了解他人的代码。是的,阅读代码的想法是痛苦的,但在实践中这是一个伟大的教育经验的机会,它给你的想法在未来看什么。

当然,太多的东西都是坏事,我看到开发人员必须连续3个月进行代码评论。他们必须休息一下,修复错误,检查电子邮件,跳过 - 没有评论的东西。

也许花些时间去了解更多关于这个项目的内容,它是如何工作的,它可能会让一些无聊的部分变得更有趣,因为它们对你更重要。与每个模块的开发者交谈,询问他们做得如何,以及他们担心哪些部分。

当然并且,咖啡因)

11

做一定数量的练习的代码,你检查(如每千行代码20个仰卧起坐,或类似的东西),每个块。你可以添加一些小东西,例如为你看到的每一个无用注释做5个俯卧撑,或者为你找到的每个重复功能提供10个注释。身体活动使头脑保持专注,并且考虑到世界上大多数代码的状态,你很快就会被严重撕裂。

警告推荐传统的ASP。心脏病发作和中风将是不可避免的。

+7

好主意,喜欢的警告;) – 2009-09-21 14:21:03

+2

虽然我喜欢有趣的答案,这不是一个真正的答案的OP问题 - 他说:“我经常发送到我需要对系统进行代码审查的网站,我不参与“......您不可能在客户的网站上这样做......:P – eglasius 2009-11-14 15:46:13

+0

Freddy:除非您是顾问教学重点技巧。 – 2009-11-16 21:31:19

1

我不会推荐切换上下文。当你分析复杂的外星代码时,你必须保留大量的信息。与操作系统世界不同,切换上下文不仅需要时间,还可以让你忘记刚刚读过但尚未记忆的内容。

真正有用的是用你的双手做一些事情。在代码中写下评论,解释它的作用。当你看到不寻常的东西时留下笔记。大纲问题和TODO标记稍后返回给他们。为他们使用不同的颜色。

这会让你100%的时间忙于集中。而且它也会将你的进步形象化,让你振作起来!

1

我宁愿你同时有一个共同评论者。这提高了速度和效率。

+0

配对有帮助。十五个字符也是! – gmoore 2009-11-11 17:55:05

3

除非您非常幸运,否则您应该在前5k行代码中有足够的反馈。

检查this电子书固体。

不要只关注一组隔离的类。首先从顶级用法开始(用户界面级别 - 如果有多个层级也进入界限)。选择一对重要的流程,并按照流程进入系统的更多内部部分。选择一些看起来可能会遇到问题的班级,然后对这些班级进行全面检查。

要特别注意影响最大的问题,即跨层聊天交互,加载大量数据库数据,执行大量往返行程,大页面/或资源。您可能需要对其他物品进行有限的关注,如果这些物品处于其中。

1

您能否以自顶向下的方式进行评论?查看最高级别(主要方法?)并撰写评论。然后在每个抽象层中深入一步并对其进行评论。有时候,我直接钻了14层的方法,当我回来的时候完全丢了。保持广泛的评论可能会有所帮助。

也许在IDE中这样做是最好的,所以你可以跳过代码。

不是我会羡慕的东西。我不喜欢与附近的开发者进行评论。

至于时间管理,请尝试番茄钟法。当我面对马拉松编码会议时,这真的帮助我。

2

我认为最好的代码审查时进行这样的:

  1. 编码器谈到每种方法;一次一个。重点在于它如何以及为何做它的功能;而不是输入或输出。这可以使它变得有趣,因为团队中的每个人都对代码感兴趣。
  2. 团队负责人担任执法人员。他迫使任何出发点的人回来。
  3. 它被制成一种传统,并被执行DESPITE什么(需要修理一个微小的刺臭虫,咖啡壶中只有无咖啡因的咖啡,人们不会觉得它等)。然后人们进入一个节奏和流动和代码审查不会因其他活动而逐渐停止。
0

如果代码使用Java,请使用PMD或CheckStyle。它的优点在于,您可以编写自己的规则来标记基于该站点代码标准的违规行为。

2

我通常在同一时间通过功能遍历,GUI下降到DB/reporsitory层。

如果评论不存在,我会添加我认为正在进行的评论。

我会保留我对系统的理解的思维导图/维基。思维导图在休息之后更容易取出。

我会跟其他队友谈论我的发现。

2

我怀疑任何人都可以从一天中读取5000行代码中提取任何有意义的东西。

我认为代码评论应该是互动的,这也让他们感兴趣。如果我负责审查别人的代码,我不会在意让他们通过它的方式。他们可能会专注于他们喜欢的东西,或者他们认为他们做得很好的东西,而我通常对相反的东西感兴趣。

我喜欢的格式是让我坐在连接到投影机的笔记本电脑上,并在屏幕上显示代码,以便我可以轻松地从一个部分跳到另一个部分。然后在阅读屏幕上的代码时,向开发人员提问:为什么你这样做?你总是这样做吗?你怎么决定这个结构? x的单元测试在哪里? - 同时进行观察:可以在此处使用更多评论,此代码格式不符合标准等。另外,让开发人员或其他人在房间中记录有关开发人员应该查看或稍后修复的事项明确指示应该在所有代码中修正常见问题,而不仅仅是已审查的代码。

想法是而不是来看看每一行代码。这是开发经理的工作,也可能是QA。代码审查的主要目的是仔细检查代码背后的思想过程,包括体系结构,流程等,以及质量方面:性能,可伸缩性和安全性。

如果您尝试做或看太多,不仅会烧坏,但结果将不会对任何人有用。

0

你应该在你的代码评论中有某种结构,因为一次只读一行代码是不可能的。

  • 我通常从单元测试或使用示例(如果存在)开始,以便在看到代码时我会知道它是如何使用的。
  • 之后,我建议从使用和钻取到实施一次检查一个方面/特征。
  • 如有必要,重复

你应该限制审查的审查是有效的代码的大小 - 我的工作场所,我们在提交代码回源控制前审查和,因为我们保持我们提交小我们也限制审查持续时间。

在审查过程中,我要求将我直接在有趣的/有问题的地方在代码的问题:选择一个具体实施时

  • 你做了哪些决定?
  • 作出具体决定的好处是什么?
  • 你的代码遵循什么设计模式/设计原则?

代码审查的目的是为了通过改进代码进行学习和教学。只是阅读5000行代码直看起来似乎是错误的...

0

我同意其他人,你在做什么不是一个真正的“代码审查”。我认为最重要的是要记住你正在寻找的东西并将注意力集中在它上面 - 从字面上看,你需要回答一些项目和问题的清单。

对代码库进行开放式检查需要很长的时间,如果您的参与应该是短暂的,那么很难有效。

关于阅读电台上的代码问题,有一个很不错的播客:link。这是对Dave Thomas(“实用程序员”的作者)的采访。我认为这适用于你想要做的事情。

1

是的代码审查你需要阅读代码。但不是只有5K条直线,没有目的或计划。难怪你不能保持专注。

生成度量标准的分析工具可以专注于您。运行分析工具并根据其指标对结果进行排序。每个工具会告诉你“前5名的文件或功能”上一个给定的问题,有问题的:

  • 长文件
  • 长函数
  • 大扇入或扇出
  • 复杂
  • 皮棉侵犯

我猜你被称为给代码质量的一个为期一天的评估。所以做上面的事情,然后用专注的代码阅读来补充它,以找到每种问题的一个非常明确的例子。你不会直接阅读5K行文字,你可以用它来达到目的,并且可以搜索奖品。这不会很无聊,你会专注。

准备您的报告,其中包含指标,对工具和概念的参考以及代码库中每种问题的示例。

所有的事情都完成了,他们付出巨大的代价告诉他们他们可能已经知道但他们不想承认自己。