┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.104 2005/08/10
■ I N D E X
┃
┣【ＰＦ】価値と原則[8]
┣【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[6]
┗【アンケート】気になるシステム業界 ホントのところ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【ＰＦ】価値と原則[8]
前回に引き続き、プロジェクトファシリテーションの「価値(value)」を実現す
るための「原則(principle)」を1つ1つを示していきます。
●リズム
チームは、ある一定の頻度で集まったり、何かをアウトプットしたりします。
例えば、それは会議であったり、ソースコードチェックインであったり、顧客
へのリリースであったり、ふりかえりの時間であったり。 チームがある同期を
とるイベントを定期的に行なうタイミングを、どのように設計したらよいでしょ
うか？
週次、日次でイベントを予定しましょう。人間のリズム感覚は、カレンダーと
時計で作られます。例えば、朝会であれば、「毎朝10時から」という具合に決
めてしまいます。進捗会議や計画会議は、「毎週月曜日」と決めてしまいます。
プロジェクトが始まったら、ファシリテーターの重要な役割は、プロジェクト
チームのリズム刻む会議体のタイミングと目的を設計してしまうことです。プ
ロジェクトが軌道にのると、この会議がハートビートとなってプロジェクトを
ドライブします。リズムが行動の搬送波となり、プロジェクトは前にすすみま
す。人間が行動を起こすには、リズムが必要なのです。
●「問題対私たち」の構図(Problem vs. Us)
二人で問題についての話をしたり、あるいは複数人で話をしたりするときに、
本来は敵対関係ではないのに敵対してしまうことがあります。共通の問題を解
決しようとして集まったにもかかわらず、お互いのあら探しになってしった経
験はありませんか？ 複数の人が話をするとき、敵対関係にならずに問題解決と
いう本質的な議論にフォーカスするにはどうしたらよいでしょうか？
席の並べ方や、ミーティング時の各人の位置関係を工夫し、全員が同じ方向に
向くようにしましょう。そして、その視線の先に、ホワイトボードやコンピュー
タ、プロジェクタのスクリーンなど、いま解決しようとしている問題を置くよ
うにしましょう。
相対で座ると、どうしても「You vs. Me」や「You vs. Us」という対立関係を
象徴する構図がうまれます。座席を工夫し、同じ方向を向くようにします。そ
して、問題点(Problem)をホワイトボードなどの「第三者」に書き出し、それに
向かってみんなで話し合いをします。こうすることによって、「Problem vs.
Us」という構図を作り出し、全員で同じ問題を解決しようという姿勢を作り出
すのです。
http://www.ObjectClub.jp/ml-arch/magazine/magazine104/PvsU.JPG
この原則を使った実践には、ペアプログラミング、ペアボード、ソフトウェア
かんばん、などさまざまなものがあります。また、この手法は、席に限ったこ
とではありません。議論のテーマ(議題)の書き方一つをとっても、工夫してこ
の「Problem vs. Us」の構図を作ることができます。 （平鍋）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-14&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-14&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=M001-14&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】Rubyで進むオブジェクトの道 〜脱初心者をめざして〜[6]
●はじめに
今回は、前回の即席で作ったプログラムに残っている課題を、リファクタリン
グしながら解決していきたいと思います。
まず前回のおさらいをすると
・注文と明細から注文の合計を計算するプログラムを作っていた
・テストを素早く通すために注文クラスを新規に作らず配列で代替した
・注文の合計を特異メソッドで記述した
・配列と特異メソッドを使ったことによる設計上の課題が残った
です。以下に前回のプログラムを記します。
---<order_test.rb>------------------------------
require 'test/unit'
require 'order'
class OrderTest < Test::Unit::TestCase
def setup
@line_note = LineItem.new("note", 110, 3)
@line_pen = LineItem.new("pen", 50, 4)
@line_card = LineItem.new("card", 100, 5)
#注文オブジェクトを配列で代替
@order = []
@order << @line_note << @line_pen << @line_card
end
def test_total
#合計計算を特異メソッドで定義
def @order.total
self.inject(0){|sum, line_item| sum + line_item.sub_total }
end
assert_equal(1030, @order.total)
end
end
---<order.rb>-----------------------------------
#明細クラス
class LineItem
attr_accessor :name, :price, :quantity
def initialize(name, price, quantity)
@name = name
@price = price
@quantity = quantity
end
def sub_total
price * quantity
end
end
-------------------------------------------------
●残った課題
・注文オブジェクトを生成するのに,一般的すぎる配列クラスを使用
例えば、注文オブジェクトに新しく注文日のような属性を追加するのに配
列で実現するには、配列の0番目を注文日、1番目以降は注文明細といった
表現方法になり、理解が容易でないプログラムになってしまいます。
これはリファクタリングで紹介されている不吉な匂いの「基本データ型へ
の執着」の臭いがします。
・特異メソッドのみで合計の計算をするメソッドを定義
特異メソッドで合計の計算を定義する方法では、オブジェクトを生成後に
毎回合計の計算のメソッドを定義しなければ、合計のメソッドを利用でき
ません。これは「重複したコード」の臭いを感じます。
●リファクタリング
▲ステップ１ 配列から注文クラスへの変換
一般すぎる配列から、よりドメインに特化した注文クラスに変更することで上
の1つ目の課題を解消します。これは、リファクタリングで紹介されているオブ
ジェクトによる配列の置き換え」に該当します。
1．テスト側で注文オブジェクトの生成を配列から注文クラスに変更
---<order_test.rb>------------------------------
class OrderTest < Test::Unit::TestCase
def setup
・・・
# @order = []
@order = Order.new
------------------------------------------------
2. Orderクラスを定義
---<order.rb>-----------------------------------
# 注文クラス ↓↓ 追加 ↓↓
class Order
def initialize
@line_items = []
end
def << an_item
@line_items << an_item
end
def inject init
@line_items.inject(init){|sum, item| sum + item.sub_total }
end
end
#明細クラス
class LineItem
・・・
-------------------------------------------------
注文クラスには複数の明細を包含する構造になっています。テストで利用して
いる<<メソッドとinjectメソッドを注文クラスに定義しました。
これで、例えば、注文日や注文した顧客といった情報を注文に付加しやすい構
造となりました。
この時点で、テストを実行するとテストはパスします。
▲ステップ2 テストにある合計計算するメソッドをOrderクラスに移動
即席で書いた特異メソッドを注文クラスのインスタンスメソッドに移動してあ
げることで2番目の課題を解消します。
厳密には異なりますが、リファクタリングの「メソッドの移動」に該当します。
以下にリファクタリング後のプログラムを記します。差分がわかるよう
コメントを残しています。
---<order_test.rb>------------------------------
require 'test/unit'
require 'order'
class OrderTest < Test::Unit::TestCase
def setup
@line_note = LineItem.new("note", 110, 3)
@line_pen = LineItem.new("pen", 50, 4)
@line_card = LineItem.new("card", 100, 5)
@order = Order.new
@order << @line_note << @line_pen << @line_card
end
def test_sub_total
assert_equal(330, @line_note.sub_total)
end
def test_total
# def @order.total
# self.inject(0){|sum, line_item| sum + line_item.sub_total }
# end
assert_equal(1030, @order.total)
end
end
---<order.rb>-----------------------------------
class Order
@line_items
def initialize
@line_items = []
end
# def inject init
# @line_items.inject(init){|sum, item| sum + item.sub_total }
# end
# ↓↓ 追加 ↓↓
def total
@line_items.inject(0){|sum, item| sum + item.sub_total }
end
# ↑↑ 追加 ↑↑
def << a_item
@line_items << a_item
end
end
class LineItem
attr_accessor :name, :price, :quantity
def initialize(name, price, quantity)
@name = name
@price = price
@quantity = quantity
end
def sub_total
price * quantity
end
end
------------------------------------------------
この時点でテストを実行するとテストはパスします。
これで、オブジェクト生成後に毎回、合計の計算をするメソッドを定義しなく
て良くなりました。
●まとめ
前回、今回を通じてTDDとリファクタリングについて触れてみました。一度に良
いソフトウェアの構造と振る舞いを見つけようとするのではなく、コンピュー
タとの対話的作業によって段階的に導き出そうとしていることを記事で読み取っ
ていただければ幸いです。
次回は、このサンプルを使って、Mixinについて触れ、Rubyらしいプログラムを
書いてみたいと思います。（IENAGA）
======== 『幸福の王子本』をメルマガ読者に プレゼントします！ =========
【オブジェクト倶楽部：2005-27号】でお知らせしましたが、オーム社さんより
読者プレゼントとして『dRubyによる分散・Webプログラミング』をいただきま
した！ http://www.objectclub.jp/ml-arch/magazine/108.html
まだ若干プレゼントできます。プレゼントご希望の方は、お名前、ご住所、電
話番号、「この書籍への想い」をお書きの上、editors@ObjectClub.jp までご
連絡ください。 ※いただいた情報は、書籍の郵送にのみに使用いたします。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-5&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-5&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=E006-5&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「夏好きですか？」のホントのところ。8月ですね、夏真っ盛りですね。
システム業界だと、会社の中にこもることが多くって、日常で夏を感じること
は少ないのかもしれませんが、みなさん夏ってお好きですか？
大好きです。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=0
どちらかと言えば好きです。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=1
好きでも嫌いでもないです。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=2
どちらかと言えば嫌いです。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=3
大嫌いです。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=4
好きな季節がありません。。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=5
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=70&choice=6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「ペアプロしたいですか？」の結果は公開中。是非ご覧下さい。
⇒http://www.objectclub.jp/special/kininaru/vol69/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。立秋を迎えましたね。暦の上では秋ですが、まだま
だ暑い日は続きそうです。
秋来ぬと目にはさやかに見えねども 風の音にぞおどろかれぬる
藤原敏行のうたです。忙しい日常の合間にも、ふと立ち止まってみてはいかが
でしょう。風の音を感じ取れるかもしれません。なお、来週のメールマガジン
は、風の音を感じるべく、お盆休みとさせていただきます。
今週の強引な一言
*** 艱難汝を玉にす（ことわざ）***
問題の解決を誰かに任せっぱなしにしていませんか。その問題を解決してこそ、
新たな問題に取り組める足腰が鍛えられるのです。せめて、仲間と一緒に問題
に取り組んでみては如何でしょう。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2005 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.