如何在请求请求中处理TODO？

当我查看请求请求中的更改时，有时会偶然发现带有“ TODO”注释的注释，该注释可能有不同的原因，在我们的情况下，主要是因为：

• 用于解决问题的解决方案可以改进，但需要大量的时间投入。作者选择了一种更快的解决方案，但评论说可能有更好的选择
• 有一个临时代码可以解决现有的错误，应尽快修复

知道TODOs通常会在代码库的整个生命周期内停留在代码库中，那么我应该如何在请求请求中对它们做出反应？我如何礼貌地避免使用它，或者如果它确实是合理的，我如何确保PR的作者在以后的晚些时候进行跟进？

当您说他们“在团队/部门/组织中通常在代码库的整个生命周期中都停留在代码库中”时，请考虑以下事项：

• 把它写下来你的国防部说TODO，FIXME或者类似的标签应尽量避免。
• 使用静态代码分析工具（如SonarQube）自动将构建标记为不稳定。
• 当且仅当您的问题跟踪器中有相应的票证时，才临时允许他们。然后，代码可能看起来像TODO [ID-123] Description ...

如我的评论中所述，最后一条语句可能仅在不允许票证腐烂的环境中才有意义（例如，如果您遵循零错误策略）。

我个人认为，TODOs为有时合理的，但不应该过分地使用它们。摘自罗伯特·C·马丁（Robert C. Martin）的“清洁代码：敏捷软件工艺手册”（第59页）：

TODO是程序员认为应该完成的工作，但由于某些原因目前无法完成。可能会提醒您删除不赞成使用的功能，或者恳请其他人查看问题。这可能是要求其他人想出一个更好的名字，或提醒您根据计划的事件进行更改。不管有什么其他办法TODO，都不可以在系统中留下不良代码。

TODO的他们自己并不邪恶。我是一个超级狂热者，从来不会深入到每一层，并且总是为每个跟踪器票修复1个问题。

我经常使用TODO或FIXME来提醒自己，我需要或想要回来解决问题。

例如，我可以调用add（a，b）并添加一个TODO来重构add方法。我现在不想使用add方法，但是我想回到它上面。

因此，在请求请求中，您将看到TODO或FIXME。例如，我使用FIXME来向其他开发人员警告他们应该负责的代码区域，我不应该对此感到困惑。例如，FIXME add不能接受负数。

为了解决看不见它们或忽略它们的问题，我使用了一个脚本，该脚本列出了所有TODO FIXME和DEGUG行。并将其附加到提交消息中。

很难忽略所有TODO的400行提交消息。因此，人们可以在已经接触有问题的代码的同时修复它们，或者通过创建新的票证并独立修复问题的代码来修复它们。

公平地说，我还确保每个项目都有内置的代码清理时间。是的，可以在15日启动，但是从15日到30日进行代码清理。（这似乎很奇怪，但是如果您曾经管理过某个产品，您就会知道，如果您尝试在发布前尝试执行具有较低可见性的任务，那么您将永远无法进入这些任务。其他事情将获得优先考虑。）

可能会有不完美的请求请求。现在，我正在做一些可以在可用时间内“足够好”完成的工作，但是还不够完美。因此，我提交了一个拉取请求，将带有注释的TODO放入代码中的正确位置，同时我添加了另一个更改请求，以将事物从“足够好”更改为“完美”。

然后，可以为新的更改请求确定优先级，并且当它是优先级最高的项目时，将对其进行处理。如果决定，它需要完善，现在正确，那么这将是递给接下来的事情。

现在您的问题是：“我如何礼貌地避免使用它，或者如果它确实是合理的，我如何确保PR的作者在以后的晚些时候进行跟进？” 根据我的描述，这似乎很愚蠢。如果我可以选择延迟交付还是交付足够好的产品，那么这不是您的决定。如果您愿意，可以询问产品经理。并且“确保PR的作者会跟进”？如果您有团队，则应确保将其记录在系统中，并希望您的团队组织得井井有条，不会丢失已记录的内容，并且当没有更高优先级的项目时，有人会对其进行修复。记住，这是团队的努力。

如果您的项目跟踪带有TODO注释的源代码中的未决项目，则必须允许它。

TODO在请求请求中存在注释的事实困扰着您，您应该告诉您，跟踪源代码中的未决项目是一个坏主意。事情往往以这种方式迷失或忽略。现在，如果您正在谈论对“工作叉”的拉动请求，那么情况就不同了。一个“工作叉”就是正在进行的工作。但是像这样的fork通常不需要拉请求。此处建议的“内部规则”是针对master分支的请求请求。

内部规则＃1-所有提交给master的提交都应准备好进行测试，因为master每天都在签入后生成。这些提交还应包括所需的任何其他测试。

如果TODO由于代码未完成，测试未完成或代码未以任何方式准备好进行测试而出现在注释中，则该代码属于本地提交，而不是请求请求。准备好后给我打电话。

内部规则2-有关未解决问题的所有信息都存储在问题跟踪器中。所有的。笔记，涂鸦，预感等等。

如果TODO评论与未解决的问题有关，并且不是该问题的实际解决方法，则该信息属于问题跟踪器。这样，在解决问题之前，可以根据需要检查和验证所有信息，以确保问题得到实际解决。

内部规则3-有关待处理项目任务的所有信息均属于优先级队列（或系统的名称）。

为了澄清起见，待定的项目任务是在具有设定优先级的项目中需要完成的任务，无论它是在生成问题凭单之前发现的缺陷，还是特定设计要求的实现，还是以下之一：该要求的必要组成部分。

如果有TODO评论说新代码将影响待处理的任务，或者指出实现新代码时发现的代码库中需要查看的其他内容，则该信息属于优先级队列，位于现有任务或作为新任务。

众议院规则4-建议属于“创意框”（或其他内容）。

如果TODO评论表明该软件的设计或实现有所更改，则该信息应属于项目的构思框中，或者是“ vNext”或“设计说明”，或者属于此类的任何内容。

众议院规定＃5- TODO源代码中不允许注释。期。

如果您遵守此规则，那么您就不必担心任何人都会跟进任何事情。