我怎样才能礼貌地请老板评论他的代码？

我的老板正在教我（我刚上完学，他想找一个有一点编程经验的人，所以他选择我来培训我该公司的专业知识），并开始使用ASP.NET MVC应用程序，一些HTML和CSS 。我对他给我的网页设计资料感到满意（无需弄清楚，就很容易理解）。

但是例如，他给我一个与ASP.NET MVC有关的任务，他的解释很好。但是他没有在他给我的代码中解释任何内容。（我们在Visual Studio 2013中使用源代码管理），因此它实际上是几百行代码，而对它应该做什么没有任何背景知识。我所看到的那种代码是我从未见过的代码，因此很难弄清楚。

我会尝试问他更多的问题，但是他一直在工作（这是他自己的事），我觉得他可能会被我遇到的所有这些问题烦恼。

因此，只有在我对事物有所了解之前，可以帮助我解决问题的方法，如何才能要求老板在他给我的代码中添加注释，但要礼貌些？

您处于“深入研究”中，我认为这是最好的学习方法。并不是因为您正在寻找自己不知道的东西，而是因为它迫使您变得更加足智多谋，并且发现了哪些组件在您刚接触的系统中扮演着哪个角色。

您的老板太忙而无法与一个好奇的人打交道（这对您没有任何帮助（而您完全有权利要保持好奇心；您渴望学习，这很好））。但是，不幸的是，为了学习而要求上级改变他们的风格和方法可能不会太好，尤其是因为您正在与您说很忙的人打交道时。

坐在您不熟悉的成千上万行代码的前面是常态。您不能总是用黑白注释解释它。但是，为了在您不熟悉它的同时进行学习，如果您确定一定要向他提出意见-也许可以解释原因。解释是因为您不想因为他经常很忙而打扰他。这不仅会像您告诉他做某事那样少得多，而且还为讨论他可能如何讨论铺平了道路，相反，他宁愿将提问时间搁置一旁。

首先，从开始就遍历数千行不熟悉的代码并感到迷失的是每个软件项目在任何地方都是如此。

您和经验丰富的程序员之间的最大区别是您不习惯。

请记住以下几点：

1. 通过足够的努力，每一点代码都是可以理解的。如果许多人在几分钟之内无法解决问题，就会感到沮丧。要比这更耐心。

2. 一个好的老板要尽可能地避免打扰和提问。一个好的员工会尽最大的努力来减少干扰和问题。意识到这一点。

3. 中断比问题要昂贵得多。您可以通过巩固讨论来更好地利用自己的时间和上司的时间，并且永远不要结束感到困惑的谈话。

4. 你的老板比你是一个更好的程序员。（也许。）这并不是说您在某些领域不能变得更强大，但总体而言，他的专业知识更强。在您没有丰富经验之前，请确保您已尽可能多地从他的专业知识中学习。

5. 如果您确定更多注释将对代码有很大帮助，请询问您的老板。“我很难理解某些地方的情况。当我弄清楚事情时，是否介意添加评论？” 也许他讨厌评论。也许他会喜欢的。也许他会无动于衷。

但是最后，可能从现在起的几个月后，您会记得问这个问题，然后想：“嗯，我想知道我有什么问题吗？这还不算太糟。嗯，嗯，没关系。”

如果您的老板没有时间回答您所有的问题，您为什么认为他将有时间评论其遗留代码？而且，是什么让您认为他的评论真正描述了您现在不了解的点点滴滴？以我的经验，仅仅问他改变老板的编程风格是行不通的，不管有礼貌与否。

在这种情况下您可以做的最好的事情：注释自己完成工作所需的代码部分 -当然，一旦您了解了这些部分，并且得到了老板的承诺，就可以了。如果您或您的老板担心您可能会通过添加注释来破坏某些内容，请将这些注释添加到一个单独的分支中，并询问您的老板在合并到主干中之前是否会花时间查看您的注释。由于您的老板只有有限的时间预算，因此请尝试花费合理的时间自己先弄清楚某个部分是做什么的。如果您确实陷入困境，则将问题写下来，例如每天询问老板一次，而不是打扰他30分钟。以我的经验，即使他们很忙，只要他们愿意为您提供帮助，这种方法也适用于大多数人-当然，您所遇到的情况就是如此。

这样，您可以确保获得所需的评论，并且老板会看到您需要其他信息的地方以及您是否做对了。而且，只要您限制自己仅对不明显的内容进行注释，那么您的注释很有可能会提高代码库的整体质量，这不仅会给您带来好处，还会为其他每个人带来好处必须处理代码，包括您的老板。

首先，让这成为您正确注释代码的示例，蚱code！

然后，我必须一直这样做。我已经签出了本地副本，并亲自对其进行了评论。（如果我将其重新签入，则可以再次将它们全部剥离掉-如果没人介意，则可以将其保留在其中。）然后，当我真的看不到任何东西时，我可以问一个人，在这里，我认为确实可以这个（我的评论），对吗？因此，您可能已经完成了实际的评论，但事实已经完成，这就是重点。

这不仅仅是个人要求。您正在尝试改变习惯/文化，这并不容易。当然，通过走廊对话或电子邮件无法完成任何事情。您将需要付出一些努力。

成为您希望在世界上看到的变化。

该报价可能被错误地归因于圣雄甘地，但这是适用的建议。当您尝试弄乱代码库时，请尽力而为，写出您想看到的注释，并在经过老板审查后提交。好处：

• 您是在积极主动，而不是na。
• 您正在树立好榜样。在最好的情况下，您的老板/团队会看到好处并效仿。
• 有些评论可能会说/* Mystery parameter 3 */或/* 2015-02-09 AidanQuinn: Is this code ever called? */-这些是您的同事有机会对代码进行正确记录或修复潜在错误的机会。
• 如果在提交前的审查中发现您编写的评论不正确，那么您的同事现在知道代码不清楚。

执行此操作时，请勿进行任何重写或重构，并且注释的引入应几乎没有风险。如果确实重写任何内容，请将这些更改保留为单独的提交。

（但是，在开始这个项目之前，请确保您对注释的期望是合理的。如果您对注释良好的代码的想法不在规范范围内（示例1，示例2），那么您只会愚弄你自己。）

我不要求其他意见，但是这里有一些建议供您参考：

1. 安排与您的老板坐下来，让他高水平地阅读代码。这应该可以帮助您入门。我希望几个小时到半天，以便您快速上手。这应该包括总体设计，使用的模式等。
2. 创建一个测试项目，并开始针对代码编写单元测试，这将帮助您理解它而不影响它。您可能还会发现一些错误！
3. 根据需要调试代码以了解某些领域。
4. 从积压的积木中删除或改进并继续进行。

注释是可以的，但是如果以直接的方式编写代码，几天后应该可以理解。

也不要期望了解所有内容，最好先专注于关键领域，然后根据需要扩展代码库知识。

大约一年前，我的处境与您非常相似。我最初的编程经验很少（尽管我了解一些OO和其他语言），而教我的人却很少。他总是很乐于助人，但我觉得我不想问我所有的问题。

其他人已经在这里提出了非常有用的建议（例如，编写单元测试，但是根据我的经验，这对我从头开始有点“太过远”；或者您自己注释了部分代码，但是可能很难，具体取决于我稍后要问的第一点/问题）。以下几点总结了我所做的事情和对我有所帮助的事情，但这在很大程度上取决于您的问题所在。

另外，我必须同意@AK_，后者说您实际上不需要C＃中的注释。这可能不是100％正确的（我认为在某些地方注释肯定有帮助，例如，反射重代码），但从本质上讲，确实如此。如果您使用名称明确的方法和变量编写真正的“干净代码”，并且有很多小“代码”，则几乎完全没有必要。到目前为止，每次阅读代码时我都觉得需要注释，然后在理解了它的功能之后，我对它的完成方式感到非常不满意，并认为通过良好的重构，它本来可以变得更清晰。 编辑：我在这里专门谈论C＃注释，而不是文档（无论是单独的文档还是XML注释），因为我认为文档始终很重要。

• 确定您的问题到底是什么以及是否可以对其进行分类。也就是说，您仍然对语言本身有疑问，还是不了解特定的语法（例如，一般来说是lambda表达式和LINQ或Reflection）？如果您不理解代码行，那么您将不了解整个方法/块的功能，因此您自己很难注释。相反，买一本好书（《 C＃in a Nutshell》是给我的，但我听说《 C＃in Depth》也很出色）并继续阅读您遇到的事情。事先对这些问题进行分类将使此操作变得容易，因为您可以立即填补“更大的空白”，甚至可以向老板询问，因为不再有很多问题，而是要解释一个主题或最常用的结构，以便您可以得到巨大的“助推”

• 与上述类似，我尝试使自己熟悉“干净的编码”和最佳常规做法（不是特定于语言）。这样做的效果可能不会立即产生，但是当您不得不扩展现有的东西，或者想知道为什么有人创建了这么多小的方法而不是包含所有内容的方法时，它迟早会得到回报；-)

• 掌握常见的设计模式。它们可能出现在您正在阅读的代码中的各处，如果您识别出它们，它将立即给您带来美好的回忆。即使您了解在那里看到的代码的功能，也可能使您想知道为什么要用这种方式完成，而自己搞清楚这通常并不那么容易。

当我对您的“技能”做出假设时，请不要接受以上内容，因为我经常不经意间在谈论自己的经历和“与您交谈”之间切换。这主要是指因为我遇到了，和我做了什么。就像其他人所说的那样，这可能是一个很好的体验，并且它几乎是阅读不是您自己的代码并且您事先不了解很多代码的工作标准。但是，最终了解那里发生的事情并认识到自己在此特定“技能”上变得越来越好，可能真的很令人满足。借此机会在短时间内学到很多东西，祝您好运！:)

您可能不会让他改变他的风格。

您可以做的是问很多问题，并写下答案。

我上一份工作继承了一个庞大的代码库，几乎没有文档，也没有评论。因此，我将在同一个问题上尝试半小时，然后，如果仍然无法解决问题，我将去问问写了它或知道如何使用它的人。然后，我要记录他告诉我的所有事情。大部分进入我们的文档，一些进入代码作为注释。一年后，我几乎写了大部分文档，并且对代码库了如指掌。

祝好运！

我遇到了同样的问题。我是phyzist的学生，并且具有良好的编程经验。我当时使用多种语言进行编程，但没有进行高级应用程序编程。

我已经为Web开发人员申请了一份工作，他们立即使我进入了Web编程的后端。当老板向我展示节点REST应用程序的基本api时，我以为我会淘汰。我从未见过带有回调和如此奇怪语法的函数。我问我的老板，如果我对代码中的任何内容都没有理解的话，我有问题吗？他伤心不，他伤心我有1个月的时间来解决这个问题，同时我将制作一个CMS来测试另一个前端程序给我。

好吧，当时我走了1行代码，然后用Google搜索我所不知道的所有内容。因此，经过了1周的时间，我对代码足够熟悉，可以与前端渲染器进行一些协作。我在beginig上的代码很糟糕，但是在那之后的三个月里让我失望了！我的编码比我们的软件架构师更好，更快！

我以为你永远不会停止学习！我的moto->保持学习并保持冷静:)不要依靠老板独立并直接问他，但只有最棘手的问题。因为在您自己进行研究之后，您会感到很高兴。记住，当您停止学习错误的东西时，请每天学习如何成为一名优秀的程序员。

如果您向老板学习，您将永远不会比他设定自己的标准更好，学习盲注，适用于您的IDE，Linux wmii的VIM或VIM插件，因此您总有一天会超越老板，变得比他更好！

作为拥有20年经验的软件工程师，主要从事安全相关工作（SF-PD），我不得不说，您的老板可能不是您想成为榜样的人。缺乏评论表明，要么是自学成才的业余编码员，但从未学会如何正确地完成工作，要么是经验不足的工程师。或者，也许根本没有时间的工程师-截止日期和权宜之计可能会对您的代码造成可怕的后果！;）对于每位称职的软件工程师来说，这绝对是一种反模式。

您的老板可能是一个非常好的编码员，但听起来他不是一个好的软件工程师。工程师利用集体的集体经验来避免其他人已经陷入的陷阱。有效的评论是软件集体经验的一部分，就像应力分析是机械工程集体经验的一部分一样。但是，有效的评论更为流畅，这绝对是您从经验中学到的东西。

最基本的是，注释不应说明一行代码的作用。有时，注释也不能说出函数的作用（尤其是在C＃中）。过度注释可能同样没有效果（并指出缺乏经验），因为您无法在浮渣中找到重要的内容。作为新手，您可能仍在研究代码的“内容”，为此，您只需要阅读并了解他的工作即可。

注释的重要之处在于，他们说为什么代码行或函数会执行它所做的事情，而这可能并不明显。您是否需要在模块Y之前设置模块X？检查返回码以查看文件是否已经打开很重要，还是我们有意识地忽略了返回码，因为已经在其他地方进行了检查？不管经验如何，代码的“为什么”都会与每个人相关-六个月后，当他被遗忘了以某种特殊方式做某事的充分理由时，它也将与他相关。评论不仅是针对其他人的，它还为将来提供帮助。

如果您想避免惹恼老板，请提出一些聪明的问题。专注于询问“为什么”，并尝试自己解决“什么”（除非它真的是晦涩的）。如果您不是R-ing TFM所能找到的那种东西，那么没有一个好老板会介意被问到这些问题。没有优秀的工程师会介意要求他们做些可以使另一名工程师的生活大大简化的事情，而这对他们来说几乎没有任何代价。（只是不要让他在整个代码库中回填注释！；）

我说过类似情况

1. 您的老板可能会出于某种原因让您学习肮脏的方式（通过遍历您不了解的代码）。正如其他答案中提到的那样，这是我们在工作中每月学习比在大学一年学习更多的方式。

2. 这就是其他答案中提到的“规范”。比起立即理解每一行代码，您应该更担心从哪里开始，如何着手以及重点关注什么。向您的老板询问正确的工具以及调试/逐步执行代码的方法。这种问题会给您一些帮助。

3. 定期与老板取得联系，以获取有关您的工作方式的反馈，这样，您就会以百分位数的名义了解自己的情况，前提是您的老板在相同情况下看到了很多人，并且知道他们的工作方式。

4. 以此为契机，随着您对代码的理解越来越好，请继续添加最初希望问老板的注释。

如果您真的想让他在他的代码中添加注释（我不建议这样做），我建议您找到需要编辑的代码，这些代码确实可以使用一些注释（大多数是自我解释的），并询问有关就像这样“我在这里看这段代码，我试图找出[问题所在]，我找不到任何注释来解释它”。基本上试图表明您已努力理解它，并解释了为什么这两个原因都可以使您从那里的评论中受益。

大约90％编写良好的代码不需要注释。您只真正想要记录经过优化且变得相当紧张的代码部分。我曾在一家公司工作过，要求您记录您修改的每段代码，基本上，注释最终会积极损害代码的可读性，因为注释通常引用已被删除或修改而无法识别的代码。当心那些糟糕的评论，我花了一周的时间调试一个函数，最后我发现，我一直在阅读关于将某某标志设置为“ false”的评论实际上是整个问题，我将该标志设置为“ true”，并且一切正常就像应该的那样。

如果您想让代码中的注释理解为什么编写某些东西，那么很可能（考虑到您是新来的）您还不了解业务需求。我确定您知道所有语法并且可以阅读代码，但是除非您知道某些代码的用途，否则您会感到有些困惑。

想到的一件事是结对编程。您说老板对您的进步印象深刻，因此您可以建议与他一起工作。从长远来看，这将对你们俩都有帮助。您的老板会发现自己不得不解释他认为理所当然的事情，您将了解有关该业务的更多信息。

正如其他人提到的那样，这很普遍，但这并不意味着您只需要将其吸干并犁耕即可。您不需要像您认为的那样深入地理解代码，并且有一些具体的策略可以使“深层次”变得更浅​​：

• 找到的东西在与手头任务的代码。通常，最容易搜索的是用户可见的内容，例如GUI上的按钮标签。写下您找到它的地方。这将是您的定位点。
• 现在，一步步搜索代码并将其记录下来。谁创建按钮？单击按钮时会调用什么代码？
• 源代码控制通常对于查找距离仅一步之遥的代码很有用。查找正在添加或更改您正在查看的代码的时间，并查看同时检查了哪些内容以及原因。
• 重复该步骤，直到您足够了解所做的更改为止，再加一级，以确保您没有丢失任何内容。
• 如果您在任何时候遇到困难，现在都需要提出一个非常具体的问题。例如，“我不知道该按钮的实例化位置。”

这是我的这笔0.02美元。我并不是在建议一个排他性的答案，这里所说的很多内容都非常相关。

我会尝试一些社交工程来安排事务，以便您的老板发现注释自己的某些代码比不注释更容易/更少时间。

现在，如果您愿意冒很大的风险并惹恼他，这可能很容易-但我们不想这样做。（旁注：您可能无法做任何事情而没有他写下或命令您哟，您坚持不懈地困扰着他，等等）

那有什么选择呢？一些想法，视情况而定。

选项1

1. 花些时间在做X时理解他的一段代码。
2. 现在想想一个合理的方式Y来误解它。
3. 告诉老板（通过电子邮件或在早餐时说些什么或诸如此类的话），告诉您您当前正在尝试找出答案。
4. 添加一条注释，说不清楚代码的含义，但是您将其理解为Y。尝试使此评论对他可见-但不要太努力！
5. 假设Y- 行动，并确保老板注意到您的行动（因此，您不会因为虚假假设而长时间浪费时间）。
6. 老板应该主动纠正你。此时，请告诉他类似的信息：“我真的希望这段代码提供一些注释，以防止我做出错误的假设。我会为自己添加的注释更正。您认为可以通过一些一般性说明为我提供帮助吗？我没有足够的经验来弄清楚确切的意图，而我只需要几个句子就可以解决问题。” 或者其他的东西..

选项2

您正在训练中。尝试安排他每周一次（其他？）固定频率的会议。在这次会议上讨论了一些代码-但是您需要为他做足够的准备，而不必解释每一行。在某个时候-希望-他会意识到，如果他只是添加评论，他可以跳过会议。

选项3

让另一个同事无法理解与您相同的代码。你们俩在不同的时间联系老板询问相同的问题。这是确保他意识到自己没有做某事的肯定方法……但是并不是每个人都在同一项目上拥有很多乐于助人的同事。

因此，只有在我对事物有所了解之前，可以帮助我解决问题的方法，如何才能要求老板在他给我的代码中添加注释，但要礼貌些？

如果您不懂代码，为什么认为注释是您的解决方案？

我不知道他的编程风格，但是我承认，如果函数和变量的名称具有误导性，将使理解代码变得非常困难。但是，如果名称和功能甚至程序的组织（类，方法，属性...）使代码易于理解，那么代码实际上将与您自己对话。

您最好向他询问程序的体系结构，如果您想请求他提供一些东西，请为函数提供一些更有意义的名称。那对他来说更方便。

即使有一种礼貌地问这个问题的方法，您的老板会对他的代码中的注释有何看法也有两种可能性：

1. 在他的代码中添加注释将是一件好事，或者

2. 他的代码中的注释不是一件好事。

如果您的老板认为在他的代码中添加注释不是一件好事，（并且对此有很好的论据，即该代码应被视为文档，并且没有文档会规定准确无误的内容）作为实际执行此操作的代码，）则什么也不会发生。

现在，如果您的老板有任何机会认为在其代码中添加注释是一件好事，那么他很有可能会告诉您学习其代码，了解其工作原理并继续向其添加注释。给自己编码。（对此也有很好的论据，也就是说，您需要学习，根据定义，他的时间比您的时间更有价值。）

因此，除非您准备要这样做，否则最好不说什么。