アジャイル開発者の習慣-acts_as_agile

第5回 設計を進化させる

この記事を読むのに必要な時間:およそ 6 分

プラクティス「リファクタリング」

リファクタリングはプログラムの外部から見た振る舞いを変えることなく,ソフトウェアの設計を改善していくことです。

リファクタリングでは,テストを実行させてコードを壊していないことを確認しながら一歩ずつ設計を変更していきます。

具体的なリファクタリングの手順は『リファクタリング』注11『パターン指向リファクタリング入門』注12を参照してください。

ちなみに『パターン指向リファクタリング入門』では,既存のコードにデザインパターンを適用させていく手法だけでなく,パターンから離れていく手法も扱っています。これは「進化は進歩ではない」とも呼応する考え方であり,興味深いです。

ここでは大規模なリファクタリングについてだけ簡単に補足しておきます。

注11)
『リファクタリング ― プログラムの体質改善テクニック』⁠Martin Fowler(著⁠⁠,児玉 公信/平澤 章/友野 晶夫/梅沢 真史(訳⁠⁠,ピアソン・エデュケーション)
注12)
『パターン指向リファクタリング入門』⁠Joshua Kerievsky(著⁠⁠,越智 典子(訳⁠⁠,小黒 直樹/村上 歴/高橋 一成(監訳⁠⁠,日経BP社)
大規模なリファクタリング

場合によっては,いくつものクラスが関わる大規模なリファクタリングが必要になることがあります。このときのポイントは「独断で一度に全部やってしまわないこと」です。

現行の設計から新しい設計への移行パスをチーム内で話し合い,一歩ずつ進めていくのが基本です。ホワイトボードなどを使って,設計の移行過程のイメージをチームで共有しておくことも大事です。

プロジェクトで作業していると時折,何もかも捨ててやりなおしたくなりますが,現在動作して価値を提供しているソフトウェアを大事にしてください(もちろん何事にも例外はあります⁠⁠。

プラクティス「継続的インテグレーション」

継続的インテグレーションは,自動化されたテストの実行を1日に何度も行うプラクティスです注13⁠。

問題を早期に発見するために,プロジェクトで正とされるリポジトリの最新版ソースコードに対するビルドとテストを定期的に実施します。⁠定期的」の頻度はさまざまですが,最低でも1日に1回,できれば数時間から数十分に1回は実施します。

継続的インテグレーションでは,テストケースがなければ問題が発生してもそのことがわかりませんし,リファクタリングによって変更が行われなければ,頻繁に実施してもありがたみはありません。ほかのプラクティスと組み合わせることで威力を発揮するものです。

今では継続的インテグレーションのためのツールはさまざまなプラットフォーム向けのものが提供されています。私の周囲ではJavaではContinuumHudsonRubyではCruiseControl.rb.NETではCruiseControl.NETに定評があります。

連載の第2回では継続的インテグレーションの考え方を開発プロセスに適用する方法を紹介しました。こちらも参考にしてください。

注13
Martin Fowlerの記事継続的インテグレーション⁠原文は2006年に大幅に改訂されており,翻訳は旧版に対するものです)

今回のまとめ

今回の内容を図3にまとめます。今回紹介した「進化的設計」は開発対象システムを変化に適応させるための習慣でした。ここで連載第3回で紹介したことを思い出してください。アジャイル開発は自己相似形なのです。

図3 今回のまとめ

図3 今回のまとめ

進化的設計で実践しているプラクティスは,プロジェクトの開発プロセスのスケールや,プロジェクトに参加する開発者個人個人のスケールにも応用できる面があるはずです。

みなさんの開発現場が変化に適応できるようになるきっかけになれば幸いです。また次回お目にかかりましょう。acts_as_agile!

テストコードのリファクタリング

プロジェクトが進むにつれて,だんだんテストコードの量も積み重なっていきます。進化的設計では,テストコードを安全ネットとして活用しつつプロダクトコードをリファクタリングすることで重複を排除し,名前を変更し,構造を整理します。

では,テストコードもプロダクトコードと同様にリファクタリングすべきでしょうか?

「プロとしてのしてのテストコード」

⁠達人プログラマー』注aは,良質なテストの特性として「プロとしてのテストコード」という考えを挙げています。⁠プロとしてのテストコード」とは「プロダクトコードと同じ作法で作成されるべき」というものです。つまり,達人プログラマーの意見は「テストコードもリファクタリングすべし」です。

故石井勝さんの意見

ところが,私が生前に石井勝さんから聞いたのは「テストコードは無条件にはリファクタリングすべきでない」という意見でした。

私の言葉で乱暴にまとめると,プロとしてのコードには,コードの重複の排除やリファクタリングは当然必要。けれどもテストコードに関しては,統一性や抽象化(テストコードの構造)と同じぐらい,さまざまな観点からの記述のしやすさや見通しのよさ(テストコードの流れ)が重要,という意見です。

テストコードリファクタリングの2つの側面

テストコードのリファクタリングは,テストコードが読みづらい/書きづらい場合に行いますが,ひとくちにリファクタリングといっても2つの側面があります。

  1. テストを読みやすく(書きやすく)するためにプロダクトコードをリファクタリングすることで,テストコードをリファクタリングする
  2. テストを読みやすく(書きやすく)するためにテストコード自身をリファクタリングする

1.は「テストしやすい設計が,良い設計」という指針に基づいた,テストコードを使った設計の検証というTDDアプローチの王道です。冒頭の達人プログラマーの意見はこれを支持しています。

2.は石井さんの意見で牽制されている「やり過ぎ注意」のリファクタリングです。統一性や抽象化も大事ですが,テストバリエーションの多様性や個々のテストケースの見通しのよさにも配慮しましょう。

『xUnit Test Patterns』

まとめると「バランスが肝心」ということになりますが,具体的にどうバランスをとるのかは一筋縄ではいきません。その証拠に,この話題だけを取り扱った『xUnit Test Patterns ム Refactoring Test Code』注bという書籍が出版されています。分厚い(800ページ以上あります)洋書ですが,まさに「プロとしてのテストコード」を考えるのにふさわしい一冊だと思います。みなさんも参考にしてください。

注a)
『達人プログラマー ム ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化』⁠David Thomas/Andrew Hunt/Mike Clark(著⁠⁠,長瀬 嘉秀(監訳⁠⁠,テクノロジックアート(訳⁠⁠,アスキー)p.229
注b)
『xUnit Test Patterns ム Refactoring Test Code』⁠Gerard Meszaros(著⁠⁠,Prentice Hall)

著者プロフィール

角谷信太郎(かくたにしんたろう)

(株)永和システムマネジメント,サービスプロバイディング事業部所属プログラマ。「『楽しさ』がシステム開発の生産性を左右する」と信じてRubyによるアジャイル開発を現場で実践するテスト駆動開発者。目標は達人プログラマ。好きな言語はRuby。好きなメソッドはextend。著書に『アジャイルな見積りと計画づくり』(共同翻訳),『JavaからRubyへ』(翻訳),『アジャイルプラクティス』(共同監訳),『インターフェイス指向設計』(監訳)。

URLhttp://kakutani.com/

著書