Advanced Ruby：RubyUnit (Testing Framework) Part 1 : XP をはじめよう 2000/11/30 石井 勝 XP (eXtreme Programming) とは ソフトウェア開発方法論の一つ Ward Cunningham, Kent Beck, Ron Jeffries ここ数年もっとも注目されている方法論 向いている分野 小人数（2人から10人程度）による小規模開発 仕様が不確定で変更が絶えないプロジェクト 「極端プログラミング」 開発を成功に導く要素を極端なレベルまで引き上げよう 2 XP (eXtreme Programming) とは 「もし，X が開発にとっていいことなら， その X を最大限にまで引き上げよう」 コードレビューがいいのなら，いつもコードレビューしよう ペアプログラミング いつも 2人でコーディングを行う開発スタイル テストするのがいいんだったら，いつもテストしよう Unit Test，Acceptance Test コードを修正するたびに行う単体テスト 顧客がシステムを承認するために行う テスト 3 Embrace Change - 変更を受け入れよ う 「将来の仕様変更を予想し，それに柔軟に対応できるような設 計にしよう」 → 本当に正しい？ 将来の仕様変更を予測することはできない 柔軟性をもたせるのは，コストがかかる 必要以上に柔軟性をもたせれば，設計が複雑になる 4 Embrace Change - 変更を受け入れよ う 変更コストカーブ 仕様変更に対するコストが開発プロセスが進むにつれてどれぐらい 変わっていくかを表したグラフ 従来の開発 こんな開発があったら？ 指数関数的に増大 開発の後段階になっても低コスト 5 Embrace Change - 変更を受け入れよ う XP の前提条件 「XP は変更コストカーブがそれほど増えない開発である」 そのときの仕様でもっとも簡単な設計にするのがベスト 仕様変更があったときに初めて修正する You‘re not gonna need it! (YAGNI) 「将来必要になると思って早めにその機能を追加するな」 これまでの常識に最も反する XP のルール 変更コストカーブがそれほど増えないことが前提であることに注意！ 6 XP の4つのものさし プロジェクト成功のカギを握る4つの「ものさし」 Communication Simplicity Feedback Courage 以上の4つを追求し改善していくことが XP 開発者に求められる XP とは 「Communication, Simplicity, Feedback, Courage の4つのものさ し」 「それらを高めるための小さなルールと習慣」 7 XP の4つのものさし Communication XP は，人と人とのコミュニケーションを特に重視 顧客と開発者とのコミュニケーション 開発文書を重視しない Planning Game • 顧客と開発者による開発計画とスケジュールを決めるミーティング 開発者間のコミュニケーション ペアプログラミング • 開発者間のコミュニケーションを促進する習慣 8 XP の4つのものさし Simplicity XP は，Simplicity - 簡単であることを重視 Do the simplest thing that could possibly work • 今の仕様を満たす最も簡単な設計にする You're not gonna need it ! • 将来の仕様変更にそなえて今の設計を複雑にするな Feedback XP では絶えず Feedback によって開発を進めていく 追加・修正をできるかぎり小さなステップで行う ステップが終わるごとにテストで検証 テストを重視し，テストを頻繁に行う 9 XP の4つのものさし Courage 勇気，失敗を恐れないこと - 4つの中でもっとも重要 勇気は信頼があればこそ生まれてくる 顧客との信頼関係 • 開発方針の大きな変更が可能 テストコードによって支えられているシステム • 設計の大幅な見なおしやリファクタリングが可能 10 ペアプログラミング 一つのモニタに向かって 2人がかりで作業を行う 少なくとも毎日，できれば日に1，2回ペアを入れかえる ４つのものさしの観点からみたメリット Communication 開発メンバのコミュニケーションがかなり向上する 各メンバは開発のほとんどの部分を知ることになる 開発方針の重要な決定は開発メンバ全体にすぐに広まる メンバが間違いをする可能性はかなり減る 11 ペアプログラミング ４つのものさしの観点からみたメリット（つづき） Simplicity 絶えずパートナーにコードの説明を行いながら開発 相手に説明できないような複雑なコードは，自然になくなる Feedback 常にパートナーがコードレビューを行う 細かいミスやおかしなコードは，パートナーによって指摘される Courage 2人で作業を行うことで困難に立ち向かえる イヤな仕事も安心してできる 12 ペアプログラミングの問題点とアドバイス 開発コストが2倍に増える？ ペアプログラミングの生産性 Laurie Williams さんによる研究 http://www.pairprogramming.com/ 単純に2倍になるわけではない • 最初は単独のプログラミングを行うケースと比べて 1.5倍の人月が かかるが，すぐに 15% 増しぐらいに落ち着く • バグの生産性は15% 程度低くなる バグの発生が減るため，変更コストカーブの増大が激しいプロジェク トほど，トータルでコストが減る コストだけでなく他のメリットも大きい 13 ペアプログラミングの問題点とアドバイス 能力主義・成果主義と合わない？ 開発者全員がシステム全体にかかわることになる 誰がどの機能を担当し，どれだけの仕事をした，ということが あいまいになる 開発者同士では，お互いの長所と短所をよく理解できる プロジェクトリーダーや開発者同士が評価していくのであれば，より正当 な評価ができるようになるかも ペアを組みたがらないプログラマ 数ヶ月後には，ほとんどの人がペアプログラミングを好むようになる 生産性が少し下がっても，何ヶ月かやってみよう それでもダメなら → あなたは XP に向いてません(T_T) 14 ペアプログラミングの問題点とアドバイス 結構疲れる 一日中パートナーに説明したり，レビューするのは結構つらい 疲れててもこっそり仕事をサボることができなくなる 慣れるまでは，強制的に休憩時間を入れよう 何ヶ月かすると，最初ほど疲れることはなくなる ペアプロ太り お菓子を食べながら楽しくペアプログラミング いつも開発メンバがお菓子を買ってくるようになった 何ヶ月も続くと本当に太ってくるのでほどほどに 15 Unit Test 開発コードの他にテストコードを大量に書く 開発コードよりもテストコードの方がコード量が多くなる Testing Framework (RubyUnit, JUnit) を使う テストコードを書いて簡単に実行するためのフレームワーク テストにはセルフチェック機能をつける テストをパスしたかどうかテストコード自身が判断 テストはいつも100点満点 テストを通らない開発コードをそのままにしておかない Test First Programming テストコードを先に書き，後から開発コードを書く 16 Unit Test ４つのものさしの観点からみたメリット Communication テストコードはクラスの使い方を表した仕様書 パートナーへの説明はテストコードを見せることから 100% パスする状態に保たれている→完全に正しい仕様 境界条件や例外処理などの仕様もテストコードで表せる Simplicity 実装前にクラスがどういう使われ方をするかをテストコード で表す（Test First Programming)． クラスの詳細ではなくインターフェイスに注目することになり， きれいで使いやすいクラス設計になる 強制的にテスト可能なコードになる 17 Unit Test ４つのものさしの観点からみたメリット（つづき） Feedback 非常に短いサイクルで，少しコードを書いてはテスト実行 test a little, code a little, ... のリズム バグの発見が非常に速い Courage システムが大量のテストコードによって守られている コードの信頼性がはるかに増す 開発の後段階になっても思い切ったリファクタリングが可能 18 Unit Test の問題点とアドバイス プログラマはテストを書くのが好きになる？ テストを書くのはかなりの労力が必要 ペアプログラミングでテストを書くのを乗りきろう 楽しいのはリファクタリングで無駄なコードを一気に消すこと Unit Test だけでは不十分 テストコードを過信するのは禁物 全体を通したテストが必要 → Acceptance Test で補充 できれば Acceptance Test も自動化しよう 19 Unit Test の問題点とアドバイス トートロジーになってしまったテスト テストコードと実装コードが同じになってしまうことがよくある テストコードを凝りすぎないように 例） 検索条件を指定して SQL 文を出力する Query クラス SQL 文の文字列比較をするテストコードを書くと… テストコード側にも SQL 文の答えを用意する必要がある 結局テストコードと実装コードが同じになってしまう クラス設計を変えてみよう Query が Result オブジェクトを生成する，という仕様にする テストコードは Result オブジェクトの中身を検証 20 Unit Test の問題点とアドバイス テストのための戦略を練ろう トップダウンでテストコードを書き始めるのは難しい パスしないテストが増えていく スタブが必要 CRCカードセッションでクラス設計 ある程度クラス構成が決まったら，ボトムアップでテストコードを 書いていく 21 XP をはじめよう 最も重要な顧客とのコミュニケーション XP は，もともと顧客指向・顧客参加型の開発方法論 短い繰り返し開発によって顧客がプロジェクトの舵をとる 顧客とのコミュニケーションをよくするルール XP の実践項目の中では最難関（ほとんど無理？） On-Site Customer • 開発チームにフルタイムで質問に答えてくれる顧客を迎える Planning Game • 顧客と開発者による開発計画とスケジュールを決めるミーティング 顧客まきこむ部分の XP の実践は難しい → まずは開発サイドから XP を導入していこう 22 XP ミニマムセット XP の中でもっとも実践しやすいルールは？ ペアプログラミング Unit Test 最小限の人数は？ 2人で一日中ペアプロを行うのはつらい 3人では余った一人の作業分担が難しい 4人ぐらいが最適 XP ミニマムセットからはじめよう 4人程度の開発メンバー ペアプログラミング Unit Test 23 XP ミニマムセットの問題点 完全な XP ではない これだけでもシステムの品質と信頼性は格段に上がるが… 顧客サイドの部分は欠落していることに注意！ 顧客とのインターフェイスは従来通りに 顧客との関係を XP 流に行うと顧客からの信頼を失うかも 仕様書など開発文書は従来通りきっちり納品しよう 開発者間の正式な文書はいらない（ソースコード＝開発文書） 変更を受け入れてよいか？ Planning Game を行わないということは… 従来の開発と同じく顧客からの仕様変更に弱い 下手に受け入れると，開発コストがどんどん増えていく危険性が 24 周りの人を説得しよう 上司の説得 いやでもバレるペアプログラミング 開発コストが 2倍になるという誤解を解こう Laurie Williams さんの研究結果を引き合いに ペアプログラミングのほかのメリットも強調しよう 開発サイクルのテストフェーズに行く前に多くのバグがなくなる プログラム設計がよくなり，コード量も減る 2人で考えることによって問題解決が早くなる 開発メンバの教育コストが減る すべての開発メンバがプロジェクト全体を見渡すことになる 25 周りの人を説得しよう （ペアプログラミングのメリットのつづき） 開発知識が自然に広がるため，プロジェクトの管理コストが減る メンバ入れ替えや補充を行ってもリスクが少ない ペアプログラミングは楽しい→退職者が減るかも メンバへの説明 XP について一通り説明 XP は開発者のスキルをそれほど要求しない 開発者間のコミュニケーションがアップするということは… 自分の長所をもっと発揮できる可能性が広がる 各メンバの知識を共有できるのは素晴らしい 全部一人で勉強して開発するのは馬鹿らしい 26 最初は Testing Framework の使い方から ペアプログラミングには慣らし期間が必要 最初はTesting Framework の勉強をペアプログラミングで行おう 開発者全員が Unit Test を書けるように 題材は？ RubyUnit 本（256本 ＸＸ編）が発売予定 JUnit なら William Wake さんのチュートリアル The Test/Code Cycle in XP: Part 1, Model • http://users.vnet.net/wwake/xp/xp0002/index.shtml The Test/Code Cycle in XP: Part 2, GUI • http://users.vnet.net/wwake/xp/xp0001/index.shtml 27 Test First Programming の習慣をつけよう テストコードを先に書く習慣をつけよう Testing Framework の使い方自体は難しくないが… テストコードを書くのはとても難しい 動いているコードに新しくテストコードをおこすのは面倒 先に書かないとテストを書かなくなる，または甘くなる Unit Test を書く手順 1. テストクラスを作ろう これから作るクラスのテストクラスをTesting Framework で書く 28 Test First Programming の習慣をつけよう Unit Test を書く手順（つづき） 2. クラスのラフスケッチを書こう クラスを頭の中でイメージ それをそのままテストクラスのテストメソッドに書く • まず オブジェクトを new して • これこれこういうメソッドを呼べば • こういう結果になるはずだ 最初は，正常動作の単純なコードのみでよい 3. コンパイルが通る程度に実装し，テストコード実行 ラフスケッチで書いたクラスとメソッドの宣言のみ 中身を書いてはいけない テストがちゃんと失敗するかどうか確認（テストのテスト） 29 Test First Programming の習慣をつけよう Unit Test を書く手順（つづき） 4. とりあえずテストが通るようにしよう コードが汚くてもかまわない 例外処理など余計な機能は後回しに 5. リファクタリングしよう もっとわかりやすいメソッド名はないか？ もっと単純に書けないか？ パートナーと相談しよう 6. テストを強化しよう 境界条件，例外処理のテストを書く テストを書いてはコードを修正，リファクタリング 30 Test First Programming の習慣をつけよう Unit Test を書く手順（つづき） 7. 新しいメソッドのラフスケッチを書こう 新しいメソッドに対してテストコードを追加 3番目から 6番目の項目を繰り返す 31 ペアの割り当て 毎朝ペアアップミーティングをしよう 進捗を聞いてペアと担当作業を決める ペア両方の人が不得意な作業を割り当てないように 頻繁にペアを入れ替えよう 毎日，できることなら一日に 2回ペアを入れ替え 開発知識が特定の人に偏らないように 開発が進めば単純にローテーションを組めばよい 32 ペアの割り当て パートナーがいないときは XP では，すべてのコードをペアで組むことになっているが… 現実には無理 なるべく簡単な仕事を割り当てるようにする テストコードに不備があったり，品質が落ちることを覚悟しよう 最初はペアでやるように指導しよう 初めのうちはなかなかペアで作業しようとしない 自分の席で個別に作業，その後ペアでレビューということをしてしまう 最初の一ヶ月ぐらいは，ペアで作業するよう指導する しばらくすると，自然にペアで作業するようになる 33 CRCカードセッション CRCカードセッションでクラス設計 Test First でいきなりテストコードから書き始めることはできない ある程度クラス設計をしておき，ボトムアップで開発していく CRCカードとは 文具屋さんで情報カードを買ってこよう（5×3のサイズが適当） CRCカードの一枚が一つのクラスを表す 一枚のカードに， クラス名 (Class) クラスの役割 (Responsibility) 協調するクラス (Collaborator) を書く 34 CRCカードセッション CRCカードセッションのやり方 規模が大きな場合は開発者全員，小さい場合はペアで行う 次の手順でカードに書きこむ 1. クラスの候補を洗い出し，カードにクラス名を書きこむ 2. ある機能についてシナリオを用意する 3. シナリオを実行し，どのクラスがどの役割を担当するか考える 4. クラスの役割をカードの左側に書く 5. そのとき必要となるクラスを右側に書く 6. 必要な場合は，新しいカードを追加して新しいクラスを作る 7. さらに別のシナリオを実行してCRCカードを洗練させていく 必要に応じて，カードの裏にメモを書いてもOK 35 CRCカードセッション CRCカードでロールプレイングゲーム オブジェクト指向初心者が多いチームに 参加者に CRCカードを配り，配られた人がそのクラス担当 シナリオを実行しながらロールプレイング CRCカードで見積もり XP では本来ストーリカードやタスクカードで見積もるが… CRC カードで見積もりも可能 カードに何ペア日でできるか予想し，後から実工数を書きこむ 正確な見積もりができるようにスキルを上げよう 36 さらに XP のルールを取り入れよう Collective Code Ownership 開発者の誰もがどのソースを修正してもよい ペアプログラミングを行うと所有権の感覚がなくなってくる CVS などのバージョン管理ツールを使いながら実践しよう Coding Standard みんなでコーディングルールを決め，守るようにする クラス名やメソッド名のつけ方，タブの文字数，括弧の位置など 参考文献 Smalltalk Best Practice Patterns (Kent Beck) Essential Java Style (Jeff Langr) 37 Ruby と XP XP との親和性は高い 基本思想は同じ － 「楽しいプログラミング」 ペアプログラミングでより楽しいプログラミングに テストとコーディングのサイクルがよりスムーズに RubyUnit は使いやすい Ruby による大規模開発に向けて Unit Test で静的型付け言語の優位性がなくなってくる これからは動的型付け言語が主流に？ Ruby は言語仕様として大規模な開発にも向いている 「Ruby でも XP を実践しよう！」 38
© Copyright 2024 ExpyDoc
