我被赋予改善公司发展的作用。我想开始的第一件事是代码审查，因为以前从未在这里进行过代码审查。

我们公司有3位程序员。我是一名网络程序员，我的已知语言主要是PHP，ActionScript和JavaScript。另外2个开发人员在VB.net中编写内部应用程序

我们已经进行了几周的代码审查。我发现很难理解VB代码。因此，当他们说出自己的所作所为时，在大多数情况下，我只需要信守诺言。

如果确实发现有问题，请解释我的意见，并说明我将如何使用我所知道的一种语言解决该问题。

有时我的建议会受到欢迎，但是很多时候我会被告知诸如“这是使用这种语言的最佳方式”或“不适用于该语言”之类的事情。

这可能是正确的，但我不知道该用哪种语言，我不确定如何确认或反驳这些主张。

我知道一种可能的解决方案是学习vb，这样我可以进行更好的代码审查。我对学习vb确实没有兴趣（特别是因为我有一系列我正在尝试为自己的项目学习的技术），并且希望保留此作为最后的选择，但这是一个选择。

我想到的另一个想法是，他们俩都对C＃感兴趣，我也对C＃感兴趣。它相对于他们是因为它的.net和相对于我来说是因为它与我所知道的语言更相似。但这对我们所有人来说都是新的。我想到了我们所有人在一个宠物C＃.net项目上进行协作并从中互相检查代码的好处。

我想也有可能聘请顾问来给我们做一些代码审查。

在这种情况下，您会建议我做什么。

您个人对学习其他事物的渴望应该让您暂时不再学习自己现在真正需要的工作。了解VB.net。您可以通过询问许多问题来有效地编写您不了解的语言的审阅代码（通常，这是一个标志，如果您知道该语言并且无法弄清楚它的作用，则表示该代码编写得不好），并且为什么）。但是不理解代码，您可以做的最好的就是让他们向您解释它，并希望他们在解释它的过程中看到任何错误。这样做并不是说我没有在评论中发现我自己的代码中的错误，但这不是编码评论的最有效方法。现在，代码审查已成为您工作的一部分，进行处理并了解需要学习哪些才能有效地进行。

当您学习时，如果他们说得不好，而这不是我们用这种语言所能做到的，请让他们向您展示表明这是一种使用技巧的资料。由他们决定在代码审查中为您辩护，而不是相反。一旦您开始看到这些链接，您的语言也会变得更好。

实际上，我不同意以上所有观点。使用JS / PHP / ActiopnScript，您对编程语言具有什么以及它如何工作有基本的了解。实际上，我认为VB和JS之间有很多相似之处。但是，这不是我的意思。即使您精通该语言，在尝试遵循他人的思维过程时也很容易忽略某些内容，因此复习应该做的是为程序员提供一个机会来解释他的所作所为以及原因。

一位朋友曾经将其描述为“看门人理论”：通过向某人​​，任何人甚至看门人解释细节，程序员将自己的代码中的任何弱点暴露给了他/她自己，这当然是审查的最终目标处理。但是，这确实需要对代码进行彻底和公开的解释（在开发人员处于防御状态时，审查无效）。

短版

1. 请记住，代码审阅对于受审者和审阅者都是一次学习的机会。
2. 短语反馈是一个问题。
3. 不要让知识不足阻止您提供反馈（只要您在做＃2）。
4. 避免使用“偏好审查”，或者至少要明确表明它们是您个人的偏好，并且不一定需要同意。
5. 尝试提交补丁，而不要成为“扶手椅代码审阅者”。

较长的版本

首先，请记住，代码审查不仅是受审查者学习的机会。这也是审稿人学习的机会。实际上，我听说过一些组织，这些组织使新程序员开始进行代码审查，以便他们对代码有所了解。

考虑到这一点，我总会发现有一条代码审查建议总体上有用，但是与您的职位特别相关。将您的反馈以问题而不是陈述的形式表达。换句话说，您可以说“为什么用这种方式编写代码而不是这样做……”，而不是说“这段代码很烂！”，这使代码检查过程更加愉快，并且使您也可以学习。

我为您提供的另一条建议是不要让您的知识不足使您退缩。如果您发现自己认为错了的东西，并且从被审核者那里得到了一个波浪状的答案，请不要退缩（至少不是由于缺乏知识）。请记住，用一种语言编写好的代码与使用其他任何语言编写好的代码几乎没有什么不同。是的，某些语言有不同的习惯用法来帮助您编写良好的代码。但是重要的是要认识到这些习语是工具，而不是目的本身。

接下来，请尝试避免进行“首选项审核”。我（和许多其他人）必须对此进行非常有意识的努力。换句话说，请避免进行与“您做了x，但我更喜欢y ” 类似的评论。现在，说明首选项没有任何问题，但是您应该清楚地标明首选项，并记下对方可以自由地不同意。这很重要，因为大多数因语言而异的事物都属于此类别。

最后，你们使用分布式版本控制系统吗？可能有帮助的一件事是，如果您不仅可以注意代码的问题，还可以按照编写代码的方式重写代码，对其进行测试，然后为其提交补丁。这有助于表明您确实对改进他们的代码感兴趣，而不仅仅是成为“扶手椅代码审查者”，并且使您有机会更好地学习该语言。另外，不同意“我认为您应该这样做”要容易得多，而不是“这就是我要这样做的方式，如果您同意，这里有一个补丁”。我想您不一定需要 DVCS，但这肯定会有所帮助。

您已经失去了对问题的关注，并想出了一个糟糕的解决方案。您已经承担了改善开发的任务，而您的解决方案是让一个不了解该语言的代码审查人员（您自己）负责。谁在审查您的代码？他们为什么不能互相复习，直到您学习该语言？

必须选择其他一些问题区域才能有更直接的改进。这样，他们只是向您吹烟，没有任何改善。

将新开发定向到一种你们都不懂的语言（C＃）上将需要很长时间才能得到回报，特别是如果大家都带来了不良习惯的话。

专注于设计（前面已经提到过）。如果他们在维护当前代码方面遇到困难，请查看一些VB重构工具。许多基本做法是相同的。

您可以“校对”您不真正知道的内容，但是您无法对其进行适当的检查。我在C语言方面很能干，对C ++的了解也很深，但是我没有梦想回顾C＃中的某些内容。

我认为您不需要聘请顾问，因为有些公司专门通过大量测试来运行您的代码，并告诉您它可能有什么问题。

不过，这取决于了解语言解释结果的个人开发人员。例如，如果代码审查员责令我不使用的返回值printf()，我会奇怪地看着他们并质疑他们的清醒，然后问：“好吧，太好了，当什么都无法打印到控制台上时，我该怎么办？有帮助吗？”

您可能要考虑的是与老板讨论建立部门和团队负责人的问题，这样您就可以在自己的领域中发挥作用，而其他人则在他们的领域中发挥作用。

不过，我认为您也许可以使用第三方进行审核。即使他们不屑一顾（即使在我的示例中也是这样），但大多数值得花钱的程序员都会注意合理的顾虑printf()。

对您不了解的事物提供指导类似于您很清楚地引导盲人。

一种方法是利用诸如FxCop和StyleCop之类的棉绒工具，这些工具可以处理代码库的静态分析前端。这将为您提供一个辩论从工具生成的报告的起点。

另一种方法是将代码审查变成设计审查。设计审核通常会在编写代码之前就发现很多问题，而往往没有发现问题。如果程序员有一个设计，他们可以从他们那里进行工作，通常他们的方法会更有效，因此，错误会减少。当不存在设计时，该方法会变得自成体系，并且代码的错误计数会增加。确保每个人都有具体的设计要实施，然后在设计审查中发现问题之前，将它们赶上来。UML是您的朋友，umlet之类的工具使用起来很快。

坏消息是，为了有效地参与代码审查，您将必须学习VB。在某些类型的项目中使用VB也将有所帮助（不一定用于生产）。

好消息是，一旦完成此步骤，当您继续使用C＃时，所学到的一些知识仍然会有用。

在进行同行评审时，您应始终保持以下想法：

“我是保持此密码的下一个人！”

您必须对它有足够的了解，以便能够在进行审查的过程中做到这一点，并且您的工作是让原始程序员意识到使它变得过于繁琐的不足之处，以至于无法充分理解代码以维护代码。 。

如果您不能在VB中编程，则无法维护代码，并且您没有资格成为同行审阅者。

您不应该查看您不理解的代码，这只会惹恼那些不得不解释他们所做的每件奇怪事物的开发人员。

您可以选择/定义编码准则，然后根据这些准则检查代码。当某些内容不符合指导原则时，您可以要求开发人员进行解释。

我将从选择现有指南开始（我不知道任何VB.net编码标准，但google给了我：

• VB .Net编码准则
• 子主体
• 一站式的代码框架

对VB .net使用类似stylecop的工具

使用NDepend分析来源（它具有关于圈复杂度，长度，深度等的规则）

完成此操作后，您可以说代码符合所选的标准，但它并没有说明功能正确或使用正确的OOP原理的代码。但是至少这是某种东西。

良好的代码审阅涉及需要您理解语言的方面-适当使用语言，API和库，样式，变量名等-以及代码如何解决问题-良好的注释，正确的体系结构，相关的设计模式，考虑所有错误情况，等等。当您第一次开始执行代码审阅时，您倾向于专注于前者。它们更易于查看和选择。（例如，我不喜欢您的变量名。您应该使用XXXX样式名。）

当更多地关注代码如何解决问题时，代码审查就变得更有价值。由于您现在无法在第一个领域提供足够的价值，因此请专注于提出问题并提供有关问题解决方案的建议，而不是问题的解决方法。

当然两者之间有重叠。了解VB.NET可以让您提供建议，例如为什么在特定情况下某种设计模式不是一个好的选择。

最重要的是，在这个阶段要谦虚。改变过程是艰难的。即使您是VB.NET专家，更改也可能并不容易。那些没有使用代码审查的人一开始不喜欢它。让其他人查看您的代码是艰难的经历。看到价值和耐心需要时间。当您获得买进时，这是一个很棒的过程，但这需要时间。

您能否将重点转移到更多的测试上，而不是直接看代码？我并不是说要放弃代码审查，但起初，让那些内部应用程序具有足够的测试来帮助解码一些正在发生的事情可能更有意义。这里的想法是测试还可以帮助您更熟悉某些功能。我只是认为这是一条不同的路线。这里的想法是，评论会稍后再返回，并且可以分两部分完成，因为进行概述/前期会议可能会值得，然后稍作休息。休息时间要到第二天或第二天，以便有足够的时间供任何可能想要睡一觉的人思考代码或类似内容，然后再提出问题并进行讨论。

当然，如果您已经进行过测试，那么不幸的是，这并不是那么有意义。另一个想法是举一个例子，说明他们在VB.Net中声称这是通过一种特殊的方式完成的，因为这可能以某种方式使这个问题更加清晰，因为我可以想象这从少量的代码标准到部分代码的变化都将如此。从某种意义上讲，VB.Net是如何构建的。

即使您学习了VB的基础知识，在不了解该语言的所有功能的情况下执行代码检查也无法检测到该语言中不安全的功能的使用。

假设您不知道Python 2中的input（）函数实际上在返回输入之前对输入进行了评估，以使解析非字符串输入类型更加容易。这样，代码将容易受到任意代码执行的影响，从而使用户可以__import__('os').execl('/bin/sh', '/bin/sh')在Linux系统上输入类似内容，从而将Python进程转换为外壳程序。相反，应使用raw_input（）来获取未处理的输入数据。

在不了解该语言的所有功能的情况下尝试执行代码审查不仅会阻止您实现以某种语言执行特定过程的更好方法；它也可能导致有害的安全漏洞。