STGつくろー！
その１ 「YAGNI（ヤグニ）の原則でいこう！」
① YAGNIとは？
STGを作るなどという大それた目標を掲げてしまいました。
掲げたからには、本腰と気合を入れて取り組まなければ！と思う反面、いったい何からてをつければいいのか皆目見当もつかないありさま･･･
「どうして見当がつかないんだろう･･･」
目の前に広がるプログラムの渦。流される私、そして滝が･･･
「滝･･･そうか！」
半ば強引に、理由がわかりました。そう、私はSTGを作ろうと気張るあまり「ウォーターフォール型」の設計を思い浮かべていたのです。
ウォーターフォール型の設計とは、分析・設計・実装・テスト・運用と滝が落ちるかのように製作工程を進めていく古典的なソフトウェア開発手法です。最初の「分析フェーズ」で実現したいソフトウェアに関するすべての事柄を将来の追加予定を含めて洗い出し、「設計フェーズ」でそれを膨大な設計図に起こし、「実装フェーズ」で設計図を元にプログラムを構築、「テストフェーズ」で徹底的なテストを行った後、「運用フェーズ」で実用段階のテストを行います。
この方法は最初の分析・設計フェーズで相当にしっかりと設計図を起こさないと、後々で「あ、失敗」と思っても後戻りが非常に難しい弱点を持っています。そもそも、そんな根性の入った設計図を一個人が完璧に作れる訳もありません。それをしようと思い浮かべるもんですから、目の前に渦なんぞ現れるのです。
「ではどうしたら･･･」
そこでぱっと光を当ててくれるのが「YAGNIの原則」です。
YAGNIとは「You Aren't Gonna to Need It.」の頭文字を並べたもので、「そんな機能は必要ないって」という意味です。この原則は、必要の無いものは設計に組み込まないという、ウォーターフォール型開発の真逆をいく開発手法です。
ウォーターフォール型では、将来に追加するかもしれない事を予測し、必要と思われる物をあらかじめ組み込みます。ところが、組み込んだ予測的な機能は、大にして使わないものなんです。プログラムを複雑にするだけで、いつしか忘れ去られる機能。そんなところからバグは発生したりします。
YAGNIの原則でいくと、プログラムは非常にシンプルになります。今必要だと思われるものだけを組み込むのですから当然です。「でも、それじゃ将来変更とかがあったらどうするの？」と心配してしまいますが、予測不可能な変更を心配していたら開発は進みません。そのために、「テスト主導型開発（Test Driven Development）」という開発手法も生まれています。変更があったときは、その時に考える。それよりも、シンプルな設計で前へ進もう！それがXP（エクストリームプログラミング）の根底に流れる考え方です。
「今回のSTGの開発はYAGNIで行くぞ！」
そう心に決めたのでした。
② 心がけたい開発精神
ここで、今回の開発で心がけたい開発の精神を列挙します。
・ YAGNI （You Aren't Gonna to Need It.）： そんな機能は必要ないさ！
～ 設計はシンプルに、怖がらずに前を向こう
・ TDD（Test Driven Development）： テスト主導型開発
～ テストから先に作る開発。高品質でバグの少ないソフトウェアの開発を目指す
・ 高頻度のリファクタリング
～ 機能を変更しないプログラムの最適化の検討を多くして、コードのシンプル化を
TDDについては、もう少し詳しく説明する必要があるかもしれません。通常、ソフトウェアはプログラムを作ってからテストを行います。ところが、TDDでは「テストプログラム」を先に作るのです。そして、クラスやその組み合わせが正しく働くかどうかをテストプログラムを積み上げながら開発して行きます。
この開発方法のメリットは、何と言っても「テストの自動化」にあります。これまでの開発手法では、クラスに何らかの変更を与えた時、改めてテスト計画を立て直していました。これは非常に時間のかかる作業です。また、工程が後ろになるほど、テストが複雑になります。一方TDDだと、新しく変更した部分については当然テストを行いますが、テストプログラムを先行して積み上げて作っているので、これまでの部分についてはそのプログラムを実行するだけで良いのです。もし、そのテストがオールグリーンならば、少なくとも変更は他に影響を与えないと判断できます。もしレッドシグナルが灯ったら、そこがグリーンなるように調整します。これにより、既存のソフトウェアに影響を与えない変更が保証されます。結局、開発スピードは常に安定し、また安心して先に進めるのです。
私は、このTDDでまだ大規模なプログラムを開発したことはありません。今回を、そのデビューにしたいと思います。