eXtreme Programming

12のプラクティスがありますが、
実際実用的と思われるのはTesting, Refactoringの2つだと。
Cording Standardsは常識と考えればね。

XP全般について語ってもいいですが、
むしろTesting, Refactoringの二つをメインに語りましょう。
Testingのテクニックなんざをね。

参考URL：
http://objectclub.esm.co.jp/eXtremeProgramming/

JUnit (for Java)
http://www.junit.org

RubyUnit
http://homepage1.nifty.com/markey/ruby/rubyunit/index.html
その他は1のリンクのFAQ見るべし

XPって理想ではあるけど殆ど妄想かも…

チームメンバの能力が相当高くないと成り立たないよね。
あとモラルも。

何も分かってないくせに、リファクタリングにかこつけて意味もなくコード
いじるオタクちゃんが絶対出てきそうだし。

テストの妥当性とか突き詰めていけばキリがなさそうだし…
そもそも、テスト書く人間のスキルがそれなりに高くないとダメだし。

ペアプログラミングと、個人の端末は持たないってのは論外。出来るわけない。

実際に導入してるところの本音とか聞きたいなぁ

>>3
>ペアプログラミングと、個人の端末は持たないってのは論外。出来るわけない。

出来ないんならやらなきゃいいのでは？
やってるとこはやってるらしいよ。

UnitTestツールは便利だよ。
うまくいって欲しい時のテストはもちろん、
例外時のテストも可能だし。
システム止まってもらっちゃ困るから、
しっかり例外時のテストしなきゃね。

>>3
>チームメンバの能力が相当高くないと成り立たないよね。

それ有りそう。たとえば馬鹿がコードを書くならば、
リファクタすればするほど改悪するかも知れないし、
馬鹿が二人そろっていれば、ペアプロで改悪が加速される。
馬鹿がコード規約を定めれば作業は瓦解する。

実際いるんだよねえ。プログラマ側にもマネージャにも客にも、馬鹿が。
まともに頭使ったら絶対こんな答え出すまい？っていうような答えを出して、
しかも平然としてる奴って。

>ペアプログラミングと、個人の端末は持たないってのは論外。

個人の端末持たないなんてPracticeは、無かったと思いますが？
それじゃネットワーク分散開発がやれないじゃん。自宅にPC持てないから。
それにHHKの売り文句みたいに「自分の気に入った操作環境」は超重要ですから、
それを拒否するなんて馬鹿なことをXPがスルとも思いがたい。

もしかして、ソースを個人で抱え込まないっていう話ですか？
>共同所有権(Collective Ownership)
>誰でも、どのコードでも、どこででも、いつでも、プログラマはコードを修正できる。

それなら、ソースを個人pcじゃなくて、サーバーのver管理ツールに置くのと、
修正を各自が勝手にやる(ことを許す)ってので、OKな筈です。

なおこーゆーことをするには、いや、しない普通の開発の場合でも、
ver管理ツールの存在は大前提っす。XPをしてなくても、これは実感。
偶発や故意(馬鹿も含めて)のソースの修正の安全性が段違いになるので。
俺んとこでもVSS(笑)使い始めてから開発「安定」性がはっきり上がった感じです。

まぁこれはXPに興味持つような人になら釈迦説法だろうけど。
RCS/CVS/VSSスレと、ゲーム開発スレを、参照どぞ。

っていうか、何で「バカがやると」とかいう前提で考えるんだ？

自分や、自分が所属する人間が、現在のやり方を捨て、
XPを実践したらどうなるかを考えたほうが健全では？

「バカ」がやれば、ウォーターフォールでもスパイラルでも
失敗するに違いないでしょ。

>何で「バカがやると」とかいう前提で考えるんだ？

>自分や、自分が所属する人間が、現在のやり方を捨て、
>XPを実践したらどうなるかを考えたほうが健全では？

ん？？？

一般論として「馬鹿」を考えた後で、
自分たちがその馬鹿に該当するかどうかを考える
という二段構えでも、おかしくないっしょ？

ん、だから、バカに関する考察して何の益があるんだろう？という
疑問なんですが。

バカがやると失敗するが、スキルのある人がやると成功する、
とかいう考察をしたいんでしょうか？

C/C++用のTestUnitが数種類あるみたいだけど、
どれが一番使いやすいかな?

結論

駄目プログラマは、どんな手法を用いても駄目
天才プログラマは、どんな手法を用いても天才

XPは、いろんな開発手法をやってきてそれでも上手く行かなかった組織が
取り上げたところで効率が良くなる手法ではないと思う。
ある程度のノウハウがあり、そこそこ開発効率の高い組織がさらに上を
目指して取り入れた場合のみ効果があるのではないか？

いずれにしても銀の弾など存在しないのだから過剰な期待は禁物。

厨房には向かないってのはもうわかったから次いこうや。

UnitTestはただテストのコードとして書くだけじゃなくて、
クラスの設計時に合わせて書くといいよ。
なぜなら設計時にテストコードを書くことは
事前に(仮想的な)クラスを使ってみることを意味するので
クラスがどうあるべきかというイメージがはっきりする。
# UMLだけ書いているときと比べてやりやすい気がする。

またテストコードがクラスのドキュメント的な性格を持つので、
UML図、仕様書とコードを常に同期させるコストを低減できる
# ことが期待される。このあたりの効果はまだ不明。

いずれにしても厨房はまともなテストが書けない。
まともなリファクタリングができないといっても不毛だよ。
厨房がXPの実践を通して設計・テスト・リファクタリングの
経験をつめると考えれば従来のコーダよりも得られるものは
はるかに大きいと思う。

>>12
その考えには反対だな。
馬鹿が集まればどんな方法論使っても失敗するけど、
優秀なやつだけで固めてもプロジェクトは失敗するときがある、
ってことでみんな頭を悩ませていたわけでしょ。
で、いろいろなプロジェクト進行法が考え出されて、そのなかで
もっとも現代的で現実的なのがXPってことでしょ。
XPを用いても優秀な人材がいないとだめってのはいっしょってことだな。

>>16
うまく言えないけど、なんかXPの思想や目的、成り立ちと合致してない気が・・・。

>>17
それって「いろいろなプロジェクト進行法が考え出されて、そのなかで
もっとも現代的で現実的なのがXPってことでしょ」って部分に対して
だよね？
スマソ、あんま考えて書いた文じゃないから変でした（藁
ただ、漏れがいいたいのは「優秀なやつだけ集めたとしても失敗する
ときがある。何らかの方法論を使えばそのリスクを軽減できるけど、
そのなかでもＸＰはなかなか逝けてるＹＯ！」ってことでした

>>10
馬鹿について考えるのが抽象的すぎて困るなら、
自分について考えるのは具体的すぎて
応用が利かないと思うが。

応用ってのは、他人とかに話を展開するときに、ね。

マルチスレッド・マルチプロセス・ネットワーク関連の
UnitTestについては専用のTestingFrameworkってあるのでしょうか。

あとGUIのテストも面倒そうですね。
メニュー選んだりクリックしたりとかが。

>>20
xUnitは言語ごとにあるから、そのプログラムが何で作られてるかによるな。
あと「何を」テストするかにもよる。
漠然と「マルチスレッド・マルチプロセス・ネットワーク関連」と言われても・・・。

>あとGUIのテストも面倒そうですね。
>メニュー選んだりクリックしたりとかが。

Javaの例がどっかにあったな。
WebならHTTP Unitなんかが使える。

とりあえず、

ＸＰエクストリーム・プログラミング入門
ソフトウェア開発の究極の手法
ケント・ベック(ベック.ケント)

は、XPの紹介だけで実際には使い物にならない本ですな。
ＸＰエクストリーム・プログラミング実行計画 を読んだことがある方
いい本でしたか?

age

age

>>22
どういう内容なら「使い物」になると判断します？
いまよんでるけど、まだ７章なんで精神論が主。

>>25
これこれこういう思想だよ、というのは伝わるが
技術的な内容は一切無かったような。

とりあえず私は2冊目の本を注文しました。
こっちもそれっぽい内容だったら鬱。

ついでだけど、既に
「テスト抜きではプログラムが書けない体」
になってしまった人いるかな(笑)

おお、珍しく知的な人たちが書いてる。

The Test/Code Cycle in XP
テストをひとつ書く。
テストをコンパイルする。まだ何もつくっていないんだから、これは失敗しないといけない。
コンパイルできる程度にコードを書く。(必要ならその前にリファクターする)
テストを走らせ、失敗することを確認する。
テストが通る程度の実装を行う。
テストを走らせ、通ることを確認する。
整理し「同じことは一個所で」となるようにリファクターする。
最初に戻って繰返す。

0.いっちゃん最初に既存のテストが100%通ることを確認

全てはここからだ。

>>27
てゆーか、早く(ニンゲンに)なりたいです俺(T_T)

今やってる仕事がいい加減なプロジェクトで、
客とか上とかの連中が仕様をまともに考えやしない
(理屈的に穴だらけだったりとか)んで、
モトネタの仕様が無くちゃテストもかけない、
でも実装本体は書かされる、という
ロクでも無い状態になってます。
テストファーストが「できる」状況にあるかどうか？は、
結構そのプロジェクトのまとも度の指標になるんじゃないかと憶測。

せめてってわけで、コードとテスト(しかも手動用の手順書)を
同時に提出するようにしてるんだけど、
他の大抵の奴はコード書いてから数十時間後でないと
テストを提出してないらしい。俺のスタイルが
ものめずらしがられてしまったよ。
テストの内容が仕様やコードと(微かにでも)ずれていることの恐さを
判っているんだろうかヤツラは？

>>30

なにかに似ていると思ったら、これって
ソースとかのバージョン管理ツールの理屈に
なんとなく似てませんか？

つまり、概念的には、ソース字面レベルじゃなくて
実行テストレベルでの「diff」なんだよソレは。

確かに字面レベルだと、ソース書きながら
そのソースや他のソースの字面を比較とかするために
頻繁にgrepとか使うもんなあ。
それの実行時版なわけね、UnitTestって。

う。俺ぁエディタでソース書くとき、数秒(誤字じゃなく)に1回
SAVEする感じなんで、同じノリでUnitTestも数秒に1回やりたいな。
将来CPUが速くなったら、コード書くのとリアルタイムに同期した
全自動テストつまりIncrementalUnitTestなんてものが
出来るようになるかも。最後の}を入力し終わった瞬間に
Test画面がRedからGreenになるっていう感じ。

ん？するとUnitTestはRCSみたいなもんってことで、
一方でCVSに相当する統合テスト自動化方法ってのも
きっとこの世のどっかにあるんだろうな(^^;;;

UnitTest+(CVS-RCS)=統合Test
みたいな感じかな。

>>32
多分アナタ、テスト中毒(Fowlerのいう、Test Infected,　うただなら
Addicted to Test)になる素質アルネ

>>33
なりたいです(廃人もーど

妄想つづき。
エディタ上でソースの任意の部分を選択ハイライトさせて
Testってコマンドを投げると、その部分に
うまく該当するTest(1つ以上)が存在すれば
そいつを走らせてくれる、というエディタとか。

まぁUnitTestのUnitより小さい単位なんてものを
考え出したら却ってハマルだけかもだが。

>>34
ワォ、アナタ天才ネ
って文体気持ち悪いから戻すけど、
buildとバージョン管理ともろもろを統合するツールは
今、いろんな人がつくりはじめてるみたい。今ならいっちょ面白い
のをつくると皆喜ぶかも。

エディターとの統合も面白いね。

>>32
>SAVEする感じなんで、同じノリでUnitTestも数秒に1回やりたいな。
これはちょっとウザいと思う。動かないのわかってて書いている場合もあるので。

>ソースとかのバージョン管理ツールの理屈に
>なんとなく似てませんか？
というより、XP,UnitTestを
開発ツールベンダに認知させる事ができたら、
開発の全フェーズに関わってくる可能性がある。
# 最近のIDEはカスタマイズ可能なので、
# ユーザーレベルで実現可能なはずだけど。

・プロジェクトと連携。ソースやクラス定義を追加したら、テストの枠組みを自動生成。
・ソース管理と連携。ソース管理のチェックイン・チェックアウトの度にテストを実行。
・実行(?)と連携。プログラムを実行したらその直前にテストを実行。
# テストのmake(前回失敗したもののみ実行)なんてのもありだね。
・デバッガと連携。テストに失敗したら、そのテストを再実行して失敗する直前に
　ブレークをかけてデバッガに制御を渡す。あとテストのステップ実行など。
・レポートツールと連携。テスト結果をデータベースに出力。
　最後に成功した(失敗した)モジュールとテスト直前に修正した他のモジュールなどをレポートする。
・プロファイラと連携。テストの時間を計測。複数のアルゴリズム・バージョン間で実行時間を比較。

これらの幾つかの機能を持ったDelphiのframeworkを作成中。
Delphiはビルドが超高速、GUIが作りやすい、コード補完、
クラスのprivate/protectedにアクセスするテストが普通に書ける、
スマートリンク、テストメソッドの検索・自動実行
ができるので、気合を入れれば結構使いやすそうなものができそう。

う〜ん
UnitTestしないで試しにプログラムを作ってみたら
発狂してしまった(爆)

ふぉっふぉっふぉ、感染してしまいましたね。
もうとめられません。あなたの因子が社内に、大学に、
伝染してゆくのです。

>>36
おおおおお！
(案の段階で既に)すばらしい！！

なるほど。Borland伝統(笑)のrunメニューのなかに
testメニューが混じってくる感じかな。
DelphiならIDEへのカスタマイズもDelphi自体で書けるから
尚更有り難いですね。

>クラスのprivate/protectedにアクセスするテストが普通に書ける

これって同一ソースファイルに書くわけですね。
リリースのとき切り離すのがアレかな。
あ、条件コンパイルすりゃいいだけか。

>プロジェクトと連携。

Wizardでクラス生成を選択したら
対象ClassとTestClassを一緒に生成っすか。うおー。

>ソース管理と連携

delphiに添付の管理ツール以外も使えるようにしてください(w
(あのツールって使いにくくないっすかかなり?)

>もうとめられません。あなたの因子が社内に、大学に、

変化を抱護せよってのは、そういう意味だったのか(w
「伝染るんです」っていう感じ。

こんな建設的なの、2ちゃんじゃないやい！！！
おいらフテネするもんね。

フテネするまえに...
でも、開発現場でISO9000とか、RUPとか、なんでも良いんですが、
重たーいプロセス体験してない人にXP菌を移しちゃっても
大丈夫なんでしょうか？

>>42
ふとまた下らないこと考えたんですが、
ISO9000とかハサップ(w)とかのノリと
XPのノリとの違いって、
型有り言語と型無し言語の違いと、
なんとなく似てるような？(よしあしはさておき

ニテルカモ
運用次第で後者の品質が極めて高くなる。
でも厨房に触らせると...

>>42
プログラマならいいんじゃない。
実践的だし、こういうのにはまる素質があるプログラマは伸びると思われ。
ただ、リーダークラスが安易にはまるとプロジェクトが崩壊するかも。

XPの評価ってオブジェクト指向普及前のごたごたと似てるな
いち早く取り入れて玉砕するも良し
否定して出遅れるも良し

>>46 そだね
ただし、みんなOO普及初期より誇大妄想少なくて
地に足がついた議論してる気がするけど

最初から小規模なプロジェクト向けの軽量な開発方法論ですって
限定してるところがポイント高し。

OOは大風呂敷広げまくりだったからなぁ。

私実は、会社で重たいの体験する前にXP面白いので、
XP本も全部揃えてはまっちゃってます。3人のチームで、
お客サンのとこ(小さなNetベンチャー)でいっしょに
On site Customerよろしく開発したりもしてますが、少々不安が
あります。どーしよう。PSPとかやってみるのがよいんでしょうか？
アドバイスいただけるとすごいうれしいです。

>>49
身近に重たい派だけど仕事できるな、っていうプロジェクト
マネージャとかいないでしょうか？
やり方が古いと頭から否定せずに、半分はその人の真似する
つもりでやってみるのはどうでしょう。

>>22
>ＸＰエクストリーム・プログラミング実行計画 を読んだことがある方
>いい本でしたか?

いい本でしたよ。訳もXP入門よりはましになってる。訳者が一人抜けた
のが良かったのか？（ｗ

それから、Ron Jefferies の XPI (Extreme Programming Installed)
http://www.amazon.co.jp/exec/obidos/ASIN/0201708426/249-0179278-0341134
を邦訳中だとか。

>>39
IDEの組み込み・プロジェクト管理関連は
ほとんどやるつもりないよ。
だって資料ないし面倒だし:-P
その代わりデバッガとの連携はきっちりやりたいね。

>これって同一ソースファイルに書くわけですね。
テスト書く場所ってメソッドの実装の真上がよくない？
リファクタリングする時も楽だし。

>Wizardでクラス生成を選択したら
>対象ClassとTestClassを一緒に生成っすか。うおー。
これはコードテンプレートで十分だと思う。
これ以上やろうとするとソースの解析しなきゃいけないので面倒かも。

>delphiに添付の管理ツール以外も使えるようにしてください(w
>(あのツールって使いにくくないっすかかなり?)
確かに使いづらい。これ誉めてるの聞いたことないね。
Winで使うならVSS>(Win)CVS>TeamSourceかな。

ところでまったく参照されないpublishedメソッド持ったクラスって
スマートリンクでうまく削ってくれるんだっけ？
テストコードの削除は{$ifdef}で囲まずにリンカに
頼ろうと思ってたけどやってくれないような気がしてきた。要調査。

>IntelliJ IDEA
>リファクタリング機能
ってなに？

>>32
DelphiのIDEと合体したUnitTest私も期待です。

>ところでまったく参照されないpublishedメソッド持ったクラスって
>スマートリンクでうまく削ってくれるんだっけ？

消してくれないみたい。実行ファイルにリンクされたメソッドは
ソースコードエディタで隣に青色の丸が付くのですぐに分かります。
RTTI情報を使って呼び出される可能性があるので仕方ないですね。

54の者だけど訂正。
「publishedメソッドを持ったクラス」が全く使われないのでしたら
リンクされません。

んー。古いけど、答えを思いついたんで。

>>10
>バカがやると失敗するが、スキルのある人がやると成功する、
>とかいう考察をしたいんでしょうか？

いや、そうじゃなくて、
馬鹿という抽象存在が、XPという具体的行為群に出会うと、
どんな馬鹿を具体的にやってくれるか？という話を書いたわけだ。
どう失敗するか？の話を付け加えたのが味噌。
あとは馬鹿抽象に俺とかアナタとかいう具体的人物を
当てはめる(のはいつでも出来る)。
TempleteMethodみたいなもんよ。

>テスト書く場所ってメソッドの実装の真上がよくない？

あっそうか。どうせ常に一対一対応だからそれでいいのか。
気付いてなかったとは撃つ出し脳。

>>54
まぁ、御本人が大変だってなら、IDE統合の部分は
誰か他の人が書いてくれることを淡く期待し…(^^;

delphiって、スマートリンクどれくらい効いているのか
ろくに考えずに今までやっていました(^^;

こりゃリファクタリングすべきだろう、と思った
ちょっと昔のコードを引っ張り出してみました。
------------------
class HHModel < Model
def initialize(ena, ek, el, gna, gk, gl, cm, v0, m0, h0, n0)
@deg_k = 4
@deg_n = 4
@Ena = ena
@Ek = ek
@El = el
@Gna = gna
@Gk = gk
@Gl = gl
@Cm = cm
@ans = [v0, m0, h0, n0]
@swp = @ans.dup #ansの一時変数
alloc(@deg_k, @deg_n)
#@k[4][4]
end
--以下略-------------------------------
initializeってのはコンストラクタなんだけど、
パラメータのほとんどをゴテゴテ引数にしてしまうのは
まずいですよね・・・
せめて初期設定だけ引数に渡して、
他のパラメータをあとから代入してやればいいのかな。

＃ちなみにこのコードはXPを知る直前。
＃テストコードなんてもちろんありませんが。

>>58

コンストラクタは必須パラメーターだけにして
あとは setter/getter みたいな手法をいつも使ってます

>>59 さん
やっぱコンストラクタには必須パラメータのみですよね。
というか何でこんなことしていたんだろう。

まぁ、救い(?)なのは、スーパークラスをいぢらないで修正できそうなのと
サブクラス(今回のを含む)が3,4つしか作っていないことかな。

>>51
オンラインで注文したんだけど・・・
実は品切れっぽかったです(笑)
そんなもん気づかないで注文した私もあれですけど。

Webのリソースって、市販されてる本と同じ分量の内容なんでしょうか？
XPの本ってなんかパート（？）ごとにでてるんで、どれをかっていいのか・・
予算が厳しいので、可能な限りWebで勉強したいと思うのですが
http://www.xprogramming.com/

Webでも結構いい勉強できると思いますよ。
このスレではメインとして
・テスティング
・リファクタリング
のお勉強をしよう、ってことにしていますが。

Javaが使えるのでしたら、1のリンク中程にある
XP関連記事を読まれるとよろしいのでは。
Kent Beck氏の記事とWilliam C. Wake氏のを読んでみてください。
もっと知りたい！って時には・・・
一緒に勉強していきましょう(爆)

>>32
http://cruisecontrol.sourceforge.net/
とか?
Martin Fowlerもお勧め(?)の由緒正しきtool

>>53
http://www.intellij.com/idea/
にあるJava用IDEのこと
この手のツールがあるとリファクタリングが楽になる
特に名前の変更やパッケージ移動に効果的

こんな本もあったんですね。

リファクタリング―プログラムの体質改善テクニック
Object Technology Series〈10〉

http://www.amazon.co.jp/exec/obidos/ASIN/4894712288/qid%3D989997569/249-9204487-7841920

>体質改善

そうか。XPのリファクタリングって、
UnitTestによって常時健康をチェックしながらの
きちんとしたダイエット、みたいなもんだったのか。

無理なダイエットはたしかに「体の機能を損なったり」するもんなあ(w

いいよねリファクタリング…

他人のソースを勝手に綺麗にするとか、
わざと適当に書いてあとから直すとか。

>他人のソースを勝手に綺麗にする

たしかに。あれ良いですよねえ。
「自分の責任で直せ」っていう言いまわしが
えらく古びたものに感じられる。

すると、コントリビューションみたいな形で労働を測るのかな(^^;
つまり、より多くの個所の改善(勿論改悪はマイナス点)を
行えた人が給料上がるみたいに。

宣伝効果抜群の共有HP宣伝掲示板を27
個設置ししました。27個の共有HP宣伝
掲示板全部にカキコすればなんと1,000
以上の掲示板にカキコしたことに!!
効率よく宣伝しちゃいましょう。その
他みなさんのお役に立つサイトを徹底
して集めています。是非見てください。

http://home9.highway.ne.jp/cym10262/

69に引っかからないように。

次号の日経コンピュータ（6月4日号）の特集は、
「究極のソフトウェア開発手法〜エクストリーム・プログラミングの全貌」
だそうだ。

糞記事の予感・・・

>>72
誰が特集を書くのかにもよるな

>>68-69
そうかなぁ？

リファクタリングを傘に着て
「とりあえずテストは通ったんだけどリファクタリングしといてよ」とか
「お前がリファクタリングしたんだからお前の責任だろ！」とか
「あとでリファクタリングすればいいんでしょ。とりあえず動くんで」とか
「あいつにだけはリファクタリングさせるなよ。」とか
「あのひと納期も守らずいつもリファクタリングばかりしてるよね。」とか

手抜きと責任転化と自己満足の正当化に使われやしないだろうか？

>>74
誰が何処をどれだけ直したのか履歴が残ってて何時でも
参照、集計できるツールがあればよいと思われ。
CVSとスクリプトかなんかでできるかな？

>>74 >>75
XPやるのに構成管理ツールは必須だと思う
作業がループしがちな人には強権発動して担当部分以外は
ReadOnlyにしてます

「とりあえずテストは通ったんだけどリファクタリングしといてよ」
--> 殴る
「お前がリファクタリングしたんだからお前の責任だろ！」
--> よく考えてから殴る
「あとでリファクタリングすればいいんでしょ。とりあえず動くんで」
--> それなりに正しい態度だと思う　あんまりなら殴る
「あいつにだけはリファクタリングさせるなよ。」
--> きたないリファクタリング(リファクタリングというのか？)
する人って見たことないけど,もしそうなら殴る
「あのひと納期も守らずいつもリファクタリングばかりしてるよね。」
--> XPの精神に反する行為なので殴る

>>75
CVSは知らないけど、VSSとRCS(^^;では、
CheckInのときにひとこと自己主張(笑)を書きこめるよね。

自分が厨房でないことを証明(?)したかったら
あそこに然るべき内容の有ることを書いて欲しいと思う。

白紙答案は禁止したいなあ。

Martin Fowler の　Refactoringをよんだら、
smalltalkには、範囲指定→右クリック→メソッドを抽出
ってツールがあるみたい。
Javaにもリファクタリング関係のツールで便利そうなのありますか？

>>79
http://www.martinfowler.com/articles/refactoringRubicon.html
にでてるIDEAとJFactorとか
emacsにも何かあったような…

Delphi用Testing Frameworkリリースage
でも使い方がよくわからない。。。

719　ふみもたたけし　　2001/05/21(月) 00:10
Delphi5用Testing Frameworkリリース。
http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/DUnit010520.zip
http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/DUnit010520.png

まだドキュメント書いてないので使い方わかんないと思うけど、
興味ある人はtestDUnit.pasを眺めててください。

JUnitというのをダウンロードしたのですが、
ドキュメントの説明が長くて、いまだに動かせないです。

これって自作のテストクラスから判定を受け取って、
赤か緑を表示する機能のほかにいいことあるんでしょうか？

Javaな人はテストツール何をお使いでしょうか？

まず、JUnitの場所を教えてちょ
話はそれからだ

http://www.junit.org/

>>82
>これって自作のテストクラスから判定を受け取って、
>赤か緑を表示する機能のほかにいいことあるんでしょうか？

コマンドラインでも使えるが･･･。
そういうことではないの？

まだ使いはじめだからはっきりしたことはいえないんだけど、
自作のテストクラスを作ることで、テストに必要な機能はほぼ完了しているから、
わざわざJUNITを使うまでも無いような気がする

>>86
JUNIT使うようになったら自作のテストクラスを
作る必要なくなったと考えると幸せになれよ。

TestingFramework自体はコード量をそれほど減らしてくれる
わけでもないし、バグの発生数を減らしてくれるわけでもない。
単にテストの習慣をつけましょう・テストを
パターン化しましょうってだけだよ。

87>
なるほど。
テストする習慣作りに役立つアイテムみたいなものってことですね。
あのランプ（？）が赤とか緑に変わる瞬間はまあ楽しいです。

自作で表示部分を面白くしようかな

xUnitは、GUIで使うのではなく、コマンドラインで使うのが本筋だと思うんだが…。

LCRダナー
赤から緑になったら〜ＯＫだよ！

一応、GUIでも使えるものがあるらしいですよ。
JUnitは使えたような。
RubyUnitとかは使えませんけど。
＃そもそも標準でGUI環境ないし＞Ruby

今・・・
諸事情により・・・
Cでプログラムを書いています・・・
テストツール・・・
使いづらいです・・・
オブジェクト指向って・・・
素敵ですね・・・

というか・・・
あれないとやっていられないですよね・・・

･･･はコンソール版のUnitTestの「テストが3個正常終了しました」
の意味でしょうか？

毎行テストしてるんかい(藁

>92
組み込み系ですが、今回UnitTestをやってみようと思ってます。
Cですけど、やっぱり使いづらいですか？

cUnitを自分で改造しましたが・・・・

92じゃないけど
動的にobjectをロードできる仕組みがないとつらい。
CやC++だといろいろ工夫がないと萎えるね。

インタプリタ、最高ですかー？

日経ソフトウェアかなんかに書いてあったが、
ペアプロってやっぱり
「キーボードやマウスを」2人で共用することなのか？

いくらなんでもそりゃ嘘だと思うのだが。
ディスプレイ＆キーボード切替器買えよっつーか。

ていうかペアプロって「ソースを」2人で共有
することだと思っていたんだが違うの？
CVS経由で(でなくても原理的にはいいが…)
隣人と同一ソースを頻繁にやり取りしながら
いじりまわすってことなんじゃなくて？

>>96
ネイティブコンパイラだけどクラスローダーがあるDelphiまんせー

>>32
だいぶ、亀になるが、もし仮に、そんなツールを使ったら買ってくれる人はどのぐらい
いるかねえ…。

テストを自動生成するアプリなら製品化されてたな。
そんなんで金取るなという気もしたけど。

>>96
>クラスローダー
え、どんなの？どんなの？

>97

本当にキーボードとディスプレイを2人で共用することでしょ。
っていうか、一人がキーボード打っている間はもう一人は
後ろで監視してます。

コーディングしながらレビューだと理解してるよん。

>>102
でもさ、それをするために「キーボードが」同一である必要は
全然ないじゃん。キーボード切替器で明らかに十分であり、
たとえばキーボードの趣味が違う2人はペアプロできないのか？とかいう
馬鹿げた疑問が沸いてくるばかりなんですけど。

他人の手垢べったりなキーボードなんて打ちたいですか？
少なくとも俺はそれだけでストレス感じますね。
自分のなら諦めるけど。

うーん。どう考えても、現代的な開発方法論が、
そんな低次元な要求をするはずないと思うのですけど。

あと、極端な話VNCみたいに
「同一の論理画面を」別の物理画面/Key/Mouse環境で
共有できるソフトなんか、どうよ？
「テレビ電話で会議はできるか？」って言ってるのと等価ね。

>>103
だよねえ。
その目的さえ満たせば手段は問わないと思うのだけど？

まとまった情報がほしいので、
XP本を「日本語」に翻訳してくれということでファイナルアンサー？

>>102 偏見かもしれないけど
日本人ほど潔癖なやつはめずらしいようなきもする
あと細かい違いを除けばアメリカには
キー配列ほとんど1種類しかないのでは？

一応こっちにも書いておこう。

DUnitのチュートリアルを書いた。
http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/index.htm

>>107
CppUnitなんかよりずっと見栄えが良い・・・すげー

早速DUnitを使ってみました。

function Max(m, n: Integer): Inteegr;
begin
　if m > n then result := m else result := n;
end;

という関数を書いたら

type TMaxTest = class(TTest)
　published
　　procedure testMax;
　end;

procedure TMaxTest.testMax;
begin
　Test(Max(10,20), 20, 'Max(10,20)=20になるはず');
　Test(Max(20,-30), 20, 'Max(20,-30)=20になるはず');
end;

というテストコードを書いて、

TestSuite.Add(TMaxTest)

と書くとテストがフォームに登録されるということみたいです。

Maxのテストなんて書くまでもないと思いますが
後からじわじわ効いてくるものなのでしょうか。
もうちょっと使ってみます。

>あと、極端な話VNCみたいに
>「同一の論理画面を」別の物理画面/Key/Mouse環境で
>共有できるソフトなんか、どうよ？

キーボードは別でもいいけど、これはちょっと違うと思う。
物理的に同じ場所にいて、コミュニケーションしながら
同じ画面を見て、っていうのが大切だと思う。

>>107
（・∀・）ｲｲ！
ページ見てなんかみたことある書き方だとおもたら、ShortCutsの作者さんだったか・・・。

自分のマシンの後ろに相方さんを連れてくればいいじゃん。
XPで一番賛否両論な部分だから、いろいろな意見が出るね。

>>106
>日本人ほど潔癖なやつはめずらしいようなきもする

まぁそれはそうかもって気がするが、
だからって共用しろと強要するのは、なんか違う。

>あと細かい違いを除けばアメリカには
>キー配列ほとんど1種類しかないのでは？

アメリカ人=単一言語主義者(そしてキーボードも…)という
推測はもしかしてあたってるかもだけど、それは別として、
配列だけがキーボードの特性じゃないんで、やっぱり嫌だな。
タッチだってサイズだって色々ある。
まぁ最近は何故か糞品質なキーボードが幅きかせてるけど。

>>110
まぁリーズナブルにはそうなんだけど、
将来つーか極端なこと言えば「テレビ会議」も
有りなんじゃないかと思うんですが…。
会議画面をsplit(?)してソースいじり中のディスプレイも映せば良し。

余談。今のところ現実的じゃないけど、考えてみれば
一人に1画面って決め付けるのもなんか妙だ。
SONYの暦本氏の研究みたいに、画面は黒板とかと同様に
複数の人で共用されても良いように思える。
Computer Aided Discussionとでもいうか。

んで、ペアプロってコーディング作業を
「一人の作業」から「Discussion」に変貌させる
っていうもんだよね。

YARPC19101で話してたひとは、キーボードは２つ・ディスプレイは
21インチくらいの1つでXPやってる、って言ってたね。

ペアプロは背中合わせになって別々の
モニタ・キーボードでやるのが経験的に一番よい
必要なら相手のモニターのぞき込めるし
腹立ったら相手の顔見なくてすむし:-P

>104
ペアプロ状態の時はキーボードも同一で、主にそのキーボードの
持ち主がタイプを担当する。
って感じじゃないかと解釈してたけど。

XPのペアプログラミングって頻繁なペアの変更を求めるし、
ペアを組替えるたびにキーボードを繋ぎかえるのって
面倒そうに思えるけど、キーボードに拘りのある人って
そうでもないのかな？

>その目的さえ満たせば手段は問わないと思うのだけど？

御意。
たぶん問わないと思うけど、キーボードに拘りのある人は
自分のキーボードを持ち歩けばいいんじゃないかな。
ペアの両方が気にする場合は切替器ってことで。

>>115
ソースの同期手段は何ですか？
論理画面共有？CVS？

>>116
>タイプを担当する

うーん？
やっぱりタイプって、コードを今考えてる本人が
自分で打ってナンボじゃない？

他人に口伝しつつ入力してもらうなんて遅いことしてたら
アイデアのほうが逃げていっちゃう。
逆にいえばそんなんでも平気なほど最初からタイプ遅い人間って
駄目とまでは言わないけどプログラム書くのは辛くない？

連弾よりツインキーボードのほうが絶対いいと思う。

>ペアを組替えるたびにキーボードを繋ぎかえるのって

延長ケーブルを計算機の裏から机の真ん前まで
伸ばしておけばよいだけでは？

関係ないけど俺はシリアルを頻繁に着脱する必要があったんで
シリアル延長ケーブル買ってきて机の真ん前に転がした。
そんな感じじゃない？

あ。
蛇足だけどプログラマ板に汗臭さスレが立ってるね(^^;;;;;

>ソースの同期手段は何ですか？
男は黙ってVisual Studio + Visual SourceSafe + IP Messenger + GCCだ(藁
何れにしてもXP-ペアプロを妄想で議論したって性悪論・破綻しか導き出せないぞ。

ペアプログラミング10則
http://objectclub.esm.co.jp/eXtremeProgramming/10PrinciplesOfPairProgramming.pdf
1のリンク先にあるんだからちゃんと読もうよ

>>118
IPMってところが素晴らしい。やっぱりあれが勝利の方程式ですか。

VSとGCCが混在ってのが凄い....

>性悪
....誰がそんな話をしていたっけかな....

>>119
pdfをプレーンテキストに変換するツールきぼん

>>121
ほい（笑
http://access.adobe.com/access_email.html

Extream Programming Installed は google に引っ掛かってるんだけどねえ
http://www.phooey.com/programming/docs/pm/xp/Extreme%20Programming%20Installed.pdf
http://www.google.com/search?q=cache:0EpZrrVnXRU:www.phooey.com/programming/docs/pm/xp/Extreme%2520Programming%2520Installed.pdf+10+principles+PairProgramming&hl=ja

頻繁にパートナーを変える場合はキーボード交換は面倒だし
できればエディタも統一しておくといいと思うけど
（うちではそうしている）

キーボードよりもむしろキーバインドが問題では・・。
あと、エディタ統一はないような気が・・・。
全部、統合環境のエディタで統一ってんならわかるけど。

>キーボードよりもむしろキーバインドが問題では・・。
極端で分かりやすい例だと、CtrlとCaps入れ替え
>エディタ
極端で分かりやすい例だと、vimとemacs(藁
どっちがどっちにうつっても死ねるし、大抵すでに最強環境構築してるはずだから、
別のに移行するのも死ねる(藁

>>125
そうそう。それそれ。
ソースの個人所有は認めないのは判るし、
コーディング規約の個人所有(つまり非統一)を認めないのも判るけど、
操作環境の個人所有まで認めないとなると、作業効率落ちまくりよ。
みんながみんなVC(?)で統一して満足ウマーできるとはとても思えず。

極論。手に障害とか有るんで特殊に調節されたデバイス
でないと困るような人は、同じ障害を持ってる人とでないと
ペアプロできない、んでしょうか？
そりゃ、変だ。

違うエディタに対しても、ファイル名と行番号さえやり取りすれば
「同じものをいじる」感じになるわけだし。

>>124-126
実現方法はともかく、「ペアプログラミング」という方法論については
どう考えるの？

>>127
よろしいんじゃないでしょうか、漫才スタイルでコーディングするってのは。
ボケと突っ込み。
一人じゃなかなか旨くいかんでしょう。

プロ野球の横浜が優勝した年、監督が
「プロにはチームワークは要らないんです。
それぞれの時に応じたコンビネーションを出来ればいいんです」
と言っていたけど、ペアプロってその境地だよね。

だから、ついていけない人も居るとは思うけど。

んー俺はあんまりこだわらんのでいいんだけど
結構こだわる人いるのね…　 > かんきょう

どっかで、
「お前のエディタとプロジェクトの成功のどっちが大切よ？」
といって説得するといっていたぞ、たしか。
えらく極端だなとおもったがeXtremeだから、まあそんなもんかな
と思った覚えがある

>>129
全体主義はまずいよ。
同じ服着ろとか同じ車乗れとか言ってるのと
それ大差なくない？

どうでもいい部分は拘束しないのが今風だと思われ。
キボドやエディタ同じにしても
生産性も士気も上がるとはとても思えず。

どなんだろう？
unix系だと更にWindowManagerまで同じにせぇとか言うわけ？

ペアプログラミングについてはプログラマ板でやって欲しいな〜。
テクニカルな話題が全然でてないじゃん。

>>130
XPには多少全体主義っぽいところがある、と思う
「あっそう、でもよそでやってね（君はいらないよ）」

>>131
XPはかなりeXtremeなので政治闘争的なものになりがちだとおもわれ
じゃあ、
「AcceptanceTestって具体的にどう書くよ？」
ってのはある程度テクニカルかな？

リファクタリングの本を買ってもらいました。
読む暇がないので序章だけを読んだんだけど、
破綻しやすいコードを書いてしまいがちな私には
目から鱗ものな内容だと思われます。

他のDUnitは試していないけど、
是非英語解説やらなにやらを作って
公開してもらいたいな。

素敵な出来だと思いますよ。

ＳＥＸプログラミングマンセー

3Pプログラミング

UnitTest、どの範囲で適用してます？
汎用ルーチンのみ？全部ごとに全部？GUIまわりも？

あげるべきでした

＞全部ごとに全部
関数ごとに全部

>>137
単純なgetter/setter以外(なるべく)全部。
バグ発生時には、バグを再現するテストを追加。その後デバッグ。

133
Martin Fowlerですか？
私も買いました。

私はクラスの切り出しがあまくて、コーディングが進むにつれて、
「このクラスにこのメソッドはよくないなぁ」
とか
「このクラスの存在する意義はないかも」
って悩むことが多いのですが、この本から得た知識で
綺麗なクラス設計に戻せそうです。

テストクラス単位、メソッド単位でメモリリークを検出する
DUnitのアイデアが固まったので実装中。
若干実行速度が遅いけど、テストクラス単位なら許容できそう。

>>134
英語版とは気が早い。
ドキュメントの分量なんてたかがしれてるけど、
日本語版の開発環境で英語版のexeを作れるのかな？
例外のメッセージなんかも含めて。

ちょと方向性違う話だけど。

プログラム日記(w)って、どうしてます？
XP風に強引に言い直すならば
「日記は12のプラクティスのどこに当てはまるか？」
って感じなんだけど。それとも「んなもんねぇよ」ということ？

Wikiでプログラム日記つけたら
どうなんだろう？って、ちと思ったもので。

開発者、ソースファイル、関数/クラス/メソッド、などなどの
それぞれに対応するWikiNameを作って、
なにか作業するたびにリンクを張り合う。

もちろんwikiでなくてもいいけど、リンク(を含むファイル：htmlとか)を
さくさくとしかも複数人でいっぺんにいじれる環境が欲しいんで。

うーん。ソースをCVSに入れちゃうだけで十分、なのかなあ？
どうでしょう？

中小企業でXPってどうなんでしょう？
実際に導入してやっている方の体験談きぼぅん。

極論すればUnitTestさえしていれば
演繹的なコードの検証は不要である。
なぜならいくつかの単純なテストにパスすることで
コードの正当性が確認できるからである。

もし一つのコードの検証に多くの複雑な
テストが必要になるとすれば、
そのコードは複雑すぎるのである。
そしてそのコードはリファクタリングの対象となる。

>>145
んなこたーない。
つーか、言葉の定義が雑すぎて評価できない。

UnitTestで困ったことがあるのですが、
とある配列の順序をランダムに並べ替えて
それをリターンするメソッドがあるのですが、
これってどうやってテストを書けばいいのでしょう?

配列の長さが同じ！とかテストしても
あんまし意味ないですし。

ソートして元の項目とあっているかどうかをチェックする。
どの程度ランダムになっているかという「性能」についての
テストはUnitTest以外のテストが必要になる。

ゲーム系に導入したいんだけどきつそう。
テストルーチンがサパーリ思い浮かばん・・・。
キャラクターの動きやらスプライトの描画やら・・・。

ゲーム系は携わったことがないからわからないけど、
テストの基本は入力とそれに対する出力をどうするか?を
決めていることが前提。

描画系はどうしようもなさそうだけど、
例えば人オブジェクトの移動メソッドくらいなら
入力：目的地の座標
出力：(移動後)現在の座標
みたいな事くらいは出来ると思う。

ファイルに出力するメソッドのUnitTestだと、
予想出力結果ファイルを作成して比べるしかないんでしょうか。
いろんなテストパターン毎にファイルを用意するのが面倒なのですが……。

>>151
文字列リスト、テキストファイルのテストはよくやるので
面倒ならxUnitを拡張してしまえばいい。
DUnitにはファイル・ファイル、ファイル・文字列リスト、
ファイル・文字列配列のテストを追加した。

TestFile('result.txt', ['aaa', 'bbb', 'ccc']);　// result.txtの中身をテスト

>>149
今ちょうどゲーム（のライブラリ）でUnitTestやっているけど、
UnitTestを導入するのはUnitTestを書きやすい
ロジック部分のみに限定した方が無難かも。

描画はほぼ不可能。UIの絡んだシーケンスは困難。
従来のASSERT、デバッグログの代わりに
Testメソッドを完備しておいて、実コード中で
Testすると多少便利になるというぐらい。

おおお。ゲーム系レスつかないとおもたら意外にも。thanx

>>152
やはり正面から対応すべきなのですね。ありがとうございます。
周りでは誰にも訊けなくて鬱々としていたところなので
救われた思いです。当方RubyUnitがメイン利用なので、
ちょっと試してみようと思います。

Rubyなら拡張するまでもないかも
p `cat result.txt` == <<"FILE"
aaa
bbb
ccc
FILE

なんか、
2ch上でペアプログラミングしているみたい >>154-155

>>149
ゲーム系描画ライブラリもUnitTest導入し始めています。
最初にフレームバッファの内容をキャプチャして画像ファイルに出力するモジュールを
書いておきます。
あとは描画機能を追加するたびにテストシーンを作って描画結果をファイルにセーブ。
描画エンジンを修正するたびに同じテストシーンを描画してファイルと比較。

先日もエンジンの高速化作業でマトリクス計算を微妙に間違えていたのを事前に発見
できました。

UIがからむもの、アニメーションがからむもののテスト方針はまだ模索中です。

おおお。
最初にキャプってテストは考えはしましたが、
本当にやっているところがあるとはー。

>>157
おおおお！まんせー！！すばらしい！！
158と同様に、157をホメテアゲタイage

ちなむとどう素晴らしいかというと、
「安易」な方法ではあるけどそれが確実で低コスト
であるのは間違いない、つまり
リーズナブルでベストな選択だ、って点が。
勝手ないいぐさで御免だけど。

>UI、アニメーション

逆にいえばそれらがテストツールにかけることが容易になればいいんですよね。

ふとWindowsMetaFileやDisplayPostscriptを思い出したんだけど、
つまり最終出力データ(=ビットマップ)じゃなくてそういうメタデータとして
表示とかを表現することにしておき、それ(多分適度に小さいだろう)のレベルで
比較するとかいうやり方でテストを行うと、いけるんじゃないだろか？

下記スレでなぜか、ゲーム系XPの話題が(ｗ

『ゲーム作品、きちんとテストプレイしてます？』
http://tako.2ch.net/test/read.cgi?bbs=2chbook&key=991063240&st=27

eXtremeあげ

UnitTestの手法?に関しては、まだ模索状態ですね。
今、シミュレーション系の数値計算プログラムを作っているのですが、
出力が(ある程度わかるとは言え)未知なので、
UnitTestが少々難しい感があります。

簡単な数値なら、実数値の誤差がどのくらいまでならOK、
というテストもあるので多少助かりますが。

＃あぁ、眠い。頭まわらないのでヘタレカキコでスマソ

リファクタリングにはまってしまい、
新い機能がなかなか追加できません

まあ自分の作った危うい設計のまま機能追加するのは、
いつかやばくなるのは分かってるんだけど、
先にすすめないのは結構きついっす

コードが大分スッキリ分かりやすくなったんで、
未来は明るいとは思うし、これからあたしくプログラミングするときに
前より綺麗な設計が出来るようにはなるとは思うんだけど・・

当たり前なんだけど、リファクタって環境問題のノリに似てるような。

汚染垂れ流しをやめれば必然的に素の成長速度は落ちるが、
かわりに持続可能な成長ができる見こみが増してくる、
長い目で見ればお徳、って奴。

というわけで、めげずにがんばれ>>163


>>162
そうか。「目的」自体が試行錯誤状態のプログラミングでは
うまくいかないかぁ…。
XPって「ゴールがあるから頑張れるの法則」に通じるところがあるから…

>>164
けど、試行錯誤しながらテストコードもしっかり書きましたよ。
その後のリファクタリングをしたんですが、
テストコードは、本体の大事な支えなんだな、と改めて実感。
＃そしてテスト中毒への道をまっしぐら(笑)

XPって、(チーム)スポーツに
雰囲気が似ていると思ったのは、漏れだけ？
なんかみんなでスクラム組んで努力友情勝利って感じ。
勿論けなしてるんじゃないよ。

未だにシミュレーション系の数値計算プログラムをコーディング。
1つは完成したけど、もう1つが厄介者。

最初に完成したと思っていたプログラムには
重大な、しかし出現率が少ないレアバグがあったため
数時間書けてバグ探し・・・

UnitTestが書けるところはしっかり例外含めてテストしていたので
そこにはバグが潜んでいなかったのですが、
シミュレーション部分はテストコード書きにくいので放置していたら、
そこにしっかりとバグが居られました。
テストが書きにくいプログラムってイヤ(涙)

たしかに、イテレーションして答えが出るまでに数週間
なんてなソフトだと(シミュレーションじゃザラでしょね)
UnitTestどころの騒ぎじゃないかも。

「実行してみりゃ判るべ」という超帰納的な手法は
時としてアダになりますね。
おいそれと実行できないものを検証することができない
ということになる。

XP-jpに、
>長い間待たされた、XP Seriesの残り2冊が発売されたようです。
とあったけど、これはなんと言う本なんでしょう？
知ってる人います？

>>169

同じくXP-mlより。
一部を転載。

>洋書の，"XP Examined" と "XP in Practice" です．
># Installed の日本語版はもうすぐ！
>Examined は多くの記事の集合体．in Practice は実践例ですね．

数値解析シミュ完了。
いろいろここで愚痴ってすみませんでした。

けど、UnitTestはシミュレーション部分以外、
つまり入力と得たい出力がはっきりしているから
非常に役に立ちましたよ。

DelphiマガジンでDUnitの記事でてるね。
source forgeのDUnit使えばいいのに。
http://dmj.psnet.ne.jp/books/ISBN4-939049-16-7.html

誰か、CUnitを使ったことがある方居ますか?

俺自作して使ってるよ

俺も。

具体的な実装方(or ソース)きぼーん。
サンプルは多いほど参考になるので。

RubyUnitを知ってまもなく作った
自作のMatrixクラスと、それのテストコードなら
サンプル程度で公開してもOKですよ。

ちなみに何故自作か?というと
標準のMatrixクラスの存在を知らなかっただけ(wara

http://www.geocities.co.jp/Playtown-Denei/1491/testMatrix.zip
今見ると、なかなか恥ずかしいソース。
テストコードを見ると、何をしたかったのかがわかると思います。
多分。

>>1
than〜x!!

Delphiのテストコード
Unitは使ってないみたいだけど
http://www.geocities.co.jp/SiliconValley-Oakland/9028/src/MonaUtils20010427.lzh

>>180
monazillaのプロジェクトの一部っすよね。
はじめ見たとき、やけにテストコードしっかりかいてるとおもたら、
XPだったんやね。

JUnitを使い出していきなり疑問が。

MyAppTestを作って、
MyAppクラスのなかのprivateなメソッドをテストしようと
思ったのですが当然無理

MyAppTestにテストコードを入れるのはいやなんです。
基本的にpublicなメソッドを（もしくはpublicメソッドを使って）
テストしろってことなんでしょうか？
なやんでしまって、テストコードがかけない状態です

privateメソッドをユニットテストの対象とするかどうか？というのは
結構議論になっていますね。

XP MLのアーカイブ

http://objectclub.esm.co.jp/ml-arch/extremeprogramming-jp/

が参考になると思います。

すいません、既出でしたね。
よいリソースありがとうございました。
いろいろ調べてみます

プライベートメソッドにする前に、そのメソッドのテストコードを書いて、
テストがいい感じであれば、
・テストコードをコメントアウト
・メソッドをプライベート化
しています。
基本的にプライベート化してからは、そのメソッドのテストはしません。
できません、と言う方が正しいかな。

private,protectedなテストは必ずする必要はないけど、
publicなテストの前にちょっと書けると便利なことがある。
#ifdefしたりスコープいじったりしないでテストできるなら
できたほうがずっと良い。

上のほうでも書いたけどDelphiなら
普通にprivate, protectedメソッドのテストが書ける。
C#もinternalすれば書けそう。

ヘジ氏の言語設計はこのあたりの手抜き加減が絶妙だったりする。

>上のほうでも書いたけどDelphiなら
>普通にprivate, protectedメソッドのテストが書ける。
同一Unit(ファイル)内なら、アクセスできるの利用するんだっけか。

xUnitのように同一の目的・機能を持ったソフトウェア（ライブラリだけど）
をいろんな言語で書くってのはなかなかないのではないでしょうか
機能・テストの書きやすさの点でどの言語のUnitが優れてますか？

ポイントはリフレクション・例外・クラス・シンタックスシュガー
といったところでしょうか（Cはちょっと不利かも）。
あと関数型言語のUnitって見かけないですね。

>あと関数型言語のUnitって見かけないですね。

俺もちょうどさっきそれを考えていたところです(^^;

Unitじゃなくmain処理のテストはUnitTestじゃ無理だ、という話がありますが、
あれって「処理がずーっと流れるようなところ」のテストはしにくい、
という意味なんじゃないかと思っています。

OOPだとしばしば、処理をちょびっと走らせて、副作用たる状態の変化を
Object(多くはself)に書きこんで、終わるわけです。
少なくともそう書くことは奨励(^^;されてはいますよね。

で、関数型言語って未だに掴めてないんですが憶測するに、
「副作用たる状態を書き込んでおく」という感じに
ならない/なりにくい、のではないでしょうか？
つまり、なにをやらせても、"処理ずーっと型"になっちゃう。

個人的には、そもそもプログラムは「走らせる」からデバッグしにくく
なるんだ、と信じて(藁)います。
1繋がりのrunが長くなればなるほど人間の脳はそれを理解しにくくなる。
有名なHackerの言葉にもたしかありましたよね、
「DBのスキーマのよしあしは一目で判るが、
ルーチンのよしあしはなかなかわからず、バグが潜んでいても気づきにくい」
とかいう趣旨のが。

そういう意味で、runの単位をいかに短くできるか？の答えの1つが、
(狙ったか偶然かは知りませんが)OOPなんじゃないか、と思っています。
また、UnitTestも、そこ(処理単位が短い部分)を重点的にデバッグ
するための手段、なんじゃないかと思います。

最近妙に日経が肩入れしているのが気になる・・・

ニュースで「最近渋谷の街の若者にキックスクートというものがはやってます」
って出たころはもう下火

ってこと？

日経ねぇ・・・

おかげで会社レベルでも注目されてるらしいけれど、
日経に出ないと注目されない、ちうのはどうなんだ。

DDJみたいのが潰れて
.NET, デザインパターン, XPを数ページで
流しちゃうような日経が思いの外
強い影響力を持っちゃうってのもいやな状況だよな。

ど〜でもい〜けど特集記事コピーして
会社にばらまくのは違法行為だぞ > 某

>>194
絶版本の復刻署名サイトはあるようだが、
DDJ復刻は、どこのサイトで署名すりゃ
受けつけてくれるんだろう？(T_T)

たとえ時折ハズシ記事があったとしても、結局
DDJくらい萌えれる雑誌は、なかったんだがなあ…。

悔しくて悲しいのでage

>>190
「XPを」という意味ですか？
うーん。いいようなわるいような。
つーか、悪いなあ。

あんな力の入ってない記事ばっかり並べられてもねえ＞日経
「ソフト業界を、そういうレベルに留め置く」のが
目的なんじゃないか？とか思ってしまうよアレは。

日経は「分かってない上司を説得するのに使う雑誌」だな。

日経(の計算機方面)の雑誌は、つまり、「絵本」だよ。

大人が子供に寓話をソフトタッチな語りと絵とで
読み聞かせてあげる、あれ。

まるっきりハズしてるとは限らないんだけど、
やはり決定的に情報欠落しまくってる、あれ。

創刊！日経DDJ

>>198
それは復刊では？（タモリクラブじゃないんだから別出版社で出るか？）

>>194-197
「日経コンピュータ」2001.6.4 号はどうよ？

５社の事例によるケーススタディ、
ベック氏インタビュー、
12のプラクティスについての解説、など。
C3プロジェクトについても、あるていど紙幅が割かれているよ。
僕には、かなり参考になったよ。

どうでもいいけど、比喩(Metaphor)をしたおかげで
他の人が混乱しました、なんてことあったら面白いね。
どうしても例えが下手な人っていますし。

RADはやっぱりXPとは相性悪いのかな。 UnitTestといっても
のんべんだらりとRADするとドコがUnit(=単位)なのかワケワカになっちゃう。
Delphiみたいな言語系でフツーに作業してると
TForm1なんてなクラスに、とんでもなく多数かつ大量のコードが
へばりつくようになってしまう。

RADの前(藁)にRapidTestDevelopmentをしないと駄目、かな。

創刊！日経 Inside Windows

>>203
まじで？

ん?
結局真相は?

XPの真髄
http://www-6.ibm.com/jp/developerworks/java/010629/j_j-xp.html

XPで大規模開発は不可能か？
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20010702/1/

>>207
自称シロートだそうだが、
こういうしっかりした文章を書いてくれるなら
シロート大歓迎だな。

それどころか目から鱗だったよ。大規模という言葉の中身を
きちんと分析というか分割統治というかしている辺りが。

そうかあ。そういや俺の仕事も、モノそのものはデカイけど、
たいして多くない人数で、何年もかけてやってるなあ。
しかもチーム構成員が時折入れ替わるし(わら)、
客先で開発してるから客は既に巻き込んでいるわけだし。
実はXPに最適なんじゃねーのか？

ただ、自前言語のコンパイルの異様な遅さをどうにかしないと
UnitTestどころの騒ぎじゃないのだが(わら

あと、ObjectDBを使ったシステムって、
UnitTestするのは効率悪そうだな。
TearDownするときにDB上のObjectを片っ端から
捨てないとならん(勿論次回再び全部作り直す)わけだから。
しかもうちのシステム、Object作るのが凄く遅いのよ(T_T)

ObjectDBということで、足回りに某社製DBMSを使うんだけど、
こいつのライセンスの制約があるんで、
Installできる数に限界がある。

で、DBがきちんと組まれていないとmakeできないようになってるんで、
新たにコンパイルサーバー環境立てるとか、
ペアプロの脇で自分用練習コーディング環境を別に作るとか、
ということが思うように出来ない(T_T)

というわけで、ライセンスという奴も
時としてXPを邪魔するのだな(T_T)

今までの静けさから一転して
多くが投稿されていますね。

なんとなくage

JUnitのテストで、
緑のバーになるとかいうテストは、
GUIのテストですよね?多分。
CUIテストにはそのようなものがありませんでしたので。

＃どうにもJavaでGU関連をIいぢったことがない

MVCのViewがGUIというだけのような。

ちょっと過熱気味なのでココで一つ冷静な意見も
http://village.infoweb.ne.jp/~fwgf2942/process/Proc.CMM-XP.html

>>207
あの記事に対するコメント見るとかなり悲しくなるものもありますね。
せめて、XP っていうのがどういうものなのか勉強してからコメントしろよ…。

CMMとかPSPとかいっている人は、なんとなく（イメージで
申し訳ないのだけど）XPとかを興味をもっている人と「位置」
が違うように思う。（気のせいか命令口調/押し付け口調という
か...）失敗したときは、「おれ知らん、おまえらが間違ったんだ」、
成功したときは、「ほーれ見ろ、いったとおりだろおが」とか言われ
そうな感じ。

CMMもPSPもTSPも、いいこと言っているのはわかるし個人的に勉強
してはいるのだが、、、XPの方が身近に感じますね。
（肌の感覚が近いっていうのか、うーん。）
# ぜんぜん論理的じゃあないですね。

要は、213さんのリンク先の人とは住む世界が違うん
だろーなー、と。あーそー見る人もいるんだなー、
ってな感じです。

>>214
| ＸＰという表現を使っているが本質的には「オブジェクト指向開発技法」
| を使って、「インクリメンタル開発」を行うことを指しているのだと思う。

ってやつが強力ですな。モノを調べずに我田引水…。

>216
でも、そういう風に思っているひとがいるみたい……っていうか私の近くにはいる。
どう説明してあげればわかってもらえるんだろう……。

エキスパートによるエキスパートのための開発技法って事か。

結局は、現状の開発技法で上手くいかない人間が銀の弾を求めて飛びついて
やっぱり上手くいかないという結論に落ちてしまいそう。

現状で上手くいってる人間はあえて枯れていない開発技法には触れないだろうし。

納期の制約が厳しく無く、検収という概念も存在せず、いつまでもソフトウェアを
改良し続けられる環境なら役に立ちそうだな。

オープンソースとか社内開発とか…

>エキスパートによるエキスパートのための開発技法って事か。

どの辺からそう思われますか？

>現状で上手くいってる人間はあえて枯れていない開発技法には触れないだろうし。

そりゃそうでしょうね。

>納期の制約が厳しく無く、検収という概念も存在せず、いつまでもソフトウェアを
>改良し続けられる環境なら役に立ちそうだな。

そんなことはないでしょう。「納期がきても完成していないので
使用できない」よりも「予定していた機能のいくつかは完成して
いないがとにかく使用することはできる」方が顧客にとっても
ありがたいはずです。
＃ ただしそれが可能なように契約することは現状では難しい
＃ んですけどね。

それに検収の概念はありますよ。受け入れテストをすべてパスすれば
「検収」ですよね。

>> 納期の制約が厳しく無く
>＃ただしそれが可能なように契約することは現状では難しい

んだな。XP…というかその先輩(?)であるスパイラル開発の時点から
判りきっていたことではあるけど、
「納期」という考え方を古臭いスタイルのまま持ち続けることが
つまりソフトにとって無理があるわけで。

そういや土建系のアプリ作ったときは大笑いだったよ。
あっち業界お得意の、作ったものを写真に取って
「ほれ作りましたよ」という証拠とする、というアレを
ソフトでもやるのな。物理的実体の無いものを
どうせいっちゅんだ？一応動いている所のDisplayを
撮影しといたようだが。

しかも窓有りのクライアントソフトだけならまだしも、
画面なんか無い鯖っぽいソフトも有ったんで、
写真がとれなくて困った…という事態を避ける「ために」、
不要なのにわざわざ鯖側にもGUIをつけた、という。

古臭い(or不適切)なんだよ、あーゆーのが。
新しいワインを思いっきり古い袋に入れてるのな。

あーいうミスマッチをまず解消して欲しい。
IT屋に仕事させるならば。
なんでもかんでも「そのまま」IT化できるってわけじゃないのに。

>>221

>「納期がきても完成していないので 使用できない」よりも
>「予定していた機能のいくつかは完成していないがとにかく
>使用することはできる」

どちらも論外だとは思いませんか？
「納期通りに全ての機能を完成させる」のが当たり前ではないですか？
("ベスト"ではないです、あくまで"当たり前"です)

>>220

しかし、顧客がそれを望む以上はそれが僕らの現実でしょう？
XPは理想ではあっても、現実とのギャップが埋めきれてないと思いませんか。

自分が顧客の立場なら、やはり納期は設定するだろうし検収も確実に動作が確認
出来るまでOKはだせない。当然不具合は何があっても修正してもらう。
少しでも不安因子のある契約内容にはケチをつけるし、だらだら納期を延ばすよう
なら担当者も変えてもらう。

この業界、顧客の立場で仕事をするという姿勢が少し欠けているように思う。
ン千万の金額を払う相手に「作ってやる」という姿勢で仕事をしている人が
多いように感じます。

横道失礼。

>>221
＞「納期通りに全ての機能を完成させる」のが当たり前ではないですか？

XPは仕様をあらかじめ確定させたりはしないから、その前提はおかしい。
それに、顧客は要求を出すだけじゃなく、チームの一員として共同作業を
行うから顧客自身も納期の責任の一端を負うことになる。

＞だらだら納期を延ばすようなら担当者も変えてもらう。

そんなことしても万に一つも納期が早まることは有りません。
延びるにはそれなりの理由って物が有るんです。
あなたもしかしてシステム作ったこと無いんじゃ？

＞ン千万の金額を払う相手に「作ってやる」という姿勢で仕事をしている人が
＞多いように感じます。

「こっちゃ金払うんだから仕様のあいまいな所はそっちで詰めてよ」って態度
の客にうんざりしてるんすけど。
そういう客ほど仕様の矛盾点を「不具合」だって騒ぎ立てるし・・・

お互いのすれ違いを解消するためにも、チームに顧客を参加させるXPは
とっても魅力的だと思うけどね。

>>222
＞＞「納期通りに全ての機能を完成させる」のが当たり前ではないですか？
＞XPは仕様をあらかじめ確定させたりはしないから、その前提はおかしい。

別にＸＰで開発を進めるのが前提であれば、「その前提はおかしい」のかも
しれないが、結局はどのように契約するかが大前提にある、ということだな。

詳細仕様を決める上でのリスクまで考えれば、契約時点でちゃんと踏まえて、
契約を結ばないといけないんだろうな。考えさせられること多し。

＞「こっちゃ金払うんだから仕様のあいまいな所はそっちで詰めてよ」って態度
＞の客にうんざりしてるんすけど。

うーむ、うちがまさにそんなドキュソな感じだな。
結局設計まで委託したのに自分で詳細仕様まで自分でやってしまったが。

>>221がいいこといった。

>>「納期がきても完成していないので 使用できない」よりも
>>「予定していた機能のいくつかは完成していないがとにかく
>>使用することはできる」
>
>どちらも論外だとは思いませんか？
>「納期通りに全ての機能を完成させる」のが当たり前ではないですか？
>("ベスト"ではないです、あくまで"当たり前"です)

そういう契約ならね。
もちろん、その当たり前のことが出来ないリスクは常に存在する。
　・今までの契約
　　1年後が納期なら1年後に最初に契約した全機能をリリース
　・XPでの契約
　　1年後が納期なら、重要な機能からリリース

　としたとき、XPでの方がリスクが少なく、顧客の要望にも
答えやすいってことじゃないの？

>>225
でもどこかで真の納期が存在するんでしょ?
いったいいつになったら開発完了するのか不安になっちゃうよ。

>>221
典型的なそもそも論って気がするな。

仕様が決定すれば(実際の)納期もある程度決定可能になるけど。
「仕様が決定」ってのはＸＰ的にはどうなの？

>でもどこかで真の納期が存在するんでしょ?
>いったいいつになったら開発完了するのか不安になっちゃうよ。

「ソフトウェアは完成しない」
XP的に言うと、開発が終わるのはそのソフトウェアの寿命がつきた
時です。

>仕様が決定すれば(実際の)納期もある程度決定可能になるけど。
>「仕様が決定」ってのはＸＰ的にはどうなの？

仕様が決まっているのは、次回にリリースするストーリーまでの
分です。XP的な開発をするには、Fixed Priceな契約ではなく、
Time and Materialsな契約でないと難しいかもしれませんね。

>>228
(1)利用者の要求仕様は永遠に確定しない
(2)開発者の設計仕様も永遠に確定しない
(3)ソフトウエアは完成することがない

つまり、仕様は決定することはないし、納期も決定することはない。
しかし、現実にはお金とか納期とかの兼ね合いで完全では無い物を
「完成品」として納品する。

>>222
222にめちゃ同意じゃ。
XPは、昔から言葉にできなかった思いを言葉にしてくれたって感じだ。
すばらしい。

>>221
>「納期通りに全ての機能を完成させる」のが当たり前ではないですか？

どっちかってーと、それが「可能」かどうか？という問題じゃないかな。
CapableかどうかじゃなくてPossibleかどうか。
物理的(?)に可能かどうかっていう奴。

いっぱいいっぱい仕事してるはずなのに追いつかなくて
製品できません、という最悪の(だよね)事態を
避けるためにはどうすりゃいいか？という話であって、
客の要望「のみ」に注目してそれを満たすことが出来るかどうか
という話より、前の次元なんじゃないかな。

労働条件の話と似ていると思います。
客の要望のみを考えるなら、ストなんかしない(できない)のが一番。
実際、今みたいな労働者権利が保証されてない時代には
ストすることがすなわち犯罪(雇用者に損害を与えた！)と
判断されていたわけです。
でも今は、特殊な業種(笑)以外は、そうじゃない(ほうが良いと
法律でも認めてくれてる)わけでしょ？

つまり、「無茶いうなよ」ということ。
それ以前の段階をクリアしないと、とてもじゃないが
量や質を上げることなんか望めないんじゃないの？という。

>しかし、顧客がそれを望む以上はそれが僕らの現実でしょう？

しかし、それでも思うように(思うの主語はあくまで客と雇用者ね(笑))
作れないというのも、「僕らの」現実です。
天秤の一方ばかりを注目してても解決はしないでしょうね。

XPで…いやそれ以前の開発手法でも言われていたことだけど…
「客を巻き込め」って言ってるのは、そういう効果もあるでしょうね。
よいものを欲しいなら客もきびきび動きやがれ、ということ。

勿論、客には客の(僕らとは違う)役割があり、その役割をきびきびやれ、
という意味ですけど。こっちの仕事をやらせるってのは論外。

で、ならばどの部分を客に担当してもらうと効率が最大化するのかな？と
色々研究だかなんだかすることで、今のいくつかの開発手法は
成り立っているんじゃないかな。XPはXPなりに、その問いに対する答えを
用意している、と。

まぁ平たい日本語でいえば「技術の隣」を客に作業してもらう
という感じかなと思っています。技術そのものは僕らの領分。
その僕らが振るう技術に密着取材(わら)するというのが彼らの領分。

>自分が顧客の立場なら、やはり納期は設定するだろうし検収も確実に動作が確認

「管理」しちゃいたくなるんですよね、どうしても。
Linux革命本を引き合いに出すのはExtreme(笑)だとしても、
いずれにせよ、「管理(=尻たたき)」すればうまくいくのか？というと
そんなことは全然ないんですよね、技術系って。
技術的に確かなところからしか次の技術(=製品)は生まれないわけで、
その層をすっ飛ばして管理だけしても、しばしば焦りを増させるだけだったり。

>>221

XPって、その形態から見れば丸わかりだけど、
ケータイ(駄洒落か?)みたいに産みっぱなしでないとまずいデバイスには
適用しにくいですね。PCを代表とするような、ソフトの入れ替えが超楽な環境を
前提としているというか。
なので、ファームアップデーターを搭載しない限り、
ケータイ産業は(少なくともXPでは)救われない、
ということになるかな(笑)

あと、顧客が不特定多数の場合も、XPだと困りますね。
客を巻き込めなくなる。
オプソにでもするなら話は別ですが。そのほうが却って幸せだけどな(わら

なんか、「納期が守れないからXPを使う」とも読めるのだけど
それって危険じゃない?

それとも「なぜ納期が守れないか」の要因解析はみんな済ました
上での議論なの?

>それとも「なぜ納期が守れないか」の要因解析はみんな済ました
>上での議論なの?

その問いに対して、一般的(=案件に依存しない)かつ
ある面から見た1つの答えを仮定しているのが、
XPの存在原理なんじゃないの？

納期が守れない(XP立場から見て正確には「納期すら守れない」
と言うべきだろうな)守れない理由の1つとして
コレコレがあるよね、だから(この意見を認めるならば)
こうやって解決しようぜ、という。

で、その仮定が自分の現場に合っているかどうか？は、
自分たち(かコンサル屋)が測るんだろうね。

>>234
> 「納期が守れないからXPを使う」
XPにも納期はあるよ、ただ一気に納品するんじゃなくて
細かい納期があり、少しずつ納品する形態。

XPでも納期は守れない可能性はあるが、従来の形態よりも
納期が守れない場合、早期のアラームを出せる。

>233

ケータイって一番ＸＰを適用すべき環境なきがするけど。

・短納期
・客の要望がころころ変わる
・新機種の機能のほとんどは前機種の引継ぎ

>なので、ファームアップデーターを搭載しない限り、
>ケータイ産業は(少なくともXPでは)救われない、
>ということになるかな(笑)

ファームをアップデートしなくても、次期ロットでバージョンアップ
するとか、ソフトだけ異なる次バージョンを出すとか。

>あと、顧客が不特定多数の場合も、XPだと困りますね。
>客を巻き込めなくなる。

大概の製品の最終顧客は不特定多数だと思うけど。
最終ユーザ全員を巻き込まなくとも、マーケティング部門とかを
顧客にするだけで、開発サイドとしては、いいんじゃないのかな。

CppUnitの使用法について、
http://member.nifty.ne.jp/masarl/article/testing-framework.html
以外で具体的な説明の載っているページ在りませんか？

JUnitの方は色々見つかるのですが、Cppの方は中々見つからないです。

Englishでも良いですぅ〜

>>237
>ファームをアップデートしなくても、次期ロットでバージョンアップ
>するとか、ソフトだけ異なる次バージョンを出すとか。

顧客サイド(笑)に立つと、結局ハードごとのリプレース
か買い替えか、ってことになっちゃうわけねそれ。
それはちょっと寒いなあ。携帯の新製品出現ペース(3ヶ月だっけ)に
そんな意味があったとはなあ(わら

>大概の製品の最終顧客は不特定多数だと思うけど。

そんな…
一品モノを専らとするソフト屋の存在も
一応お見知り置きを。

>最終ユーザ全員を巻き込まなくとも、マーケティング部門とかを
>顧客にするだけで、開発サイドとしては、いいんじゃないのかな。

その程度で「いい」ということにしたら
eXtremeとは呼べないような気がする(笑)。

少なくともそれって従来と違わないわけだから。

中間搾取(笑)層の悪影響を最小限にするってのも
XPには含まれていると思えるんだが。
だからこそXPでは「客」と喋れと要求されるわけで。

>>238
http://cppunit.sourceforge.net/
にあだけじゃだめ？

>>221 みたいな「そもそも論」って、まともに software 工学を
学んだ & 現場で苦しんだ人のいう台詞じゃないような気が。

>>234
XPの根本的なところを誤解されているようですね。

納期（というかイテレーションの期間）は動かさず、
それを守るためにスコープをこまめに調整しよう、
というのがXPの思想です。

で、236さんも書いているように、早期にアラームを
キャッチできれば何か対策を打てるでしょう、と。

どんな職業でも顧客(素人)の視点ってのは大切だ。
それはソフトウェア工学どっぷりでも、現場で苦しみに悶えていても見えてこない。
自分から見ようとしない限り。

「XPエクストリーム・プログラミング入門」あたりでさえも注意深く読んでいれば
>>231の疑問がソフトウェア技術者として至極まっとうなものであり、XPの思想と
同じベクトルを持つものであることは理解できるはず。
しかし、それに対してあとに続くレスはあまりに的外れに感じる。
(むろんXPがその疑問に十分答えうる物である事はご存知のとおり。)

日本のシステム開発に顧客軽視の風潮があるのは度々感じる。
このスレッドでも「顧客を巻き込んで云々」「顧客にも責任を負ってもらって云々」
というレスばかりで、ではどうやって顧客を巻き込むか、顧客にはどんな形で開発に
接してもらうか、どうすれば理解を得られるか。という方向には議論が一向に進まない。

今作っているシステムは客先担当者が胸を張って導入できるシステムだろうか？
自分だったら使わないようなシステムを納入してないだろうか？
今作っているシステムは「誰のための」システムなのか。
以上を問いつづけながらシステムを作っている人間がこの日本にどれだけいるだろう？

とかく開発が泥沼に入ると顧客のせいにしたがる。
「やれこんなことは聞いてなかった。」「やれいまさらこんなこと言ってくるな。」
決して十分なヒアリングが出来なかった自分達を省みようとはしない。

XPという新しい(枯れていない)開発手法に対して疑問を挟む人間相手に否定のレスしか
付かないのは正直見てて気持ちが悪い。説くことも、同調する部分も無く一方的な否定。

まるで新しく与えられた玩具をうっとりしながら磨いている子供のようだ。
それが銀の弾丸だと信じ込んでいるんじゃないか？
まさか銀紙にくるんだチョコレートだとは、撃ってみるまで気づかないのだろう。
(決してXPがチョコレートだと言いたい訳ではない。)

なーんつったりして。
気にしないで。ちょと長文でエラそうなこと言ってみたかっただけだから。
sageとくし。

>気にしないで。ちょと長文でエラそうなこと言ってみたかっただけだから。

きみは、気にするに値しないことを、書いたわけか？
自分の書いたことが、気にするに値しないことだと思っているのか？

だとすると、まさにそこに書いているような
駄目な伝統日本的開発スタイルの片棒を
君もまた担いでいるだけのことだ、ということになるが？

いや、そうだというならば、それはそれでいいのだが、なんだかなあ。
つまり「誰のための」文章なんだこれ？(わら

ちなみに俺(たち)も
>自分だったら使わないようなシステムを納入してないだろうか？

申し訳無いがこれはしばしば言えてる。

てゆーか、既に入れてる大規模フレームワークなんざ
使わずとも、もっと遥かに簡単なプログラムで
同じ仕事をやれそうなものなんだが、
今更誰もそんな恐ろしい手戻りを提案できない(笑)。
大手何社も(=雁首揃えて)がぐちゃぐちゃ絡んでいるんで…

さて。
>どうやって顧客を巻き込むか

どうといっても俺はまだよくわかってないが、
少なくとも「利益が欲しいなら動こうぜ」とは
言えるんじゃないか？
こっちが糞ソフトを作ってやがったりはしないかを
監視するっつーか、な。

あちゃ。
>>244で>>231としてるところは>>221ね。

誰のための文章かって？
もちろん自分自身のための文章だよ。
だから気にしないで。

そういうときは、無敵のキーワード「とか言ってみるテスト」を使うのだ。

>>244
> ではどうやって顧客を巻き込むか、顧客にはどんな形で開発に
> 接してもらうか、どうすれば理解を得られるか。という方向には議論が一向に進まない。
XPに書いてある。
顧客はビジネス側の決定と、仕様の検証を受け持つ。
ビジネス側の決定とはタスクに優先順位をつけること。
例えば月末に行う処理は後回しにしようとか、
まずはデータ入力をしたいからそれを最優先で作ってくれとかを
指示できる権利と責任を持つ。
仕様の検証とは自分で正しいと思うテストパターンを用意し、
それに合格すれば受け入れる、不合格ならば突っ返すことが出来る。

> それが銀の弾丸だと信じ込んでいるんじゃないか？
銀の弾丸はない。
だが狼を少しでも管理可能にする方法を模索してはいけないの？

ときに、CppUnitのWindowsのバイナリってどっかにないですか？
VC5しか持ってない（金欠でVC6買えずVC.NET待ち）ので
コンパイルできないんス。

>249
あれそんなに複雑じゃないんだから手を入れてコンパイル通してみたら？
んでVC5用パッチを送ってあげれば喜ばれるよ。

てゆーかUnitって、バイナリのみ持っていても
かなり宝の持ち腐れだったりしないか？
あれこそオプソっていうかソース配布でないと
埒があかないもんだと思うんだが。

>>249
OS依存じゃなくてコンパイラ(のver)依存の問題なの？
だとすればVC6用のバイナリを貰ってしまったら使えない
のでは？つまりキミが求めるべきは「Windows用の」
バイナリじゃなくて「VC5用の」バイナリなんじゃなく？

>>250
そういえば、Windows世界においても、ここでいう意味の
「パッチ」と言う言葉は、広く理解されるようになったんでしょうか？
きっと直接的にはunixのpatchコマンドのことを指してる
と思うんですが。
ついでにいえばあの概念がないと開発って凄くやりにくいよね。

>>248
つまり、「なんか知らぬがなんでもかんでもスグに全部揃えやがれ」
などという幼児の駄々こねのようなことを言わない責任が
客側にはある、ということだな(わら
つまり、「現実的に」考えましょうっていう。

客の馬鹿さ加減まではさすがに付き合えないんで、
銀でなくて鉛で十分だから弾丸を使いたいもんです(わら

>251
>てゆーかUnitって、バイナリのみ持っていても
>かなり宝の持ち腐れだったりしないか？
そうでもないよ。使うだけならソースは不要だし、
ソースだとテスト失敗時に例外が発生すると
デバッガがUnit内部で止めてしまうのでむしろバイナリのみのほうが便利。

>そういえば、Windows世界においても、ここでいう意味の
>「パッチ」と言う言葉は、広く理解されるようになったんでしょうか？
Winにはpatchやそれに相当する標準的なツール・手法はないのでは。
せいぜいWinに標準でついているのはwindiff(ファイル・フォルダ単位の差分表示)くらい。
>250では単に修正されたソースか修正方法という意味合いで使っただけ。
個人的には差分なんかなくて毎回数メガのソースのアーカイブやり取りしたって
別に困らないけどね。

>個人的には差分なんかなくて毎回数メガのソースのアーカイブやり取りしたって

ほんとに個人的動機だな(わら
多数の人でやったら、変更の競合とか
色々考えないとならんことがある。

それに、人間どうしが会話するときには
差分って便利だぜ。「ここが変わりました」
ってのが一目瞭然だから。

少なくとも、unix流(あるいはもっとましなのが
あるならそれでもいい)のdiffとpatchは
win方面にも広まって欲しいな。
あ。diffってのはpatchファイルを「作る」ツール。
旧ファイルと新ファイルの差をpatch形式で出力してくれる。

ついでにいえば、ソースのver管理ツールと
diff/patchが連動できると、すごく快適だぞ。
ver管理ツールの内部では実はpatch情報しか保存してない。
その保存形態をexportするみたいな感じだな。

>>250-251
うう、どもッス。「内部コンパイルエラー」とやらがポコポコ出て
対処方法が分かんないです。ま、いろいろ調べてみますです。

自分達が抱えている問題が何かを分析整理する前に、ＸＰを導入しようとして
いる所はすべて失敗するでしょうね。

もし、一戸建ての家よりも、キャンピングカーで生活した方が快適で人間的だ！と
変人小泉首相がいったらどれぐらいキャンピングカー生活をはじめる人が
いるのだろうか。

XP,XPっていっている人って、地に足がついていない、ただの新しいもの好きばかりのような。

>>256
鋭い。耳が痛い。恐れ入った。m(__)m
たしかに、XP自体にも一定の守備範囲があるんで(エリアXP？)、
それと自分の問題とが合致してないと論外だな。

ただ、ここら界隈の最近の文で、その手の勘違いを
してると思われクンは、どれだけいたろうか？

>>255
VC5にサービスパックが色々出ていたように思いますが、
きちんと当てていますか？
VCの5だの6だのの出荷状態って、テンプレートのあたりで
バグ／使えない仕様がワンサカじゃなかったっけ？

>>258
>>256を「するどい」なんて本気で思ったの？本気で畏れ入っちゃったの？
だとしたら、重症だよ。完全にXP信者じゃん。
自分達の現状を省みずにXP入れたら何もかも上手くいくって思ってたの？

>>256の言ってることは当然のことだよ。

ソフトウェア開発はＸＰ的なやり方が向いているとしても、
世の中の多くのビジネスとは違うプロセスである所が、問題として残る。
そういう開発が出来ているところはすでにやっているとも言え、今まで
そういうやり方を出来なかったところがＸＰ的な開発プロセスでビジネス
をしていけるかどうかが問題ということ。特に、受託開発をＸＰ的な開発
プロセスでやっていけるのかどうかが、おおきな問題だと思う。
ここら辺解を持っている人がいれば教えてください。

>>259
当然だけど、経営的視点とかマネジメント的視点を持ち合わせていないと、
短絡的に「なんだかよさそう」「優秀な人がいいといっているからきっといいはず」
「新しいことはよいことだ」という発想の中で、気になって気になって仕方が無い
という人は、意外と多いものです。
まずは自分達がどうなりたいのかというのがあって、次に現在の問題を整理し、
次にその解決を考えるのは基本ではあるけど、どうありたいかも、問題を整理
することも簡単なことではない。簡単でないからこそ短絡的に、良さそうなもの
に飛びつくわけです。だれでも簡単にできないからこそコンサルタントという
仕事も成り立つわけだし、そういったコンサルティング的な仕事を社内または社外
でしている人がメーリングリストを立ち上げたりコンソーシアムを立ち上げている
のもまた当然。ただ、歴史を振り返ってみて、そういう人に頼ったプロセス改革で
うまくいったという事例がすくないのもまた事実。結局は、自分達の事を自分達で
真剣に考え変えていこうすることができるかどうかがすべてということです。
しかし、これがまた難しい。難しいからこそ、毎日、仕事に生きがいや遣り甲斐を
感じることなく、それでも一生懸命働いている人がたくさんいる。
そして、その中で、すこしでも今よりよくなればとＸＰなどの方法論に助けをもと
めようとする。しかし、これを繰り返している限り、生きがいや遣り甲斐を感じる
毎日にすることは難しい。
この悪い連鎖を断ち切り、まずは、自分達の足元を固める事が何よりも大切では
ないかと私は思います。
小泉首相がやろうとしていることととても似ているかもしれない。自分達の会社
の構造改革を政治も業界も同調しながら進めていくことを考えてみる事が日本人
として、今なら考えて良い時期で、絶好の機会かもしれない。
みなさん、がんばってくださいね。日本がソフトウェア大国になるようにボトム
アップの方向でもがんばっていくことができればと最近思います。

>>256
営業や経営に問題が多いということも多いしね （藁
経営陣を変えれないので、下の方にいつもしわ寄せがきて、新しい方法論で
なんとか乗り越え様と考える管理者って多いよね。

>>260
日経系の雑誌やらにXPがふつーに取り上げられるようになれば、
("春からはじめるXP"とかﾜﾗ)発注側からXP流ご指名で受託
できるのでわ？

>>263
そうなるといいね。
でも、ＸＰって人間系に重点がおかれるので、発注側担当の人格や
知識にプロジェクトが強く作用さるようになるのかもといくらか
心配します。
発注側に落ち度があっても、ハイ！さよならされると、安心して事業
計画を立てられなくなるので受託側では新たな問題を抱えそう。
どのような法的に認められる契約を結ぶかを考えないといけないでしょうね。
そういった面で、日経系の雑誌で乗れば簡単にそういう風潮になるとは
単純には思えない所も私はあります。

>>263
そうだ。日経に期待しているのはまさにそれだ。もっと
煽ってくれ。

顧客も共同責任を負うのが当然、という意識が少しでも
芽生えれば、どんなに我々は幸せになれることでしょう。
米国ではそういう意識はEC系を中心に結構広まってると
向こうのコンサルに聞きました。

要は、大金はたいてプロジェクトをキャンセルするはめに
なるより、積極的に協力した方が得だという考え。裁判で
違約金もぎとったところで、逃した機会は永遠に取り戻せ
ないわけで。

>>265
ヲレ、web front 系のお仕事では、顧客の曖昧なイメージを prototyping して
動くものを作って使わせて、新たに出た要望をまた実装してとかいう感じなんで、
最終的に出来るものがダメな場合は当然顧客にも責任が出るよって感じで開発
してます。

でも、もうちょっと積極的に開発プロセスに関わらせたい…。

ようやく余裕ができたので、今まで読み進められなかった
リファクタリングの本を、とりあえず6章まで読んでみました。

6章でのテクニックは、どことなくLispを思わせるコード改善だな、
という印象を受けました。
Lispに関しては、かじった程度なので間違いだらけかも知れませんけど、
一時変数をなるべく取り除き、メソッドに置き換える、とか、
パラメータへの代入の除去とかが、それに当たりますね。

メソッドオブジェクトによるメソッドの置き換えは、
伝家の宝刀のようですが、タイミングが難しそう。
通常手段のメソッド置き換えができないときなど、
最終手段として用いられるようですけど、いざその場になったら
メソッドオブジェクトなんて思いつくかなぁ?

Java Worldに、JUnitの特集が組んでありました。
そこで衝撃の事実が!
XPのプラクティスが、なんと2個増えている!!

知らなかったの、俺だけか?

UnitTest萌えage

XPエクストリーム・プログラミング導入編 ― XP実践の手引き
が、8月10日に発売されるそうですねage

VBマガジンでもＸＰのってたけど.....

�AｃｈのツワモノはVBなんて誰も使ってないようだ。

池袋西武のリブロにはもう売ってたヨage >>270

秋葉の書泉で買った

MLで話題になったぞage

どこのMLだよ>274
それともメタランゲージの方か？

>275
XP-MLです。>1からたどれますよ。

情報システム版にもＸＰのスレあり。

http://mentai.2ch.net/test/read.cgi?bbs=infosys&key=986909661&ls=50

>>271
VB使いで悪かったな。
荒らすぞｺﾞﾗｧ

>>270
>XPエクストリーム・プログラミング導入編 ― XP実践の手引き

コレ、めちゃくちゃ良かったよ。
今後も、XP関連の書籍は、この訳者が担当して欲しいなぁ。

>>279
俺はまだ始めにを読んでるよ

>>278
よかったという意味は、実践に使えそうだと判断したと思っていいですか？
この本amazonでやたらと売れていますね。日本は大丈夫かよ？

ユニットテストについて一言。

全クラスの全メソッドに対してやるのは、非現実的だね。
やってみれば分かる、テスト作ってる時間の方が長くなっちゃう
んだよ。

あとassert文いくら沢山つくっても、多くのメソッドには
良いテストにならない。何故かを言うと、クラスのメソッド
の多くは、インスタンスの状態を変化させる為の物で、
そのブラックボックスの状態変化の効果は、その後の複合
したメソッド呼び出しのみ、認識しえるから。

でも使える部分も沢山あると思う。staticなメソッドは
必ずテストメソッド作るべきだし、凄い役に立つね。

ペアーも新人と経験者は一緒にやるってのはいい発想だと
思う。

よかったといえば訳がよかった、
自動翻訳通したカンジじゃなかった。

眼鏡っ娘K.K.ちゃん萌え〜 あげ

http://piza2.2ch.net/test/read.cgi?bbs=tech&key=998619229&ls=100
そっちのスレよりも先に出来ておりますage

>>282
｢失敗しそうにない｣ことはテストするな、ってことね。
テストが要るかどうかについて先入観を持ってしまうと
良くないとは思うが。

関数型言語とUnitTestって排他的なものなの？
むしろ相性がよさげに思うんだけど。

>>282
>staticなメソッドは 必ずテストメソッド作るべき

なぜstaticメソッド(Classメソッドって意味だよね)だと作るべきなの？
Instanceメソッドでテストなくてもいいやつがあり、
一方Classメソッドでテストが必須、ってのは、なぜ？

>>287
UnitTestを作らなくても、ある入力に対する出力が一定
(参照透明性ね)なので、別に作らなくても楽な予感。
とりあえず排他的ではないと思う。

>>282
全クラスの全メソッドのテストを書く必要が無いのは同意。

>テスト作ってる時間の方が長くなっちゃうんだよ。
でもこれを理由にテストを却下するのは疑問。
テストを書くことで品質が上がるなら、実装よりも時間をかけても
問題ないと思う。

全クラスの全メソッドのテストを書く必要がないと思うのは、
いわゆる80-20の法則で、一部のメソッドへのテストを書くだけで
大きな効果があり、残りのメソッドのテストは効果が少ないと
思うから。

クラスメソッドと静的メソッドを分ける発想はなかったので、ちょっと
新鮮。どちらかというと、「ではクラスメソッドのテストはどのように
書くべきか」という方向で議論したほうが生産的かな？

テストを省略するのは単純なget/set系と
そのメソッドを呼んでいるメソッドのテストが
しっかりなされている場合かな。
で、上位のテストに失敗したら
あと付けで細かいテストを追加してく。

むしろ迷うのは異常系のテストをやるかどうか、
やる場合どこまでか、という所。
迷ったらやる。という方針にしてもなお迷ってしまう。

bimyou ni functional-programming thread de
hanashi ga deteta

age

グラフィックオブジェクトのテストなんかも書くの？
何度回転したらこういう座標になるはずだとか。

書かない理由は？

　　　 　 　 ∧ ∧ 　／￣￣￣￣￣￣￣￣￣￣￣￣
〜′ ￣￣( ﾟДﾟ)＜　 見た目テストをやればいいんでないの？
　 UU￣￣ U U　　＼＿＿＿＿＿＿＿＿＿＿＿＿

　　その見た目テストコードを書くという事が重要デスデス
　　それを人が見て確認する。

>書かない理由は？
書けますか？、、書いてみせて欲しいな。
難しいと思うのですが。

>書けますか？、、書いてみせて欲しいな。
>難しいと思うのですが。

え？
そのグラフィックオブジェクトって「座標」というメンバがいくつかと、
そのアクセッサと、rotate()みたいなメソッドがあるようなものでしょ？

だったら、一般的なパターンを２つくらいと、特異パターンをいくつか
書けばいいんでないの？

「グラフィックオブジェクト」といえばコレみたいな何かがあって、
俺がそれを知らなくて、激しくはずしてる？

　　　∧∧　　　／￣￣￣￣￣￣￣￣
〜''~（,,ﾟДﾟ）　＜　あー。グラフィオブジェ＝何らかの座標を持っている
　 UU'UU　　　 ＼のでしょうか。

　単に画面に描画処理だけを行なうものと思ってしまったのですが

　そうだとすると、見た目以外で
　テストが通るか通らないかを判断する手法はないかと
　思ったのですが…

　ドット(?)のOn/Offでやるにしても
　テスト書くのもその検証もちょっときつすぎるような。

　もちろんテストがかけないはずはないんですが
　目で見るテストというのも場面によってはアリかなと思うてます。

うーん、294さんに内容を聞かないとなんとも言えないけど、UnitTestしよう
というんだから、自作のクラスだろうし「回転」というメソッドと材料（メンバ）と
アクセッサがあれば、必ずなんらかの（正常パターンだけでも）テストが
書けると思うんだけど。

Directホゲホゲみたいなのを使ったものだと、確かに厳しいかもしれないね。

今だ！300ゲットォォォォ！！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

　UnitTestとは言ってないと思われ。

　描画オブジェクトだとすると
　描画が正常かどうかをテストしないとテストの意味がなくないですか？

　どのようなテストを想定されてます？

　折れは、こういう場面では
　画面にぐるっと一回り文字を描画するテストを書こうと思います.

>UnitTestとは言ってないと思われ。

Σ（ﾟдﾟlll）ｶﾞｰﾝ

>　描画オブジェクトだとすると
>　描画が正常かどうかをテストしないとテストの意味がなくないですか？

んと、「描画オブジェクト」が思い浮かばないのでパス。

　　　　　 ∧∧　　／角度指定フィールドとDrawメソッドが存在するだけのクラスです
　＠' ― (,,ﾟДﾟ) ＜　＞描画オブジェクト
　 　し― し-Ｊ　 　＼
　　ｱｯｻﾘ ﾊﾟｽ ｶﾖ・・・

リファクタリングの自動化ってできないの？

　　　 ∧ ∧　　 ┌────────────
　　 __(,, ﾟДﾟ)＿＜　トリッキーな質問したアナタにはこれを贈呈
　／　/　づ　／| └────────────
. |￣￣￣￣|／ 　 http://www.assiston.co.jp/item/0182_propellercap.html
　　　　　　　　　　　ｶﾌﾞｯﾄｹ

>リファクタリングの自動化ってできないの？

こんなのありますよ。
Martin Fowlerの本「リファクタリング」に載っているので知っている人、多いでしょうけど。

Refactoring Browser
ttp://chip.cs.uiuc.edu/users/brant/Refactory/

ただSmalltalk用っていうのがねー

GUI用テストフレームワークみたい
英語読めない馬鹿なので内容は判らなかった

Java FAQ (What's New)
ttp://www.nk-exa.co.jp/~andoh/java/javanew.htmlより引用

>[ TOOL ] mattcas, Swing ベースのアプリケーションのための Unit test tool [ JFCUnit 0.2.1 ] をリリース
>ttp://sourceforge.net/projects/jfcunit/

Haskellという有名な関数型プログラミング言語のテスト用ライブラリ

QuickCheck: An Automatic Testing Tool for Haskell
ttp://www.cs.chalmers.se/~rjmh/QuickCheck/

っていうのがあります。
テスト用のコードさえ書けば、型システムを使ってテスト用のデータが自動生成され関数の動作テストされます。
かっこいー

>>305
http://www.refactoring.com/
を見てたら
http://www.instantiations.com/jfactor/
http://www.intellij.com/idea/
というのがあるらしい。jFactorはJBuilderのプラグイン。

AssertRange(int value, int min, int max)
{
　Assert(min <= value && value <= max);
}

AssertRange2(int value, int min, int max)
{
　Assert(min <= value && value < max)
}

これらのテストメソッドの適切なメソッド名・引数名はどんなんでしょう？

IntInRange, IntInRange2 ???

>>309
それ、メソッドに分けずに直接ソースに assert() 埋め込んだ方が良いと思うが。
assert に引っかかったときに、AssertRange(), AssertRange2() のファイル名と
行番号が取得できても嬉しくないでしょ。

kent beck来日記念あげ

で、何かニュースはあったの？>>312

>>313

帝国ホテルで公演があって観にいった。
内容は、xpの紹介程度。
あとその日のXP-mlOFFにも出現したな。
OFF逝った人感想きぼーん

age

12のプラクティスで

>比喩(Metaphor)
>どの様に全体のシステムが機能するかを示すシンプルな喩え話(メタファー)を
>メンバーが共有することで全ての開発を導く（ガイドする）。

ってあるけど、喩え話ってのが今ひとつ意味分かんない…だれか教えてください。 (´_｀ )

例えば、ファイルを圧縮するソフトをXPで開発するとしたら、
どんなメタファーが考えられるのでしょうか？

>>316
XP-jp ML に丁度メタファについてのスレッドがあるよ
http://objectclub.esm.co.jp/ml-arch/extremeprogramming-jp/2400/2490.html

　　∧,,∧∩　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ミ,,ﾟДﾟ彡　＜　しつもーそ
　　U　　ミ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　ﾐ　　ﾐ
　ノ∪∪

　12のプラクティスの箇条書きってどこかにありますか？
　

>>1 のリンクのFAQってトコにあるはず

　　∧,,∧　 　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ミ,,ﾟДﾟ彡　＜　ありがとございます。
　 ,;ﾞ　　ﾐ　 　 　＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　ﾐ.　　ミ
／゛゛゛゛

もひとつｼﾂﾓｿ
オンサイト顧客のオンサイトってどういう意味ですか？

>>319
お、そのFAQの下の方を見ると、

白XP本（既刊）
ピンクXP本（既刊）
緑XP本（既刊）

の後に、

オレンジXP本
水色XP本
黄緑XP本
紫XP本

の４冊が翻訳中ですね。
誰が翻訳してるんだろう？（あの人はヤだな）

>>320
オンサイトって十分日本語化してると思うんだけど、そうでもないのかな？
「開発現場の（にいる）顧客」
というような意味。

ふと思いついて、本家XPサイトに行ったら、リニューアルされてて
Toppageがいやにスッキリしてた。

で、面白そうなもの発見（今まで気づいてなかっただけか？）。

XP Magazine
http://www.xprogramming.com/xpmag/index.htm

翻訳するのめんどいから、誰か訳してくれないかなぁ（ヘタレ）。

　　　　　　　　　＿＿＿＿＿＿＿＿＿
　 ∧,,∧　　 ／
　ミ；ﾟДﾟ彡＜　いまさら、超ガイシュツかもしれませんが
　 ﾐつ　つ 　＼ 白本の誤訳みたいのを
〜ﾐ ,,　ﾐ.　　　　修正している所ってどこでしたっけ
　 ∪∪　　　ﾋﾟﾝｸはリンク先にあるようですが。

改めて白本を読みましたが
技術書籍の翻訳としては
叩かれるほど変でもないような気はしました。

むしろ、日本ジンが書いた日本語なのに読みにくい
技術解説の方がよっぽど嫌かも。

>>324
それもリンクされてるよ。

Essential EC Kent Beck の Embrace Change 本関連
EC 本要約 essential-ec.html (by ホソカワ, 矢崎, 上手, 佃, やまの)
EC 本，邦訳(XP エクストリームプログラミング入門)へのコメントec-errata.txt (by 小野 剛)

ってとこ。

＿＿＿_∧ ∧＿ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＿＿＿ミ,,ﾟДﾟﾐ＜　どーもー。>>325さん、ｻﾝｸｽｺ
＿＿ ミ ⊃ つ　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿〜ﾐ,,　,,〃
＿　∪ ∪

XPに出てくる４つの変数のスコープって何ですか？

　　　∧∧ 　↓こいつは赤外線ｽｺｰﾌﾟ？
　　 ミ,, ﾟД⊆0＿＿＿,,
　　　ﾐ⊃二O,---'￣￣
　　　ﾐ 　 ﾐ
　　　.∪∪

http://objectclub.esm.co.jp/ml-arch/extremeprogramming-jp/0/85.html

スコープ ー （そのスコープが顧客の問題を解決しているのであれば）控えめのスコー
プは質の向上に繋がります。それから、納期を前倒しすること、または、安く納品す
ることができます。

ソフトウェア開発で一番意識していなければならないのが、スコープです。スコープ
を積極的に管理できれば、マネージャーや顧客にコスト、質と時間を管理させられま
す。

スコープの凄いところは、しばしば変化するという点です。要件が最初から明確になっ
ていることなど一度もありません。顧客は何がほしいか一度も正確に言えたためしが
ありません。

　　　∧,,∧ 　ｾﾞﾝｾﾞﾝ ﾜｶﾗﾝ
　　 ミﾟДﾟ,,⊆0＿＿＿,,
　　　ﾐ⊃二O,---'￣￣
　　　ﾐ 　 ﾐ
　　　.∪∪　赤外線ｽｺｰﾌﾟは夜でも見えるんだぞ(多分)
　　　　　　　オサマもイチコロ。

http://objectclub.esm.co.jp/ml-arch/extremeprogramming-jp/2200/2206.html
> > の第 4 章で「スコープ」という用語が出てくるのですが、意味がわかりません。
> > 　scope を英和辞典で引いてみると「(知力・研究・活動などの及ぶ)範囲、視野」
> > とありますが、そういう意味でいいのでしょうか。

> これは，「XP エクストリーム・プログラミング入門」を読んでだ
> れもが疑問に思うことだと思います．私も最初分かりませんでし
> た．

> スコープ: リリースに盛り込む機能の範囲．何を今回のリリースに
> 含めて，何を後回しにするか，ということ．XP では，プロジェク
> トを管理する4つの変数として，コスト，時間，品質，スコープを
> 挙げており，中でもスコープをコントロールしてプロジェクトを「運
> 転(steer)」すべきだ，と言っています．

　 ∧,,∧　 　　 ／
　ミ,,ﾟДﾟ彡　 ＜　だってさ。参ったね。
　 U　 U　　　　＼
〜ﾐ　　ﾐ
　 ∪∪

>>328
どこまでやるかっていう範囲のことだよ。

そうそう、このプロジェクト(またはリリース)では何を実現するか、もしくは
何を実現しないか、っていうこと。

ほんとはこれが決まっていないと納期も金額も決められないはずなのだが、
いいかげんなまま見切り発車するプロジェクトが多い。

age

sage

>>331
最初に正確に分かるはずがないから、
少しずつ修正しながら進めよう、ってのがXPでわ。

客が欲しいタスクをイハ°イ書く
→プログラマ達がそれぞれのタスク作成にかかる期間を見積もる
→客が、どのタスクから作るか決める

次のリリースまでに欲しいものが全部入らないとき、
どれを入れるかは客が決める。

最終期限までに入らないとき、機能を削るのか期間を
延ばす（もっと金をかける）のかは客が決める。

良くある「安くしろ、機能は削るな、納期は延ばすな」という
不毛なやり取りはなくなる…はずだが、こういう金の出し方
をできる客が日本にどのくらいいるかは不明。

　　　∧∧　　　／どのくらいの企業が
〜''ミ ﾟДﾟミ　＜　　XP採用や採用検討しているのでしょうね。
"UU'UU"　　　 ＼

こういう先進的な技法を率先して取り入れる力のある
ソフトハウスってSRAくらいしか思いつかん。

SRAってソフトハウスだったのか。

XPを導入する上で一番のネックは実は案件の受発注のやり取りじゃないか？
日本じゃ何が何でも最初に金額と納期を決めようとするが、そのくせ要件定義で
出た話と金額が見合うかどうかなんて殆ど考慮されてない。
最近やった仕事でその辺を痛感したんで、その辺の問題意識をもってる営業さん
と共同戦線を張ろうと画策中。

激同。
On-site customerと並んでネックだね。

まずは社内開発プロジェクトから始めてみるのかなあ。

　　　∧,,∧　　　／￣
＠,,,ミ,,ﾟДﾟ彡　＜　お客さんの実行する機能テストというのは
⊂,,,,,,,,,つつ.　　 ＼どういうものをさすのですか？

>>340
例えば「この入力を与えたら、こういう帳票が出力されないと困る」
というのを顧客が（ワープロやエクセルで）数値まできちんと書いて、
それをチェックするテストはプログラマが書く。

>>341サンクスコ
　なんかイメージ湧きませんが
　客もテスト作って、すぐリリースされたものを使えや(ﾟДﾟ)ｺﾞﾙｧ
　ってところでしょうか。

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　　ﾍﾞﾝｷｮｳﾍﾞﾝｷｮｳ
　　ミ,, ﾟДﾟ彡
　　 〃つl⌒|⌒l
　〜ﾐ,,［￣￣￣.］
　　　　 ￣￣￣
　もっとXPの話題でてこないかな。

>>342
テストケースを作るのはオンサイト・カスタマー
つまり、プログラマ・チームといつも一緒にいて
指示を出してる顧客だよ。ユーザはまた別。

　∩∧,,∧∩　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ﾞﾐ,,ﾟДﾟ彡ﾉ　＜　スラッシュドットage
　　ミ　　ミ　　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　ﾐ　,,　ﾐ
　ノ∪　∪

http://slashdot.jp/article.pl?sid=01/10/29/1719222

ファシリティというのは
日本語訳すると何？

>>345 Facility 辞書で引いてみよう。

http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=Facility&sw=0
まぎらわしいな。

>>345

オフィスレイアウト、座席配置ってことだと思う。
個人の席を隅、ペアプログラミング用の席を部屋の真中に置いて、
みんなで共同で使うと良いらしい。

うち会社、席が広いのは嬉しいんだけど、
パーティションで区切られてて、人がまばらに居る感じ。
孤独で寂しいし、ペアプログラミングしにくい…。

>>347のリンク先を見ると
設備，　施設という訳が正解みたいだね。

ところで、
継続した結合のインフラが重要と本に書かれてあるのだけど

継続した結合の為のインフラというのはどういうものがありますか？
WinDiffやVSSを思い浮かべますがそういうもののことですか？

>>349
俺の意見。

・いつでもクリーンビルド出来るマシン（高速のものが良い）
・バージョン管理ソフト（CVSがおすすめ）
・自動インテグレーションの仕組み（オプション）

かな。

>>350レスありがとう。

>・いつでもクリーンビルド出来るマシン（高速のものが良い）
クリーンビルドって何？

>・バージョン管理ソフト（CVSがおすすめ）
これはわかるが

>・自動インテグレーションの仕組み（オプション）
自動インテグレって？

>>クリーンビルドって何？

すべてのソースをコンパイル、リンクすることでしょう。大規模な
システムでは高速なマシンでないとやってられませんな。

>自動インテグレって？

最新ソースを落として、ビルドを実行し、できればすべてのテストを
実行してその結果を報告するまでを行う。

タバコが嫌いなので
喫煙所パターンXPとか言ってる輩は殺していいですか？

>>353
喫煙もエゴですが、嫌煙もまたエゴです。
殺すときはあなたももろともに。

分煙のためにプロジェクトを分けてください

嫌煙の方がまだましでは？

>>356
50歩100歩の50歩の方だな。目くそ鼻くその目くその方かな。

目くその方が上か･･･

VC5.0でCppUnit1.5使えてる人います？
今度のプロジェクトはVC5.0を使うことになってしまった。
ちょっと試したんだけど、謎のRuntimeErrorが・・・（泣

使えてるとか、使えないよ、というレベルで良いので、情報が
あったらお願いします。

海老捨て目に聞けば？

>>359
同志よ。吾輩も使えておらぬ。
いまさらVC6買うのもアレであるし、
気長にVS.NETとサービスパックを待とうぞ。

>>361
うう、そうですか。
VC6はあるんですが（仕事なんで）、今回はVC5.0指定なんです。

今まで、JUnit, RubyUnit, PHPUnit, JSUnitを使ってきて、
VCもそのときインストールしていたVC6でcppunit（CppUnitじゃ
ないほう）を試して、「今回のプロジェクトもxUnitは楽勝でしょう」
なんて言っちゃったんですよ。

CUIのほうだったら使えるのかな。来週試してみよう。

エピス氏に聞いてみようかな・・・。

ケントべっ君は本の中で
クライスラーＣ三のシステムが、ああでこうでこうなっているよ

と度々おっしゃっていらっしゃいますが

そのクライスラーというのは
どの程度の規模の会社で

C3というのは
どのくらい重要度の高いシステムなのでしょうか。

XPを上司に紹介する時に、
クライスラというネームバリューがあったら
XPの実践を説得しやすいかと思いますので

具体的にどのくらいでかいんだぞ。と
枝葉末端に至るまで偉大さを分からせてくださるような
情報キボンヌ。

Extreme Programming / Chrysler C3 Payroll article from the October 1998 issue.
http://www.xprogramming.com/publications/dc9810cs.pdf

Chryslerは今はDaimlerChryslerになってるね。
サイト見てみると従業員は 416,501人(2000年末時点) か。でかい…

>>361, 362
VC5.0 は template をまともに使えません。
CppUnit は template を使います。たぶん
VC5.0 では CppUnit をコンパイルするだけ
でエラーになると推測します。

ていうかクライスラーってやっぱ、あのクライスラーだよな・・・

Java で Input/OutputStream を
継承した解凍/圧縮ストリームの
ユニットテスト書きたいんですけど

　ExpandInputStream(InputStream in) extends InputStream {
　　read() で解凍された1byte読み出し
　}

　CompressOutputStream(OutputStream out) extends OutputStream {
　　write() で1byteを圧縮して書き込み
　}

みたいなストリームって
どうやってテストしたら良いんでしょ…

>>368
まず圧縮して解凍して問題なければもんぢあなし

>>369
やっぱ そーゆーテストの方法しかないっすよね…

手動で圧縮済みデータ作って比較。

>>371
手動で圧縮済みデータ作るの大変そうだなぁ…
はっ 良く考えたら手動で作った圧縮済みデータの
正当性検査はどーしたら？

それは良いとして、 それ以外のチェックって
ストリームの補助機能のチェック
ぐらいしか思いつかんのですけど、
read(int data) で data が 256以上でもちゃんと処理されるとか
mark() / reset() のサポート/非サポートが 仕様どうりかとか
available() の戻り値はOKかとか
それ以外ってチェック項目ありますかねぇ…

>>372
Javaは知らんが、圧縮をどうやってやるのかによる。
自前のロジックを組むなら、圧縮されたデータの正当性の検査は出来ると思う。
既存のライブラリを使うなら、圧縮済みデータを作ることは容易だと思うけど。

>>372
>それ以外ってチェック項目ありますかねぇ…

自分が実装しようとする（あるいはしたもの）についてテストすれば良い。
異常データのときに、ちゃんと異常処理されるか、
期待した例外がちゃんとthrowされるか、とか。

　　　　　　　　　＿＿＿＿＿＿＿＿＿
　 ∧,,∧　　 ／
　ミ；ﾟДﾟ彡＜　解凍ツールで解凍したら・・・
　 ﾐつ　つ 　＼
〜ﾐ ,,　ﾐ.　　　　￣￣￣￣￣￣￣￣￣
　 ∪∪　　　って独自の圧縮形式だったらダメだけど...

　圧縮/解凍して元のデータとの整合性を
　チェックすればいいだけでは？

圧縮プログラムなんて、圧縮後のサイズが元より小さくて、圧縮したデータを正しく復元できれば、多少間違ってても要件を満たしてると思うなり。。。

圧縮/伸張処理自体も自分で書いてるものなら、いろんなパターンの
データを食わせてきちんと復元できることを確認しないといかんね…
同じバイトばっかり並んだやつや、欧文、日本語文テキスト、exeファイル、
乱数列、とか。

元が小さい場合、ヘッダ付加の分サイズが膨らむこともよくあるから
常に小さいかどうかってのはアレだが。

ロジックが十分複雑な場合、圧縮解凍して元に戻ればよい
というのはブラックボックステストであって
ユニットテストではない。

ExpandInputStream/CompressOutputStream内部で呼んでいる
メソッドについてテストを書くことを検討してみたら。
テストを書くのが簡単になってその上デバッグが楽になるよ。

結局、誰が翻訳者としてよくて
誰が翻訳者としてダメなわけですか？

ピンク色の本は翻訳はよくても冗長で分厚くなってしまっているのでは？

>>376
＞圧縮プログラムなんて、圧縮後のサイズが元より小さくて、圧縮したデータを正しく復元
＞ できれば、多少間違ってても要件を満たしてると思うなり。。。

圧縮済ファイルをもう一度圧縮するとサイズがでかくなるよ

>>380
たとえば、lhaとかは圧縮結果をまた圧縮して
これ以上小さくならないところまで圧縮を繰り返す
なんて聞いたことがあるんだけど、ホント？
そういうアルゴリズムなら再圧縮しても大きくならない
ような気もするけど、圧縮ロジックの中での再試じゃないから
やっぱりヘッダなりなんなりが付加されて大きくなるかな？
元ファイルがこれからしようとしてる圧縮形式と同じもので
かつ圧縮後もやっぱりちいさくならないようなら
圧縮しない（もしくはしたフリ）でファイルに手を加えない
ってロジックは欲しいかもね

>>380
おなじアルゴリズムで2回圧縮したらどうしたって1回目より大きくなっちゃうんじゃないの？

VC5でcppunitが使えました！

cppunit-xという奴です。
http://member.nifty.ne.jp/glad/cpp/test/

ただし、USE_LEAK_CHECKERを有効にすると、コンパイルできません。
（oeprator deleteの引数の数が違うと怒られる）

「eXtreme Programming テスト技法」
http://www.shoeisha.com/book/detail.asp?bid=1304
という本が発売されていて、その中でcppunit-xも紹介されているそうです。
（でも、この本、長瀬氏監修なんだよな・・・）

この本は、まだ買ってないので、評価は出来ません。

自分が質問したような「変換用ストリームの検査方法」の「確
立した検査方法」とかあるのかな？とか思って質問したんです
けど、やっぱり正攻法でやるしかないみたいですね…
Base64OutputStream とか作ってる人いるみたいだし、
そーゆのあるのかなぁ…とか思ったんですけど。

>>381
>>これ以上小さくならないところまで圧縮を繰り返す
ってのは違います。LHAは名前のとうり LZ77 圧縮した結果を
Huffmanで圧縮して終わりです。
個人的な経験では圧縮２回目は圧縮率９？％で圧縮できます。
でもこの圧縮率はヘッダの大きさ含んでないので書庫サイズ全
体としては１回目の圧縮後より大きくなってる可能性もありま
す。もちろん圧縮失敗する可能性もあり、その場合は「圧縮前
より大きくなる」のでなく無圧縮で格納しなおします。その場
合は確実にヘッダ分だけ書庫サイズは増加します。

普通は解凍に手間と時間がかかるだけで、意味が無いので二重
圧縮は嫌われます。たしか bzip2 だったかは二重圧縮に比較
的強いと聞きましたが自分は試したことが無いので、どの程度
「強い」のかは知りません。

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview05.html
http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview06.html
この二人のどっちがいいのかな。

　　 ∧,,∧∩　　　あらためてDUnitのこと効いてもいいですか？
　　ミ,,ﾟДﾟ彡　＜　そもそも、Unitテストの使い方がサパリわからないですー
　　 U　　ミ　　　　猫でもわかるUnitテストを教えてキボーン
　＠ﾐ　　ﾐ
　　 ∪ ∪
DUnitは二つあるみたいです...

DUNIT Am Xtreme testing framework for Delphi programs
http://dunit.sourceforge.net/
DUnit - Delphi Testing Framework
http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/index.htm

下のほうは日本語のチュートリアルついてんじゃん...
それ読め

>>386
>>383 の本を読んでみたら？

>>386
その二つのHPをちらっと見たところ、前者がxUnitのDelphiバージョン、
後者はUnitTestingの精神にのっとった、独自バージョンつー感じがした。
（ダウンロードして試したわけじゃ無いので違うかも。つーか、Delphi知らんし（藁）

まずやるなら、前者の方がいいかも。xprogramming.comでもpreferredに
なってるし。

いちおう、こんなページも見つけた。
http://www.toymap.net/fightingpg/fighting.htm

しかし、GoogleでDelphi&DUnitで<b>約17件</b>とは・・・。

>>387さん　キビシイですな...

>>388さん
[XP-jp:02767]でさりげなく無視されてたり

>>389さん
xUnitもよくわかなのですが、なんとかやってみます。

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　　ｻﾝｸｽｺ
　　ミ,, ﾟДﾟ彡
　　 〃　 つ旦~~
　〜ﾐ,,,ｎ,,ｎ［￣￣￣.］
　　　　　　　￣￣￣

んで、何がxUnitの特徴なのかというと（OOPL以外のxUnitは使ったこと
無いので除外）

・TestCaseがクラスになっている
・それぞれのTestCaseの前後で、setUp(), tearDown()というメソッドを
　呼び出すことになっていて、そこで、準備、クリーンアップが出来る。
　なので、それぞれのTestCaseが独立している。
・TestCaseをまとめる、TestSuite（テスト一式）という概念がある
・オブジェクト（クラス）の情報がわかる言語では、Testメソッドを自動的に
　順番に実行してくれる
・テスト実行（TestRunner）はGUIバージョンとCUIバージョンがある。
　GUIのほうは必須ではない。
・テスト結果がオブジェクトである。
　よって、結果に自由にアクセスできる。

つー感じ。

>>390
なるほど。XP-jp で無視されたら読む価値なしか。

>>392　違うがな！

うーん、いまチュートリアル読んでるけど
http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/tutorial/writing_code.htm
なんか説明が難しい。

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　
　　ミ,, ﾟДﾟ彡
　　 〃つl⌒|⌒l
　〜ﾐ,,［￣￣￣.］
　　　　 ￣￣￣

だ、、だめだ
>>386の下の方、どうやってもフサには理解できん..

　　 　　　∩,,,,,,,,,,,∩ ,,,_
　　　〜⊂｀'''''''''ミ｡Д｡ミ⊃
　　　　 　｀'''''''''''∨ ∨ 　　　ｱﾎﾞｰﾝ

つーか、上からやれって。

>>394
無茶苦茶簡単ですが？
サンプルに以下のコード追加したら普通に動きましたよ
Del6Personalで確認

unit testDUnit;

interface

...

function Plus(a, b: Integer): Integer;
function Minus(a, b: Integer): Integer;

type
TMyTest = class(TTest)
published
procedure testPlus;
end;

implementation

...

function Plus(a, b: Integer): Integer;
begin
Result := a + b;
end;

function Minus(a, b: Integer): Integer;
begin
Result := a * b; // バグ有り
end;

procedure TMyTest.testPlus;
begin
Test(Plus(1,2), 3, 'Plus1');
Test(Plus(1,-2), -1, 'Plus2');
Test(Minus(4,2), 2, 'Minus'); // バグ有り
end;

initialization
TestSuite.Add(TTestTest, [TTestNone, TTestSuccess, TTestFailure, TTestError, TTestException, TTestProfile, TTestExecute
,TMyTest]); // <-追加
end.

エラーレポート
Test failed - Minus
TestName: TMyTest
Type: Integer
Actual: 8
Expected: 2

お、Delphi使い登場ですな。

ところでDUnitはテストコードとテスト対象コードを分離することは出来ないの？

http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/tutorial/writing_test.htm
↑ここまではわかるけど

http://members.jcom.home.ne.jp/monazilla/shortcuts/DUnit/tutorial/condition.htm
↑ここで
procedure TestとかTestNとか
fooとかTMyTestとか定義も説明も一切無いのになぜわかるのですか？

　　　∧,,∧　　　／￣
＠,,,ミ,,ﾟДﾟ彡　＜　うーん、>>396さんの説明とチュートリアルに一切接点がみられないのですが...
⊂,,,,,,,,,つつ.　　 ＼＿

unit testDUnit; じゃなくて
uses testDUnit？？

>>397
一緒に合ったほうが分かりやすくない？
リリースコンパイル時には分離できるのだし。

procedure Test(msg: String=''); overload; // 無条件に成功
procedure TestN(msg: String=''); overload; // 無条件に失敗
右にあるコメント見れば一目瞭然な気が

overloadしまくりなテストメソッドって大丈夫なの？

>>399
俺はDelphiも知らない全くの外野ですけど（汗

一緒にあると、バージョン管理がヤじゃないですか？
テストコードを更新すると、テスト対象のバージョンも上がってしまう。
あと、ドキュメント自動生成をやろうとしたときに、両方一緒だと邪魔だとか。

いや、ただ、それだけなんですけど・・・。

>>400さん、いやｾﾞﾝｾﾞﾝわかりません。

沢山あるソースのどこにTestが定義されているのかもわからないし
そもそも、そのprocedureを自分で書くのか、利用するのか？
という事も伝わらないです。

procedure TTest.Test(Actual, Expected: Integer; msg: String);
begin
　　if Actual = Expected then Succeed
　　else Fail(IntToStr(Actual), IntToStr(Expected), 'Integer', msg);
end;
かろうじて、このソースを見てからなら意味はわかるのですが...

　　　∧,,∧　　　ﾑｽﾞｲ...
＼,,,,ミ,,ﾟДﾟ彡　　五里霧中の中を突き進むような試行錯誤です。
⊂,,,,,,,,,つつ.

そもそもXPのユニットテストに精通している人間にしか
Test手続きが、評価する関数だって理解できないですよ。

procedure Testって、TTestのメソッドだってのも
どうやって、あのページから類推するのでしょう？

>>401さん、たぶん大丈夫(分かりにくいかもしれませんが)
>>402さん、選択できるといいですよね。
基本的にはテストコードはテスト対象コードと一緒にしておく方が
よいと俺は思っています。

>>401
名前同じで引数だけ違うものを複数書くときにoverloadと記述するんだけど
"大丈夫"って何が心配なの?

>>402
テストコードを含めてのコードじゃないかな。特に XP の test-first な視点では。
typo 一つでも commit するときはしなきゃいけないので
バージョンが上がるのは気にしない。

ドキュメントの自動生成は面倒だね。
これも気にしないことにしてるけど（ｗ、
生成ツールにテストコードを omit するオプションつけてくれると嬉しいね。

>>403
そのDUnitがxUnitの精神を忠実に実装しているかどうか知らないけど、

xUnitは、
・テストケースを書く仕組み
・テストケースをハンドリングする仕組み
・各種チェックメソッド
・テストを実行する仕組み
・結果をハンドリングする仕組み

を含んでいる。
つーか、本買ってきて読め。
あるいは、Java, C++, VBを知ってるなら、JUnit, CppUnit, VBUnitのドキュメントを
Googleしてみろ。つーか、使ってみろ。
Ruby知ってるならRubyUnitだな。256倍本も出てるし｡

xUnitの枠組みは、簡単で、誰にでも分かるもの（OOPLの場合）。
・提供されたチェックメソッドを使って、提供されたTestCaseクラスを継承したテストコードを書く。
・提供されたTestRunnerでテストを実行する。
・提供された結果表示機能を使って、結果を確認する。

ただそれだけだ。

この石井氏の記事はどうよ。
xUnit が理に適った作りをしていることが分かる。
http://member.nifty.ne.jp/masarl/article/testing-framework.html

>>405
そういうもんかな。

今まで使ってきたxUnitが全部TestCaseは別ファイルだったから、
違和感を感じるだけかもしれない。

そもそも、コードとテストコードが同一ファイルにあるというのが、
古くからの伝統だったので、xUnitで分かれたのはそれなりの
理由があったのかもしれない。

単に最初の（ほんとか？）のJUnitがJavaであるがゆえにそうなった
というだけかもしれないけど。

>>408
自分のコードみたら言語によってまちまちかも。
分けた方が全体的な保守性はいいのは確かだね。

あんまり詳しく読んでないので怪しいけど
このDUnitのクラス構造ちょっと変わってるね。

TComponent <- composite
　+ TTest <- この時点でテストを階層化してる。こいつを継承してテストを書く
　　+ TTestSuite <- テストの(階層的な)実行、レポート、singleton
　　+ TMethodTest <- TTestの個々のメソッドをオブジェクト化、テストメソッドの呼び出しを担当。テストメソッド毎にもテスト結果を持てる。

あとプロファイラなんかの拡張機能もTTestに突っ込んである。

TComponentって事は登録してフォームに貼り付けてGUIテストもできるのかな？
# ソースではregisterしてないけど

つーか、どっちのDUnitの話なのか明示しやがれ、ｺﾞﾙｧ。
つーか、同じ名前を付けんじゃねーぞ、ｺﾞﾙｧ。
>>386では”DUNIT"ってかいてるけど、ソースフォージの表記は"DUnit"だぞ、ｺﾞﾙｧ。
つーか、>>383の本買ったぞｺﾞﾙｧ。
まだ読んでねーぞ、ｺﾞﾙｧ。

CRCカード使ってる人いますか？
使い勝手どうですか？

WindowsXP発売記念age

それは創刊！スレでやってくれ

perl_unitを使ったことのある人いませんか？
make testでエラーがでて困ってるんですけど
なんとかなりませんか？
あと使い勝手はどうですか？

　　　

eXtremeあげ

極限age

だれか書き込んでage

プログラミング以外の作業にもXP使えないかな。

最近興味を持ち始めました。
webをまわってみても実際に何をするのかがいまいちつかめなかったので
とりあえずXP入門の本から読んでますが、珍妙な訳にくじけそうです。

実力があって、頭の回転という意味でも人間的にもデキルやつで、
性格もよくて、将来に何の不安もなくて、毎日楽しく生きてる、
ようなプログラマーが集まれば、勝手にＸＰになります。

>プログラミング以外の作業にもXP使えないかな。

(デジタルなどのおかげで)成果物の「完璧コピー」がとり易い分野であり、
成果物の「ただしさ」がはっきり定義できる分野ならば、
ほかでも使えるかもね。

プログラム以外で、そういう意味でデジタル化されてる分野ってーと
なにがあるでしょう?

とりあえず思いつくのが、音楽とかの芸術分野と、設計図分野。

でも芸術は「ただしさ」が定義できないんで、
UnitTestとかが意味をもたない(藁)

設計図はいけるかもね。
実際、大企業むけのシステムでは最近、(リモートでだけど)複数人間による
図の同時編集なんてのが行なわれている。もちろんVer管理もあるし、
間違いも定義可能なのは言うまでもない。
なのでUnitTestもRefactoringもPairProgもできる。

>勝手にＸＰになります。

それは言えてるかも。
馬鹿なやつは下らない(有害無益な)管理方法を採用してデスマーチに嵌っていく。

どこまでUnitTest使えてます？
ウチでは，UnitTestって言うくらいなんで，当たり前だけどIntegrationTest（組合せテストね）
では全然使えません。何が言いたいかって言うと，単純なクラス以外は適用が困難で（つまり
テストのための準備が大変すぎて）実行時テストの方が工数的に妥当だよね。
ファイルやネットワークやモジュール間通信をするクラスなんかはこれに当たることが多いなり。
で，単純なクラスってなると大抵，基礎的なクラスで，そうそういじらないと。新しいプロジェクト
じゃない限り枯れてる事も多いと。逆に上位のクラス（アプリクラスって言ってるけど）では，適用が
大変だと。むにゅー，どこに使うなり？適用事例求む。

>>424
禿しく同意。
cppunit 拾ってきて、UnitTest の環境作って
テストクラス書こうとして、1行目で挫折しました。

>>424
俺は出来るところだけテスト書いてる。だからテストが書けるのは10%くらいかな。
でも最初にこれをやることが肝心。いちどコンパイルのサイクルの中にテストが
入ってくれば徐々にテストは増えていく。1ヶ月も続けるとテストなしでは不安を
感じるようになったよ。
「テスト書いたから実行時テストは要らない」にはならないんだから、すべてを
網羅しようとしないことが大切だと思う。

>>426 同意。
テストユニットは几帳面で完璧主義な人には向かない。
テストユニットは動作保証というより、
コーディング前にテストを用意することにより、
設計検証として役に立つ(ことがある)。
テストを作ると「この仕様だめじゃん」とか気付く。

　実際、どんな所でテストユニットを使いましたか？
　具体例を交えて話題が出ると
　スレも盛り上がるかと…

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　ｵﾚ ﾊ DUniｔ ｦ
　　ミ,, ﾟДﾟ彡　　ｲｷﾅﾘ ｻﾞｾﾂ ｼﾃﾙﾝﾀﾞｹﾄﾞ....
　　 〃つl⌒|⌒l
　〜ﾐ,,［￣￣￣.］
　　　　 ￣￣￣

ユニットテストをしやすいクラス、しにくいクラスという話で、
テストしやすいクラスは設計の筋がよいという経験則をよく聞きます。
例えば値を計算するメソッドと、それを表示するメソッドを分けるとか。

ひょっとして関数型プログラミングの副作用をなくして参照透過性を保つとい
う考え方に通じるものがあるんでしょうか？

dunitもcppUnitも普通に使ってるよ。

論理処理とユーザーインターフェイスの分離は前提だよな。
そしてユニットテストは論理処理の側だけに書く。
XP的にはユニットテスト書くのが困難ならリファクタリングすべきだと思うけどどう?

>>424
>テストのための準備が大変すぎて）実行時テストの方が工数的に妥当だよね。
「実行時テスト」というのは初めて聞いたけど、どういうものなの？
「テストのための準備」というのを、テストをやるたびにしなきゃならないなら、
多少工数がかかっても、UnitTestを書いておいたほうがいいと思う。

>ファイルやネットワークやモジュール間通信をするクラスなんかはこれに当たることが多いなり。
これも、

>逆に上位のクラス（アプリクラスって言ってるけど）
これも、UnitTestは可能だと思うけどなぁ。

ちなみに僕は、ほとんどの場合、下位クラスはstubに置き換えて結合して、
UnitTestをやってます。
んで、下位クラスが出来たところで、結合してUnitTestを実行。

>>426
>1ヶ月も続けるとテストなしでは不安を
>感じるようになったよ。
うんうん。

となりのチームは、コンパイルもせずに、ダーっとコードを書いて、
山のようなコンパイルエラーが出て､それをちまちま取って、コンパイルできて、
動かそうとしたら全く動かなくて途方に暮れてるみたいだけど、
こんなやり方で、良く集中力が持続するなーって感心する。

>>427
>テストユニットは動作保証というより、
>コーディング前にテストを用意することにより、
>設計検証として役に立つ(ことがある)。

そう？
僕は動作保証の為にUnitTestを書いてるけど。

だって、穴のたくさんあいたTest Suiteだと、リファクタリングも怖くてできないし、
他の人の作ったのなんて、怖くてメンテできない。
そんなことない？

あ、僕はUnitTest依存症なんだと、今気づいた。

で、ペアプログラミングってやってる人いるの？

もう一人の人格と話しながらやってます。

CppUnit1.5 を VC++6.0 で使おうとしていて困ったことが。

サンプルに付いてくる HostApp はMFCアプリですが、自分が
テストしたいのはコンソールアプリです。コンソールアプリから
TestRunnder::run() を呼ぶとダイアログを表示するところで
エラーが出でしまいます。

マニュアルによるとTestRunner.dll のようなMFC と動的にリンクされる
レギュラーDLLではエクスポート関数の先頭でAFX_MANAGE_STATE
マクロを使ってモジュール状態を切り替える必要があると。

で、このマクロをつかうと今度は DllMain の多重定義のエラーが
出てしまい、いろいろ調べまわってみましたが同様のエラーに悩んで
いる人はたくさんいましたが解決法が見つかりません。

だれか解決法知っている人いませんか？

>>435 コンソール版の TestRunner が付いてなかったか？

>>435
http://member.nifty.ne.jp/glad/cpp/test/
こちらがよいと思われますぞ。

>>436
コンソール版の TestRunner というのはみあたらないですね。

>>437
実は最初に cppunit-x を使ってこれはちゃんと動きました。
プアな環境でも動作するようにつくってあるということで
独自のマクロを使っているので、VC++6で使う分には CppUnit1.5
のほうが分かりやすいと思ったのでそっちも試してみたのでした。
あと結果の表示がグラフィカルで見やすいと思ったので。。
「eXtreme Programming テスト技法」でも主に cppunit-x が
紹介されてましたが、みなさんこっちをつかってるのですか？

あり？わしが使ってるのはコンソール版なんだが、
これは CppUnit1.5では無いのか。
TextTestResult.h/cpp ってのは入ってないかい？
若干手を加えたので、どれがオリジナルか判らん状態。

C++Builder5にCppUnitCBをインストールしたんだけど、
サンプルのSmartPtrTestが予期した動作をしてくれないっぽい。
起動すると、「Unknown test class: TestSuite」ってダイアログが出て、その後もフォームこそ出るけど、その中のボタンを押しても反応無し。

どなたか、原因を知っている方いらしたら、よろしくお願いします。

CppUnit1.5 の TestRunner がコンソールアプリから使えない件で、
TestRunner.dll がレギュラーDLLであると書いてしまいましたが、
拡張DLLの間違いでした。拡張DLLの関数を呼ぶことができるのは
MFCアプリだけということなので、今のままではコンソールアプリから
CppUnit1.5 の TestRunner を使うことはできないみたいですね。

たびたびすまんです。
SourceForge から CppUnit1.6.2 をひろってきたら TextTestRunner
や TextTestResult というクラスがありました。これを使ったらOKでした。
>>439 ありがとう！

チーム全体で使ってみた所の感想が聞きたいんだが。
誰かいない？

>>443

これは読んだかな？
http://objectclub.esm.co.jp/eXtremeProgramming/XpPracticeReport.html

>>444

ありがと。
読んでみた。
なかなか面白そうだと思ったけど、444のリンク先は、実際のプロジェクトとは少し離れ過ぎている気もする。

実際のプロジェクトでやってる人の感想とか聞いてみたいなぁ。
UnitTestやリファクタリングは自分でやってみたのでどんな感じかわかるが、
ペアプロとか毎回誰がどこ組むか決められる(共同所有)、とかそういうのがうまくいくのかどうか。
なんかこんなにうまくいかなさそうな気がするんだよなぁ。

顧客周りはいってもはじまらんのでどうでもいいや。

まえにどっかの雑誌でインタビューしてたよ
でも全てのプラクティスを実行したわけじゃなかった
例えばペアプロ->一人で組んで、もう一人がコードレビューとか
雑誌名忘れちゃったな。日経ソフトウェアだったかな？？？

毎日ペアプロしてますがなにか？

毎日もう一人の俺とペアプロしてますが、なにか？

　∩|
　ﾐ ﾞ''ﾞﾞﾞつ
　ﾐ∧,,∧　　　／￣￣￣￣￣￣￣￣
　ミ,,ﾟДﾟ彡 ＜　いきなりシツモンなのですが
　Ｕ　Ｕ　　　　＼＿＿＿＿＿＿＿＿

ピンク色XP本の
P180の完成したストーリーグラフ図の

５番と６番のところに黒色の塗りつぶし分がないのが
なぜかよくわかりません。

なぜでしょう。

現在、イテレーション４を終了した所なんでしょう。

　　 .∧,,∧　　／￣￣￣￣￣￣￣￣￣￣￣
＠'"ﾐ,,ﾟДﾟﾐ ＜　サンクス
　UU''UU　　　＼＿＿＿＿＿＿＿＿＿＿＿

あら、ご無沙汰してます>>Error401さん

では
5になれば
自動的に75以上のストーリーが完成するという事でいいのですか？

妙に日本語訳が意味通じない気がしますが
適当に感じたらいいのかな。

>>451
>あら、ご無沙汰してます>>Error401さん

ちょっと前にデータベーススレで切れてしまったので、コテハンは
やめようと思ってたんだけど、文体を変えるのが面倒なので復活
させることにしました。

>5になれば
>自動的に75以上のストーリーが完成するという事でいいのですか？

でしょ？

それから、あそこで言いたいのは、
・トラッキングせよ
・公開せよ
・ストーリー数が増えている理由を把握せよ
ってことでしょう。

>妙に日本語訳が意味通じない気がしますが

さっきP179-P181を読み返してみたけど、意味が良くわからない
ところがありました。
最初に読んだときには気にならなかったんだけどね。っていうか
精読してないし・・・。
気になる箇所があったら、しかるべき所にメールしてみればいいかもね。

ってゆーか、XP実践記でてるじゃん。
http://www.pearsoned.co.jp/washo/object/wa_obj46-j.html

んで、さっき買ってきた。
Servlet+JSP+DBのWebアプリケーションを例にしてるみたい。

パラパラとめくってみると、具体的な（完全な）コードがかなり
載ってる。ほとんどがServletのだけど。

なかなかよさげだよ。

実践記まで翻訳なのかよ
日本人で書ける奴いねーの？

結構良い本だと思うけど、リファクタリングの結果、Servletとしてはダメなコード
にしちゃっている。訳注でちゃんとフォローしているからいいけど。

>>453の本、面白かったよ。
翻訳も良かった。こなれた日本語になってる。

ところで、XPを「究極の〜」といってる人をたまに見かけるけど、
アレ、何か元ネタあるんでしょうか？

コードに仕様変更があったりするとあちこちのテストを
修正しなきゃならないってのはテストとしてよくないんでしょうか？
ここを変えるとするとああここもあそこも…って感じで
ちょっとげんなりです。

>>456
ミスター味っ子

>>457
テストとしてよくないというか、プログラムとしてよくないというか…
変更が波及しています。スメルがバッドです。リファクタリングのサインです。

でも、ある程度は仕方がないと思う。

>>456
Googleしてみたら、テクノロジックアーツのページなんかで、
extremeを「究極の」って訳してた。
「究極のプログラミング」と言われると、ちょっと違和感あるんだけど・・・。

>>457
なぜ「あちこちのテストを修正しなければならない」ことになるんでしょう？
それがわからないと、なんとも言えません。
ひょっとしたら、テストコードのリファクタリングが必要なのかも。

foo()がbar()を呼び出していて、bar()に仕様変更が入り、その結果foo()の
挙動も変更になるので、foo()のテストもbar()のテストも変更する必要がある、
ということなら、それは仕方が無い。

XP本で、「究極の」って訳してる所があったかなぁ？
暇なときに探してみようかな。

なぜこのことが気になるかというと、
「XPって究極のプログラミングと言ってるが、どこが”究極”なんだよ」
みたいな批判をするのを、たまに目にするから。

っていうか、『XPエクストリーム・プログラミング入門』の副題が、
「ソフトウェア開発の究極の手法」
ってなってました（汗

そうかー、そうだったのか。
僕はずっと、「なんでも極端にやる、極端流プログラミング」だと思ってたのだけど・・・。

>>454
>実践記まで翻訳なのかよ
>日本人で書ける奴いねーの？

平鍋派と長瀬派が対立してるので難しいのかも、などと思ってみる。

# 対立してる云々は全くの想像。
# テクノロジックアーツじゃなくて、テクノロジックアートでした。スマソ。

ペアプロで意見が対立した場合どうしてます？

いまの会社では激しい論争を起こしても問題のない人ばかりなのでよいですが、
そうでもない環境ではどうなんでしょう。

例えばどういうことで対立する？

対立するとしたら、設計の重要な部分だろ。
他のメンバー集めてスタンドアップミーティングすれば良いだろ？
すぐにミーティングが開ける環境を作るというのも極端なプログラミング
を行いために重要だと思う。

重要な部分で無い点で、相棒と対立した場合は、あなたが折れましょう。
どうで大したことじゃないんだから。そんな所に力を注ぐことは無い。

>>459
>変更が波及しています。スメルがバッドです。リファクタリングのサインです。
>>460
>ひょっとしたら、テストコードのリファクタリングが必要なのかも。

レスどうもです。やっぱりそうですね…。
クラスの結合テスト的な部分でよくこうなるんですが、クラス自体の
機能はそれぞれのユニットテストにまかせて、結合部分ではインターフェイス
のみテストするようにした方がいいのかな？ スタブで置き換えて、正しく
引数が渡されてきてるかチェックするとか…。

とりあえずCppUnitを試してみようとはじめてみたのですが、
ちょっと疑問です。

内部状態を遷移させ状態を元に処理をディスパッチするようなクラスメソッド
をテストする場合ってなにか有効なテストの書き方があるのでしょうか？

従来のUTでは状態遷移マトリクスを書いて、通しやすいセルから埋めて行き、
通しにくいパスは、試行錯誤しながら時には強引に状態を制御しつつ全パス
のチェックを行っていました。

CppUnitでテストをする場合もやはりこういったマトリクスから、全パスが
通るようなシナリオをひねり出してテストクラスに埋め込んで行くのでしょうか？
かなり負荷が大きいような気がしますが。
そんなものなのでしょうか？

テスト専用に、内部状態を直接いじる方法を用意するのって、ＸＰ的には、反則？

いろいろと論議を呼ぶ話題だな、それは。

XPむずかすぃ

　Stateパターンで各状態に対する処理をオブジェクトに分離し、
それぞれのオブジェクトを直接ユニットテストする。
　それらのState objectから別のStateへの変更を起こすようなアクションが呼べるように
親Interfaceを定義しておく。
　UnitTestではそのInterfaceをテスト用に正しく呼ばれたことを記録するだけにして、
その記録をassert。

　みたいにやっとるよ。

　 ∧,,∧　　　 ／　めおけあー
　ミ,,ﾟДﾟ彡　＜　 新年も、XPでいきまっしょい。
Π￣￣￣|　　＼
|つ 新ﾈｿ ()　　　
| |＿＿＿.|
　　∪∪

ピンク本のP242の
インテグリティーってなあに？

唐突ですが、教えてちょ。

integrity constraints

　∩ ∩
　ﾐ ﾞ''ﾞ〜
　ﾐ∧,,∧　　　／￣￣￣￣￣￣￣￣
　ミ,,ﾟДﾟ彡 ＜　ありがと
　Ｕ　Ｕ　　　　＼＿＿＿＿＿＿＿＿

http://home.alc.co.jp/db/owa/eijiro_red
訳は完全性って所か。

ところで、新しい職場でXPの事言って
「ペアプログラミングが〜」とか言ったら

優秀そうな、おっちゃんに
「それってどうなのかなあ。」と
かなり懐疑的な目で見られてしまいました。

どうやって、XP普及を促進させたらいいかなあ。

XPのよいプレゼンテーションを
頭の中で画策しているんだけど,,,うまく思いつかない。

12のﾌﾟﾗｸﾁｽとか言っても、
「日本的なやり方ではダメじゃないか？」とか言われると
なんとも反論が出来ん。で萎え。

　　（｀´｀）　
　　│　│
　　∧＿l　　　∫　　　／￣￣￣￣￣￣￣￣￣￣￣
　 ミ,,ﾟДﾟ彡　 ∬　　＜　 今日はウドン鍋つくタ。
　　 |∪ |つ＝■　　　＼　冬はあたかい食べ物がいいね
　〜|￣｜
　　 U''U

ところで、XPスレが沈降しすぎて沈没しそうなので
ネタアゲ

[XP-jp:02971] 原子力発電所運用と XP の共通点

この記事面白かった。

CMMには今のところ、興味ねーので[CMM と XP]スレが詰まらん。
でもって、2チャソでスレ立てたらとか言い出すし・・・・・・・

日本の場合、「なにを作るべきか？」って質問に答えられるひとがクライアント側にいないから、だめでしょう。

|,,∧　
|Дﾟ彡
|　U 　
|　ﾐ 　
| U

>「なにを作るべきか？」って質問に答えられるひとがクライアント側にいないから
じゃあ、クライアントは何を作って欲しいんだろう？
誰にも答えられないな。

>475
白本を最初から最後まで読ませる。
たぶん12のプラクティス全部を理解してないんじゃないかな。
40時間労働、ペアプログラミング、テストユニット、とかの目立つとこだけ見てると、
そんな甘い話じゃないだろ、となっちゃうと思う。

俺も話を聞いてパラパラ眺めただけの時は懐疑的でした。
あれって、マニュアル的に拾い読みするのと、通して読むのとで印象が変わる。

「日本的」というのはそんな関係ないんじゃないの?
あれが「アメリカ的」というわけでも無いんだから。

>>476

>CMMには今のところ、興味ねーので[CMM と XP]スレが詰まらん。

でも、

>「日本的なやり方ではダメじゃないか？」とか言われると

　の対策としては、CMMとの比較も役に立つんじゃないの？

　既存の開発手法やソフトウェア工学の何が駄目で、
　XPが何を解決しているか？
　の話題なんだし。

>>477

>日本の場合、「なにを作るべきか？」って質問に答えられるひとがクライアント側にいないから、だめでしょう。

日本に限らず、「自分が何が欲しいか？」を本当に分かっているクライアントはあまりいないでしょう。
だから、XPでは小規模リリースを繰り返すんだし。

あえて日本がどうなのかを考えるに、日本人の
「建前と本音」を分けるのが好きだという困った性質を
忘れるわけにはいくまい。

みかたによっては、XPとは、「みんな(開発者も客もマネージャも)裏表や嘘偽りは無しでやろうぜ!」
という方法論だ、とも言えよう。

そこから、出来ない約束はしない(=小規模リリース、シンプルデザイン)、
プログラマ間で隠し事はしない(=ペアプロ、共同所有)、着実に出来るプログラムだけをしていく
(=ユニットテスト)、などなどが導けるのだ思われ。

で、これは特に日本人の不得手とするところなのではないか?という心配が、あると思う。
日本人は、「建前と本音」つまり嘘で固めるのが大好きだから(藁

なおこの問題は、XPに限らず、ソフト業界(ゲーム除く：あれはユーザーを「裏切って」も許されるので)全体や、
オンラインフリーソフトの方面などにも、響いている問題と思われ。
しかも昔から今に至るまでずーっと。

ほかにも、
悪いコードに嫌気がさす自分を偽って、だめなソースを使いつづけない(=リファクタ)、
腹が減っては戦はできぬから10秒チャージしろ(=お菓子もちこみ(藁))、なども。

>>482
客と開発チームの間に、嘘がないこと。
→小規模リリースなど

開発チームの内輪に、嘘がないこと。
→ペアプロなど

開発者と計算機そのものとの間に、嘘がないこと。
→テストなど

プロジェクトにかかわる幾つかの存在の間に、このように
"嘘のない関係"が築かれていくのでしょうね。

>>475
多分、「完全性」ではなくて、「整合性」と言うのが普通だと思います。
integrity constraint（データベース用語）は、「整合性制約」が普通だと思う。

あの本では、データの保存先を普通のファイルにして、さらにファイルを複数に
分けたときのファイル間の「整合性」の話をしてるのだと思います。

オンサイトクライアントは、「何を作ればいいのかわからない」ということを
解決するものではないと思います。

ビジネス上の判断（ベネフィットとか優先順位とかリスクとか）を迅速に
その場でしてもらう、あるいは、そのことについてコミュニケートしやすく
する、というのがオンサイトクライアントの主な目的ではないかと。

今、XP本を読み返す暇が無いので、間違ってるかもしれませんが・・・。

　　 .∧,,∧　　／￣￣￣￣￣￣￣￣￣￣￣
〜'"ﾐ,,ﾟДﾟﾐ ＜　ＸＰ普及のためにも
　UU''UU　　　＼＿優れたプレゼンをクレ

なまじ、自分が"出来る"と思っている人間が
意外と否定的だったりしません？

>>485
いつも、ありがとうございます。

建前と本音は大きい企業になるほど
より強く存在するもんなんでしょうかね。

うちの会社では、黙ってこれ（白本）を読め、ですみました　>　プレゼン

…プログラマの間だけですが

あげとく。

　　　　　　　　　＿＿＿＿＿＿＿＿＿
　 ∧,,∧　　 ／いきなり否定から入っているからなあ
　ミ；ﾟДﾟ彡＜　白本よめってのは
　 ﾐつ　つ 　＼ ちょっと通じなさそうなのです。
〜ﾐ ,,　ﾐ.　　　　￣￣￣￣￣￣￣￣￣
　 ∪∪　　

やっぱり、上に立つ立場の人が理解して挑戦しないと
イテレーション計画やｵﾝｻｲﾄ顧客系の
試みは、なかなか実践できないねー.

上司にどうやってXPを伝えたらいいのかしら。

　>>480
　CMMのスレ読んでみたら
　痛い奴ばっかじゃん
　読まなきゃよかった。

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　　ﾁｪｯ　　
　　ミ #ﾟДﾟ彡∬
　　 〃　 つ旦O
　〜ﾐ,,,ｎ,,ｎ［￣￣￣.］
　　　　　　　￣￣￣
H氏の意見は正論だけど粘着しすぎ
Mは単なるﾈﾝﾁｬｸ厨房だしっ

CMM は ISO うんたらと同じで
取ることがステータスみたいな面が大きいのが弊害だな。

>>490
>上司にどうやってXPを伝えたらいいのかしら。

UnitTestを上司の目の前で実演するのは効果的。
XPの雰囲気を実感させないとイテレーションとか口で説明しても
(ﾟДﾟ)ﾊｧ?
って顔されてしまう。

喫煙ルームでマターリと根回しするのも忘れずに。

　　 .∧,,∧　　／￣￣￣￣￣￣￣￣￣￣￣
＠'"ﾐ,,ﾟДﾟﾐ ＜　お子様だから、たばこ吸えません
　UU''UU　　　＼＿＿＿＿＿＿＿＿＿＿＿
　でも、女性にもてたりするよね。
　ｱﾗ,ｷﾉｾｲｶｼﾗ

>口で説明しても (ﾟДﾟ)ﾊｧ?

そうそう。なんとかやっていきたいね。

>>491

>H氏の意見は正論だけど粘着しすぎ
>Mは単なるﾈﾝﾁｬｸ厨房だしっ

H氏は議論の誘導が下手だね。
どんどん脱線させられていくし。

>>490

>上司にどうやってXPを伝えたらいいのかしら。

良いことしか伝えないで、口頭で同意を取り付ける。
あとは、勝手に実践する。

　権限がないなら、逸脱する。

口で説明して解からないなら、ゲンコツでもビールビンでも…

　　∧,,∧　 　／￣￣
　 ミ；ﾟДﾟﾐ ＜　　強制的に物理アクセス？
　 ﾐ　 　ミ　 　＼＿＿
〜ﾐ,ＵＵ_ﾐ 　ﾋﾞｰﾙﾋﾞﾝﾊ ﾁｮｯﾄ…
　　　　　　　ﾊｰﾄﾞｳｪｱｶﾞ ｺﾜﾚﾁｬｳ ｵｿﾚｶﾞ…

>>497
下の口にですか？

>>498
AAを見ただけでネタスレと勘違いする奴が多いからsage進行の方がいいよ。
とくに連休中は。

（493の続き）
折れも吸わないけど、上司と気軽に雑談できる数少ない場所なんでよく行きます。
そういう場所なら、
「え？人月の神話読んだ事無いんですか？ダメっすよ。」
とか言っても角が立ちにくいしね。

>>454
激しく遅レスだけど、実践記本書きたいす。
でも顧客の都合というものが……。
実名出せない実践記ってウソくさいもんねえ。

なんでEPじゃなくてXPなの？

どうして本にしたがるのさ
Webで紹介すりゃいいだろ
紙の無駄だよｺﾞﾙｧ!!

XPの本質はいかに変更に伴う負荷を減らすかにあると思うのですがいかがでしょうか？
ペアプロとか、担当者がいなくなってもよいための１つの方法であって、
必ずしもXPだからといってペアプロをやる必要はないように思います
何か方法論のみが1人歩きしているように感じてしまいます。

>>504
XPを部分的に取り入れていて、痛切に感じるのは「共同所有」の
大切さと難しさです。
この共同所有を実現するために、そして、プログラムの、テストの
品質を保つのに最も重要なのが「ペアプログラミング」だと思います。

リファクタリングの勇気を与えてくれるのは「テスティング」でしょうが、
それは、適切なテストを前提としなければなりません。
適切なテストは、一人でやっていると難しいものがあると思います。
チーム全員が高スキルで、いつでも最高の調子で仕事が出来れば
別でしょうけど。

>XPの本質はいかに変更に伴う負荷を減らすかにある

それだけがXPの本質である、と言われるとちょっと違うような気がします。
それは一面をとらえただけにすぎないのではないでしょうか。

XPとは、ソフトウェアの品質・価値を最高に高め、そして開発を楽にさせる
手法である、と僕は考えています。

ちなみに・・・。

ずっと前にマ板で書いたことがあるのですが、僕のチームはXPを部分的に
取り入れています。
できていないのが「ペアプログラミング」「オンサイト顧客」です。
（週40時間もできてませんが、それはおいといて）

後者は、XPと比べて単純に時間がかかるだけで、何度もコミュニケーションを
とれば、ほぼ問題は無いのですが、前者ができないのは大問題です。

XPのプラクティス「単純な設計」、適切な「テスティング」、そして、コードの
品質。これを保証するのに多大な労力が必要です。
これを解決するために、不必要かもしれない設計書（メモ）と、レビューを
やっています。

ひょっとすると、ペアプログラミングをすれば以上のような問題も解決して、
週40時間も達成できるのかもしれません。
ただ、これは心理的なハードルが高くて、なかなかやる気になれないんですよね。
あまりにも今までの文化と違いすぎて。

>リファクタリングの勇気を与えてくれるのは「テスティング」でしょうが、

テストが全て自動でできればいいのですが、ユーザーインターフェイスの部分は自動ではできませんよね。
ですからテスト、リファクタリングのサイクルをまわしていくには、自動でテストできる部分と
できない部分をうまく分けて設計すること、いわゆるモデリングの部分も大事だとおもうのですが、
いかがでしょうか？

>>507
えーと、何かの反論でしょうか（汗
判りづらかったかもしれませんが、>>505-506の僕の主張は

・XPでは「共同所有」こそが最も大事ではないか
・XPは単に「変更に伴う負荷を軽減する」ためだけのものではない

ということです。

いわゆる「詳細設計書」なしの開発や、事前・事後のレビューなしの
開発を実現するにあたって、共同所有が必要であり、そのためには
ペアプログラミングこそが必要であると。

シンプルデザインに関しては、以前マ板でハマッタ覚えがあるので
言及しません（汗

リファクタリングに関して説明を追加しておきます。

リファクタリングをするにあたって最も重要なのが、「適切な」テストスィート
の存在です。これがなければ、他人のコードはおろか、自分のコードさえ
自信を持ってリファクタリングなんかできません。

テストは一人で作っていると、それが「適切である」という保証もないし、
適切なものにならないほうが多いかもしれません。
それを補う意味で、ペアプログラミングが重要なのであり、決して

>何か方法論のみが1人歩きしているように感じてしまいます。
ということではないと思っています。

もちろんモデリングも大事ですが、XPは最初から完璧なモデリングを
要求しているものではないと思います。そのためのリファクタリングでしょう？

・・・って、ペアプログラミングを実践していない人間が言っても説得力ないか（汗

>>508
> ・XPでは「共同所有」こそが最も大事ではないか
いや、そうは思わない。

コードは、プログラマの財産であり、仕事に対する成果でもある。
財産の共同所有とは即ち共産主義である。
共産主義は現在の資本主義よりも優れていると吹聴され、
いくつかの国家では実際に行われたが、思った通りには行かなかった。

共産主義は清すぎたと思う、そしてXPも清すぎる。
人の悪い部分は全て無視しているような気がする。
XPの「Testing」「Refactoring」についての技術的な部分に関しては同意するが、
思想的な部分「ペアプログラミング」「共同所有」については同意できない。
# 「週40時間」なんて嘘だと信じている

>>511
＞コードは、プログラマの財産であり、仕事に対する成果でもある。
つうかコードは会社の財産だけど。

>XPの「Testing」「Refactoring」についての技術的な部分に関しては同意するが、
>思想的な部分「ペアプログラミング」「共同所有」については同意できない。

わたしもいまのところ（あんまり詳しくないので）そういう考えです。
アクティブに動いているプロジェクトなら、共同所有のメリットは多いかもしれませんが、
ほとんど忘れたころに昔のプログラムを修正するなんて場合には
あまり役に立たないんじゃないでしょうか？

>ほとんど忘れたころに昔のプログラムを修正するなんて場合には
>あまり役に立たないんじゃないでしょうか？
そりゃそうだ。そもそもXPはこういうプロジェクトは
ターゲットにしていない。

XPの有効なプロジェクトとはどんなものでしょうか？
逆にXPに向かないものとは？
ああ、それから私は別にXPに反対とかそういうのではないです。
XPといっても、いま１つふにおちないのでいろいろな意見が聞ければ幸いです。

>>515
> XPの有効なプロジェクトとはどんなものでしょうか？
・納期が自分で決められる。
・大人数のプロジェクトでない。
・クライアントが協力的である。

> 逆にXPに向かないものとは？
・納期が自分で決められない。
　仕様が決まっていないのに納期だけ決まっているプロジェクトなど以ての外。
・大人数のプロジェクトである。
　特に、終わりが決まっているので、アホみたいに人を入れ、
　責任の押し付け合いをしているプロジェクトには向かない。
・クライアントが非協力的である。
　納期間近にとんでもない仕様変更を言ったりしない、
　要求項目の質問を何度言っても無視するクライアントだと向かない。

>> 逆にXPに向かないものとは？
>・納期が自分で決められない。
>・大人数のプロジェクトである。
>・クライアントが非協力的である。

こういう条件が向いている（っていうか被害が少なくてすむ）
開発手法ってあるのでしょうか？
　XPの場合、上記の条件をなんとか変えるように努力を促し、
無理なら早急な撤退を求めているきがするけど.

>XPの「Testing」「Refactoring」についての技術的な部分に関しては同意するが、
>思想的な部分「ペアプログラミング」「共同所有」については同意できない。

　XPは思想的な部分がもっとも重要だと思うんだけど。

　「ペアプログラミング」は「共同所有」を実現するために必要だとして、
　もし「共同所有」が無ければ、「変化を抱擁する」が実現できなく
　なってしまいませんか？
　そこは自分が書いたんじゃないから直せない、
　じゃあ、変化を受け入れることにはならないでしょうし。

　また、XPは開発者が勇気と自信を持つための開発手法であると思いません？

　

＞517
その条件全部だと、もてる発言力を総動員して、待避したほうｔがいいような。
むしろ、高度に政治的な問題になるのではないかと予想。

>コードは、プログラマの財産であり、仕事に対する成果でもある。

そういう「慢心」を捨てることで、結果的にプログラムを改善できる、ってのがXPかと。

昔からよく言うが、営業の人間は同僚がライバルであり極端にいえば足引張りあいも有りだが、
技術の人間は同僚が協力者でなければならない。せっかく共同で何かを作るために
その場に雁首そろえているのに、そいつらが互いに協力もしないなら、ろくなものが作れないのは日を見るより明か。

その延長にXPは有ると思う。人という字は二人の人が支えあって(以下略(藁

>ほとんど忘れたころに昔のプログラムを修正するなんて場合には

たしかにそれは言える。オプソでもしばらく放置プレイされたソースなんて腐ってる。
それはソースそのものの質が下がるという意味では勿論なく、
ソースの随行者たるプログラマが不在だということだ。

活発に共同所有してペアプロしている「間」は、そのソースのことをメンバーの大勢が
「しっている」んだよね。記憶している、理解している。
ソース自体が全員からアクセス可能であると同時に、全員の記憶がソースとシンクロしている、
つまり記憶はソースを補完(そのおかげでドキュメントもたいして要らない)し、
ソースは記憶を補完する。両方が作用しあってプロジェクトは活性になる。

その状態が去ってしまい、記憶から忘却されれば、ソースだけの片肺飛行。
ドキュメントが存在する従来方法論のほうがマシかもしれない。

>>517
ウチの会社のこんな条件のプロジェクトばっかりだな。
不景気な世の中だね・・・。

ＸＰなんて夢のまた夢か(;´Д｀)。。

>>517
XP の思想が広まれば
（例えば日経なんかでひつこく喧伝してくれれば）
そういう仕事はまともなソフトウェアハウスは引き受けない
という認識を顧客が持つようになる…といいなあ

XPは開発者たちの文字通り「極端な」理想なのさ。
だから100%実行する必要なんてない。
楽になろうぜ

ペアプロしたほうが明らかに良質なコードができるが、
ある程度のカオスは許容することにして、
簡単であろう部分は単独で書くというスタイルでやっているんだけど、
これって「ＸＰ」的には駄目なのかなあ。

>>511
>コードは、プログラマの財産であり、仕事に対する成果でもある。
>財産の共同所有とは即ち共産主義である。

>>512さんのおっしゃるとおり、コードの所有権は普通会社に帰属しますが
それはおいといて。
XPの「共同所有」は、所有権という権利の話をしているのではありません。
知識を共有しようぜってことですよ。

>人の悪い部分は全て無視しているような気がする。

具体的には、どのようなことですか？
XPは、開発者側のもっとも悪い部分である「思い込み」「勘違い」を
解決してくれるものだと思います。

># 「週40時間」なんて嘘だと信じている

嘘もなにも、XPの「週40時間」以外のプラクティスを実践すれば、
結果的に週40時間が実現できるなどと言ってるのではないです。
週40時間もプラクティスのひとつです。勘違いしてませんか？

XPに限ったことじゃありませんが、週40時間を実現できないとしたら、それは
・仕事のやりかたがまずい
・能力不足
・できない仕事を受注している
のどれかだと思います。

それから・・・。
XPのことはよくわかった。でも、XPなんてクソだね。
って人は、何も言わずに他のプロセスをやればいいと思うんですけどね。
批判せずにはいられないんでしょうか（笑

>>513
>ほとんど忘れたころに昔のプログラムを修正するなんて場合には
>あまり役に立たないんじゃないでしょうか？

確かに、XPではメンテナンスに関してあまり言及がありませんね。
というか、上流の話も全然出てきませんね。
紫本を読んでいると、ユースケースさえ書かないみたいだし。
ストーリーカードがその代わりをしているみたいですが。

ただひとつ言える事は、テストセットは大きな自信になるって
ことですね。
巨大なぐちゃぐちゃのコードがあり、解析不能で、ドキュメントもなく、実際に動いている
画面を指して「これが仕様だ」なんて言われるよりは、よっぽどましかと（笑

紫本じゃなくてピンク本ですね（汗

ピンク本でもなくて、オレンジ本ですね（滝汗
すみません、何度も。

>上流の話も全然出てきませんね。
>紫本を読んでいると、ユースケースさえ書かないみたいだし。
>ストーリーカードがその代わりをしているみたいですが。

XPに対する疑問の１つが、「それで本当にできるのか」です。
ある程度のスキルがある人なら問題ないでしょうが、根本がよくないものを
リファクタリングしたってよくならないんじゃないのかなと。

>>525
511じゃないけど、俺は自分の能力を認めてもらいたいからペアプロで「完全に」共有コードになる
ことは耐えられない。同僚のコードを修正するのも自分のコードを見てもらうのも賛成だけど、
はなから共同で開発なんていや。
それにペアプロなんてしたらこうしてサボって2chもみれなくなるし。

それに俺が一番充実するのは火の点いたタスクを残業して片づけているときだから40時間なんて
守ってられないし、そもそも仕事しないで遊んでいる時間の比率で毎日の就業時間は決まる。

俺もXPの他のプラクティクスには大賛成だけど、どうもこの二つは受け入れられん。

>紫本を読んでいると、ユースケースさえ書かないみたいだし。
>ストーリーカードがその代わりをしているみたいですが。

ストーリーカードというよりテストプログラムがユースケースのかわりなんじゃないのかな？
だから、テストが書けないものはユースケースを書いたほうがいいと思う。

>紫本を読んでいると、ユースケースさえ書かないみたいだし。
>ストーリーカードがその代わりをしているみたいですが。

ストーリーカードというよりテストプログラムがユースケースのかわりなんじゃないのかな？
だから、テストが書けないものはユースケースを書いたほうがいいと思う。

　　,,,,,,,,,,,,,∧,,∧　 　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
〜′,,,,,,,ミ,,ﾟДﾟ彡 ＜　ちょっと、言わしてもうらうざんす
　 UU""" U U　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

>>529
もしかして
>ある程度のスキルがある人なら問題ないでしょうが、
>根本がよくないものを
というのは、スキルのある人しかXPできないとか
思っているんじゃないでしょうか。

それこそが、最もよくあるXPの誤解だと思うんだけど....

XP本を読めるほどの日本語/英語がない
というのならスキルがないんだろうけど。

>>530
>はなから共同で開発なんていや。
ならXPチームからは外れてくれって、ベックは逝ってるんじゃなかた？

>そもそも仕事しないで遊んでいる時間の比率で毎日の就業時間は決まる。
俺だって、2チャソで遊びたいが
遊んでいたら仕事は終わらないだろ。
さっさと定時帰りで家で2チャソすれ。

>>533
>ならXPチームからは外れてくれって、ベックは逝ってるんじゃなかた？
まあ本気でペアプロするチームなら(可能なら)外れるよ。別にXPチームで仕事がしたいわけ
じゃないぞ。単に効率的な開発手法に興味があるだけだ。

>俺だって、2チャソで遊びたいが
>遊んでいたら仕事は終わらないだろ。
>さっさと定時帰りで家で2チャソすれ。
いや終わるぞ。つーか一日の純粋な仕事時間は平均したら3時間くらいじゃないかな？
それでも俺はぶっちぎりでエースだ。
第一定時で帰って家で2チャソするメリットってなに？

>まあ本気でペアプロするチームなら(可能なら)外れるよ。別にXPチームで仕事がし
>じゃないぞ。単に効率的な開発手法に興味があるだけだ。

XPでは、そーゆー
個人プレーではいけないよって事を
ベックは比喩で「チームから外れてくれ」
って表現で伝いたいと思われ.

￣￣￣∨￣￣￣￣￣
　　　∧,,∧ 　　　
　　ミ,, ﾟДﾟ彡
　　 〃　 つ旦~~
　〜ﾐ,,,ｎ,,ｎ［￣￣￣.］
　　　　　　　￣￣￣
最初から、ﾍﾟｱﾌﾟﾛで全部は無理だろうから
少しずつ、はじめは一日1時間、次の日はちょっと増やして
増やしすぎたら
それで開発効率があがるかどうかを試せって
本に紹介されてたっす。たしか。

全部ペアプロってのはしんどいと思うけど。
俺は試してみたいな。
最初から否定に走る事ないと思われ

>いや終わるぞ。つーか一日の純粋な仕事時間は平均したら3時間くらいじゃないかな？

そのへんが、XPでは完全作業時間という話で紹介されていて
完全作業時間見積りに2〜3倍をかけて実際の見積もりとする
ちうスタイルが好き。

>それでも俺はぶっちぎりでエースだ。
でも、プロジェクトのチーム全体で
失敗に向かっていたら楽しくないよね。

>第一定時で帰って家で2チャソするメリットってなに？
知らん。

>>535
>最初から否定に走る事ないと思われ
まあね。俺は自分で実験する気が無いから周りでもっとペアプロの評価が高くなれば
試してみるよ。

>いや終わるぞ。つーか一日の純粋な仕事時間は平均したら3時間くらいじゃないかな？
>そのへんが、XPでは完全作業時間という話で紹介されていて
>完全作業時間見積りに2〜3倍をかけて実際の見積もりとする
そうじゃなくて、見積もり作業時間が平均して3時間くらいってこと。
完全作業時間はそれこそ1.5時間くらいだろう。

>でも、プロジェクトのチーム全体で失敗に向かっていたら楽しくないよね。
あたりまえ。何がいいたいのかよくわからん。

＞それでも俺はぶっちぎりでエースだ。
ｶｺﾜﾙｲ

>>534
>それでも俺はぶっちぎりでエースだ。

「そーゆー人はプロペラ帽をかぶってなさい」

いや、君の言うことはよくわかる。
漏れも（自慢したいわけじゃないが）同じだし。
でもね、ＸＰではチームプレイによって成功を得ることが目的なのよ。

エースという言葉が出たから野球にでも例えてみると、君がたとえ必勝不敗のエースだったと
しても、135試合全部で先発完投することはできない。
君が登板する試合は全部完全試合だったとしても、残りの試合で全部負けたらチームは優勝
できないでしょ。
だから、エースは自分の出る試合でだけ活躍するんじゃなくて、選手兼コーチとして他のメンバ
ーをサポートするとか、あえて抑えに回って勝てそうな試合を全部拾うとか、そういうチームプレ
イでチームを優勝に導くの方がいい、ってのがＸＰの考え方なわけだ。

ペアプログラミングも、ただ単に二人でコードを書くということじゃない。
お互いに教えあって、お互いの技術や発見を共有することに意味があるんだよ。

……と、かくいう漏れもペアプログラミングはほとんど経験ないんだが（ｗ
つーか、ＸＰが適応できるほど余裕がある仕事なんかねーよ。うわーん！

ペアプロネタはマ版でやってくれ｡
まともな議論は全く見当たらない｡

ここ、sage進行ですか?

511さんとか525さんの言ってること、すごくわかるんですが。
私もXPプロジェクト意外では似た立場・似たスタンスですから。

でも、ペアプロを実践してみて、ペアでやった結果コード品質を上げたり、
OJT効果を上げたり、コーチとしてチーム全体のコードに目を配ったり、
そういったことを可能にするのはまさにエースプログラマあってこそ、なんですね。
#「全員エース級である」必要はないです。

もちろんシングルで他の人の数倍の生産性・品質を上げたり、
他の誰にも書けないようなコードを書いたりしたときの自己満足(自嘲
というのは捨てがたかったりはするんですが。
そこんところをちゃーんと評価してくれる環境にいると、やってて満足感あります。
#そういう上司を育てるためにはXPについて啓蒙しなくっちゃいけなくて、
#自分がXPに懐疑的すぎるとなかなか難しかったりはしますが。

最終的に顧客にとっての費用対効果が最も高くなる方法論(のひとつ)として
捉えることが大事で、その効果が上げられると評価・報酬も高くなる、のが本筋。
素人さんなら自己満最優先でもいいけどね。

で、個人的には、
「XPによって費用対効果が上がる案件の特質」とか、
「XP適用可能顧客の条件」とか、
「見積もりにおける理想時間とベロシティの測定のコツ」とか、
そういった方向に議論を広げたいんですが、実践されてる方いかが？

よく見たら538さんと無茶苦茶被ってました……。

　　,,,,,,,,,,,,,,,,∧,,∧　 　／
〜′,,,,,,,,,,ミ,,ﾟДﾟ彡 ＜　エースが去って会社も逝ったでは
　 UU"""" U U　　　 ＼　ビジネスにならないわけで…
　リスク回避リスク回避っと。

　ベロシチーって何だわさ？

>>542
velocity

>スキルのある人しかXPできないとか思っているんじゃないでしょうか。

いえ、そういうわけではありません。
XPの場合ユースケースとか書かずにプログラミングを始めることになると思うけど
そうした場合にスキルのない人がきちんとコードを書けるのか？という疑問があります。
もちろんペアプロでそのへんは補えるかもしれないけど、それだと1部の人に負担が
かかりすぎてしまうのではと。XPといったときにがちがちにドキュメントを書く必要は
ないと思うけど、ある程度は上流に時間をかけたほうがいいのでは。

> XPの場合ユースケースとか書かずにプログラミングを始めることになると思うけど
> そうした場合にスキルのない人がきちんとコードを書けるのか？という疑問があります。

RADツールを使うことが前提なの？
RADツールを使うスキルの無い人＝スキルの無い人 なの？

スキルのない人ってどういう人の事を指します？

俺的にはキーパンチャーレベルの人のことかと思うんだけど

この世の中で、開発に参加している人の中で
純粋な意味でのコーダーというか
キーパンチャーなんて存在するかな。
　　　　　　　　　＿＿＿＿＿＿＿＿＿
　 ∧,,∧　　 ／　
　ミ,,ﾟДﾟ彡＜　　んなやつ、いねーよ
　 ﾐつ　つ 　＼　
〜ﾐ　　ﾐ.　　　　￣￣￣￣￣￣￣￣￣
　　Ｕ Ｕ 　ﾀﾞｲﾀｲ ｷﾞｮｳﾑｱﾌﾟﾘ ﾉ ﾄﾞｺﾆ
　　　　　　ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ ｽｷﾙ ｶﾞ ｲﾙﾉｻ....

ﾋﾂﾖｳ ﾅﾉﾊ ﾌﾟﾛｼﾞｪｸﾄ ﾏﾈｼﾞｬ ｽｷﾙ ﾃﾞｽﾜ


最低限、if,for,whileと変数と関数とがわかっていれば
なんとかプログラム組めるでしょう。
開発していくうちにスキルアップできるでしょう。

”プログラム組めないSE”というのでも
それくらいは誰だってできるっしょ。二時間くらいで学習するだろさ。

元々それに達さない人・・・
掃除のおばちゃんもXPプロジェクトに参加してもらうのは
ちょっとできないよね。

　　∧,,∧　 　／　ユースケースってUMLの事？
　 ミ,,ﾟДﾟﾐ ＜　　
　 ﾐ　 　ミ　 　＼
〜ﾐ,ＵＵ_ﾐ
ﾕｰｽｹｻﾝﾀﾏﾘｱ ｦ ｵﾓｲﾀﾞｼﾀｰﾖ

設計図を書いたら仕様変更がやりにくくならないですか？
プログラムと設計図の同期が面倒だから
作ったらすぐ捨てろってXPでは書いてありますね。
設計図は頭とプログラムで保存しておくって事かな。

>もちろんペアプロでそのへんは補えるかもしれないけど、それだと1部の人に負担が
>かかりすぎてしまうのではと。
ペアプロパートナーが成長すると負担が減るかと。

>ある程度は上流に時間をかけたほうがいいのでは。
いつでも、設計、いつでも仕様変更
変化を抱擁して、車を運転するように
ﾌﾟﾛｼﾞｪｸﾄを成長させて逝った方が
顧客満足度が高いと思います。

>>RADツールを使うスキルの無い人＝スキルの無い人 なの？
ケントベッ君はVisualｱｹﾞ4ｽﾓﾙﾄｸ使いなような…

UMLは手書きが基本かもー

RADというよりCASEツールかな。

>最低限、if,for,whileと変数と関数とがわかっていればなんとかプログラム組めるでしょう。

「いまから、web browser　を開発するんだけど、ペアプロでやるよ。じゃ、プログラミング始めて」
といわれてもなにもできない人がほとんだと思うけど。

　∩|　
　ﾐ ﾞ''ﾞﾞﾞつ　
　ﾐ∧,,∧　　　
　ミ,,ﾟДﾟ彡
　Ｕ　Ｕ　　　　

まったく未経験の分野の開発なら
2週間くらい調査期間をつくっておくってのも
書いてあるけど…

俺だって、ゲッコーエンジンから開発しろって
言われたら、何からやっていいかわけわかになるけど
とりあえず、テキストビューからかなあ。

>とりあえず、テキストビューからかなあ。
それでほんとにテキストビューのコーディングを始めるのはいくらなんでも無謀。

　∩ ∩
　ﾐ ﾞ''ﾞ〜　
　ﾐ∧,,∧　　／￣￣￣￣￣￣￣￣
　ミ,,ﾟДﾟ彡 ＜　なんで？
　Ｕ　Ｕ　　　＼＿＿＿＿＿＿＿＿

XP だっていきなりコーディングはじめるわけじゃなし…

「ペアプログラミングの有効性は既に実証されている」そうな。

http://www.ogis-ri.co.jp/otc/hiroba/specials/oday2001/report/A3.html

ペアプログラミングて何？＞５５３

>>549

（548じゃないけど）
「2週間で基本的な概念が身につかない分野には手を出すな」という警句ともとれ
るよね。餅は餅屋にってところかな。

>>548
グラフィック系やワープロ系アプリの開発をやってるような会社ならWebブラウザ
の開発も守備範囲になるだろうし、そういう会社ならペアプロしたって全然問題
無いでしょう。

夫婦でペアプロ...これ最強

夫婦間では隠し事だらけになりますが、なにか？

女の子とペアプログラミングしたい。

>女の子とペアプログラミングしたい。

そういえばペアプロは「つっこみの要領でやります」ということでしたね。

>オブジェクトリポート 第6巻10号
>思考停止を解除するためには：ペアプログラミングは機能するか？
>カリフォルニア大学アーバイン校 鈴木 純一
これ読んだ人いる?

>>553
>分析／設計は、日々の作業として行われている。

此処が XP の要点なのかな…
日々分析／設計を続ければ、理不尽な設計に煩わされる事も無くなりそうだし。

そう考えると、ペアプログラミングは、共同所有と云うより…
全員がコード全体を把握する様な、分業に依らないプログラミングなのかな…

>ペアプログラミング
素朴な疑問。
奇数人プロジェクトでは残りものはどうしますか？まさか3人？
誰かが風邪で休んだときはどうすればよいのですか？

ちょっと実験プログラムを書きたいときはどうすればよいですか？

珍しくいいこと言っている

日経BP IT Pro 記者の眼 ソフトウエア開発は楽しいですか？
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020120/1/

>XP だっていきなりコーディングはじめるわけじゃなし…
コーディングの前に何をして、何をすべきでないか？意見求む。

>>562
こういうやり方はどうでしょうか?
http://objectclub.esm.co.jp/ml-arch/extremeprogramming-jp/2100/2196.html

>>563
XPじゃ無くとも、「納期を自分で決める」ことができるなら
ソフトウエア開発は楽しい。
# ま、俺個人の意見だが．．．。

>>566
でも、ね。それだけだと
ﾏｼﾞﾒでﾊﾞｶ正直なPGだけが
自分の限界ギリギリまで働く事を想定した納期を
設定してコン詰めて、自爆してしまう危険性を伴うよ

　　　　　 　 　　　　∫　　　 ＿＿＿＿＿＿＿＿＿
　　　∧,,∧ 　　 　∬　　 ／
　　 ミ,,ﾟДﾟ彡っ━~　　＜　正直者はバカをみるってか？
＿と~,,　　~,,,ﾉ_. 　∀　　　＼　
　　　 ﾐ,,,,/~), │　┷┳━ 　￣￣￣￣￣￣￣￣￣
￣￣￣ .じ'Ｊ￣￣|　┃
￣￣￣￣￣￣￣ 　┻
「納期を自分で決める」ことができるの
さらに一歩進んだ所にXPはあるんじゃないでしょうか。

自分で決めるのは納期じゃなくて、見積もり期間だけどね。

∀
┷┳━ 　 　　,,,,,,,,,,,,,,,∧,,∧　 　／￣￣￣￣￣￣￣￣￣
　 ┃　　　〜′,,,,,,,,,,ミ；ﾟДﾟ彡＜ 　ヤバー
　 ┻.　　　　UU"""" U U　　　 ＼
　　　　　　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣￣
関係ないんだけど、たったいま、同僚にAA見られて
「その絵うまいですねー」
とか言われちゃった。どうするべ。

ペアプログラミングできないね………
パートナーもニチャンネラーに洗脳するしかないか・・・・・・・

>>559 ペアプロ界の大輔花子を漏れは目指す！

>[XP-jp:03109] XP が２ちゃんにデビュー

　　∧,,∧　　　 ／不毛な議論でゴミメール散在させて
　 ミ ﾟДﾟﾐっ　＜　あげくのの果てに「２ちゃんにスレ立ったようです」
　　|''Ｕ￣|　　　＼だって？！マ板ばっか見てんじゃねーぞ
　　|￣￣|
　/　　　　ﾞヽ
（ 　　ﾟДﾟ　　） ｲｯﾃﾖｼｲｯﾃﾖｼ
人＿_＿＿ノ

『ゴミに対する考え方』
ゴミメールばっか作成しても
生産性は高まらない。

以上、XPMLからのネタでした。

スマンコとか逝っとけ！

あー、どおでもいいけど
超かわいい女の子とペアプログラミングしたいね

　　ｾｸｰｽしながらﾌﾟﾛｸﾞﾗﾐﾝｸﾞ
　　ｾｸｰｽﾄﾘ〜ﾑﾌﾟﾛｸﾞﾗ…
＼　　　　
　 ￣￣￣￣￣ |/￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　∧ ∧∧∧
　　　　　　　ミ,,*ﾟДﾟ彡 ,,ミ ﾊﾆャｰﾝ
　　　ﾊﾟｺﾊﾟｺﾐ 　 つ 　 ﾐ
　　　　　 ((（ヽ　 ﾐ 〃Ｕ
　　　　　　　Ｕ Ｕ Ｕ

>>572
本日はお日柄もよく、とても寒いですね。
暖房をつけているのに、ここは何処なんだというほど寒気がしました。
すばらしい能力です。
ぜひ、うちのデブで臭い新人の横に座ってくださいませんか。
そして、あの殺人的体臭をあなたのお言葉で抑えてください。
おながいします。

>>572
で、成果物は10ヶ月後に世に出る・・と？

正直XPの経験も知識もなくその穴を偏見と妄想で補いつつ
偉そうに講釈垂れてるAAコピペ荒らし野郎は
せめてこのスレ以外を荒らしてくれ｡

良いこといっているので、みなさん参考にすること！

ーーーーーーー
[procimprov:00054] Re:ソフトウエア開発は楽しいですか？
こんにちは、上手です。
雑談です。

> プロセス改善でもXPの良い所はどんどん取り入れるべきだと思いますよ
> もっとも、プロセスレベルが低いままだとXPの良い所がどこなのか把握するのが
> 非常に難しいんですけど

最近プロセス改善に関する認識は、一般受けする区別としては、「XP以前とXP以
後」と言ってもいいのかな、と思い出しました。
＃プロは昔からちゃんとやってる、という意味で。

RUPとかオブジェクト指向開発方法論とか言っても「いまいち人の話」という感じ
だったのが、XPを通じて、現実の話としてプロセスを議論できるようになったの
かな、やっぱりXPの功績は大きかったな、という感想を持っています。

しかし某所の議論を見ていると、ご存知のように、プログラマ全体としての問題
もかなり顕在化してますね。

１　議論のやりかた、論理展開の仕方を全く知らない人が多い
　・必要な概念の定義をしないで進める
　・網羅的に議論しないで、一部のみとりあげてコメントする
　・人の意見を「推測」し、それに基づいて議論を先にすすめる

２　基本的な知識の不足
　・ソフトウェア工学の基本
　・品質管理の基本
　・経理的・経営的な初歩の知識
　　・付加価値という概念を知らないので、「売上げ」などという単語で代用する
３　パッケージ開発などを知らず、人月の頭で考えている人も多い

こんな状態で、ちゃんとした仕事ができているのだろうか？
「井の中のカワズ」状態なのではないか？

やっぱり教育しかないのですかね？
＃自分の周りも全く同じだけど・・

（では）

XP-jp荒れてますねぇ。
僕は濱井氏に肩入れして読んでるけど。（っていうか、濱井氏の敵？が
気にくわない（藁）

ところで、超久しぶりにVBの仕事をやることになりました。
んで、VBUnitをダウンロードしようと思ったら、シェアウェアバージョンが
ありました。違和感ありまくりで、ちょっとびっくり。

２ヶ月の極小プロジェクトなので、VBUnitを極めるつもりもないので、
フリーソフトバージョンを使うことにしましたとさ。

>>577

俺も濱井氏派。

っていうか、
>この辺でやめておきます。
って言いつつ何度も発言を繰り返したり、

別のML行って
>しかし某所の議論を見ていると、ご存知のように、プログラマ全体としての問題
>もかなり顕在化してますね。
って陰口叩いたりしているのを見ていると

とっても２ちゃんねると同じ匂いを感じるんだけど。

あと、
> :-)
これをつければ、ツマラナイ嫌味が、面白いコメントになると
思っている奴とか。

>>578
同感。上手は何様だと思っているのか？
自分が優秀であるなら、途中で投げ出さずきっちりと議論しろっていうの。
濱井さんの方が立派。

　　　　樋口って人が相当変なんじゃないの？
|,,∧
|Дﾟ彡　ｼﾞｰ 　　
⊂ﾐ 　　
| ,;ﾞ 　　ｱ ｵﾚﾊ ｲｹﾝ ｲﾜﾝﾎｳｶﾞ ｲｲﾉｶ…
|´
南ツーか。こういうのを
近親憎悪というのではないかと....

http://www24.big.or.jp/~faru/txt1036.html

>>580

>ｱ ｵﾚﾊ ｲｹﾝ ｲﾜﾝﾎｳｶﾞ ｲｲﾉｶ…

２ちゃんねるなら、いいんじゃないの？
樋口も煽るなら、ここでやりゃいいのに。

>>579
私も濱井さん派。

だけど、濱井さんの歯切れの悪さも感じる。
けど、対抗している派の人には、とっても嫌悪感を感じる。

>>582
これじゃぁ、XPの4つの価値のコミニュケーションの
価値が下がっちゃう。（笑）

やっぱり、フェイスtoフェイスなんやね。

>>567
＞しかし某所の議論を見ていると、ご存知のように、プログラマ全体としての問題
＞もかなり顕在化してますね。


別にプログラマ全体の問題でもないと思うけど。
人間のコミニュケーションの問題でしょ。
プログラマは、人を継承するからプログラマとしている
んだろうけど。

>>582

>だけど、濱井さんの歯切れの悪さも感じる

　たしかに議論が下手だね。
　でも、それに対して煽る発言を繰り返すのが嫌だね。

　CMMとかソフトウェア工学とかの批判がよっぽど気に触ったんだね。

みんな真面目に読んでるんだ．．．僕は読み飛ばし。
ああなっちゃうと議論のための議論になっちゃって，
有益な部分を読みとる労力が大変だし。

意見の本質はともかく，なんでああいう煽り口調で議論するのかねえ。あとさ，みんな会社のアドレスで昼間からやってるけど，
大丈夫なのかな。人ごとながらちょっと心配。

>>586 なんでまずいの？
っつーか、技術調査目的でもインターネット使っちゃいかんの？

>>587
技術目的のインターネット利用に関しては、
それぞれの上司が判断するだろうけど、
もしそれがOKだとしても、
今回のケースは2chでもあんまりいい意味でなく話題になるくらいだから、
内部的にも外部的にも微妙な判断をする人がいるだろうな、
という個人的な感想です。

某Nとか某Aとか（書いても大丈夫かな？）、
この会社暇なのかあ、って思わない？
XPの話題のわりに、トップダウン的というか、管理至上的というか
なんとなく不思議な感じがしない？

MLの方、昨日まで興味持てなかったんで、実は事情を知らないんです。
荒れている時に参加したくはないなー(笑

＞XPの話題のわりに、トップダウン的というか、管理至上的というか
＞なんとなく不思議な感じがしない？

私は、CMMとRUPとXPを調和させる道(笑 を模索しているんで、
身につまされる問いかけですね。

MLの方追っかけてみますです。

＞XPの話題のわりに、トップダウン的というか、管理至上的というか
＞なんとなく不思議な感じがしない？

　もともと、XPの導入を阻害する原因は何か？

って話題だったから、管理やなんかの話題がからむのは
仕方ないんじゃないかな？

>って話題だったから、管理やなんかの話題がからむのは
>仕方ないんじゃないかな？

違う違う。議論の内容ではなくて、
議論の進み方とか話題の出し方とか反論の仕方とかが、
トップダウン的だなあと思って。
共通点とか解決法を探って頑張りましょう、って雰囲気がないかな、と思って。

あくまで話の展開の仕方（内容ではなくてね）に対する
個人的な感想なので、根拠はないけど。
議論しているテーマ自体にはとても興味があります。
ああいう展開になって残念です。（予想はしてたけど。）

ここでMLと同じ展開にもなっても仕方がないのでのんびり行きましょ。

また新たなミイラ採りが現れたようだ。このhasegawa氏は何でこうも
何でもわかっているというお高い感じで書くんだろう。

[XP-jp:03095]
>予測は予測です。危険率ちゃんと入れてますか？
>もし余ったらお金返しますか？
>超えたら、追加で貰いますか？
>危険率大目じゃないと、受注自体危険な行為じゃないですか？
>そもそも、一点で見積もれるのですか？
>予測するのはいいんですがギャンブラーですね。
>危険率大目ってのはつまりぼったくっているってことですよね。
>機能仕様が流動的なのに、一点ですか。
>すごいな、予知能力者だね。
>僕なんて、車で吉祥寺から渋谷移動する時間さえ一点で予測できないです。

いやー、このフレーズ、好きだなぁ。
僕もかつては（４，５年前かなぁ）、生産性をあげることが正義だと信じてました。
つまり、1000万で受注して、500万の工数であげれば、500万もうかる、みたいな。（受託開発の場合）
でも、、見積もってるのも僕だから、「これっていわゆるボッタクリなのでは・・・」
などと悩んでました（藁

あ、XPと関係ない話ですね。
情シス板向けの話かなぁ。でも、あの板あまり行きたくないし。

>>593
CMMの事も全然分かっていないようだし、
話もCMMとXPとの対立だと思っているようだし、
ここまでおめでたい自己陶酔型の人も珍しい・・・。

どっちにしても、この騒動が収まるまではあのMLはだめだね。
話題があれば是非こっちへ。
XPの話題がないと、ML観察スレになってしまう（藁

ム版のXPスレ（これ）はMLに紹介しちゃだめだぞ。

みんな読んでんだなー。

「てめぇら、全部まとめて逝ってよし！」と言えないから、
どーにか収めようとして、火に油を注いじまったぃ。ｽﾏｿ

>>577
>フリーソフトバージョンを使うことにしましたとさ。

短期のプロジェクトなら尚のこと有償版を使った方が生産性上がると思うよ。
現にオレ今使ってるし。

ユニットテストについて聞きたいんですが、
直接入出力を触るようなユニットテストを作るのって難しくありません？

今、ソケットを持ったクラスがいて、
それのテストをどうやって書けばよいか困ってます。
ソケットからはひとかたまりのコマンドが流れて来ます。
また、非同期通信でこちらからも送信を行います。

接続後、
1. どのタイミングで
2. どんなコマンドが
3. どのような引数を伴って
くるかわかりません。

また、こちらからコマンドを送る際に、コマンドのレスポンスがすぐ来るとは限らない
ので、解決のイトグチを見付けられないのですが。

みんなどうやってるの？

タイミングはわからんけど, 生のソケットを直に使うんじゃなくて
ダミーと交換できるようなラッパにしとく. で テストはダミーで行う.
発想は Model/View の分離に似てる.

#そのラッパのテストは....

>>599
blackbox testではなくwhitebox test(=unitTest)の話ならば

まず対象クラスが使うソケットの機能をインターフェイスとして定義し
そのインターフェイスを初期化時に与えられるようにする。
ソケットを直接扱う部分はクラス化してそのインターフェイスを実装する。
対象クラスは初期化時にこのインターフェイスを与えられるようにする。

テスト用にそのインターフェイスを別途実装して、任意のデータ列を
読み書きできるキューを作る。(ここに好きなだけテスト用機能を追加できる)

次に対象クラスでプロトコルとしての処理が外から1ステップづつ進められるように、
OneStep メソッドを公開する。
これは何かを受信したときに呼び出され、それを処理してすぐに戻ってくるだけのもの程度。
引数なしで良し。
外向けコードでは内部でこれをぐるぐる呼び続けるものになるだろう。

あとはテストケースではテストインターフェイスを与えて構築して、
テストインターフェイスにデータを与え、OneStepを呼び出し、テストインターフェイスに
溜まったデータを確認してゆくだけ。

というふうにやっている。

ラッパめんどくさいなー。やっぱそれしかないんかな。
ラッパは超簡単な構造にしてテストを極力減らす、とか。
この場合は conn, disc, recv, send の４つだけで済みそうだし。

もっと楽な方法募集中。

# 私は Model/View じゃなくて Bridge Pattern が浮かびました。

ソケット、ソケットリスナ、プロトコル処理部、とかに分けて、
インターフェイスにして、それぞれモックつくって別々にテストってのは？

少なくとも個々のテストは簡単になると思う。
コードは増えるけどね。

とにかくクラス内部に直接リソースアクセスぽいものを持ってると
不幸のもとだと思う。

>>599
識者の人がレスをしていけど、
インタフェースをきってモックオブジェクトを
作ってやるのが、一番簡単で確実です。

しかしまだ、XP-JPは続いているね。
うざすぎ。
もう、逝ってメールしたいよ。（笑）

多段階のレイヤーからなるオブジェクト群の一番外側からまとめて全部テストかけようとすると
内部状態の組み合わせが膨大になってテストしきれないっしょ。
というかそれはもはやユニットテストじゃない。

一番内側のものからバラでテスト(unit test)していけるようにしないと。
ってことで結局インターフェイスで分割するのがトータルのテスト量がかなり削減できて
しかも確実だよね。

ってこれじゃみんなで同じことばかり書いてるだけだな。

実験計画法とか使わんのですか？

>>607
何？

「インターフェースで分割」したUnitTestてのがイメージつかめなかったから、
とりあえず、「実験計画法」＝「相関の低いテストをマージして、テスト量を減らす方法」
を挙げときました。

>相関の低いテストをマージして、テスト量を減らす
それより、分割して単体でテストできるようにしたほうがよいと思う

実験計画法なんているようなUnitTestって…

>>594
ぼったくって正解だよ。悪じゃない。
生産性を上げて費用を低く押さえるのは実質的値下げ。
むしろ、値下げは必ずしも正義じゃない。

っていうか、普段高くしておいて、「XPなら2割安くなります」とか言って
無理やりXPを広めるのも良いかも。

　 ∧,,∧　 　　／　スパイラルで
　ミ@д@彡＜　　　目、まわしとけー
　 U　 U　　　　＼
〜ﾐ　　ﾐ XPの紹介は次回だってさ
　 ∪∪

http://www.atmarkit.co.jp/fjava/devs/process01/process01.html

> 「開発プロセス」は、1つのソフトウェアをどのような手順で作り上げるかの取り決
> めです。その意味で、ソフトウェア開発の現場には必ず開発プロセスが存在します。
> 本稿では、前編で、開発プロセスの目的とその歴史を眺めながら、ソフトウェア開
> 発の現場が従来の開発プロセスによってどのような課題を抱えてきたのかを整理し
> ます。そして後編では、従来の開発プロセスが抱える課題に対する解答として登場
> してきた、新しい開発プロセスであるRUPやXPを紹介します。

>>611
生産性が上がらないから見積もりを多めにとって
危険を減らすのがぼったくっているっていってるん
でしょ。

>>613
言葉が足りなかったみたいだね。

<生産性が上がらないから見積もりを多めにとって危険を減らすようなぼったくりなら>
ぼったくって正解だよ。悪じゃない。
生産性を上げて<受注する>費用を低く押さえるのは実質的値下げ。
むしろ、<受注費用を安く押さえるような>値下げは
<他の下請け業者にもその安い価格での発注が波及してしまうという意味で>
必ずしも正義じゃない。

>>613-614
うーん、なんていうのかなぁ、生産性をあげればあげるほど、
ボッタクリ度が高くなる傾向になってしまう、ってことが言いたかった。

最近は、小規模プロジェクトでは、かなりソフト代が安くなってきてるけど、
僕が仕事を始めた頃は、UnixのCで1〜1.5Kステップで1人月とかやってたんです。
たかだか数十人月のプロジェクトで。

ちょっとプログラミングに自信がある人なら、普通の人の10倍くらいの
生産性があると自負してると思う。製造工程だけじゃなくて、全工程おしなべても、
人の倍くらいはいってる、と自負してる人が多いんじゃないかな。

僕もそうだったし、もっと生産性を上げてやろうと思ってた。
でも、結果は、密度の高いところは高いけど、1日で見たら、とんでもなく
密度の薄い仕事をするようになってしまった。それで仕事こなせちゃうし・・・。
（その原因はいろいろとあるんだけど・・・）

うーん、言いたいことがわからなくなったな。
ただ、一つ言えるのは、XPの見積もり方法はすごく気に入っていて、
実践したいなって思ってるということ。

[XP-jp:03180] Re: ＸＰとＣＭＭ : 某氏
（追伸）
このＭＬの状態がほぼ復旧されたかと思いますので、
私もそろそろROMオブザーバーに戻ろうかと思います。
-------
みなさんに質問です.
このおじさんは,自分が復旧させたと思っているのでしょうか?
また,いちいちROMオブザーバーに戻ると宣言するのはなぜだと思いますか?
頭がいかれてるんでしょうか?

>>616

たぶん、頭がいかれてるんだと思います

>ただ、一つ言えるのは、XPの見積もり方法はすごく気に入っていて、
実践したいなって思ってるということ。

　実践しているけど、いいね。

　一応最初の見積もりは、伝統的なLOCな見積もりを使って、
計画の調整や変更をXPの見積もりを使っている。
自分達で決めるんで、自ずと厳守しようとする傾向がある。

　ただ、ウォーターフォールな文書成果物に適用すると、
成果物のスコープでなく、品質で（計画に対して）コントロールしようと
してしまう傾向があり、ちょっと対策を思案中。

>>615 Error401
　あくまで漏れの感想だし、もしかしたら承知のことかも
しれんが、そうだったらゴメソ。

　追加する機能を実装する時間を、一定の精度で予測できるようにする。
っていうのが重要なんだよね。
　このことを可能にする前提条件は、ソースコードが綺麗にリファクタリング
ていることだよね。
　このリファクタリングにかかる時間が、予測できるかというのが結構難しい
気がする。

　ソースコードの構造をアーキテクトする人だ必要なのかも・・・、しかも一人がいい。
　(複数の人が設計に関わると、いいことにならないきいがする)
　あとピンク本にも書いていたように、ツールやコーティングスタイルも統一したほうが
良いかも。
　うーん、やっぱりXPは難しい

>>619
>あとピンク本にも書いていたように、ツールやコーティングスタイルも統一
>したほうが良いかも。

XPやるならそれは必須条件。
タブの文字数が違うだけでリファクタリング効率ガタ落ち。

XP導入した場合に、無能な人間を切るタイミング
ってどういうときなのですか？

>>619
>　追加する機能を実装する時間を、一定の精度で予測できるようにする。
>っていうのが重要なんだよね。
ちょっと話が違うし、XPとも関係ないけど書いちゃいます。

前の会社は、ほとんどの仕事が受託開発の下請けで、それを一括請負で
やってました。
ほとんどのプロジェクトは数十〜百人月程度で、その後のｎ次開発とか
機能追加なんかも、一括請負でやってました。

で、数人月〜１０人月程度の小さな改造の場合、
「これって、ここに100行くらい追加して、ここを数行修正すれば終わり」
ってのが結構あったんですね。
もちろん、改造しやすい構造にしてたからだし、機能追加されそうな項目を
予想したつくりにしてたからなんだけど。

そういう時に上司とぶつかった。
僕「これって、５人月の予算だそうですけど、１週間で終わっちゃいますよ」
上司「５人月っていうんだから、それにあうよう、適当な見積もりだしとけ」
ってな具合に。

途中で書き込んでしまった・・・。

で、作業工数で見れば「嘘」の見積もりを出すことになるんだけど、
これがすごくいやだったんだよね。
そういう時にこう考えた。
「これって、クライアントから見ると、どれくらいの価値があるんだろう？」
「作業工数ベースで見積もりするのは正しいことなのか？」
「作業効率が上がって、差分を儲けとするのはボッタクリでは？」

そういうことが続いて、しんどくなって、もうソフトウェアの仕事は止めちゃおう
と思って、前の会社を辞めました。（開発ソフトをほとんどコピーでまかなってた
ってのもあったけど）

でも、また、この業界に戻ってきちゃったんだけどね。

>>623
｢何が正しいことか｣を仕事の中で考えることは無駄だしハードだし結論も出ないけど、
自分を鍛えることになるのは間違いない。
きっと後で役に立つからその調子でがんばれ。

>>619
>ソースコードの構造をアーキテクトする人だ必要なのかも・・・しかも一人がいい。
XPについて書かれた物を読むと、ある程度うまく、アーキテクトされたものを
開発するにはいい方法だと思うんだけど、アーキテクトする人はいったいどうすれば
いいんだ。と思ってしまう。

XP信者=アカ

>>622 >>619
理想と現実の差ですね。
XPは、良いアプリを段階的、弾力的な開発方法ですから
今のウォータフォール的開発と合いませんね。
現実的には、妥協点 トレードオフを顧客と直接することはない訳ではない
という程度ですから。
オンサイト顧客かー。
顧客、営業しだいだね。

>>625
説明不足でしたね。
開発対象のデザインをアーキテクトする人という意味です。
ミーティングなど民主的な方法で解決できない場合は
大統領が必要だと言う意味です。
これも最初に決めるべきだと思っています。

{ソースコードの構造|デザイン}をアーキテクト「する」？
用語は正確に。

あーあ、みんな黙っちゃった。(w

とりあえず関連スレ

プログラマー板の「XP（エクストリームプログラミング）」
　http://pc.2ch.net/test/read.cgi/prog/1011833287/
情報システム板の「エクストリームプログラミングで」
　http://mentai.2ch.net/test/read.cgi/infosys/986909661/

平鍋氏は,調整ができないのかそれともしないのか? 謎.
本当に元に戻るのかね.
技術は優秀でも精神面で未熟な人が多く受容が下手なので,
紛糾しやすいということなのだろうね.
中盤煽る奴が多かった時には2chかとおもた。（藁
春から社会人になるの鬱だ.

>>631

調整が望まれていたと思いますが
議論のための議論はしないということなのか

＞６３１

俺は、ＭＬを何とかしようと思って発言した人への感謝がないのが頭にくるのだが。
どうよ？
結城さんを見習え！

>633
奴は感謝しすぎ

堀内撃沈！

hello World

>>623
人月で評価しているところを相手にする以上は、
効率が上がれば、実際の作業工数より多目の
工数見積りはやむを得ないのでは？　っていう
か、相手が納得する工数見積りであれば、あり
がたく儲けさせてもらわないと(藁

ﾍﾟｱﾌﾟﾛは2人で1人前だから、工数半分なんて
見積もられたら辛いけどね(涙

>>631
しないんでしょ．そんなん決まってんじゃん．
なんでそこまでメンドーみなあかんのよ．

>>638
どうしてきまってるの？ そこら辺がおいらにはわからないのだ。

>>639
自分の発言に責任を持つのは基本．けつを拭くのは自分でするのが当然．

>>635
撃沈してないと思うぞ．きっと明日あたり反撃！

>>640

そうなのかな・・・・

＞６３３

同感．esmで立ち上げているＭＬなのだから会社の宣伝にもなっている
部分もあるのだし，ポイントポイントでリーダシップを発揮して欲しい
と感じるのだが，おれは変か？ おしえろ！

ＭＬの時代は終わり。 2chで行こう！

>>643

リーダーシップは望まないまでも，
良い雰囲気にしようと発言した人への感謝は必要ではないでしょうかね．

とりあえず感謝します。

>>639
そそ。子供の喧嘩でしょ。
そんなの仲裁してるほどひまじゃないよ、フツウ。

>>647 仲裁は暇の人がやるとう論理は成り立たないと思うけど？

>>648
でも忙しい人にはそんなのやってるひまないよ。
やる気がある人とか文句がある人がゆえばいいのに。

不毛な論争は ML じゃなくて当事者間でやってほしいよね。
すげぇ迷惑。

それはわかるー。>>650
まさに子供の喧嘩なんじゃないの?

>>651
そういう都合の良い考えの方がよっぽど子供だと思うけど。

>>649
周りを見渡すと忙しい人ほど時間を作くるのが上手だったりしますけ
どね。

　　　　　 　 ∫
　　　∧,,∧ ∬　　　　 　 ／￣
　　 ミ,,ﾟДﾟノ,っ━~ξ　＜　ああいう一太刀を
＿と~,,,　　~,,,ﾉ＿.　■P　＼　
　　　 .ﾐ,,,/~),　　.|　━┳━ |　2chでは厨房って呼ぶんじゃ？
￣￣￣ .し'J￣￣|...　┃ 　　＼
￣￣￣￣￣￣￣ 　 .┻
　誰かが、"厨房逝ってヨシ"とでも言ってやらないと
　わかんないんじゃないのでしょうか？

M.Horiuchとか。あんたのメールが一番実にならないとか
言ってやる人はいないん？

マ。ぷろぐらマなんてのはｺﾐｭﾆｹｰｼｮﾝ能力の少ない人。
だけど、そういう前提はあっても、これはひどすぎる。

濱ヰ氏にしたって、いつも
「あなたのいう事は当然わかってますよ。だけど○○なんですよ」
って人を上から見下ろしている態度だし。
んなんじゃ、見ているほうはｳｯﾄｳｼｲだけでは？


「ＭＬで議論をするためのパターンランゲージ」
＞＞２ｃｈで匿名の名無しさんにバカにされたら議論はやめとく・・・・

>>654 おめーのように影でくちぐち言っているのが一番厨房。あほ。

>>654
|＞＞２ｃｈで匿名の名無しさんにバカにされたら議論はやめとく・・・・

はぁ，パタンランゲージになっていませんが？

　　　　　　　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　 ∧,,∧　　＜ 　厨房って言われちゃいました
　　　　　　　　 ミﾟДﾟ,,彡＿　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　 ／￣￣∪　∪　／|
　　　／∧＿∧　 　　／／|
　 ／　（ ；´∀｀）＿／／┌─────────
　||￣（ 　　　 つ　||／　＜ 　正解です。
　||　（_○_＿_)　　||　　　└─────────

>>653
時間作った結果でしょ．
優先順位高いとはぜんぜん思えないけど．

>>658
そんなに優先順位が高くないにしても，時間もそれほど掛ける必要も
ないのでは？ 優先順位云々よりも，そうする必要があると思っているかどうかと
いうことなのではないかともうのだが．

>>656
パタンランゲージって役に立つの？ どういうもの？

パタンランゲージ
　　　　学ぶ暇あったらLISPでもやってろ

>>659
だからー．ないと思ってるんでしょう．

>>659
あると思うんならその時に
「どうにかしろ」ってメールを本人に出せばいい話．
いまさらどーしようもないのでは?

>>663 出した人いたじゃん。けれども相手にされなかったので
その内容をそのままＭＬに流してたね。

>>664
あれ、そうだっけ。
それは失礼。
読んでなかったってことね。

「トヨタ生産方式とXP」が Subject に含まれるメールを読まずに捨てる
フィルタを定義したよ。最初は興味深いスレッドだったのに、残念だね。
合掌。

>>666 嘘ばっかり。（藁

そういう過度な事をいう奴に限って毎回どういう状況に
なっているか気になって気になってしかたないんじゃないの？
興味深かったならもっと興味深くなるように意見を出せばいいだけじゃん。
なんでそんなに鼻息荒くするのさ？

>>667

その程度のレベルの参加者が，多いってことで許してやってください．

技術偏重で精神面がついていっていないっていうのは
知的な仕事には常について回る問題っすね ＞ハマイ氏・ホリウチ氏 他多数

Kent Beckに対抗して(ｗ
Smalltalk 紫本のアデル・ゴールドバーグ(だよね？)も、
こーゆー本出してるみたいね。
http://www.amazon.co.jp/exec/obidos/ASIN/479529707X/qid%3D1013858320/250-3986046-5466660
#今日発見して、手持ちが少なくて買えなかった

＞ ６７０

ＳＭＬで青木＠SRA氏は親鸞とか持ち出しているが仏教徒なのか？
結城さんはキリスト教だし、共通するものがあるのかな。
俺も何か信仰する必要あるのかな。
鬱だ

>>669 技術偏重ではなく、知識偏重では？

俺は，色んな人がいるなぁとわかって楽しいけどな．

濱井氏のどんなに攻撃されてもへこたれない所を尊敬してしまっている僕がいる〜

>>671
日本の歴史に残る名経営者は決まってしっかりとした宗教観を持っているし
日本の芸術や伝統芸能の根底には禅思想がありますね．
海外でも宗教音楽や宗教芸術が根本にありますね．
宗教に入らなくても宗教観を持つのはクリエイティブな仕事には必要かも
しれないですね．

つまり、馬鹿を業界から払拭させれば、
品質の高いのができるってことじゃない。

>>666
>なんでそんなに鼻息荒くするのさ？
ｵﾏｴｶﾞﾅｰ

>>675
なるほどRubyの松本氏もクリスチャン！
他にいますか？

＞６７６ 頭の良さではなくて生き方や在り方だとおもうけど。
もしかしてあなたは、おれは馬鹿だってことを表明しているの？

禅は勉強してみたいな

MLで紹介があった『目で見る管理』を買って読んで見た．
３時間程で読めちゃったけど共感できた．
目で見るようにという見方をするだけでも工夫をする事ってたくさんあるなと思った．
要約できるほど理解できていないけど，
管理者を必要としない職場を作ることを目指しているように思った．

Ｕｎｉｔテスト最初はテストケース書くの楽しいけど、
中盤すぎるとだんだんと面倒になって
最後まで書きつづけることができない俺は厨房か？
みんなは最後まで書きつづけられてる？

結城さんはすごい人だとおもうけど，神様に感謝している日記を読むと
なぜか引いてしまう俺がいる・・・．
小乗仏教や禅はまだ受け入れられるのだけどね．
キリスト教は，クリスチャンの国が戦争を好んでいるのを目の当たりに
するとキリスト教はどうもだめだ．

多分ＸＰＭＬでの出来事を書かれているのではないかと思われ．
http://www.hyuki.com/diary/dia0202.html#i16
良いこと書きますね．でもこれを直接ＭＬで意見として書き
間違っているといってあげればよいのに書かないから胡散臭く感じる．
そう書くんなら実行しろといいたい．

　　 　 ∧,,∧　　 ／￣￣￣￣￣￣￣￣￣￣￣
　　　 ミ,,ﾟДﾟ彡＜　君子危うきに近寄らず
　　　'ﾐ つ旦)~~ 　＼＿＿＿＿＿＿＿＿＿＿＿
　　⊂ミ",,　,,ﾐ つ
　　　　　　　　結城ﾀﾝがXPMLでくだらないやり取りに
　　　　　　　　参加してたら幻滅するよ

こういう所で名前が出てくるっていうことはそれだけインパクトがあると
いうことなのでしょうね。叩かれることが幸せと思えるようになると
本当に強いですね。

すれ違いで申し訳ないが、
結城は真性のアホです。

>>687 その根拠は？

>>688

http://pc.2ch.net/test/read.cgi/prog/994305513

クリスチャンの国アメリカが戦争を続けている状況をどのように考えている
のか結城に問いたい！ 神なんていないことは頭がまともだとすぐわかるはずだが．

剥げ鍋は終わり

>>682
おぉ、同じ悩みだ （涙

やっぱりさぁ、2chだとよくもわるくも雑談形式になっちゃうよね。

フィードバックについて：
私ゃー、変わって欲しい方には(例え相手がお偉いさんでも)、
何らかのフィードバックしますけど。
相手に良く思われたい時とか、どーでも良い相手には、フィードバックしにくい事ってあるよね。

ところで、
アデル本の評判はどうなんでしょう？
XPML覗いたらわかりますか？

↑あ、>>684へのレスね。

>>695 信仰していない人の場合にはそれはあるし矛盾のないものだと思うけど，
信仰している人にとってはそれは矛盾であり信仰しているということが
何も価値のないものになってしまう瞬間にも思える．

(´Д`)

>>696
(´Д`) ジーザス関係詳しくない無神論者なんで、
　　　　お気に触ったら申し訳ないんですけれど...

　　　　「慈愛」って言葉を聞いた事がありますが、
　　　　聞く耳持たぬ相手/気を使ってもしょうがない相手に、
　　　　きちんとしたフィードバックをしない事で、
　　　　矛盾を感じられておいででしょうか？

(´Д`) なんか、踏み込んではいけない領域にはいっちゃったみたい

ねぇ、アデル・ゴールドバーグさんの本って、わかりやすい？

>>699
>>698 は、 日本語が変です。

敬語を重ねると、
文意が通じにくくなるという罠

判ってるつもりで、気を使い過ぎると、
相手を怒らせる罠

>>703 がんばったけど、劣

まってたぴょん！

俺的には、>>704 みたいな、わけわからん単発書き込みいれてくる方とは、
ペア・プログラミングしたくないなぁ

>>704 みたいな奴がいると、開発グループの雰囲気悪くなるよね。

哀れな>>704の書き込みマナーが向上しますように(はぁーと

>>671
青木淳さんは世界的なSmalltalk使いだよね。
最近の彼はSmalltalkやめてSMLに行っちゃったんすか？本当？
昔から（プログラマが型を宣言する）型付の言語には批判的だったが、
MLタイプの型推論を受け入れたとはね...

青木さんは、自身は仏教徒、中でも密教系やねん。
でも密教以外や、他の宗教にも詳しい。
（背後にSRAの岸田孝一さんという人がイスラム教などの入れ知恵もしてるらしい。）
セミナーや本では宗教を使った比喩が得意やけど、
普段やビジネス中は特に宗教色がある人には見えなかった（少なくとも昔＝２０世紀ぐらいには）。

>>708
Standard MLじゃなくてSmalltalkers' Salon Mailing List

>>707 いちいちつまらないことが気になる貴殿も雰囲気を悪くするタイプでは？

>>709
SRA(青木氏が働いている会社)には関数型言語のページもあるよ。
個人のページだけどね。
http://www.sra.co.jp/people/nishis/learning/fpl/index.html

すまん