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

我正在单独进行项目，必须维护自己的代码。通常，代码审阅不是由代码作者完成的，因此审阅者可以以崭新的眼光看代码-但是，我没有那么奢侈。我可以采用哪些实践来更有效地查看自己的代码？

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

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

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

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

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

如果您正在寻找来自以下领域的项目中特定代码段的反馈，则……

• 最佳做法和设计模式用法
• 安全问题
• 性能
• 意外情况下的正确性

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

我在脑海中培养了几个完全不同的人。其中之一甚至都不是程序员！我们正在聊天，讨论最新消息并查看彼此的代码。

我强烈推荐我的方法。

ps他不是在开玩笑。

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

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

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

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

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

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

我问我自己：

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

首先，将代码保留尽可能长的时间。处理其他内容，以及其他一些代码。即使经过一天，您也会对发现的结果感到惊讶。

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

有人说，真正掌握一门学科就是将其教给他人的能力。使用文档，您正在尝试向他人讲授您的代码。

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

这个概念为您带来了奇迹，使您能够以适当的思维方式来处理代码，就像它是新的一样。

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

那么重要的是要限制自己的思维方式。您既是审稿人，又是审稿人，不能同时兼任。因此，作为审稿人，我记下客观笔记以与被审稿人分享。我在审查代码时不会更改代码，这不是审查者应该做的。

形式有时会有些荒唐，但是我发现当我独自工作时，我经常会朝着很多方向发展。因此，我可能不必在其他事情出现之前就结束审核循环-这种形式（实际上，我在Wiki工具中说的是粗略的注释）对于确保审核完成很有用。同样，戴上QA帽子后，我会在修复错误之前添加故障单。

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

以下是我几年经验的提示：

• 随手准备一份清单。这些是您在阅读代码时要标记的东西。
• 使您的代码审查脱机。听起来可能很浪费，但是要进行打印输出，您可以对其进行注释和来回翻转，或者将数字突出显示的pdf同步到iPad，然后将其脱机。离开办公桌，以便您做的就是无干扰地检查代码。
• 在清晨而不是工作日结束时进行操作。一双新鲜的眼睛更好。实际上，在每天重新检查代码之前，最好远离代码。

仅供参考-这些准则是几年前我在Oracle时在Oracle中提出的建议的一部分，目的是在代码进行测试之前在上游捕获错误。尽管很多开发人员认为它很无聊，但它却起到了很大的作用。

尽管需要依靠有关您的工作和产品质量的历史数据，但用于审阅的“个人软件处理”技术可能会很有用。

您从有关工作产品的历史数据开始，特别是缺陷的数量和类型。有多种分类缺陷的方法，例如PSP课程中的一种。您可以自己开发，但其想法是您必须能够分辨出自己在过程中犯了什么错误。

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

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

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

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

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

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

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

每当我遇到与自己相同的情况时，我都会尝试通过使用代码审查/度量工具来解决“过于接近代码而无法客观地检查它”的问题。毋庸置疑，工具无法提供与经验丰富的审阅者相同的价值，但是您仍然可以使用它们来查明不良设计的领域。

我发现在这方面相当有用的一个工具是SourceMonitor。这有点简单，但是它为您的代码提供了很好的中级意见，例如，类中方法的数量以及每种方法的复杂性。我一直认为，这类信息与通过StyleCop等工具（很重要，但通常不是最大问题的根源）来实施编码样式一样重要（甚至比起重要）。将这些工具与通常的免责声明一起使用：知道何时打破经验法则，而代码度量工具中的所有绿色内容并非自动具有良好的质量。

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

我在代码审查中经常发现的另一件事是，开发人员实际上并未遵循该要求。因此，比较您的代码及其实际要求是一个很好的检查。

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

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

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

回到大学时，我是一名写作导师。它无疑给了我一些我认为许多开发人员从未想到过的编码观点。最重要的方法之一就是大声阅读代码。听起来似乎不多，但是我将举一个我认为每个人都可以与之联系的完美例子。

您是否曾经写过电子邮件或论文，多次阅读以确保其正确无误，然后再发送，却发现自己存在明显的拼写错误，错别字或语法错误？昨天，当我要求客户按下狗屎键而不是Shift键时，我才这样做。当您脑海中读书时，您会看到想要看到的东西。

这是其他人提出的“只等一天，一周或一个月”建议的捷径。如果您大声阅读它，您会发现同样的事情。我不知道为什么它如此有效，但是在与数百名学生坐在一起并让他们大声朗读之后，我只能说它是有效的。

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

但是最好的做法是，对自己进行审查，然后再让至少两个其他具有出色角色的人员进行审查。

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

http://en.wikipedia.org/wiki/Software_inspection

也有一些书籍，例如Google撰写的Strauss和Ebenau撰写的“软件检查过程”。

另一种选择是付钱给某人检查一个重要的项目-或偶尔付钱给他们检查您的所有代码。这个人很好，我们已经多次派他出去训练我们的新开发者：

http://www.javaspecialists.eu/

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

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

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

当然，这不会为您带来团队的集体经验，但可以使您从新的角度审阅代码。

例如，如果您留下了一段令人讨厌的代码，那么，如果您随后立即查看代码，则可能不太愿意对其进行修复。毕竟，当您开始查看代码时，您已经知道并且已经接受了这种hack。但是，如果您睡个好觉，您可能会更有动力寻找更好的解决方案。

当我们入睡时，大脑实际上并没有停止处理我们所遇到的问题，因此您实际上可以在那里找到解决方案，尽管有时这些解决方案可能以奇怪的方式出现。