技術/リズム駆動開発(Rhythm-Driven-Development) (v1)

• [ Prev ]
• [ Next ]
• [ 技術 ]

半分ネタ、半分本気。

リズム駆動開発(Rhythm-Driven-Development)の目的

「リズム感」をソフトウェア開発に導入することにより、個々人のプログラマの生産性を向上させる。

実施方法

特に開発フェーズにおいて以下の３ステップをリズミカルに繰り返し、プログラマが快感と安心を得られるようにする。

1. コードを書く。
2. コードを実際に動かしてみて動作確認する。
3. コードを洗練する。(できれば設計も)

より具体的には、例えばテスト駆動開発(TDD)が挙げられる。
TDDの場合、上の「コードを実際に動かしてみて動作確認する。」部分にxUnitなどのテスティングフレームワークを導入することで、この３ステップをコード全体で素早く回せるようにしている。また、続く「コードを洗練する。」のフェーズでデグレ予防の効果もある。

なぜ「テスト」ではなく「動作確認」という表記なのか？

1. 品質保証(QA)での「テスト」という単語と明確に区別したいため。
2. プログラマにとって「よし！出来た！」と思える水準が「動作確認」であり、次の「洗練」フェーズへ進む為の条件。極めて主観的な基準点であることを明確にしたいため。

よくある誤解

RDDやTDDを導入すれば幸せになれる

銀の弾丸など存在しない。

xUnitの導入が必須

必須ではない。もちろんRDDの手法の一つ、TDDを活用すればxUnitによる自動化されたテストスイートが結果として出来上がるが、それは単なる副産物の一つである。重要なのは開発時にプログラマがリズミカルに開発に専念できることであり、それがxUnit以外の方法で達成出来るのであればそれでよい。「実際に動かして動作確認」→「洗練」のサイクルを、人間の手だけで素早く回せ、かつ洗練のフェーズでもデグレ防止で特別にxUnitによる自動化テスト一式が必要でなければ、それはそれでOK。

テストファースト/TDDでなければならない

上と同じ理由により、リズミカルにプログラミング・動作確認・洗練ができれば、テストファースト/TDDでなくとも良い。

何が何でもテストを書かねばならない

上と同じ理由により、テストを書かなくとも良い。テストコードを書くのはリズムを保つ為である。たとえばGUIのユーザインターフェイスであったり、並行/並列処理であったり、非同期処理であったり、入出力デバイスやネットワークとのインターフェイス部分などテストコードを書くのが難しい部分については、少なくともRDDにおいては、無理してテストコードを書く必要はない。重要なのはリズミカルな開発であり、そうしたテストコードを書くのが難しい部分で"嵌って"しまうのは本末転倒である、とRDDでは捉えている。

品質向上に寄与する

RDDは、極論すればプログラマが「ノリノリだぜ～ヒャーーーハハッ！！」状態で開発する為の技法なので、品質向上とは関係ない。慎重派のプログラマが「動作確認」のフェーズで、xUnitにより緻密なテストコードを構築して品質が向上する場合はあり得るが、そうでないプログラマが、例えxUnitによるテストコードを構築したとしても、正常系しかテストしていなかったり境界値分析やデータパターンのバリエーションが不十分であったりする場合も当然あり得る。特にテスト駆動開発を活用したRDDの場合、「テスト」という単語から品質向上/品質保証(QA)と関連があるのではとミスリードし易いが、基本的には無関係である。

RDDにおけるxUnitなどによるテストコードの存在意義、そして「快感」と「安心」

RDDではテストコードは必須ではない。なぜなら、必須としてしまうと、自動化テストが難しい部分までテストコードを書こうとして、却ってリズムを崩してしまいかねないからだ。

とはいえテストコードを書けそうな部分であれば可能な限り書いた方が良い。なぜなら「ノリノリだぜ～～ヒャーーーハハッ！！」状態で書いたコードにはバグも紛れ込み易いからである。

RDDでの「快感」

リズムを保つことで「ノリノリだぜ～～ヒャーーーハハッ！！」状態に。

RDDでの「安心」

テストコードを書き自動化テストを構築することで、特に「洗練」フェーズにおいて気持ちよくコード、さらには設計を洗練できるようにする。

自動化テストを活用する時に、絶対にやってはいけないこと

「xUnitのテストコードがあるんだから、Excelでぎっちり作り込んだテスト仕様書に従ってテストするなんて面倒くさくてやってられねぇよ！」

これは単なる思い上がりと怠慢である。
何度も繰り返すが、RDDにおいてはxUnitなどの自動化テストは品質保証とは関係ない。

Excelでぎっちり作り込んだテスト仕様書に基づいたテスト作業が、組織の開発プロセスに組み込まれているのであればそれに従った方が良いだろう。規模が大きくなるにつれそうした現場は増えてくるだろうが、同時にプログラマのレベルのばらつきも大きくなってくる。そうすると当然、テストコードの質のばらつきも大きくなる可能性が高い。
テストコード自体のレビューを頻繁に行い、境界値分析・異常系・データ入力パターンの過不足・コードの網羅率などを全体で改善できるのであれば品質向上にも寄与できる。
しかし、そこまでのマンパワーが無い場合は「RDDで構築した自動化テストはあくまでも開発者のもの」と割り切って、品質保証としてのテスト作業を謙虚に実施した方が良いかも知れない。

もちろんケース・バイ・ケースではあるので、組織によってはTDD導入の結果得られた自動化テスト一式を以て単体テストレベルを担保できるケースもあるだろう。

（以下、思いついた時に随時追記）

• [ Prev ]
• [ Next ]
• [ Up ]
• [ 技術 ]