用重构注释扩展代码是一个好主意吗？

我正在研究“意大利面条代码”项目，并且在修复错误和实现新功能的同时，我还进行了一些重构，以使代码可以进行单元测试。

这些代码通常紧密耦合或非常复杂，以至于修复一个小错误将导致许多类被重写。因此，我决定在代码中停止重构的位置画一条线。为了清楚起见，我在解释这种情况的代码中添加了一些注释，例如：

class RefactoredClass {
    private SingletonClass xyz;

    // I know SingletonClass is a Singleton, so I would not need to pass it here.
    // However, I would like to get rid of it in the future, so it is passed as a
    // parameter here to make this change easier later.
    public RefactoredClass(SingletonClass xyz) {
        this.xyz = xyz;
    }
}

或者，另一块蛋糕：

// This might be a good candidate to be refactored. The structure is like:
// Version String
//    |
//    +--> ...
//    |
//    +--> ...
//          |
//    ... and so on ...    
//
Map map = new HashMap<String, Map<String, Map<String, List<String>>>>();

这是一个好主意吗？这样做时我应该记住什么？

用重构注释扩展代码是一个好主意吗？

如果您已经分配了时间来完成重构，并且确实做到了，那么可以-它可以解决。

这样做时我应该记住什么？

现代IDE可以选择查找和显示TODO行。您应该不时检查它们，并尝试尽可能减少它们的数量。

我会/// @todo针对doxygen或易于安装的问题进行评论 javadoc自定义标记，以便将其自动提取到API文档的todo部分。普通注释将很容易被忽略，并最终迷失在代码的深处。

[编辑]顺便说一句：这是个好主意吗：

在修复错误并实现新功能的同时，我还进行了一些重构，以使代码可进行单元测试

我认为（经验丰富！），重构可能非常危险，尤其是在还没有单元测试的情况下。因此，最好在添加待办事项注释时限制您的额外工作（在修复错误等时）……众所周知：只要有可能；