リファクタリングによってコードが単純になるのはなぜですか？

先週は、戻り値が一貫しているメソッドについて取り上げ、それがコードをシンプルにすることを紹介しました。しかし、そもそもなぜ適切なリファクタリングを行うとコードが扱いやすくなるのでしょうか？ 良い抽象化と悪い抽象化の違いはどこにあるのでしょうか？ 闇雲にコードを並べ替えるだけで、質の高いソフトウェアが生まれるわけではありません。

こうしたテクニックがなぜ機能するのかを理解できれば、コードのどこに手を加えるべきかが見えてきます。そして、最も効果を発揮する場所で、適切なツールを使えるようになるのです。

ソフトウェア開発における最も難しい問題とは？

「コンピュータサイエンスにおける難しい問題は2つだけある。キャッシュ無効化と命名だ。」

– フィル・カールトン（Phil Karlton）

確かに、この名言はあちこちで目にします。しかし、実務のソフトウェア開発には、それよりもさらに難しい問題があります。それは「複雑性の管理」です。

ソフトウェア開発における複雑性にはいくつかの定義がありますが、その本質はこうです。「プログラムの複雑さとは、そのコードに取り組んでいる間、頭の中に入れておかなければならない情報の量である」ということです。

ソフトウェアを書く経験を積むほど、一度に頭に入れておける情報量は増えていきます。それでも、どんなに優れた開発者にも限界はあります。プロジェクトが複雑すぎると、脳の処理能力を超えてしまい、プログラムのさまざまな部分について忘れ始めます。そして最悪のバグは、プロジェクトのある部分を変更した際に、その変更が同じプロジェクトのまったく別の部分へどう影響するかに気づかずに発生するのです。

「前提」によって単純化する

もし完全記憶能力があって、プログラムのすべての部分がどう組み合わさっているかを覚えていられるなら、バグはずっと減るでしょう。ただ、記憶力を鍛えるのは簡単ではありません。しかし「一度に一つのことに集中できる」という状態だけでも、同じようなメリットの多くを得られるのです。

ソフトウェア開発における多くのベストプラクティスは、同時に頭に入れておくべき事柄の数を減らすことを目的としています。いくつか例を挙げましょう。

• 戻り値の一貫性： 扱うべきデータの種類が一つに絞られるため、状況ごとに異なるデータ形式への対応を考える必要がなくなります。

• 抽象化： コードを、よりシンプルなインターフェースの背後に隠す手法です。良い抽象化があれば、その抽象化が「どう振る舞うべきか」だけを考えればよく、内部でどう動いているかを気にする必要がありません。

• テスト： ある領域のコードに取り組んでいる間に、別の領域のコードを誤って壊してしまうのを防ぎます。「うっかり壊したものはテストが検出してくれる」という前提で作業できるため、目の前のコードだけに集中でき、壊れた箇所は後から修正すればよくなります。

• テスト駆動開発（TDD）： 期待どおりに動作するコードを書く助けになります。テストを通過する最もシンプルな実装に集中して書けば、仮に単純すぎて期待どおりに動かなかったとしても、テストがそれを検出してくれます。

これらのテクニックを正しく使えば、有益な「前提」を置けるようになります。その結果、頭に入れておくべき情報量は大幅に減り、コードがシステム全体に及ぼしうる膨大な影響をいちいち心配せずに済みます。だからこそ、より良く、より信頼性の高いコードを書けるのです。

一方で、これらのテクニックを間違った場所で使うと、本来見えているべきコードを隠してしまうことになります。隠されたコードがあると、置いた前提がときに裏切られます。すると、かえってコードを壊してしまう可能性が高まってしまうのです。

だからこそ、悪い抽象化は抽象化なしよりも有害であり、「メソッド抽出」を繰り返し適用すればコードが魔法のように良くなる、ということもありません。

適切なリファクタリングを、適切な場所で

明快なコードとは、自分が何をしているのかを率直に示すコードです。「知っておくべきことを見せることは、知らなくてよいことを隠すことと同じくらい重要です。」

リファクタリングを行ったり、ベストプラクティスを適用したりするときは、最終的にどんなコードになったか、そしてそれが複雑性の削減にどれだけ役立ったかを立ち止まって考えてみましょう。他のコードが安心して前提を置けるよう手助けになっていますか？ それとも、重要な知識を単純すぎるインターフェースの後ろに埋もれさせていませんか？ この視点を持つことが、質の高いリファクタリングへの第一歩です。