リファクタリングコメント付きのコードを広めることは良い考えですか？

私は「スパゲッティコード」プロジェクトに取り組んでおり、バグを修正して新しい機能を実装している間、コードをユニットテスト可能にするためにリファクタリングも行っています。

コードはしばしば非常に密結合または複雑であるため、小さなバグを修正すると多くのクラスが書き直されます。そこで、リファクタリングを停止するコードのどこかに線を引くことにしました。これを明確にするために、次のような状況を説明するコメントをコードにいくつか落とします。

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行を検索して表示するオプションがあります。あなたは時々それらをチェックし、可能な限りそれらの数を減らすようにしてください。

doxygenの/// @todoコメントやjavadocのインストールが簡単なカスタムタグを考慮して、APIドキュメントのtodoセクションに自動的に抽出されるようにします。単純なコメントは見過ごされやすく、最終的にはコードの深部で失われます。

[編集]ところで：これはいいアイデアですか：

バグを修正し、新しい機能を実装している間、コードをユニットテスト可能にするためにリファクタリングも行います

リファクタリングは非常に危険な場合があります（特に単体テストがない場合）。そのため、todoコメントを追加する際の余分な作業（バグの修正時など）を制限した方がよいでしょう...