Title: コードリファクタリング
Author: Aki Hamano
Published: 2023年10月6日
Last modified: 2023年10月8日

---

# コードリファクタリング

[↑ ページの先頭へ戻る](https://ja.wordpress.org/team/handbook/core/contribute/code-refactoring/?output_format=md#wp--skip-link--target)

コードのリファクタリングは、できることだからという理由で行うべきではありません。
長い間使用されてきた関数の名前を変更する提案や、より最近に確立されたコーディング
標準に準拠する提案など、時間の経過によって開かれた「リファクタリング」チケットは
数多くあります。一方で、もっと価値のあるタスクがたくさんあります。ここでは、これらの
チケットがレビューの対象となるために必要なガイドラインをいくつか提案します。

 * **ユニットテスト**。たとえ、そのコードが以前はカバーされていなかったとしてもです。
   リグレッションは避けるべきであり、これによりテストのカバー率を向上させることが
   できます。
 * 適用前と適用後の**パフォーマンスベンチマーク**。リグレッションは避けるべきです。
 * 変更についての**適切な正当性と明確な根拠**の両方が必要です。多くの場合、これらの
   パッチの目的、目標、またはフォーカスを決定できません。可読性、個人的な狭い意見、
   一般的な主観などを口実として、コードを書き換えるべきではありません。

これらが守られないと、レビュアーやコミッターの気が散ってしまい、費やすべき重要な
注意力や集中力が削がれてしまいます。

またコードのリファクタリングによって、より重要な既存のパッチが不必要に古くなる可能性
もあります。

Linux カーネルへの貢献に関するドキュメントに、コーディング標準を扱う際の[落とし穴に関するセクション](https://dri.freedesktop.org/docs/drm/development-process/4.Coding.html#coding-style)
があります。これは、リファクタリングという広い視野にも適用されると思います (強調
は引用者)。

> カーネルは長い間、Documentation/CodingStyle に記述された標準的なコーディングスタイル
> を持っていました。その多くの期間、このファイルに記述されたポリシーは、せいぜい
> 勧告的なものとして扱われてきました。このようなコードの存在は、カーネル開発者にとって
> 2つの独立した危険性をもたらします。
> **これらのうち最初のものは、カーネルのコーディング規約は重要でなく、強制される
> ものではないと信じてしまうことです。もう一つの罠は、すでにカーネルにあるコード
> について、早急にコーディングスタイルを修正する必要があると思い込んでしまうこと
> です。**

とはいえ、内部的には一貫性を保ち、自分たちのルールに従いたいものです。コードは詩
であり、私たちのコードは美しくあるべきです。

[原文](https://make.wordpress.org/core/handbook/contribute/code-refactoring/) / 
[日本語訳](https://github.com/jawordpressorg/core-handbook/blob/main/core/contribute/code-refactoring.md)

公開日

2023年10月6日

最終更新

2023年10月8日

[  前へ: コードによる貢献](https://ja.wordpress.org/team/handbook/core/contribute/)

[  次へ: コードリポジトリ (Git)](https://ja.wordpress.org/team/handbook/core/contribute/git/)