TDD(テスト駆動開発)で野球上達(1)

技術責任者のM.S.です。
技術っぽいことと野球について主に書いていく予定です。

当面、TDD(テスト駆動開発)で行う野球の練習方法について書いていきます。

ちなみに、TDDとはテストコードを書きつつ開発を行い、開発が完了した時点でテストがすべてOKになるように実コード(ここでは成果物となるコードを示します)を書いていくという手法です。

通常は設計⇒開発⇒テストという順でプロジェクトが進んでいくと思いますが、開発が終わってさあテスト実施という段階で設計もれや設計と実コードの齟齬に初めて気づくことも多いかと思います。もちろん、開発中にこんなインプットはあり得ないとか、こんなアプトプットは出力できないとかの使用考慮漏れに気づくことも。

TDDでは、開発と同時に実際にテストコードでテストを行う(厳密にはテストコード作成⇒実コード作成のサイクルを繰り返す)ことで、よくある「設計⇒コードの間で起きてしまう仕様の齟齬、考慮漏れ」などを開発しながらつぶしてしまうことができます。

詳しくはまた別の機会に書きますが、この手法ではテストコードを作りつつ本コードを作っていくため、テストに必要なアウトプットとインプットを開発する前に具体的に決めてしまうもしくは、開発中に考えながら作業を進めていく必要があります。その為、TDDによる開発を経験すると、「どういう処理か」よりも「どういうインプットに対してどういうアウトプットがあるか」を重点的に考えるようになってきます。

長々と説明しましたが、今回野球に取り入れようというのはTDDの「処理内容ではなく、インプット、アウトプットに重点を置き、テストを繰り返しつつ開発を行う」という考え方になります。

というわけで、第1弾は「バッティング」です。
※おそらく複数回に分けることになります。

「バッティング」に関しては、上からたたけとか、体を開かないとか、最短距離で打つとか、なんとかetcもっともらしい指導がいろいろあります。なので、バッティングをよくしようとしたとき、これらの断片的な(しかも正しいかどうかも不明)理論や、その他自分の感覚などをもとにフォームを作っていき、打って試してみる。

これが、設計(ヒットを打つ、ボールを打つ)⇒開発(スイングしてみて色々と微調整する)⇒テスト・本番(実際に打つ)という感じの通常の開発フローに則った練習方法と言えます。

では、TDD的な練習方法とはどんなものか?
・・・と続けたいところですが、だいぶ長くなりましたので、これについては次回に。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)