TDDでリファクタリングを行う適切なタイミングとは？［2ページ目］

[高梨] 今度は、「すべての投球で1本ずつ倒した場合」です。古谷さん、1つ目のテストパターン「すべての投球でガターを出し続けた場合」で作成したテストコードを参考にして、追加してみてください。
[古谷] えーと、こ、こんな感じでしょうか……？

（クリックで拡大）

[高梨] 大丈夫です！　結果もちゃんとRed（失敗）になっていますね♪
[古谷] そりゃあ今scoreメソッドはゼロしか返していませんから、Red（失敗）になるに決まっていますよ！　だから私が前回ちゃんと作ろうとしたのに！！
[高梨] テストケース追加時にまずRed（失敗）になるのは正しい流れですよ。インクリメンタルにいきましょう。それではいよいよ古谷さん待望の、「スコアの計算ロジック」を記述していきます。まずはインスタンス変数「@score」を定義して、引数で渡された点数をそこで集計するように、設計を進化させてみましょうか？
[古谷] あのー……　スペアやストライクのロジックはどうしますか？
[高梨] 今はまだ考えなくても大丈夫ですよ。そうだ、古谷さんは「YAGNI」という言葉を知っていますか？
[古谷] いえ、インドの神様の名前か何かですか？
[高梨] 確かにそれっぽい響きではありますが違います。「YAGNI」とは“You ain't gonna need it”を、短縮したものです。これは「機能は実際に必要となるまでは追加しないほうがよい」とする、TDDをはじめとするエクストリーム・プログラミングにおける基本的な考え方です。特徴として下記があげられます。

・「きっとあとで必要になるだろう」との予測で作ったものの90％は無駄になる。
・予測できない事態にともなう変更に対しては、設計を単純にすることで対処できるが、今必要とする以上の機能を追加すると設計が複雑になってしまう。
・必要のない機能を追加すると、あなたがその機能を実装するのに費やした時間以外にも、他のみんながそれを読むのに費やした時間、その機能がソースや仕様書、取扱い説明書等に占める領域すべてが無駄になってしまう。
・コードをすばやく実装するため・バグを減らすため、最適な方法は「あまりコードを書かないこと」である。

どうですか？理解できましたか？
[古谷] YAGNIの考え方自体はとてもよくわかりました。でも、今回に限って言えば、スペアもストライクも必要になるのもわかっていることでは……？
[高梨] それはそれとして、インクリメンタル設計とYAGNIがとても相性が良いことを理解していただけたのであれば結構ですので、コーディングに入ってください。あ、そうそうRubyには、Javaでいうコンストラクタと同じように、オブジェクトが作成される時に自動的に呼び出される「initialize」というメソッドがあります。今回はそれを定義してそこでインスタンス変数「@score」を初期化する処理を記述してくださいね。
[古谷] なんかすごい剛腕で話を戻された気がしますが、まあいいや……　こんな感じですか？

（クリックで拡大）

[高梨] 大丈夫です！　では次に進みましょう……　と言いたいところですが、そろそろこの辺でリファクタリングを行いましょうか？
[古谷] リファクタリングですか。具体的にどうやればいいでしょう？
[高梨] それでは、まずリファクタリングの定義を行いましょうか？一言でいえばリファクタリングとは「機能（ふるまい）を変えずに設計を改善する」ことです。
[古谷] それくらい私だって知っています！
[高梨] それはすみませんでした。それでは「ExtractMethod」というリファクタ手法は知っていますか？
[古谷] うっ、そ、それは知りません……
[高梨] ははは。とはいえ、現在リファクタリング自体に厳密な定義があるわけではありません。ただ、Martin Fowlerというアメリカで活動しているソフトウェア技術者によって、リファクタリングのパターンはある程度カタログ的に整理されています。今回はその中から「ExtractMethod（メソッドの抽出）」という、基本中の基本のリファクタ手法を使いましょう。
[古谷] はい！　あ、でもbowling_game.rbのコーディングはほとんど進んでいませんけど……
[高梨] TDDのリファクタリングでは、テストコードも対象になります。
[古谷] なるほど、了解です！　ちなみに、リファクタリングはどのタイミングで行ったらいいのですか？
[高梨] コード全体から「不吉なにおい」がしだした頃でしょうかね？

TDDでリファクタリングを行う適切なタイミングとは？［2ページ目］

この記事のキーワード：

この記事をシェアしてください

エンジニアのスキルを伸ばす“テスト駆動開発”を学んでみよう

ボウリングでスペアを取得した場合のテストケースを考える

バックナンバー

この記事の筆者

吉谷愛

フロイデ株式会社代表取締役

「最新のアーキテクチャを追及し続ける技術者集団」を目指す、フロイデ株式会社代表取締役社長。現在は、自身のCOBOLからRailsまでの非常に幅広い開発経験や、学生や未経験社員への技術指導経験を糧に、技術講師としてソフトウエアエンジニアの育成に注力している。2013年06月より、初心者向けの「はじめようRuby on Rails開発！」シリーズを考案。“技術者の立場にたった、技術者の心に火をつける”熱い講義をモットーとしている。

吉谷愛のプロフィールを見る

業界情報やナレッジが詰まったメルマガやソーシャルぜひご覧ください

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。