┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.80 2005/02/09
■ I N D E X
┃
┣【Topics】モデリングコンテスト 盛り上がってます
┣【ＸＰ】継続的結合 再入門[3]
┣【コラム】まちぶせ
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 モデリングコンテスト 盛り上がってます
〇 〇━━━━━━━━━━━━━ ━━・
モデリングコンテストの話題と黒帯稽古の話題でいつになく盛り上がっている
モデリング道場からのお知らせです。現在すでに、メーリングリス上で公開し
ているものと応募していただいているもの合わせて、10件近くの作品が公開さ
れています。応募締め切りは来週月曜日です。まだ間に合います！
詳細はこちらです。
http://www.ObjectClub.jp/community/modeling/modeling_contest/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【ＸＰ】継続的結合 再入門[3]
■はじめに
ここ最近、街を歩くと風邪と花粉症のためか、マスクを着用している人が多い
気がします。ご多分にもれず私も先日風邪をひいてしまい、マスク(超立体)を
つけて歩く羽目になってしまいました。いつも感じるのは「予防をしっかりし
ておけば、風邪をひかなくて済んだかもしれないのに」ということです。ソフ
トウェア開発も、風邪のような「問題」が起きないようにする「予防」って必
要ですよね。継続的結合もソフトウェア開発の「予防」のひとつと言えるでしょ
う。
■今回の概要
前回は、手動結合と自動結合についての話と、それぞれのメリット/デメリット
について解説しました。今回は実際のプロジェクトに含まれる6つの変数と、変
数毎の結合指針について紹介します。
結合指針とは、前回までの連載で解説した通り、大きくわけて手動結合(マニュ
アルで実行される)と自動結合(なんらかのトリガーで自動的に実行される)の2
種類を指します。
■6つの変数と結合指針
ソフトウェア開発プロジェクトにはいくつもの変数がありますが、今回はその
中の6つに焦点をあててみました。これらの変数はプロジェクトごとに異なりま
す。ある変数に対する結合指針は、他の変数の結合指針と一致するとは限りま
せん。最終的には6つの変数の結果を踏まえた総合的な判断が求められます。
・ チーム人数
・ 開発スキル
・ コミット頻度
・ プログラミング体制
・ 規模
・ 作業場所
以降は個々の変数についての指針について個別に紹介していきます。
▲チーム人数
1つのチームの人数が少ない(〜8名)の場合には、フィードバックが速く、実行
も簡単な手動結合をお勧めします。手動結合のデメリットである待ち行列も、
少人数ならばそれほど発生することはありません。手動結合は開発のリズム(実
装→コミット→結合)を作り、全体を考慮する視点をも養います。
一方、大人数の場合はどうすべきでしょうか。手動結合も可能ではありますが、
結合の待ち行列が発生してしまうことが予想されます。結合を円滑にすすめる
ために自動結合を設定して実行することを検討すべきです。
逆に少なすぎる(1〜2人)の場合はどうでしょうか？そもそも１人では、常に結
合しているような状況になりますので、結合の意味がないと思われるかもしれ
ません。しかしワークスペース(=実際に開発している環境、ディレクトリ)での
結合と、リポジトリに格納されているリソースを使用した結合は結果が異なる
ことがあります(コミット忘れ、環境の相違など)。開発に使用しているワーク
スペースとは別のディレクトリにリポジトリから取得したリソースを展開して
行う結合(=クリーンビルド)を実施することをお勧めします。
▲開発スキル
チームメンバーの開発スキルを平均的に見た場合、レベルが低いと思われる場
合があります。そのような場合には、結合頻度を上げるために、手動結合、あ
るいは頻繁な自動結合をおすすめします。全体的にスキルの低いチームの場合
には、どうしても結合環境での失敗というケースが発生してしまいがちです。
開発当初から問題の早期発見を当見据えておく必要があります。一方、開発ス
キルが平均的に高い場合には、それほど頻繁な結合をせずとも開発が進むでしょ
う。定時感覚の自動結合でも十分です。もちろん、より頻度の高い結合がよい
のは言うまでもありません。
▲コミット頻度
SCM ^1 のリポジトリへのコミット(登録)の頻度が低い(ex 1日1回など)プロジェ
クトの場合は、必然的に結合頻度が低くなります。このような場合には、自動
結合で定時実行でも十分でしょう。一方コミット頻度が高いプロジェクトの場
合は、結合頻度も高くしないと、問題の発生源を捉えにくくなります。手動結
合や、頻繁な自動結合で対応します。
コミット頻度は、本来プロジェクトの開発ポリシーによって決定するものです。
プライベートブランチを使用してメイン枝(=結合対象)に影響を与えないような
仕組を取る場合には、必然的にメイン枝のコミット頻度は下りますので、結合
頻度が低い場合と同様に考えてよいでしょう。
▲プログラミング体制
これはソロプログラミングか、ペアプログラミングかという意味です。ソロプ
ログラミングの場合、ファイルのコミットし忘れや、ローカルでのテストの実
行し忘れなどの問題が発生しがちです。手動結合による頻繁な結合が有効です。
ぺアプログラミングの場合は、そういったミスが軽減できることから、自動結
合で十分でしょう。
▲規模
システムやソフトウェアの規模が大きい場合は、結合自体に多くの時間を費さ
ねばなりません。そのため必然的にそれほど頻繁な結合はできなくなります。
そうなると、自動結合による定時実行に落ち着くでしょう。ただし、規模が巨
大なほど、サブシステムやコンポーネントなどの単位に分割されるはずです。
個々の分割単位では、できるだけ頻繁な結合を手動/自動問わず実践すべきです。
▲作業場所
物理的に遠隔地同士の共同作業を行っている場合は、手動結合はなかなか実施
しにくくなります。 ^2 同じ建物でも、別フロアになってしまうと、感覚的に
は遠隔地と同様です。このような場合は必然的に自動結合がメインになります。
しかし、IM ^3 などで密なコミュニケーションをとっている場合は、声かけに
よる手動結合も可能になります。
もちろんこの場合の手動結合とは、リモートマシンにsshなどでログインして実
行、あるいはHTTPなどでのOneButtonBuildが可能なことが前提となります。
■まとめと次回予告
今回は6つの変数を基にした結合指針について紹介しました。ここで重要視して
おきたい点は「リズム」です。筆者は結合も、TDD ^4 における「テスト→実装
→テスト」のような開発リズムに含めてよいのではと考えています。そうする
と、例え定時実行による結合であっても、自動では開発「リズム」を培うには
役不足だと感じてしまうのです。
「リズム」はより円滑な行動を促進します。更には「リズム」を形成する行動
群を、1つの行動セットとして捉えることができます。
もちろん実際のプロジェクトではリズムよりも重視すべき点もありますので、
各変数の値の結果を踏まえて総合的に判断、選択してください。
次回からは、実際の結合作業の手順について紹介したいと思います。（懸田）
[1] Software Configuration Management - ソフトウェア構成管理ツール
(CVS,VSS,Subversionなど)
[2] Instant Messanger - MSN Messenger、ICQなどのメッセージ交換ソフト
[3] Test Driven Development - テスト駆動開発
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?G002+2+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?G002+2+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?G002+2+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【コラム】まちぶせ
「テスト駆動開発」で使われる、assert(アサート、表明)という概念を表現す
るのに、よい日本語（和語）がないか、と思っていた。
「まちぶせ」はどうだろう。「ここに来るだろう」という場所で、来るべき相
手を待っている。
♪夕暮れの街角、覗いた喫茶店。
微笑み見つめあう 見覚えある二人
（この歌にピンとくる人はどれくらい？）
そう、「まちぶせ」だ。待っている。好きな人を。しかも、その人をこちらに
振り向かせる自信はあるんだ。
♪好きだったのよ〜、assert
胸の奥でずっと。
もうすぐ、私きっと、あなたをグリーンにさせる。
ちなみに、石川ひとみの「まちぶせ」は荒井由実の作詞作曲だ。（平鍋）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?H003+7+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?H003+7+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?H003+7+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「眼鏡かけてますか？」のホントのところ。パソコンとにらめっこの時
間が多いこの業界。目の悪い方が多いのではないでしょうか。
眼鏡を常用しています。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+0
必要な時だけ眼鏡使用。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+1
眼鏡とコンタクトレンズを併用。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+2
コンタクトレンズを常用してます。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+3
見えづらいけれど、気合いで裸眼。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+4
目は良いです！
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+5
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+44+6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「花粉症ですか？」の結果は公開中。是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。今日はサッカーW杯最終予選 日本 vs 北朝鮮戦の試
合ですね。試合で白星を挙げてほしいのは言うまでもありませんが、それ以前
に、試合が無事に終了することを願います。政治とスポーツは別だという意見
もありますが、日本人拉致やミサイルの問題、板門店を訪れた時の重々しい雰
囲気等、私にとっての北朝鮮は、どうしても脅威の国という印象を拭えません。
政治的背景は複雑ですが、今日の試合が、2国をつなぐ架け橋になればいいなと
思います。
今週の強引な一言
*** 嘘からでたまこと（ことわざ）***
嘘はいけませんが、嘘のような大きな夢を語るのはよいのでは。何度も語って
いるうちに現実味を帯び、いつの間にか自分がそうなっていたなんて事は、よ
くあることです。内なる思いを、言葉にしてみると、本当にやりたいことが見
えてくることもあります。ぜひ言葉にしてみてください。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒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.