如何查看自己的代码？ [关闭]

#1 楼

首先，利用工具进行尽可能多的检查。测试（以合理的代码覆盖率进行备份）将使您对代码的正确性有一定的信心。静态分析工具可以捕获很多最佳实践的东西。虽然总会有一些问题需要您的眼睛来确定，但您永远无法像其他人那样出色地审查自己的东西，但是您可以做一些事情来帮助您


检查测试是否存在并通过（可能具有目标测试范围，尽管在某些情况下您可能需要打破此规定，但您应该能够证明原因）
检查静态分析通过（也将为假）否定在这里，但这很好，只要您能证明为什么然后用它来抑制它们就可以了）
保留检查其他清单的清单以供检查（如果可能，最好将其作为新的静态分析规则添加）确保您检查SA无法检查的任何内容，例如，注释是否仍然有效，事物的名称是否正确（命名事物当然是计算机科学已知的两个难题之一）
如果识别出故障，请检查是否原因是系统性的，请查看为什么在较早的测试或评论中找不到它的原因

这当然是在查看其他代码时也很有用

#2 楼

看一下Code Review Stack Exchange网站。它用于共享您正在研究的项目中的代码以供同行评审：


代码评审Stack Exchange是一个寻求对代码进行同行评审的问答网站。我们正在努力通过采用可工作的代码并使其变得更好来提高全球程序员的技能。

如果您希望在以下领域中从项目中获得有关特定代码段的反馈，则……

安全问题
性能
意外情况下的正确性



您还可以使用代码静态分析工具来检测某些类型的问题，但是在某些情况下它们会产生错误警报，并且无法建议如何改进设计。

评论

---

这是对“如何审查我的代码”这一问题的绝妙答案，并且总体而言是一个很好的建议（我肯定会这样做的）—但仍然有些偏离主题。

– Max Yankov
2012年12月12日12:04

---

我通常不喜欢5个字的答案，但是这个答案非常正确。

– Maple_shaft♦
2012年3月12日12:37

---

充其量这只是一个有限的解决方案。持续将您的全部日常输出放在CR.SE上是不可行的，因为其中的大部分将是相当平凡的样板代码。对于发现需要对应用程序编写的整个应用程序体系结构或领域有非凡理解的问题，CR.SE也不会有太大帮助。从非正式的角度来看，查看同事代码的签入样式，查看我在哪里工作，这些错误可能比适合通过CR.SE捕获的错误更常见。

–丹在火光中摆弄
2012年12月12日13:12

---

审查的真正价值是获得一些代码段，尽管您永远不会发现并突出显示任何问题，这些问题不是显而易见的，也不是自我解释的，甚至是逻辑上不正确的。如果您尚不知道这是一个有问题的代码，则不能将其发布以进行代码审查。

– ZJR
2012年12月12日13:31

---

@ZJR那么，您的项目中的代码是否经过100％审查？如果是，则您的工程师有太多的空闲时间。至于您的第二条评论，在您认为完美的代码中要求进行代码审查时，我认为没有问题。

–BЈовић
2012年3月12日13:40

---

#3 楼

我在脑海中培养了几个完全不同的人。
其中一个甚至都不是程序员！ >我强烈推荐我的方法。

ps
他不是在开玩笑。

#4 楼

我同意jk-s的观点，即单人审核不如2人审核有效。但是，您可以尝试充分利用它：

短期审查（在代码生成后不久）

我正在使用git作为本地存储库。每当我完成一项功能或修复了一个错误后，我都会将更改转移到存储库中。

在签入之前，我先比较代码中已更改的内容并重新考虑：


变量/方法/类名是否仍反映它们的用途？

长期复审（代码生成后6个月）

我问自己：


我可以在一句话中描述类/方法/变量有什么作用？
孤立地使用一个类（淘汰其他类）或为其编写单元测试有多容易？

#5 楼

首先，将代码保留尽可能长的时间。处理其他代码。即使一天后，您也会惊讶于发现的内容。

其次，记录您的代码。许多程序员不喜欢记录他们的代码，但让自己坐下来写出文档，如何使用代码以及如何工作。通过以不同的方式查看代码，您会发现错误。

有人说，真正掌握某门学科就是将其教给他人的能力。通过文档，您正在尝试教别人您的代码。

#6 楼

将此调试技术转换为代码审查技术：http://en.wikipedia.org/wiki/Rubber_duck_debugging

该概念使您有一个正确的思维方式，使您能够像处理代码一样处理代码新。

#7 楼

除了其他答案中提到的有用工具之外，我认为修改您的思维方式对进行代码审查很有用。这很愚蠢，但是我对自己说：“我戴上了代码审查帽”。我也会对质量检查进行同样的操作。

然后限制自己的思维方式很重要。您既是审稿人又是被审稿人，不能同时兼任。因此，作为审稿人，我记下客观笔记以与被审稿人分享。在审阅代码时，我不会更改代码，这不是审稿人应该做的。拉向很多方向。因此，我可能不必在其他事情出现之前就结束审核循环-这种形式（实际上，我在Wiki工具中讲的是粗略的注释）对于确保审核完成很有用。同样，在戴上质量检查人员帽子的情况下，我会在修复错误之前添加故障单。

#8 楼

似乎普遍的看法是自我审查是无效的。我不同意，并且我认为自我审查可以彻底解决很多问题。

以下是我几年经验中的一些技巧：


有一个简单的清单很方便。这些是您在阅读代码时要标记的内容。
使代码检查脱机。听起来可能很浪费，但是要进行打印输出，以便您注释和来回翻转，或者将数字突出显示的pdf同步到iPad，然后将其脱机。离开办公桌，以便您所做的就是无干扰地查看代码。
请在清晨而不是工作日结束时进行操作。新鲜的双眼更好。实际上，最好是在一天前重新检查代码，然后再去修改。目的是在代码进入测试之前在上游捕获错误。尽管很多开发人员认为它很无聊，但它却起到了很大的作用。

#9 楼

用于审核的“个人软件过程”技术可能会很有用，尽管它依赖于有关您的工作和产品质量的历史数据。缺陷。有多种分类缺陷的方法，例如PSP课程中的一种。您可以自己开发，但其想法是您必须能够分辨出自己在途中犯了什么错误。

一旦知道自己犯了什么错误，就可以制定一份清单，您可以在审核期间使用。此清单将涵盖您认为最适合在评论中发现的最主要错误（与使用其他工具相对）。每次查看工作产品时，请使用清单并查找那些错误或错误，记录并修复。定期修改此清单，以确保您专注于代码中的实际相关问题。

我还建议在有意义时使用工具支持。静态分析工具可以帮助发现一些缺陷，甚至可以帮助进行样式检查以增强一致性和良好的代码样式。将IDE与代码完成功能和语法突出显示一起使用，还可以帮助您预防或检测某些问题，然后再单击“生成”。单元测试可以解决逻辑问题。而且，如果您的项目足够大或复杂，则持续集成可以将所有这些结合到一个定期运行的流程中，并为您生成精美的报告。

#10 楼

单独工作意味着除非您信任完全陌生的人代表您检查代码，否则您将需要研究编写软件的方式以保持代码质量。

首先，您应该有一种方法可以确保您的代码符合要求，其次，如果您稍后决定发现错误，则可以相对轻松地更改代码。我的建议是出于以下原因而采用行为驱动开发方法：


BDD意味着首先编写代码测试。这样可以确保您的所有代码都可以被测试覆盖。
BDD本质上是TDD，但是重点和“语言”略有不同。这意味着您在处理代码时会不断对其进行重构，并使用测试来确保重构工作继续进行，以确保您的代码满足您的产品规格。
BDD语言鼓励使用基本上将需求编码为单元测试的语句形式。

所以这里的想法是，即使在通过测试之后，您也可以对代码进行连续的重构，这意味着您正在有效地检查自己的代码，并且使用单元测试作为“额外的注意”，以确保您的代码不会偏离测试中编码的要求。此外，基于需求的高测试覆盖率可确保您将来能够更改代码而不会违反需求。

对您而言，真正的问题是您是否能够在代码中发现潜在的问题，这些问题表明需要重构。市场上有几种性能分析工具可以为您提供帮助，以及其他一些与代码质量指标有关的工具。这些通常可以告诉您代码审查可能遗漏的许多内容，这是您自己开发项目时必须要做的。但是，实际上，经验是关键，一旦习惯了无情的重构，您对自己的代码的批评就会变得更加严格。如果您还没有的话，我建议您阅读Martin Fowler的Refactoring书籍作为起点，并寻找一个良好的BDD API，使您感觉可以使用您选择的任何一种语言来工作。

#11 楼

每当我遇到与自己相同的情况时，我都会尝试通过使用代码审查/度量工具来解决“过于接近代码而无法客观地检查它”的问题。不用说，一个工具不能提供与经验丰富的审阅者相同的价值，但是您仍然可以使用它们来确定设计不良的地方。是SourceMonitor。这有点简单，但是它为您的代码提供了很好的中级意见，例如，类中的方法数量以及每个方法的复杂性。我一直觉得，这类信息与通过StyleCop等工具（很重要，但通常不是最大问题的根源）来实施编码样式一样重要（甚至比起重要）。将这些工具与通常的免责声明一起使用：知道何时打破经验法则，而代码度量工具中的所有绿色内容并不能自动获得良好的质量。

#12 楼

我无法告诉您我一直在向代码审查员解释某些内容的次数，而脑海中的灯泡打开并说：“嘿，请稍等。”因此，我经常在代码审查中发现其他人没有看到的我自己的错误。因此，您可以尝试一下，只要开始解释代码，就好像有一个人坐在您旁边，试图了解您的工作及其原因。开发人员实际上并未遵守要求。因此，比较您的代码及其实际要求是一个很好的检查。

我们经常做类似SSIS包这样的事情，它们具有相似的结构需求-对于代码审查，我制定了要检查的事情清单（是正确的配置，正在设置日志记录，是否使用元数据数据库，标准位置的文件等）。您可能还需要在每次代码审查中检查一些方便的事情。坐下来，考虑一下要在代码清单中添加哪些内容，以确保检查代码（第一项，确保满足要求，下一项可能与陷阱和日志记录错误有关）。当您犯错并纠正错误时，您可以将其他项目添加到列表中（例如，是否要循环移动到下一个记录，或者我要无休止地重复相同的第一项-只需一个无休止的循环即可）教你寻找那个！）。这主要是为了防止您忘记做一些应做的事情。

#13 楼

给它3个月的时间，然后回头看看您的代码。我向你保证，如果您找不到它的问题（或问题是谁写的这个垃圾！），您将比我更好！

#14 楼

我通常会打印出所有代码，然后在安静的环境中坐下来阅读，发现很多错别字，问题，需要重构的内容以及执行此操作所需的清理工作。我认为每个人都应该做的很好的自我检查。

#15 楼

回到大学时，我是一名写作导师。它无疑给了我一些我认为许多开发人员从未想到过的编码观点。最重要的方法之一就是大声阅读代码。听起来似乎不多，但我会举一个我认为每个人都可以与之联系的完美例子。然后发送它，却发现您存在明显的拼写错误，错别字或语法错误？昨天，当我要求客户按下狗屎键而不是Shift键时，我才这样做。当您脑海中读书时，您会看到想要看的东西。如果您大声阅读它，您会得到相同的结果。我不知道为什么它如此有效，但是在与数百名学生坐在一起并让他们大声朗读之后，我只能说它是有效的。

#16 楼

大多数人倾向于将自己的密码视为自己的婴儿，并用自我喂养而不是现实。就像其他任何代码审查一样，请在查看其他人的代码时对其进行审查。完全忘记您已经写了一些东西。查看代码的每一行。检查表将有助于使自己更美观地检查自己的代码。自动化的代码审查工具可以在一定程度上有所帮助。我使用了一些工具，例如klocwork（商业软件），当您在大型项目中工作并且有几个开发人员正在为此工作时，这非常有用。始终专注于缺陷检测而不是纠正。

#17 楼

考虑由您自己进行Fagan检查-您必须自己调整流程，因为您应该自己做，但是您应该能够从中获得很多价值。诀窍将是找到一个正确的“规则集”，以作为一个单独的开发人员来评估您的代码，然后让该学科每次以批判，分析，无情的心态提出这些问题。我怀疑您可能想集思广益，先解决自己的4-5个关键问题，然后逐步发展。有些人反对正式检查，因为它们似乎很耗时...在您决定它们太昂贵之前，请记住所有统计证据，表明适当进行检查实际上会减少项目时间。这是一个Wikipedia链接，您可以通过以下链接开始进一步的研究： Google由Strauss和Ebenau提出的“软件检查过程”。这个家伙相当不错，我们已经抽空多次培训他的新开发人员：

http://www.javaspecialists.eu/

#18 楼

除了所有有关代码审查的建议之外，您还可以使用PMD和findBug之类的工具来对代码进行第一级的完整性检查。

#19 楼

这实际上尚未放入答案中（但已作为注释添加到现有答案中）

睡个好觉后检查代码，例如通过回顾您前一天编写的代码来开始新的一天。

当然，这不会给您团队的集体经验，但是会让您从新的角度审阅代码。

例如，如果您留下了一段令人讨厌的骇客代码，那么在此之后立即检查您的代码，您可能就不太倾向于修复它。毕竟，当您开始查看代码时，您已经知道并且已经接受了这种hack。但是，如果您睡个好觉，您可能会更有动力寻找更好的解决方案。

当我们睡觉时，大脑实际上并不会停止解决我们遇到的问题，因此您可能实际上在那里提出了一个解决方案，尽管这些解决方案有时可能会以奇怪的方式出现。