リファクタリングとコードの臭い – きれいなコードへの旅

リファクタリングは、より理解しやすく、メンテナンスしやすい、きれいなコードにするのを助けてくれる。それにはコードの臭いを嗅ぐ経験と実践が必要だ。つまり、コードの中にあるより深い問題を示す悪い設計の兆候を見つけることだ。コードを壊すことなく、小さなステップでリファクタリングを行うことを支援するツールもある。

CoduranceのHalima Koundi氏はSwanseaCon 2016でリファクタリングとコードの臭いについて語った。InfoQはカンファレンスの内容を記事やインタビューで取り上げている。

Koundi氏はMartin Fowler氏のコードの臭いの定義を紹介している。

コードの臭いは表面的な兆候であり、システムの深い問題と関連しています。

適切にメンテナンスし改善することに必要な注意を払わなければコードの質は悪化していく。Koundi氏はいくつかのコードの臭いの種類を紹介し、その臭いに気付く方法を説明した。ひとつの種類として"オブジェクト指向乱用"という臭いがある。これはオブジェクト指向の設計を不完全にあるいは間違って実装したものだ。オブジェクト指向乱用の臭いに気付くことで、オブジェクトを間違った振る舞いに導く、オブジェクト指向の原則を無視しているコードを見つけることができるかもしれない。

また、"変更障害"という臭いも紹介した。これは、コードの上のひとつの変更(例えば新しい機能の実装や既存機能の改修)が多くのクラスに影響しコード全体の拡張を必要とするケースだ。 "並列の継承階層"や"変更の発散"のような臭いもこれに当たる。

Koundi氏はJetbrainsのReSharperを使ってデモを行い、安全にリファクタリングする方法を示した。デモを通じて、新しい支払いメソッドを追加するときにどのようにコードを修正するかを示し、小さなステップでコードをリファクタリングしコードを壊さないようにするための方法を説明した。

InfoQは講演の後、Koundi氏にインタビューしてコードの臭いの種類や臭いに気付く方法、コードの臭いへの対処方針やリファクタリングの仕方、コードを破壊しないために開発者ができること、リファクタリングするべきとき、するべきでないとき、リファクタリングの利点について話を聞いた。

InfoQ: コードの臭いの種類について教えてください。

Halima Koundi: コードの臭いはいくつかのカテゴリに分類できます。ある種の臭いは何度も現れます。注意不足やコードベースの抽象の不足から生まれるからです。長いメソッドやたくさんのパラメータなどがこれに該当します。また、オブジェクト指向の原則を中途半端にあるいは間違って導入した場合も同じです。例えば、Refused Bequestは間違った抽象のひとつでしょう。

システムにノイズを加えるコードもひとつのカテゴリです。例えば、コードからコメントを少なくし、メソッド名にしっかりとした意味を持たせるべきです。使っていないコードは後で使うと思っていても削除するべきです。

InfoQ: 開発者はどうやってコードの臭いに気付くことができますか。

Koundi: コードの臭いは、視覚的なサイン、あるいは、物理的なサイン、あるいは、抽象的なサインでわかります。視覚的なサインとは、長いメソッド、長いパラメータリスト、同じパターンで何度も現れる変数などは責務が混ざっており、抽象が間違っている兆候です。物理的なサインは多くのファイルの修正が伴う変更というかたちで現れます。抽象的なサインは"なぜ振る舞いを共有しないのにこの親クラスを継承するのか"というような問いかけをするときに現れます。

コードの臭いに気付くには訓練と経験が必要です。訓練を助ける練習や型はたくさんあります。コードの臭いは兆候です。なんらかの設計原則に違反していることを次第に明らかにしてくれます。これらの原則を知っておくことで何がおかしいのか理解する助けになるでしょう。

InfoQ: コードの臭いへの対処方法の一般原則について教えてください。

Koundi: リファクタリングとは振る舞いを変えずにコードの設計を変えることです。これはプラットフォームに依存しません。コードの臭いは悪い設計の兆候です。Martin FowlerのRefactoring: Improving the Design of Existing Codeを読むことをお薦めします。抽象へリファクタリングするのは常に正しいとは限らないという点は重要です。システムをより複雑にし、それ自体がコードの臭いになり得るからです。抽象の利点を得られるほどコードが複雑でない場合もあるでしょう。

InfoQ: 講演ではリファクタリングの実践について話し、デモを行いましたね。コードのリファクタリング方法について例を教えてください。

Koundi: とても協力でシンプルなリファクタリング方法は下記です。

• メソッドの抽出: 多くの処理をしている関数があったとして、コードを読みやすくしたい場合、段階的に処理を分けてそれぞれをひとつのメソッドに切り出し、振る舞いに応じた名前をつけます。

• メソッドのリネーム: 表現力のないコードを扱うのは難しいです。例えば、メソッドを見つけて理解するのに10分以上かかる場合です。より適切な説明が見つかったらメソッドの名前を変えます。ただし、公開APIではない前提です。

デモで示した通り、リファクタリングの知識と同じくらいツールが重要です。開発環境を知ることによってリファクタリングがとても簡単に安全に素早くできるようになります。リファクタリングの方法の助けになるリソースはたくさんあります。Matthew Buttはリファクタリングのスクリーンキャストで小さなステップでコードをリファクタリングする方法を示しています。

InfoQ: コードを壊さないために開発者ができることを教えてください。

Koundi: リファクタリングを始める前に次のことを確認してください。

• リファクタリングによってシステムの残りの部分に影響がないこと。これはテストで担保します。

• 対象のコードの使い方について明確なドキュメントがあること。テストによってドキュメントを作ります。

• リファクタリングをした部分がおかしくなっていないこと。これもテストの仕事です。

リファクタリングをする前にテストがあるようにしておきます。

InfoQ: リファクタリングするべきとき、しないほうがよいときについて教えてください。

Koundi: リファクタリングはテストを書くことと同様、機能実装の一部分です。単独の作業ではありません。今までは準備できていなかったコードの変更の準備をしたいときにリファクタリングをします。リファクタリングはテスト駆動開発の工程のひとつです。

コードレビューもリファクタリング実施の良いきっかけです。

一方、コードベース全体に価値の乏しいリファクタリングをして"完璧なコード"を目指すのは金めっきと呼ばれます。これはコードをきれいにするのに有害です。リファクタリングのためのリファクタリングによって本当のリファクタリングのニーズを希薄にしてしまうのです。コードが問題なく動いており、変更する必要がないなら触らないほうがいいでしょう。

InfoQ: リファクタリングがもたらす利点とはなんでしょうか。

Koundi: リファクタリングの背景にあるアイディアは、よりきれいなコードに向かう、ということです。これが意味するところは、理解しやすく変更コストが低いコードを目指すということです。