この国では犬が

本と芝居とソフトウェア

トップ > ソフトウェア > シンプルに実装することと、実装をシンプルにすること（シンプリシティについての断章）

シンプルに実装することと、実装をシンプルにすること（シンプリシティについての断章）

ソフトウェア

XP の 5 つの価値のうちの 1 つに「シンプリシティ（シンプルさ）」があります。

このシンプリシティについて、気づいたことがあるので記します。要点は以下の 2 つです。

  • XP での開発におけるシンプリシティの実現には、「シンプルに実装すること」と「実装をシンプルにすること」という 2 つの側面がある
  • XP での開発において、シンプルに実装することと、実装をシンプルにすることは車の両輪

シンプルに実装すること

XP での開発におけるシンプリシティの第一の側面は、シンプルに実装すること（implement simply）です。

今取り組んでいる目の前のストーリーの実現にあたって、「もっともシンプルで、うまくいきそうな設計・実装」だけをする。

その判断のために役に立つ原則（経験則）もあります。以下のものです。

  • すべてのテストをパスする。
  • コードの重複がない。
  • すべてのコードについて、プログラマの意図を明確に表現している。
  • 最小限のクラスとメソッドを備えている。

この原則にのっとって、「もっともシンプルで、うまくいきそうな設計・実装」を判断し、それ以上のことをしたくなる誘惑に負けないように、自分を厳しく律します。

これが「シンプルに実装すること」です。

実装をシンプルにすること

XP での開発におけるシンプリシティのもう一つの側面が、実装をシンプルにすること（simplify implementation）です。

いわゆるリファクタリングですね。

XP では継続的にリファクタリングを行いますが、中でも特にリファクタリングに適したタイミングが 2 つあります。以下の 2 つです。

  • テストファーストで書いたユニットテストがパスしたとき。（レッドからグリーンになったとき）
  • 新たな機能の実装に取り掛かるために、既存のコードを訪れたとき。

どちらも重要ですが、特に 2 つめの機会について意識的であることが重要だと思います。
というのは、1 つめの機会については「レッド→グリーン→リファクター」というフレーズがよく知られており、比較的見落としにくいと思いますが、2 つめの機会については 1 つめに比べるとあまり語られることがないように思えるからです。

2 つめの機会では、前回このコードを訪れたときに十分「シンプルに実装」していたとしても、その実装をさらにシンプルにできる可能性があります。
それは、前回と今回では、前掲の原則にも出てきた「プログラマの意図」が異なるからです。前回は、前回実装しようとしていた機能が「プログラマの意図」でした。今回は、「前回実装しようとしていた機能だけでなく、今まさに実装している機能も加わったとき、それは何なのか？」というのが「プログラマの意図」ということになります。

これが「実装をシンプルにすること」です。

シンプルに実装することと、実装をシンプルにすることは車の両輪

そして、ここがこの記事の核心なのですが、シンプルに実装することと、実装をシンプルにすることは車の両輪だと思います。つまり、どちらか片方だけではバランスを崩し、うまく走ることが難しくなります。

「シンプルに実装すること」は、「実装をシンプルにすること」に依存しています。より正確に言うと、今「シンプルに実装」しようとしている人（便宜的に Alice と呼びます）が、のちに前述の「リファクタリングの 2 つめの機会」に触れる人（便宜的に Bob と呼びます）が「実装をシンプルにしてくれる」に違いない、と信じることに依存しています。

なぜなら、「Bob が（のちの機会に）実装をシンプルにしてくれるに違いない」と信じられなければ、Alice はあらかじめ「Bob が実装に取り掛かるタイミングになったとしても、十分シンプルであり続けられるであろう設計・実装」を想定して作り込みたくなってしまうからです。結果として、「シンプルに実装」することはかなわなくなります。

ひるがえって、「実装をシンプルにすること」もまた、「シンプルに実装すること」に依存しています。Alice が「シンプルに実装」してくれていればこそ、Bob は「実装をシンプルに」することができるからです。

もし Alice が「そのときにシンプルな実装ではなく、先々も十分シンプルであり続けられるであろうと考える設計・実装」をしていたとして、いざ Bob が実装しようとしたときには Alice の想定していたものとは違うものが必要になってしまっていたら、どうなるでしょう。Bob は、まず Alice の過去の想定を読み解き（直接聞いた方がよいとは思いますが）、現時点の最新の知識にもとづいて修正し、それから実装を（その時点での）シンプルなかたちにやり直す必要があります。それでも「実装をシンプルにする」こと自体は可能ではありますが、「Alice の作業がムダになる」「Bob が本来必要のなかった修正作業をするはめになる」という 2 つのムダが生じてしまいます。

だから、Alice は Bob を信じて常に「シンプルに実装」し、Bob は Alice が残してくれたシンプルさに報いるため、そして将来そのコードを触る人（それは Bob 自身かもしれないし、Alice かもしれないし、また別の誰かかもしれません）のために必ず「実装をシンプルに」するのです。そうすれば、車の両輪がバランスよく回り、XP による開発がもっともよい価値の流れを生み出すことができます。