コードリファクタリング
コードのリファクタリングは、できることだからという理由で行うべきではありません。長い間使用されてきた関数の名前を変更する提案や、より最近に確立されたコーディング標準に準拠する提案など、時間の経過によって開かれた「リファクタリング」チケットは数多くあります。一方で、もっと価値のあるタスクがたくさんあります。ここでは、これらのチケットがレビューの対象となるために必要なガイドラインをいくつか提案します。
- ユニットテスト。たとえ、そのコードが以前はカバーされていなかったとしてもです。リグレッションは避けるべきであり、これによりテストのカバー率を向上させることができます。
- 適用前と適用後のパフォーマンスベンチマーク。リグレッションは避けるべきです。
- 変更についての適切な正当性と明確な根拠の両方が必要です。多くの場合、これらのパッチの目的、目標、またはフォーカスを決定できません。可読性、個人的な狭い意見、一般的な主観などを口実として、コードを書き換えるべきではありません。
これらが守られないと、レビュアーやコミッターの気が散ってしまい、費やすべき重要な注意力や集中力が削がれてしまいます。
またコードのリファクタリングによって、より重要な既存のパッチが不必要に古くなる可能性もあります。
Linux カーネルへの貢献に関するドキュメントに、コーディング標準を扱う際の落とし穴に関するセクションがあります。これは、リファクタリングという広い視野にも適用されると思います (強調は引用者)。
カーネルは長い間、Documentation/CodingStyle に記述された標準的なコーディングスタイルを持っていました。その多くの期間、このファイルに記述されたポリシーは、せいぜい勧告的なものとして扱われてきました。このようなコードの存在は、カーネル開発者にとって2つの独立した危険性をもたらします。
これらのうち最初のものは、カーネルのコーディング規約は重要でなく、強制されるものではないと信じてしまうことです。もう一つの罠は、すでにカーネルにあるコードについて、早急にコーディングスタイルを修正する必要があると思い込んでしまうことです。
とはいえ、内部的には一貫性を保ち、自分たちのルールに従いたいものです。コードは詩であり、私たちのコードは美しくあるべきです。
最終更新日: