【XP】 Agile Process 【UP】
1 ： ：
Agile関連の議論、情報交換、質問のために使って下さい。
XPスレと補い合う感じで役立てばいいなと思います。
関連スレ
・eXtreme Programming Part.3 （XPスレッド）
http://pc3.2ch.net/test/read.cgi/tech/1023709462/l50
・Agile Alliance にあるドキュメント集
http://www.agilealliance.org/home
・Wiki本家のAgile関連ページ
http://c2.com/cgi/like?AgileProcess
・Agile Modeling（お勧め）
http://www.agilemodeling.com/
なるべくマターリでおながいします。
XPスレと補い合う感じで役立てばいいなと思います。
関連スレ
・eXtreme Programming Part.3 （XPスレッド）
http://pc3.2ch.net/test/read.cgi/tech/1023709462/l50
・Agile Alliance にあるドキュメント集
http://www.agilealliance.org/home
・Wiki本家のAgile関連ページ
http://c2.com/cgi/like?AgileProcess
・Agile Modeling（お勧め）
http://www.agilemodeling.com/
なるべくマターリでおながいします。
|
|
|
2 ：デフォルトの名無しさん：02/09/25 01:00
で、なんなのそれ？
3 ：デフォルトの名無しさん：02/09/25 01:22
3げと
4 ：3：02/09/25 01:34
>>2
http://www.metabolics.co.jp/XP/AgileCommentary.html より
>「アジャイル開発プロセス 」とはある特定の開発手法を指す言葉
>ではありません。「アジャイルな」とはつまり、良いものを手早く
>無駄なく作ることです。「アジャイル開発プロセス」という言葉は
>アジャイルにソフトウェアを開発することを可能にするさまざまな
>手法全体を指して使われています。
>かつては「軽量級の(lightweight)」プロセスと呼ばれていました。
>
>皆さんよくご存知のエクストリーム･プログラミングも
>アジャイル開発プロセスの代表的な手法の一つです。
>近年エクストリーム･プログラミングが日本でも急速に普及している
>のと同様に、合衆国ではここ数年来エクストリーム･プログラミング
>を含む多くのアジャイル開発プロセスが提案され、
>広く利用されています。
http://www.metabolics.co.jp/XP/AgileCommentary.html より
>「アジャイル開発プロセス 」とはある特定の開発手法を指す言葉
>ではありません。「アジャイルな」とはつまり、良いものを手早く
>無駄なく作ることです。「アジャイル開発プロセス」という言葉は
>アジャイルにソフトウェアを開発することを可能にするさまざまな
>手法全体を指して使われています。
>かつては「軽量級の(lightweight)」プロセスと呼ばれていました。
>
>皆さんよくご存知のエクストリーム･プログラミングも
>アジャイル開発プロセスの代表的な手法の一つです。
>近年エクストリーム･プログラミングが日本でも急速に普及している
>のと同様に、合衆国ではここ数年来エクストリーム･プログラミング
>を含む多くのアジャイル開発プロセスが提案され、
>広く利用されています。
5 ：3：02/09/25 01:38
まだ読んでいないんだけど、今月の JavaWorldに特集組まれてるね>AgileProcess
6 ：デフォルトの名無しさん：02/09/25 01:40
このスレ幸先いいスタートとはいえないよなあ。
ま、がんばれ。
ま、がんばれ。
7 ：デフォルトの名無しさん：02/09/25 01:45
手法じゃなくて目的意識か
8 ：デフォルトの名無しさん：02/09/25 02:06
RUPスレがほしいな
9 ： ：02/09/25 13:03
>>7
だいたいそんな感じです。
↓は関連する引用です。
The question for using agile methodologies is not,
"Can an agile mothodology be used in this situation?"
but "How can we remain agile in this situation?"
Alistair Cockburn -『Agile Software Development』
だいたいそんな感じです。
↓は関連する引用です。
The question for using agile methodologies is not,
"Can an agile mothodology be used in this situation?"
but "How can we remain agile in this situation?"
Alistair Cockburn -『Agile Software Development』
10 ：デフォルトの名無しさん：02/09/25 17:21
アジャイルの本はずいぶん読んだから意味はわかるけど、
そもそも「アジャイル」ってどういう意味なん？
話はその辺から。。。。。。。。。。
そもそも「アジャイル」ってどういう意味なん？
話はその辺から。。。。。。。。。。
11 ：デフォルトの名無しさん：02/09/25 17:25
辞書を引いてみようとは思わないのだろうか。
12 ：デフォルトの名無しさん：02/09/25 17:33
ハゲしく宗教スレな予感…
13 ：デフォルトの名無しさん：02/09/25 17:39
Java World でアジャイル特集やってなかったっけ?
あの雑誌も最近なんだかアレな匂いがして来たが…
あの雑誌も最近なんだかアレな匂いがして来たが…
14 ：デフォルトの名無しさん：02/09/25 17:43
15 ：デフォルトの名無しさん：02/09/25 17:47
>13
最近あらぬ方向へ爆進してるような。
というか宗教じみてきた。
最近あらぬ方向へ爆進してるような。
というか宗教じみてきた。
16 ：デフォルトの名無しさん：02/09/25 17:50
まあ、乱世に宗教はつきものだがな
17 ：デフォルトの名無しさん：02/09/25 18:12
>>10
Agile:
{形}素早い｛すばやい｝、機敏｛きびん｝な、身のこなしの軽い、敏捷｛びん
しょう｝な、身の軽い、機動的｛きどうてき｝な、鋭敏｛えいびん｝な、敏活
｛びんかつ｝な、活気のある、頭の回転の速い、しなやかな
Agile:
{形}素早い｛すばやい｝、機敏｛きびん｝な、身のこなしの軽い、敏捷｛びん
しょう｝な、身の軽い、機動的｛きどうてき｝な、鋭敏｛えいびん｝な、敏活
｛びんかつ｝な、活気のある、頭の回転の速い、しなやかな
18 ：デフォルトの名無しさん：02/09/25 19:12
agilityを高めて乱世を逃げ切れ！
19 ：デフォルトの名無しさん：02/09/25 19:51
まあ宗教といえば宗教って言えないこともないけど、それって
オブジェクト指向を宗教とみなすのと同レベルだと思うよ。
少なくともOver-documentなプロセスの対抗馬がXPのみって
状況よりは遥かにまともに見えるけど。
オブジェクト指向を宗教とみなすのと同レベルだと思うよ。
少なくともOver-documentなプロセスの対抗馬がXPのみって
状況よりは遥かにまともに見えるけど。
20 ：デフォルトの名無しさん：02/09/25 20:00
>>1
また胡散臭い紺猿好みなネタ出してきやがったな。
また胡散臭い紺猿好みなネタ出してきやがったな。
21 ：デフォルトの名無しさん：02/09/25 20:02
やっぱりトークネタか
22 ： ：02/09/25 20:04
>>21
トークネタって何？
トークネタって何？
23 ：デフォルトの名無しさん：02/09/25 20:05
営業トーク
24 ：デフォルトの名無しさん：02/09/25 21:02
もう中身の無いキーワードに踊らされる時代は終わったんですけど。
25 ：デフォルトの名無しさん：02/09/25 21:13
それなら放っておいたらどうですか？
26 ：デフォルトの名無しさん：02/09/25 22:42
>紺猿
みんなこれでわかるのか？
脳が2ちゃんに犯されてないか？
みんなこれでわかるのか？
脳が2ちゃんに犯されてないか？
>>5
JavaWorld読みました。名前しか知らなかったのも紹介されていて
興味深かったです。
ただSCRUMに関しては、なんか精神論的な部分が強調され過ぎていて、
正直引いちゃいました。
いまのところ移行とか導入のノウハウの方もわりと需要があると
思うんですが、雑誌なんかでもそういったところを紹介して欲し
いですね。
JavaWorld読みました。名前しか知らなかったのも紹介されていて
興味深かったです。
ただSCRUMに関しては、なんか精神論的な部分が強調され過ぎていて、
正直引いちゃいました。
いまのところ移行とか導入のノウハウの方もわりと需要があると
思うんですが、雑誌なんかでもそういったところを紹介して欲し
いですね。
28 ：デフォルトの名無しさん：02/10/03 14:36
これってXPよりいいの？
29 ：デフォルトの名無しさん：02/10/03 14:50
>>28
XP、SCRUM、クリスタルシリーズなどが agile なプロセスと言われている。
XP、SCRUM、クリスタルシリーズなどが agile なプロセスと言われている。
30 ：デフォルトの名無しさん：02/10/03 14:58
どっちが良いっていうか、XP も含んだ大枠ってところか。
31 ：デフォルトの名無しさん：02/10/03 15:10
スモールチーム・ノンドキュメントが成り立つ（許される）
状況におけるアジャイルプロセスの実現形態の一つとして
XPを捉えるといいかも。
状況におけるアジャイルプロセスの実現形態の一つとして
XPを捉えるといいかも。
32 ： ：02/10/06 05:39
おまいらアジャイル開発するときにあったら便利な小道具とか
ユーティリティとか、なんか挙げて見てください。
ユーティリティとか、なんか挙げて見てください。
33 ：デフォルトの名無しさん：02/10/06 13:13
>>32 論点ずれずれ
34 ：デフォルトの名無しさん：02/10/06 13:16
【XP】 Fragile OS 【down】
35 ：デフォルトの名無しさん：02/10/07 01:09
36 ：デフォルトの名無しさん：02/10/07 01:26
UML PostIt!
37 ： ：02/10/07 01:32
38 ：デフォルトの名無しさん：02/10/07 02:05
ちゃうちゃう、
ピーターコッドのカラーUMLその他で紹介されてる、
紙にペタペタPostIt!貼り付けて、UMLの各種ダイアグラムを書く方法。
Agile周りの雑誌記事見ると、予めUML用に印刷されたPostIt!もある始末。
ピーターコッドのカラーUMLその他で紹介されてる、
紙にペタペタPostIt!貼り付けて、UMLの各種ダイアグラムを書く方法。
Agile周りの雑誌記事見ると、予めUML用に印刷されたPostIt!もある始末。
痛い勘違いしてしまった。
デスクトップに貼っとく付箋紙をイメージしてしまった。
デスクトップに貼っとく付箋紙をイメージしてしまった。
40 ：デフォルトの名無しさん：02/10/16 02:00
あげ
41 ：デフォルトの名無しさん：02/10/16 02:02
ひでぇ閑古鳥の様相だな。
やはり怪しい紺猿が好きそうなキーワードだけじゃもう誰も飛びつかないってことか。
やはり怪しい紺猿が好きそうなキーワードだけじゃもう誰も飛びつかないってことか。
42 ：デフォルトの名無しさん：02/10/16 02:06
43 ：デフォルトの名無しさん：02/10/27 01:05
おまいらドカタは、一生泥まみれの形だけのＷＦで一生デスマーチに追われてるのがお似合いです。
44 ：1：02/10/27 12:00
45 ：デフォルトの名無しさん：02/10/27 14:06
２ちゃんて、まともな議論する事もなくﾈﾀスレに突入する事が多いなぁ。
誰もこんな所で議論したいと思わないから、ただﾈﾀとして消費するしかない、と。(寒
誰もこんな所で議論したいと思わないから、ただﾈﾀとして消費するしかない、と。(寒
46 ：デフォルトの名無しさん：02/10/27 14:52
XPはxUnit/Refactoring Browserとか
おもしろツールの紹介もあったから
流行ったんじゃない？
RUPに負けたやしらまで騒ぎ始めた辺りから
猿臭くなってきてなんか冷めた。
おもしろツールの紹介もあったから
流行ったんじゃない？
RUPに負けたやしらまで騒ぎ始めた辺りから
猿臭くなってきてなんか冷めた。
47 ：デフォルトの名無しさん：02/10/30 21:25
ハゲしく宗教スレな予感…
48 ：デフォルトの名無しさん：02/10/30 22:18
Agileは、野に咲く一輪の花のように、
現場で洗練されるべきプロセス。
Agile売り込む紺猿って、一見良識派に見えるが、
実は「ロンドンでは今パンクが大ブームです」てぇな事言って、
ストリート文化にブランド付けて堅苦しく売り出す、
貿易商の可能性大。
現場で洗練されるべきプロセス。
Agile売り込む紺猿って、一見良識派に見えるが、
実は「ロンドンでは今パンクが大ブームです」てぇな事言って、
ストリート文化にブランド付けて堅苦しく売り出す、
貿易商の可能性大。
49 ：デフォルトの名無しさん：02/11/15 16:07
ぷぅ
50 ：デフォルトの名無しさん：02/12/08 02:36
51 ：デフォルトの名無しさん：02/12/25 13:32
XPのテストファースト実践するのって大変だな。
慣れるの大変だ。
今までantを使ってきた。
javasdocでコメント書いてきた。
テストファーストではプログラムにコメントかかずにテストプログラムにのみコメント
書けっていうのも、いまからそのように方針を変えなくてはならない。
antからJUnitを呼び出して動かす方法に2,3日かけてやっと慣れてきた。
もっともっと修行が必要だ。
仕事でやっているわけじゃないし、
一人でしかプログラミングしていないからペアプログラミングしようが無いんだな。
そのうち誰かにも手伝ってもらうが自分の周りにXPはおろかオブジェクト指向もおろかJavaを
理解できるものがいない。
しかもオブジェクト指向の必要性を理解していないと来た。
関数だけで十分といっているのが殆ど。
なかには、関数すら使っていないものがいる。大変だ。
慣れるの大変だ。
今までantを使ってきた。
javasdocでコメント書いてきた。
テストファーストではプログラムにコメントかかずにテストプログラムにのみコメント
書けっていうのも、いまからそのように方針を変えなくてはならない。
antからJUnitを呼び出して動かす方法に2,3日かけてやっと慣れてきた。
もっともっと修行が必要だ。
仕事でやっているわけじゃないし、
一人でしかプログラミングしていないからペアプログラミングしようが無いんだな。
そのうち誰かにも手伝ってもらうが自分の周りにXPはおろかオブジェクト指向もおろかJavaを
理解できるものがいない。
しかもオブジェクト指向の必要性を理解していないと来た。
関数だけで十分といっているのが殆ど。
なかには、関数すら使っていないものがいる。大変だ。
52 ：デフォルトの名無しさん：02/12/25 13:39
53 ：デフォルトの名無しさん：03/01/09 02:54
ｺｿｰﾘ(･∀･)
54 ：デフォルトの名無しさん：03/01/09 03:35
/＼ /＼
/:::::::ヽ＿＿＿＿/::::::::ヽ、
丿 ::.__ .::::::::::::: __ ::::ヽ_
／ ／。 ヽ_ヽｖ /: ／。ヽ ::::::ヽ
-┼- 丿~~~| / ／￣￣√_＿＿丶 ￣￣＼ ::::| ■ ■
-┼- /~~~~/ ━━━ | .:::::::::: / / ｔｰｰｰ|ヽ ..::::: ::|━━━━━━ ▼ ▼
.| 丿 | .:::::. ..: | |ヽ ::| ● ●
| ::: | |⊂ニヽ| | :::::| ＼
／ ／| : | | |:::T::::| ! .::| ＼ ＼＼
／ ／ ＼: ﾄ--^^^^^┤ 丿 ＼＼＼ ＼＼＼
お、大阪・・・・
/:::::::ヽ＿＿＿＿/::::::::ヽ、
丿 ::.__ .::::::::::::: __ ::::ヽ_
／ ／。 ヽ_ヽｖ /: ／。ヽ ::::::ヽ
-┼- 丿~~~| / ／￣￣√_＿＿丶 ￣￣＼ ::::| ■ ■
-┼- /~~~~/ ━━━ | .:::::::::: / / ｔｰｰｰ|ヽ ..::::: ::|━━━━━━ ▼ ▼
.| 丿 | .:::::. ..: | |ヽ ::| ● ●
| ::: | |⊂ニヽ| | :::::| ＼
／ ／| : | | |:::T::::| ! .::| ＼ ＼＼
／ ／ ＼: ﾄ--^^^^^┤ 丿 ＼＼＼ ＼＼＼
お、大阪・・・・
55 ：デフォルトの名無しさん：03/01/09 04:18
いい加減コピペしまくる目的を書いて頂きたいところ。
56 ：デフォルトの名無しさん：03/01/09 13:53
...〆(．．) ﾒﾓﾒﾓ
57 ：デフォルトの名無しさん：03/01/09 14:43
決定した事だから
もう元には戻しません。
時は流れる。
もう元には戻しません。
時は流れる。
58 ：デフォルトの名無しさん：03/01/09 17:39
======2==C==H======================================================
２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数： 138720人 発行日：2003/1/9
年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。
そんなわけで、年末に予告したIP記録ですが実験を開始しています。
「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。
んじゃ！
────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数： 138720人 発行日：2003/1/9
年末年始ボケがそろそろ収まり始めた今日このごろのひろゆきです。
そんなわけで、年末に予告したIP記録ですが実験を開始しています。
「２ちゃんねる20030107」
こんな感じで各掲示板の最下部に日付が入ってるんですが、
20030107以降になってるところはログ記録実験中ですー。
んじゃ！
────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
59 ：デフォルトの名無しさん：03/01/09 23:31
言いたいこともいえないこんな2ちゃんねるじゃ
60 ：デフォルトの名無しさん：03/01/10 08:31
電気店のパソコン売り場から２ちゃんにｶｷｺする奴が増えるんだろうなあ
61 ：デフォルトの名無しさん：03/01/10 09:51
いやぁ、いろんな人から電話かかってきておもしろかった。
んじゃおやすみなさい（３回目）
んじゃおやすみなさい（３回目）
62 ：デフォルトの名無しさん：03/01/10 10:32
明け方は逢魔時
63 ：デフォルトの名無しさん：03/01/10 11:03
なんでこんなにスレが伸びてるんだ？
64 ：デフォルトの名無しさん：03/01/10 11:47
2ちゃんねる が衰退していく
あるネット関連会社の社長は、
「いずれにしても2ちゃんねるは資金が底をつけば終わり。
あまり知られていないことだが、2ちゃんねる内部関係者によると今、
大手通信会社系が調査費名目で資金提供している。
だが、それが止まれば続けてはいけないだろう」
と証言する。
2ちゃんねるが判決によって力を失った場合、
資金提供の打ち切りも予想される。
http://ascii24.com/news/reading/causebooks/2002/07/01/636911-000.html
あるネット関連会社の社長は、
「いずれにしても2ちゃんねるは資金が底をつけば終わり。
あまり知られていないことだが、2ちゃんねる内部関係者によると今、
大手通信会社系が調査費名目で資金提供している。
だが、それが止まれば続けてはいけないだろう」
と証言する。
2ちゃんねるが判決によって力を失った場合、
資金提供の打ち切りも予想される。
http://ascii24.com/news/reading/causebooks/2002/07/01/636911-000.html
65 ：デフォルトの名無しさん：03/01/10 12:17
腹減ったな
66 ：デフォルトの名無しさん：03/01/10 13:08
だって元々IDからプロバイダは割り出せるんでしょ
67 ：デフォルトの名無しさん：03/01/10 15:30
削除管理委員という方は見たことないです。
スレ救出隊っていうのも聞いたことないです。
68 ：デフォルトの名無しさん：03/01/10 16:58
記念に・・・。
69 ：デフォルトの名無しさん：03/01/10 23:19
70 ：デフォルトの名無しさん：03/01/11 00:42
( ´db｀)ﾉ＜ 地味に→地味な
71 ：デフォルトの名無しさん：03/01/11 00:50
じゃあ本当の意味言ってみろよ（･∀･）ﾆﾔﾆﾔ
72 ：デフォルトの名無しさん：03/01/11 10:12
発言に責任の持てない厨はﾔﾌﾟｰに逝くか
ママに添削してもらってから書き込めってこった
ママに添削してもらってから書き込めってこった
73 ：デフォルトの名無しさん：03/01/11 10:46
======2==C==H======================================================
２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数： 139038人 発行日：2003/1/10
なにやら、連日メルマガだしてるひろゆきです。
そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。
重くなって落ちたりしてもご愛嬌ってことで。。。
んじゃ！
────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
２ちゃんねるのお勧めな話題と
ネットでの面白い出来事を配送したいと思ってます。。。
===============================読者数： 139038人 発行日：2003/1/10
なにやら、連日メルマガだしてるひろゆきです。
そんなわけで、ログ記録実験ですが、いちいちサーバ指定するのが面倒なので、
全部のサーバに入れてみました。
重くなって落ちたりしてもご愛嬌ってことで。。。
んじゃ！
────────────────────────Age2ch─
■この書き込みは、Age2chを使って配信されています。
────────────────────────────
Keep your thread alive !
http://pc3.2ch.net/test/read.cgi/software/1041952901/l50
────────────────────────────
74 ：デフォルトの名無しさん：03/01/11 11:37
それはまあ自業自得だろう
75 ：デフォルトの名無しさん：03/01/11 12:13
馬鹿ネタはへらんだろ。ただ、ｷﾁｶﾞｲネタが少し減るだけ。
76 ：デフォルトの名無しさん：03/01/11 13:11
ただ、これはもう既出だろうけど、ただIPとってもひろゆきの責任は減らないんだよね。
要は、削除権を適切に行使しているかがポイントになる訳だから。
その意味では、これまたヲチ板がいい例だが、現状ではとても免責は無理だろう。
要するに、ひろゆきは今後さらに追いつめられることになる。
要は、削除権を適切に行使しているかがポイントになる訳だから。
その意味では、これまたヲチ板がいい例だが、現状ではとても免責は無理だろう。
要するに、ひろゆきは今後さらに追いつめられることになる。
77 ：デフォルトの名無しさん：03/01/11 13:41
また連休中に元に戻ったりしてな、きまぐれだから
184 ：ひろゆき ◆3SHRUNYAXA ：03/01/11 05:40 ID:kSb7xo24
イナゴのように資源を食い尽くして移動していきます。
184 ：ひろゆき ◆3SHRUNYAXA ：03/01/11 05:40 ID:kSb7xo24
イナゴのように資源を食い尽くして移動していきます。
78 ：デフォルトの名無しさん：03/01/11 16:26
IPアドレス記録は今後継続していきましょう。
もっと踏み込んだ手段をとればなおいいが。
もっと踏み込んだ手段をとればなおいいが。
79 ：デフォルトの名無しさん：03/01/11 16:34
Yahoo! JAPAN コンピュータニュース - 1月9日(木)19時43分
2chでIP記録実験が始まる
http://headlines.yahoo.co.jp/hl?a=20030109-00000021-zdn-sci
ZDNet News - 2chでIP記録実験が始まる
http://www.zdnet.co.jp/news/0301/09/njbt_07.html
ネット掲示板「2ちゃんねる」管理人のひろゆき氏は1月9日、掲示板に書き込んだ
ユーザーのIPを記録する実験を始めたことを明らかにした。
ひろゆき氏が発行するメールマガジンで明らかにした。各掲示板の最下部の日付が
「2ちゃんねる20030107」以降のものはアクセスログの記録を実験しているという。
ひろゆき氏は2002年末、都内の動物病院が同掲示板への発言の削除を求めた裁判の
控訴審で敗訴したのを受け、IP記録の開始を示唆していた。（ZDNet）
2chでIP記録実験が始まる
http://headlines.yahoo.co.jp/hl?a=20030109-00000021-zdn-sci
ZDNet News - 2chでIP記録実験が始まる
http://www.zdnet.co.jp/news/0301/09/njbt_07.html
ネット掲示板「2ちゃんねる」管理人のひろゆき氏は1月9日、掲示板に書き込んだ
ユーザーのIPを記録する実験を始めたことを明らかにした。
ひろゆき氏が発行するメールマガジンで明らかにした。各掲示板の最下部の日付が
「2ちゃんねる20030107」以降のものはアクセスログの記録を実験しているという。
ひろゆき氏は2002年末、都内の動物病院が同掲示板への発言の削除を求めた裁判の
控訴審で敗訴したのを受け、IP記録の開始を示唆していた。（ZDNet）
80 ：デフォルトの名無しさん：03/01/12 03:27
ああ
81 ：デフォルトの名無しさん：03/01/12 03:28
ビビったよ
漏らした
漏らした
82 ：デフォルトの名無しさん：03/01/12 10:55
誰も言わないから、えー顔しーのオレが
なな乙
なな乙
83 ：デフォルトの名無しさん：03/01/12 10:58
このコピペ厨はアンチ２ちゃんを静めるのに効果抜群だな。
実はこのコピペは取り巻きが…
実はこのコピペは取り巻きが…
84 ：デフォルトの名無しさん：03/01/12 21:29
test test
85 ：デフォルトの名無しさん：03/01/12 21:32
>インターネットという新しい社会に秩序を保とうとしています。
今のひろゆきにこういう積極性はあるのだろうか。
http://www.nikkei.co.jp/digitalcore/event/011207/02.html
>逆に、影響力が大きいので、法律の素人が判断する筋合いではないと考えている。
>手段でしかない匿名掲示板に責任を求めるのは、無理がある。
ひろゆきのための２ちゃんねるという宣言文句とこれは、額面では矛盾するように思えるな。
今のひろゆきにこういう積極性はあるのだろうか。
http://www.nikkei.co.jp/digitalcore/event/011207/02.html
>逆に、影響力が大きいので、法律の素人が判断する筋合いではないと考えている。
>手段でしかない匿名掲示板に責任を求めるのは、無理がある。
ひろゆきのための２ちゃんねるという宣言文句とこれは、額面では矛盾するように思えるな。
86 ：デフォルトの名無しさん：03/01/12 21:43
どれぐらいでおわるの？ 明日までにはおわりそう？
（＾＾）
88 ：デフォルトの名無しさん：03/01/13 23:34
敗訴ｷﾀ━━(ﾟ∀ﾟ)━━( ﾟ∀)━━( ﾟ)━━( )━━( )━━(ﾟ )━━(∀ﾟ )━━(ﾟ∀ﾟ)━━━!
（＾＾）
（＾＾）
91 ：デフォルトの名無しさん：03/01/29 05:28
XPのスレ見当たらんと思ったらいつのまに。
アジャイルメソッドって、XPがWinXPと名前ダブるから呼び名変わった程度に思ってたんだが
そうでもないん？
アジャイルメソッドって、XPがWinXPと名前ダブるから呼び名変わった程度に思ってたんだが
そうでもないん？
92 ：デフォルトの名無しさん：03/01/29 08:00
そうでもないんよ。まずはコーバーンの本嫁。
93 ：デフォルトの名無しさん：03/01/30 03:18
今日うちの社長が新しい開発手法だと言って
ウォーターフォールを紹介されました
なんだかなあ
ウォーターフォールを紹介されました
なんだかなあ
94 ：デフォルトの名無しさん：03/01/31 01:02
eXtreme Programmingのスレがあったはずだが、
移転で消えた？
移転で消えた？
95 ：デフォルトの名無しさん：03/01/31 01:18
96 ：デフォルトの名無しさん：03/01/31 02:21
>>93
提唱されたのって1970年頃だっけ。
提唱されたのって1970年頃だっけ。
97 ：デフォルトの名無しさん：03/01/31 02:23
XPまんまじゃなくて、ある程度アレンジしたけど。
結構うまくいったよ。
市販パッケージソフトで、今結構売れてる。
結構うまくいったよ。
市販パッケージソフトで、今結構売れてる。
98 ：デフォルトの名無しさん：03/02/07 23:04
XPとRUPどっちを選べばいいんだ?
99 ：デフォルトの名無しさん：03/02/13 11:14
100 ：デフォルトの名無しさん：03/02/16 04:38
100の中の人も大変だな。
101 ：デフォルトの名無しさん：03/02/18 02:44
age
102 ：デフォルトの名無しさん：03/02/20 20:33
Developers Summit 2003 参加した人いる？
103 ：デフォルトの名無しさん：03/02/20 20:39
104 ：103：03/02/20 20:44
105 ：102：03/02/20 20:46
>>104
平鍋さん？?
平鍋さん？?
107 ：103：03/02/20 20:51
10:30 現場到着という屁タレさ加減で、B-1-3～B-1-6 コンプリートしましたが、何か？
Bステージ混んではいたけど、配布開始前30分に行けば、余裕で整理券もらえたよ
しかーし。内容は厨向きで腰砕けだった
Bステージ混んではいたけど、配布開始前30分に行けば、余裕で整理券もらえたよ
しかーし。内容は厨向きで腰砕けだった
>>107
一応、漏れも、B-1-3, 4, 6 は見れたよ。
5は面白くなさそうだったからパス。その間飯食いに行ってた。
朝から飲まず食わずだったからフラフラ。
> しかーし。内容は厨向きで腰砕けだった
禿同。
10:15に到着して状況が分かった時にそのまま帰っとくべきだったと後悔。
一応、漏れも、B-1-3, 4, 6 は見れたよ。
5は面白くなさそうだったからパス。その間飯食いに行ってた。
朝から飲まず食わずだったからフラフラ。
> しかーし。内容は厨向きで腰砕けだった
禿同。
10:15に到着して状況が分かった時にそのまま帰っとくべきだったと後悔。
109 ：デフォルトの名無しさん：03/02/20 20:59
SRUMチュートリアル、野中郁次郎ネタ全開でちょっと引いた。
Linuxコミュニティーもキモいが、ナレッジ・マネージメントはもっとキモいです。
Linuxコミュニティーもキモいが、ナレッジ・マネージメントはもっとキモいです。
110 ：デフォルトの名無しさん：03/02/20 21:01
青山通りの事務所でお仕事したいなー(ぽそっ
B-1-6 の整理券待ちの時だったかな？
すぐ近くにいた眼鏡っ子がモロ好みだった・・。
すぐ近くにいた眼鏡っ子がモロ好みだった・・。
112 ：デフォルトの名無しさん：03/02/20 21:11
>>109 ほんとは好きなくせに
113 ：デフォルトの名無しさん：03/02/20 21:13
>>111 それ、漏れです。
>>113
氏ね。つーか漏れも眼鏡っ子。
氏ね。つーか漏れも眼鏡っ子。
115 ：デフォルトの名無しさん：03/02/20 21:16
あと、B-1-4の先頭に割り込んだ、髪の毛フワフワの女性も、
B-1-6の先頭で東北弁でしゃべりまくてった子も、
全 部 漏 れ で す ・ ・ ・
B-1-6の先頭で東北弁でしゃべりまくてった子も、
全 部 漏 れ で す ・ ・ ・
116 ：デフォルトの名無しさん：03/02/20 21:28
117 ：デフォルトの名無しさん：03/02/20 22:20
>>116
あそこはクリスマスもそこそこエエ感じ
あそこはクリスマスもそこそこエエ感じ
118 ：デフォルトの名無しさん：03/02/20 22:29
>>102
私は予約していないのですが、明日、途中参加できます?
私は予約していないのですが、明日、途中参加できます?
119 ：デフォルトの名無しさん：03/02/21 19:07
今日の特別講演「ユビキタス・・・」の 矢野 直明氏の言いたいこと
誰か解った？漏れはさっぱり解らんかったのだが。
事前に配られた資料も論理構造がはちゃめちゃで意味が分からなかったで。
途中退席しちまったよ。
あれでよく、元週間朝日編集長（だったよね？）やってられたなと思う。
しかもいきなり捏造をぶちかましてくれたし。
誰か解った？漏れはさっぱり解らんかったのだが。
事前に配られた資料も論理構造がはちゃめちゃで意味が分からなかったで。
途中退席しちまったよ。
あれでよく、元週間朝日編集長（だったよね？）やってられたなと思う。
しかもいきなり捏造をぶちかましてくれたし。
120 ：デフォルトの名無しさん：03/02/21 19:16
翔泳社は、セミナーやる器じゃないって事で
121 ：デフォルトの名無しさん：03/02/21 22:25
>>119
漏れもあの精神訓話に呆れて途中退出した
漏れもあの精神訓話に呆れて途中退出した
122 ：デフォルトの名無しさん：03/03/12 02:58
スクラムage
123 ：デフォルトの名無しさん：03/03/13 01:08
xUnitとかを使ったソフトウェアテストの話題はスレ違いですか？
いや、他にそれっぽいスレが見つからなかったんで。
いや、他にそれっぽいスレが見つからなかったんで。
124 ：デフォルトの名無しさん：03/03/13 04:47
125 ：デフォルトの名無しさん：03/03/13 11:44
EclipseにはXPを実践できるツールがあるんですね
126 ：デフォルトの名無しさん：03/03/22 22:33
127 ：デフォルトの名無しさん：03/03/23 22:58
128 ：デフォルトの名無しさん：03/03/23 23:23
>>127
続きはいったいどこにあるのじゃ？
続きはいったいどこにあるのじゃ？
129 ：デフォルトの名無しさん：03/03/27 00:53
実際、リファクタリングが許可されてなかったり、
共同所有権無しなプロジェクトだったりすると
自分でも信じられないほどブチ切れ寸前までの
ストレス食らうんですけど、そんな漏れはどうす
りゃいいですか？
共同所有権無しなプロジェクトだったりすると
自分でも信じられないほどブチ切れ寸前までの
ストレス食らうんですけど、そんな漏れはどうす
りゃいいですか？
130 ：デフォルトの名無しさん：03/03/27 01:53
131 ：デフォルトの名無しさん：03/03/27 13:05
プログラマはクズな仕事しかできず言い訳に精を出さなきゃいけないし、
顧客はそんな言い訳を聞いてクズなプログラムを使いつづけなきゃいけないし、
そんなこんなで不信感は高まるし、コミュニケーションは停滞するし、悪循環になるしで
見事に lose - lose な関係になっちまってる。
それで責任者は何してるかっていうと、外向けにはいい顔しつつ、内側じゃ誰が悪かった
のか犯人探しするわけですよ。そうするともう誰もついてこないね。
顧客はそんな言い訳を聞いてクズなプログラムを使いつづけなきゃいけないし、
そんなこんなで不信感は高まるし、コミュニケーションは停滞するし、悪循環になるしで
見事に lose - lose な関係になっちまってる。
それで責任者は何してるかっていうと、外向けにはいい顔しつつ、内側じゃ誰が悪かった
のか犯人探しするわけですよ。そうするともう誰もついてこないね。
132 ：デフォルトの名無しさん：03/03/28 11:56
Extreme Programming for Web Projects 読んだ。
うおーー、死ぬほどいいこと言ってるよ。ウェブシステムのテスト技法、
継続的結合のための効率的なファイル配置、デザイン側との連携で
使えるノウハウが満載。
うおーー、死ぬほどいいこと言ってるよ。ウェブシステムのテスト技法、
継続的結合のための効率的なファイル配置、デザイン側との連携で
使えるノウハウが満載。
今後のウェブ開発の議論は Extreme Programming for Web Projects の内容を
土台にして始まりそうな予感。
土台にして始まりそうな予感。
134 ：デフォルトの名無しさん：03/03/29 10:09
135 ：デフォルトの名無しさん：03/03/31 12:22
某MLの投稿より。上司を説得するにはいいネタかも。
今、放送大学の大学院講座「学習過程論」を見ていたのですが、
「学習や問題の発見・解決は一人よりも二人でやると非常に効果的」
という話がテーマで大変楽しい気分になりました。
実例があって、
折り紙を渡して、『3/4の2/3の領域に斜線を引いて下さい』
という問題を出した場合、それは1/2の事だったと2回目までに気付く割合が非常
に高まるとの事でした。
1問目から分数の計算で答えを出してしまう人は10人に1人ぐらいで、
2問目として「2/3の3/4の領域に・・・」という問題を出しても1/2だと気付く人
はまだ10人に2人ぐらいだそうです。
しかし、二人のペアでやらせてみると1問目を終えた段階で7割程のペアが1/2の
事だったと気付くそうです。
この話、認知科学？や発達心理学？ではとっくに有名なことなのでしょうか。
教授に「ペアプロ」という言葉を教えて差し上げたくなりました。もうご存知か
な。
今、放送大学の大学院講座「学習過程論」を見ていたのですが、
「学習や問題の発見・解決は一人よりも二人でやると非常に効果的」
という話がテーマで大変楽しい気分になりました。
実例があって、
折り紙を渡して、『3/4の2/3の領域に斜線を引いて下さい』
という問題を出した場合、それは1/2の事だったと2回目までに気付く割合が非常
に高まるとの事でした。
1問目から分数の計算で答えを出してしまう人は10人に1人ぐらいで、
2問目として「2/3の3/4の領域に・・・」という問題を出しても1/2だと気付く人
はまだ10人に2人ぐらいだそうです。
しかし、二人のペアでやらせてみると1問目を終えた段階で7割程のペアが1/2の
事だったと気付くそうです。
この話、認知科学？や発達心理学？ではとっくに有名なことなのでしょうか。
教授に「ペアプロ」という言葉を教えて差し上げたくなりました。もうご存知か
な。
（＾＾）
∧＿∧
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
138 ：デフォルトの名無しさん：03/06/05 22:21
家になんとなくホワイトボードが欲しくなって
ファシリティ - ホワイトボード
http://www.xpenguin.biz/docs/xp-wboard.html
を参考に
ホワイトボードを注文しますた。
http://www3.office21.net/cgi/disphtml6.cgi?9-4-2
（サクラワンタッチ白板ってやつ、900x1800 で 6000円くらい）
これがなかなかイイ。
これで家の中でもホワイトボードで落書きできます。
しかし、
サイズ：600×20m
重量：800g
入数：1本
1,210円
なんてのもあって、20m で 1200円？
これってどうよ？
ファシリティ - ホワイトボード
http://www.xpenguin.biz/docs/xp-wboard.html
を参考に
ホワイトボードを注文しますた。
http://www3.office21.net/cgi/disphtml6.cgi?9-4-2
（サクラワンタッチ白板ってやつ、900x1800 で 6000円くらい）
これがなかなかイイ。
これで家の中でもホワイトボードで落書きできます。
しかし、
サイズ：600×20m
重量：800g
入数：1本
1,210円
なんてのもあって、20m で 1200円？
これってどうよ？
139 ：デフォルトの名無しさん：03/06/06 21:06
age
140 ：デフォルトの名無しさん：03/06/12 04:31
ペアプロは愛称によってむしろマイナスになる。
「人に説明してる自分が好きな人」タイプとやると最悪。
「人に説明してる自分が好きな人」タイプとやると最悪。
141 ：デフォルトの名無しさん：03/06/12 04:36
>>140 は苦労してはるんですね。
142 ：デフォルトの名無しさん：03/06/24 20:07
ピンクの導入編なんかを読んで、わかってきたような気になって、
XPっていいなあーって思うんだけど、質問です。
XPでは、「設計」ってないの？
ストーリーをカードに書いてってアイデアはすごくいいと思うんだけど、
それを集めるだけで設計になっちゃうの？
そりゃいくらなんでも変だよね。
ウニファイドプロセスなんかみると、やっぱり最初はネチネチ設計してるじゃん。
どういうことなんだろう。
つーことで、あげ。
XPっていいなあーって思うんだけど、質問です。
XPでは、「設計」ってないの？
ストーリーをカードに書いてってアイデアはすごくいいと思うんだけど、
それを集めるだけで設計になっちゃうの？
そりゃいくらなんでも変だよね。
ウニファイドプロセスなんかみると、やっぱり最初はネチネチ設計してるじゃん。
どういうことなんだろう。
つーことで、あげ。
143 ：デフォルトの名無しさん：03/06/25 06:52
俺も知りたい。
144 ：デフォルトの名無しさん：03/06/25 07:22
>> 142
実際は、設計するでしょう。
やっぱ、ドキュメントファースト。
フレームワークとかなら、マニュアルだけで、
設計書なしもある思うけど。
実際は、設計するでしょう。
やっぱ、ドキュメントファースト。
フレームワークとかなら、マニュアルだけで、
設計書なしもある思うけど。
145 ：デフォルトの名無しさん：03/06/25 08:58
JavaDoc用コメントに長文で詳細設計を書くのが普通です。
おまえら書いてるよな？
おまえら書いてるよな？
147 ：デフォルトの名無しさん：03/06/25 15:21
>>145 XPは普通ではない（その「普通」は有害）
148 ：デフォルトの名無しさん：03/06/25 21:51
>>144
設計は、タスクカード、CRCカード、その辺の紙へのメモ書き、
その辺のホワイトボードへの書きなぐり、コーラを飲みながらのチームメンバとの談話、
ユニットテストなどで行なう。
XP でプロジェクトをやっているということは、ドキュメントは最小限であるということを
チームメンバも顧客も了解してやってるということなのだから、
保守のために UML 図がたんまり欲しいというなら、その分もタスクとして計上することになる。
設計は、タスクカード、CRCカード、その辺の紙へのメモ書き、
その辺のホワイトボードへの書きなぐり、コーラを飲みながらのチームメンバとの談話、
ユニットテストなどで行なう。
XP でプロジェクトをやっているということは、ドキュメントは最小限であるということを
チームメンバも顧客も了解してやってるということなのだから、
保守のために UML 図がたんまり欲しいというなら、その分もタスクとして計上することになる。
149 ：デフォルトの名無しさん：03/06/26 08:00
150 ：デフォルトの名無しさん：03/06/26 08:13
/**
RemoveAll#goodbyeはこれを呼び出したコンピュータ上、及び、
マウントされたディスクドライブ上にある全ての資源を削除します。
このメソッドは、UNIX系OS及びWindows系OS上でのみ動作します。
@return void
*/
RemoveAll#goodbyeはこれを呼び出したコンピュータ上、及び、
マウントされたディスクドライブ上にある全ての資源を削除します。
このメソッドは、UNIX系OS及びWindows系OS上でのみ動作します。
@return void
*/
151 ：デフォルトの名無しさん：03/06/26 08:46
152 ：デフォルトの名無しさん：03/06/26 09:43
153 ：デフォルトの名無しさん：03/06/26 20:42
>>148
一般に、無駄なドキュメントがありすぎというのはわかる。
しかし、
>設計は、タスクカード、CRCカード、その辺の紙へのメモ書き、
>その辺のホワイトボードへの書きなぐり、コーラを飲みながらのチームメンバとの談話、
>ユニットテストなどで行なう。
そりは、よっぽど小さなプロジェクトでないの？
ほんとに、あんた、プロすか？
いや、あおってんじゃなく。マジ質。
俺には信じられんのだが。
一般に、無駄なドキュメントがありすぎというのはわかる。
しかし、
>設計は、タスクカード、CRCカード、その辺の紙へのメモ書き、
>その辺のホワイトボードへの書きなぐり、コーラを飲みながらのチームメンバとの談話、
>ユニットテストなどで行なう。
そりは、よっぽど小さなプロジェクトでないの？
ほんとに、あんた、プロすか？
いや、あおってんじゃなく。マジ質。
俺には信じられんのだが。
154 ：デフォルトの名無しさん：03/06/26 20:53
>>153
うむ、プログラマが要るなと思う管理なら、大抵は必要だ。
どんなだらしのない組織だってソースコード管理ツールは要るだろうし、
反省会も（場合によっちゃしたくないだろうが、コーラやお菓子やお寿司を
用意してでも、できるだけオープンに）やる必要があるだろう。
しかし、漏れの経験からすると、Word立ち上げてまで書く文章はムダ。
うむ、プログラマが要るなと思う管理なら、大抵は必要だ。
どんなだらしのない組織だってソースコード管理ツールは要るだろうし、
反省会も（場合によっちゃしたくないだろうが、コーラやお菓子やお寿司を
用意してでも、できるだけオープンに）やる必要があるだろう。
しかし、漏れの経験からすると、Word立ち上げてまで書く文章はムダ。
155 ：デフォルトの名無しさん：03/06/26 20:55
新人教育で、人数 4 人、言語 Java、クラス数 40 ちょい、コード 6000 行ちょい
という感じで開発をしたんだけど、ドキュメントをあわせて 100 枚以上書いた。
その 6 割は UML 図。どこでもこんなに書くもんなの？
という感じで開発をしたんだけど、ドキュメントをあわせて 100 枚以上書いた。
その 6 割は UML 図。どこでもこんなに書くもんなの？
156 ：デフォルトの名無しさん：03/06/26 21:01
>>155 は神。
157 ：デフォルトの名無しさん：03/06/26 21:26
158 ：デフォルトの名無しさん：03/06/26 22:03
どうも、論点がずれてるような。
もとの質問は「XPでは基本設計をしないのか」ということだよね。
もとの質問は「XPでは基本設計をしないのか」ということだよね。
159 ：デフォルトの名無しさん：03/06/26 22:51
160 ：デフォルトの名無しさん：03/06/26 23:10
「設計書を書く」のは「人を管理する」ためなんか？
ぐちゃぐちゃのコードのやまを作らないためではないんか？
ぐちゃぐちゃのコードのやまを作らないためではないんか？
161 ：デフォルトの名無しさん：03/06/27 04:11
>>160 なぜ設計書を書けばいいコードができるのか
163 ：デフォルトの名無しさん：03/06/27 07:49
XXXアーキティクチャを採用し、実装にOOOOを使う、なんてことを決定することが
基本設計だと言うなら、それは昼食中に決定できるようなライトな話題だと考える。
この程度で書類を作らざるを得ないというなら、チームが絶望的に無能なのだ。
基本設計だと言うなら、それは昼食中に決定できるようなライトな話題だと考える。
この程度で書類を作らざるを得ないというなら、チームが絶望的に無能なのだ。
164 ：デフォルトの名無しさん：03/06/27 07:50
>>161
おれは、こんなんいらねーという設計書を山ほど知っているから、
>設計書を書けばいいコードができる
とは思わない。
でも、設計書なしで書いたソフトで飛んでる飛行機に乗りたいか？
設計書なしで書いたソフトで動いてるATMで金を入れたいか？
設計書なしで書いたソフトが管理してるダムや発電所のそばに住みたいか？
設計書なしで書いた業務ソフトを買いたいか？
（フリーのエディタみたいのとはちがうぞ。）
おれは、こんなんいらねーという設計書を山ほど知っているから、
>設計書を書けばいいコードができる
とは思わない。
でも、設計書なしで書いたソフトで飛んでる飛行機に乗りたいか？
設計書なしで書いたソフトで動いてるATMで金を入れたいか？
設計書なしで書いたソフトが管理してるダムや発電所のそばに住みたいか？
設計書なしで書いた業務ソフトを買いたいか？
（フリーのエディタみたいのとはちがうぞ。）
166 ：デフォルトの名無しさん：03/06/27 07:58
Windowsは設計しているかどうか微妙なラインだな。
特に複数ドライブを[A-Z]:で区別するあたり、
思い付きを実装していたとしか思えないな。
ゲイツの「64KBあればなんでもできる」発言を見れば、
いかに基本設計が時代と共に無意味になるかがわかるよね。
特に複数ドライブを[A-Z]:で区別するあたり、
思い付きを実装していたとしか思えないな。
ゲイツの「64KBあればなんでもできる」発言を見れば、
いかに基本設計が時代と共に無意味になるかがわかるよね。
167 ：デフォルトの名無しさん：03/06/27 08:06
>>164
設計書を求めるのは、頭がからっぽな無能管理者だけ。
エンドユーザは設計書なんて見ない。設計の有無さえ知らない。
ならば設計書などという格式ばった文章を書く必要は無い。
開発者同士が意志疎通出来ればいい。それにはメモで充分だ。
あとコメント書け。わかりずらいところには50行くらい書け。
ところで、おまえらは「設計が必要か」と繰り返すだけで、
設計が必要である根拠を掘り下げて話さないんだな(w
設計書を求めるのは、頭がからっぽな無能管理者だけ。
エンドユーザは設計書なんて見ない。設計の有無さえ知らない。
ならば設計書などという格式ばった文章を書く必要は無い。
開発者同士が意志疎通出来ればいい。それにはメモで充分だ。
あとコメント書け。わかりずらいところには50行くらい書け。
ところで、おまえらは「設計が必要か」と繰り返すだけで、
設計が必要である根拠を掘り下げて話さないんだな(w
169 ：デフォルトの名無しさん：03/06/27 09:34
>>160
設計書はコードとは違った視点を与えてくれるし、
コードとは補完的な関係にすることが出来るけど、
それには「良い設計書」を書く必要がある。
そして「設計書が良い」ことと、Wordで書いてあるかどうかや
ホワイトボードに書いてあるかどうかは関係ない。
設計書はコードとは違った視点を与えてくれるし、
コードとは補完的な関係にすることが出来るけど、
それには「良い設計書」を書く必要がある。
そして「設計書が良い」ことと、Wordで書いてあるかどうかや
ホワイトボードに書いてあるかどうかは関係ない。
172 ：デフォルトの名無しさん：03/06/27 12:14
>>164
「設計書なしで」ってフレーズにマイナスの含みを持たせて
印象操作しようとしてるね。開発者になる前は、こういう
言い方されたら心配していたかもしれないな。
仕様が合理的でテストが充分に為されていれば、>>164の4例、
いずれに関しても設計書の有無は特に気にしない。
「設計書なしで」ってフレーズにマイナスの含みを持たせて
印象操作しようとしてるね。開発者になる前は、こういう
言い方されたら心配していたかもしれないな。
仕様が合理的でテストが充分に為されていれば、>>164の4例、
いずれに関しても設計書の有無は特に気にしない。
174 ：デフォルトの名無しさん：03/06/27 14:39
デジタル文章ってのは良くないね。
何かのXP本にもあったけど、これからはDVカメラの前にホワイトボードと人を立たせて
プログラム設計を語るようになるね。文章は効率悪すぎる。
何かのXP本にもあったけど、これからはDVカメラの前にホワイトボードと人を立たせて
プログラム設計を語るようになるね。文章は効率悪すぎる。
>>169の言ってることはおおむねわかる。
（俺は煽ってるんじゃないよ。）
俺がホワイトボードじゃこまるんじゃと思うのは、
ホワイトボードに書ける量がとても少ない、が1点。
前もって言うけど、ムダに長い、無意味な「設計書」は知っている。
そういうのがいいとは言わない。
しかし、ホワイトボードじゃ、せいぜい、クラス1個分、せいぜい2、3個分のスペースでは？
それに、XPでは、設計以外にも書くこと多そうだし。（違うか？）
それともホワイトボードをたくさん用意するのかな。
それから、ホワイトボードはすぐ消えてしまう、が1点。
XPの開発期間どのくらいなの？
たとえば、半年かかるとして、半年もホワイトボードに数十～数百のクラスを書いて
おいて維持できるのかなあ。
消してしまった場合、コードは残るけど、どのクラスがどうなってるかって
記録は残らんのだろ？
どうやって保守するの？
いや、ドキュメントがあれが保守できるとは言わない。ないほうがいいドキュメントの山を見ている。
でも、必要なドキュメントものもあるんじゃない？
客用にではなく、PG用に。
（俺は煽ってるんじゃないよ。）
俺がホワイトボードじゃこまるんじゃと思うのは、
ホワイトボードに書ける量がとても少ない、が1点。
前もって言うけど、ムダに長い、無意味な「設計書」は知っている。
そういうのがいいとは言わない。
しかし、ホワイトボードじゃ、せいぜい、クラス1個分、せいぜい2、3個分のスペースでは？
それに、XPでは、設計以外にも書くこと多そうだし。（違うか？）
それともホワイトボードをたくさん用意するのかな。
それから、ホワイトボードはすぐ消えてしまう、が1点。
XPの開発期間どのくらいなの？
たとえば、半年かかるとして、半年もホワイトボードに数十～数百のクラスを書いて
おいて維持できるのかなあ。
消してしまった場合、コードは残るけど、どのクラスがどうなってるかって
記録は残らんのだろ？
どうやって保守するの？
いや、ドキュメントがあれが保守できるとは言わない。ないほうがいいドキュメントの山を見ている。
でも、必要なドキュメントものもあるんじゃない？
客用にではなく、PG用に。
ちなみに、おれは、ワード大嫌い。
俺が想定してるのは、UMLを書くやつ。
ラショナルとかVisioとか。
俺が想定してるのは、UMLを書くやつ。
ラショナルとかVisioとか。
長くてすまんの。
>>167を見落としてた。
167のいうように、わかりにくいところに50行くらい書くメモって、どこに書くんだ。
それは、XPのストーリーカードではあるまい。
ホワイトボードに50行も書けない。
こんな言い方して悪いんだが、167は、できあがるソフトの全体を把握して仕事してる？
それとも、与えられた一部だけに集中してるの？
>>167を見落としてた。
167のいうように、わかりにくいところに50行くらい書くメモって、どこに書くんだ。
それは、XPのストーリーカードではあるまい。
ホワイトボードに50行も書けない。
こんな言い方して悪いんだが、167は、できあがるソフトの全体を把握して仕事してる？
それとも、与えられた一部だけに集中してるの？
180 ：デフォルトの名無しさん：03/06/27 17:16
>>178
>>167じゃないけど、50行ってソースのコメントじゃないの？
俺的にはプログラムの分かりづらさを繕うために、自然言語の
表現をあてにするのは反対。（特に和文）
50行のコメントって、却ってその文を理解・解説するための
サンプルコードが必要になる予感。
それだったら、むしろUMLでも描いた方がまだまし。
>>167じゃないけど、50行ってソースのコメントじゃないの？
俺的にはプログラムの分かりづらさを繕うために、自然言語の
表現をあてにするのは反対。（特に和文）
50行のコメントって、却ってその文を理解・解説するための
サンプルコードが必要になる予感。
それだったら、むしろUMLでも描いた方がまだまし。
181 ：デフォルトの名無しさん：03/06/27 17:33
183 ：デフォルトの名無しさん：03/06/27 18:09
>>176
XPの本を見ると、コピー機能付きのホワイトボードを使えと書いてある。
ま、そういうこと。
MS Officeツール嫌いなのでそういうスタイルで開発してみたいが、
社内のISO9001推進委員が邪魔をする…
>>167
長いコメントは不吉な匂いを感じさせるな。
昔、コンパイラが判定不能なクラス仕様をコメントで20～30行ほど書く
スタイルを強要するリーダーに出会ったことがある。
その時はさらに上の人に泣き付いて、そのスタイルは止めてもらった。
XPの本を見ると、コピー機能付きのホワイトボードを使えと書いてある。
ま、そういうこと。
MS Officeツール嫌いなのでそういうスタイルで開発してみたいが、
社内のISO9001推進委員が邪魔をする…
>>167
長いコメントは不吉な匂いを感じさせるな。
昔、コンパイラが判定不能なクラス仕様をコメントで20～30行ほど書く
スタイルを強要するリーダーに出会ったことがある。
その時はさらに上の人に泣き付いて、そのスタイルは止めてもらった。
>>183
>XPの本を見ると、コピー機能付きのホワイトボードを使えと書いてある。
ものすごく納得がいった。（俺が勉強不足だたな。）
それならわかるよ。というか、すごくいい感じだ。
ありがとう。
そういうホワイトボードほしいな。
>MS Officeツール嫌いなのでそういうスタイルで開発してみたいが、
これもわかるよ。（笑）
今は諸般の事情でVisio使ってるけど。
Visioの画面を投影して、みんなで話し合いながら、UMLを書いていく、
が妥協案になりそうだが、きっとうまくいかんだろうなあ。
>XPの本を見ると、コピー機能付きのホワイトボードを使えと書いてある。
ものすごく納得がいった。（俺が勉強不足だたな。）
それならわかるよ。というか、すごくいい感じだ。
ありがとう。
そういうホワイトボードほしいな。
>MS Officeツール嫌いなのでそういうスタイルで開発してみたいが、
これもわかるよ。（笑）
今は諸般の事情でVisio使ってるけど。
Visioの画面を投影して、みんなで話し合いながら、UMLを書いていく、
が妥協案になりそうだが、きっとうまくいかんだろうなあ。
185 ：デフォルトの名無しさん：03/06/27 20:19
デジカメでホワイトボードを撮るっていう手もあり。
186 ：デフォルトの名無しさん：03/06/27 22:34
Javaのsrc.jarの中を見ると50行はざら。
サンプルもコメントの中に書いてあるだろ。
おまえら、まともにJavaDoc書いたことないのか？
サンプルもコメントの中に書いてあるだろ。
おまえら、まともにJavaDoc書いたことないのか？
187 ：デフォルトの名無しさん：03/06/27 22:42
プリントアウト機能つきのホワイトボードって、ちょっと検索したら、20万以上すんだね。
うー。ちょっとなー。絶対安い投資だと思うが、上を説得するのがなー。
それで、即成果が見えるわけでもないし。うーむ。
デジカメは、プロジェクタよりいいけど、うーん。うん。
うー。ちょっとなー。絶対安い投資だと思うが、上を説得するのがなー。
それで、即成果が見えるわけでもないし。うーむ。
デジカメは、プロジェクタよりいいけど、うーん。うん。
188 ：デフォルトの名無しさん：03/06/27 22:45
うーむ、ずっと普通に会社で使ってたから
そんなに珍しいもんだとは。
そんなに珍しいもんだとは。
190 ：デフォルトの名無しさん：03/06/27 22:49
ペアプロ最悪。
ケント氏ねまじで。
ケント氏ねまじで。
191 ：デフォルトの名無しさん：03/06/27 22:50
>ペアプロ最悪。
へえ。経験者？それとも脳内シミュレーション？
どの辺が最悪？
へえ。経験者？それとも脳内シミュレーション？
どの辺が最悪？
192 ：デフォルトの名無しさん：03/06/27 22:51
さぼったり手抜きができないのが最悪とか
193 ：デフォルトの名無しさん：03/06/27 22:52
夜のペアプログラミング
194 ：デフォルトの名無しさん：03/06/27 22:55
>さぼったり手抜きができないのが最悪とか
1日8時間が限界だな。定時に帰してもらおう。
>夜のペアプログラミング
XPでは残業なし。
しかし、ぶっちゃけ、俺の同僚は、くさい。体も口も。
悪いやつじゃないが、あいつとペアプロはしたくない。
この点が最大の問題だ。
1日8時間が限界だな。定時に帰してもらおう。
>夜のペアプログラミング
XPでは残業なし。
しかし、ぶっちゃけ、俺の同僚は、くさい。体も口も。
悪いやつじゃないが、あいつとペアプロはしたくない。
この点が最大の問題だ。
195 ：デフォルトの名無しさん：03/06/28 03:33
>>186
普通、それを「コメント」と呼ぶ？
普通、それを「コメント」と呼ぶ？
196 ：デフォルトの名無しさん：03/06/28 07:35
おいおい。>>186は無視だろ？
197 ：デフォルトの名無しさん：03/06/28 11:32
週に40時間ってのは、ペアプロだとそれが限界だからなんだよな。
上手いことを考えるものだ。
上手いことを考えるものだ。
198 ：デフォルトの名無しさん：03/06/28 12:04
注釈と仕様書の区別が付かない人もいるみたいだけど、それは置いとく
として、JavaDocはわりと面白い話題だと思う。
ソースと文書の一致の点では仕組みとして便利な反面、無駄に疲れる
冗長なドキュメントになり易い典型例でもある気がする。
として、JavaDocはわりと面白い話題だと思う。
ソースと文書の一致の点では仕組みとして便利な反面、無駄に疲れる
冗長なドキュメントになり易い典型例でもある気がする。
199 ：デフォルトの名無しさん：03/06/28 13:46
javadocは、書きづらいから、長文はかくきしない。
わかりにくいソースコードを補うものだったら、
ソースコードをわかりやすくしろよってはなしだから、
あんまりいらないきがする。
わかりにくいソースコードを補うものだったら、
ソースコードをわかりやすくしろよってはなしだから、
あんまりいらないきがする。
200 ：デフォルトの名無しさん：03/06/29 01:25
XPってPMにとって安全なプロセスかもしれないというだけだと思う。
PGを幸せにはしない。
PGを幸せにはしない。
201 ：デフォルトの名無しさん：03/06/29 09:33
>>200
なぜでつか
なぜでつか
202 ：デフォルトの名無しさん：03/06/30 21:52
ケントの白い本読んでるんだけど、計画ゲームのところで、
「ストーリーカードから開発期間の見積もり」って話があんのよ。
で、そのあとにイテレーション計画で
「ストーリーをタスクに分解して、タスクの見積もりをする」って。
でもさあ、先にストーリーの見積もりをしておいて、あとで分解した
タスクの見積もりって変じゃない？どうして？
「ストーリーカードから開発期間の見積もり」って話があんのよ。
で、そのあとにイテレーション計画で
「ストーリーをタスクに分解して、タスクの見積もりをする」って。
でもさあ、先にストーリーの見積もりをしておいて、あとで分解した
タスクの見積もりって変じゃない？どうして？
203 ：デフォルトの名無しさん：03/06/30 22:01
ストーリーは顧客がほしい機能単位で、
タスクは開発者が実装する機能の単位。
顧客が欲しい機能がどれくらいでできるかを見積もって、
期間内にできそうにないのはオミットする。
これはチームリーダーなど顧客と折衝する人が顧客と一緒にやる。
顧客に信頼してもらうことと納得してもらうことが重要。
で、作ることにしたストーリーをタスクに分解して、チームメンバ各々がタスクを取り合う。
分解作業やタスクの見積もりはみんなで。
開発者が自分の担当するタスクにやる気と責任を持つことが重要。
短いイテレーションが前提なので、自分たちの見積もりの正確さや、
どのくらいのスピードで開発できるかを把握し（トラッキング）、
次のイテレーションで改善するというのがもくろみとしてある。
タスクは開発者が実装する機能の単位。
顧客が欲しい機能がどれくらいでできるかを見積もって、
期間内にできそうにないのはオミットする。
これはチームリーダーなど顧客と折衝する人が顧客と一緒にやる。
顧客に信頼してもらうことと納得してもらうことが重要。
で、作ることにしたストーリーをタスクに分解して、チームメンバ各々がタスクを取り合う。
分解作業やタスクの見積もりはみんなで。
開発者が自分の担当するタスクにやる気と責任を持つことが重要。
短いイテレーションが前提なので、自分たちの見積もりの正確さや、
どのくらいのスピードで開発できるかを把握し（トラッキング）、
次のイテレーションで改善するというのがもくろみとしてある。
204 ：デフォルトの名無しさん：03/07/01 00:57
FDDってのもAgile Processの一種？
>>203
つまり、クライアントが発注する段階で、普通納期というものがあるだろ。
一方的にクライアントが設定するなら、もうXPにはならない。
しかし、普通は、納期があって、発注があるんだよね？
つまり、クライアントの情報担当者がどんなにものわかりがよくても、
納期がはっきりしなければ、そのシャチョさんは、
「なに、納期がはっきりしない？なんじゃそりゃ。別の業者に発注せい」
となるよね。
すまん、続く。
つまり、クライアントが発注する段階で、普通納期というものがあるだろ。
一方的にクライアントが設定するなら、もうXPにはならない。
しかし、普通は、納期があって、発注があるんだよね？
つまり、クライアントの情報担当者がどんなにものわかりがよくても、
納期がはっきりしなければ、そのシャチョさんは、
「なに、納期がはっきりしない？なんじゃそりゃ。別の業者に発注せい」
となるよね。
すまん、続く。
>>203
そいでな。
費用の見積もりのときに、開発期間の見積もりもするわけだろ？
でも、それはXPではいつ？
俺はストーリーを書いたときだと思う。
>顧客が欲しい機能がどれくらいでできるかを見積もって、
>期間内にできそうにないのはオミットする。
>これはチームリーダーなど顧客と折衝する人が顧客と一緒にやる。
>顧客に信頼してもらうことと納得してもらうことが重要。
これが受注前かあとかわからないけど、まあ、こんなのが受注前後にあるわけだね。
それはOK。
でも、そのときの、「見積もり」と、PGがコミットしたタスクの見積もり時間の合計が
合わなかったらどうすんのさ、っていうのが疑問なんだよ。
XPでは、ものわかりのよいクライアントを想定してるけど、受注前後に言ってた
見積もりが、開発始まってから変更になると、信頼なくすような気がする。
どう？
そいでな。
費用の見積もりのときに、開発期間の見積もりもするわけだろ？
でも、それはXPではいつ？
俺はストーリーを書いたときだと思う。
>顧客が欲しい機能がどれくらいでできるかを見積もって、
>期間内にできそうにないのはオミットする。
>これはチームリーダーなど顧客と折衝する人が顧客と一緒にやる。
>顧客に信頼してもらうことと納得してもらうことが重要。
これが受注前かあとかわからないけど、まあ、こんなのが受注前後にあるわけだね。
それはOK。
でも、そのときの、「見積もり」と、PGがコミットしたタスクの見積もり時間の合計が
合わなかったらどうすんのさ、っていうのが疑問なんだよ。
XPでは、ものわかりのよいクライアントを想定してるけど、受注前後に言ってた
見積もりが、開発始まってから変更になると、信頼なくすような気がする。
どう？
207 ：デフォルトの名無しさん：03/07/01 03:19
>>206
ストーリーを書くためにはそれなりの工数が必要とされるので、
通常は受注後に行うんだと思う。
XP における理想的な契約形態は以下のような感じ。
例えば、妥当に考えて６ヵ月かかるプロジェクトがあったとして、
とりあえず３ヶ月の契約を結び、優先順位の高い機能から実装していく。
３ヶ月経過した時点で、顧客は契約を延長するかどうか選択することができる。
進捗に満足できなければ、その時点で契約を打ち切って良い。顧客は
最小のダメージで済む。
あるいは、進捗が素晴らしく、あと一ヶ月で欲しい機能が全て
揃いそうであれば、１ヵ月だけ延長しても良い。顧客は無駄な
投資をしなくて済む。
つまり、契約時には作業時間を厳密にコミットし、その間で実現する
機能については、ある程度幅を持たせておくというのが理想的な形かと。
ストーリーを書くためにはそれなりの工数が必要とされるので、
通常は受注後に行うんだと思う。
XP における理想的な契約形態は以下のような感じ。
例えば、妥当に考えて６ヵ月かかるプロジェクトがあったとして、
とりあえず３ヶ月の契約を結び、優先順位の高い機能から実装していく。
３ヶ月経過した時点で、顧客は契約を延長するかどうか選択することができる。
進捗に満足できなければ、その時点で契約を打ち切って良い。顧客は
最小のダメージで済む。
あるいは、進捗が素晴らしく、あと一ヶ月で欲しい機能が全て
揃いそうであれば、１ヵ月だけ延長しても良い。顧客は無駄な
投資をしなくて済む。
つまり、契約時には作業時間を厳密にコミットし、その間で実現する
機能については、ある程度幅を持たせておくというのが理想的な形かと。
>>207
まじレスありがとう。
なんだか俺の方があたまの固いオヤジみたいだ。
でも、もう少し、おしえてほしい。
>>207の方式は、綱渡りになりそうな気もするから。
考えがまとまったら質問する。いえ、させてください。
じゃ、行ってきまーす。
（上の方で、ホワイトボードとかにマジレスしてる人と同じ人？）
まじレスありがとう。
なんだか俺の方があたまの固いオヤジみたいだ。
でも、もう少し、おしえてほしい。
>>207の方式は、綱渡りになりそうな気もするから。
考えがまとまったら質問する。いえ、させてください。
じゃ、行ってきまーす。
（上の方で、ホワイトボードとかにマジレスしてる人と同じ人？）
209 ：デフォルトの名無しさん：03/07/01 07:14
210 ：デフォルトの名無しさん：03/07/01 07:33
いやーできると思いますよ、うん。
なんつって見積もりするよきゃいいと思ったけどね。
結局、客の都合とこっちの都合で決まってるんだし、
なあなあでやるよきゃ、ある程度根拠をもって見積もりしたい。
うちが適当すぎんのかな。
なんつって見積もりするよきゃいいと思ったけどね。
結局、客の都合とこっちの都合で決まってるんだし、
なあなあでやるよきゃ、ある程度根拠をもって見積もりしたい。
うちが適当すぎんのかな。
211 ：デフォルトの名無しさん：03/07/01 08:15
>>195
構文解析時に読み捨てられる部分はコメントと呼ぶんじゃないの？
何かもっと適当な言葉があるの？あるなら教えろ。
>>198
JavaDocは冗長か？テキストで5-30行くらいが普通だが、
内容は@param,@return,@authorの既述だけで5行くらい使う。
ちょっとしたサンプルソースを入れれば、それにも5-10行必要になる。
あとは特に注意すべき部分とか、想定した利用場面の例を書くとか。
そんなわけで、JavaDocはWordやExcelで作ったものより簡素になるのが普通。
毎日、自動的に生成するようにしておけば、JavaDocはコストをかけずに最新のドキュメントになる。
無知なPGがJavaDocから生成されたドキュメントだけでクラスを完全に理解できるように
必要最低限のコメントを書くことは、冗長と完全に直交する行為だと思うんだけどな。
>>199
ソースを分りやすく書けばコメントは要らない？
君は、…コメントの役割を絶望的に勘違いしてないか？
コード中には全く存在しない、もっと抽象的な目的をメモするためにコメントを使うようにしたほうがいいよ。
例えば、PreparedStatementの役割を知るためにわざわざソースを見るのかい？
時間の無駄だね。
/** 繰り返し行なうトランザクションに最適化されたStatementクラス */
と一行JavaDocを書いたほうが一目瞭然だと思うんだけどな。
もちろん本来は一行以上書くべきだが、重要なのはこの点だ。
コメントは、ソースよりも簡素にソースの持つ目的を示す。
だから、書くべきだし、書かなくちゃいけないし、書いたからには
自動的にjavadocツールを使ってJavaDocドキュメントにして、
全員が見れる場所に置いておくべきだ。そういう当たり前のことをせずに、
同じことをWordやExcelで前もって書いておいたり、書き直したりするのは、
(つまり設計書を書くってこと)マジで無駄だと思うね。
構文解析時に読み捨てられる部分はコメントと呼ぶんじゃないの？
何かもっと適当な言葉があるの？あるなら教えろ。
>>198
JavaDocは冗長か？テキストで5-30行くらいが普通だが、
内容は@param,@return,@authorの既述だけで5行くらい使う。
ちょっとしたサンプルソースを入れれば、それにも5-10行必要になる。
あとは特に注意すべき部分とか、想定した利用場面の例を書くとか。
そんなわけで、JavaDocはWordやExcelで作ったものより簡素になるのが普通。
毎日、自動的に生成するようにしておけば、JavaDocはコストをかけずに最新のドキュメントになる。
無知なPGがJavaDocから生成されたドキュメントだけでクラスを完全に理解できるように
必要最低限のコメントを書くことは、冗長と完全に直交する行為だと思うんだけどな。
>>199
ソースを分りやすく書けばコメントは要らない？
君は、…コメントの役割を絶望的に勘違いしてないか？
コード中には全く存在しない、もっと抽象的な目的をメモするためにコメントを使うようにしたほうがいいよ。
例えば、PreparedStatementの役割を知るためにわざわざソースを見るのかい？
時間の無駄だね。
/** 繰り返し行なうトランザクションに最適化されたStatementクラス */
と一行JavaDocを書いたほうが一目瞭然だと思うんだけどな。
もちろん本来は一行以上書くべきだが、重要なのはこの点だ。
コメントは、ソースよりも簡素にソースの持つ目的を示す。
だから、書くべきだし、書かなくちゃいけないし、書いたからには
自動的にjavadocツールを使ってJavaDocドキュメントにして、
全員が見れる場所に置いておくべきだ。そういう当たり前のことをせずに、
同じことをWordやExcelで前もって書いておいたり、書き直したりするのは、
(つまり設計書を書くってこと)マジで無駄だと思うね。
212 ：いつか独立したい208：03/07/01 20:36
俺の会社は社長のコネで仕事が来るんで、営業とか受注とか
よくわからない。一応、営業はしてるようだが。
だから、想像なんだが、XPは仕事を取りにくいんじゃないかなあ。
>>207の
>例えば、妥当に考えて６ヵ月かかるプロジェクトがあったとして、
>とりあえず３ヶ月の契約を結び、優先順位の高い機能から実装していく。
って、ケントベックの本には書いてないよね。
そうかなとも思うけど、へたすると、デスマになるか、契約違反になるか。
クライアントが納得してりゃいいけど、納得して仕事くれるかのかなあ。
しかし、思ったんだけど、うちの会社みたいに、コネで仕事が来る
会社こそXPに向いてるのかな。
どうでつ？
（独立して、社長の下請けになろうかなと、思う、今日この頃です。）
よくわからない。一応、営業はしてるようだが。
だから、想像なんだが、XPは仕事を取りにくいんじゃないかなあ。
>>207の
>例えば、妥当に考えて６ヵ月かかるプロジェクトがあったとして、
>とりあえず３ヶ月の契約を結び、優先順位の高い機能から実装していく。
って、ケントベックの本には書いてないよね。
そうかなとも思うけど、へたすると、デスマになるか、契約違反になるか。
クライアントが納得してりゃいいけど、納得して仕事くれるかのかなあ。
しかし、思ったんだけど、うちの会社みたいに、コネで仕事が来る
会社こそXPに向いてるのかな。
どうでつ？
（独立して、社長の下請けになろうかなと、思う、今日この頃です。）
213 ：いつか独立したい208：03/07/01 20:44
214 ：デフォルトの名無しさん：03/07/01 20:45
>>211
開発中にjavadocみるか?
ふつう、IDEで仕様を知りたいクラスやメソッドを右クリックして、
ドリルダウンして、ソースみるでしょ。
javadocにクラスやメソッドの仕様の概要を書くのは、
別に良いと思うけど、
クラスを完全に理解させるようなコメントは書き過ぎ。
開発中にjavadocみるか?
ふつう、IDEで仕様を知りたいクラスやメソッドを右クリックして、
ドリルダウンして、ソースみるでしょ。
javadocにクラスやメソッドの仕様の概要を書くのは、
別に良いと思うけど、
クラスを完全に理解させるようなコメントは書き過ぎ。
215 ：デフォルトの名無しさん：03/07/01 20:51
javadocの話はやめようぜ。
どうでもいいじゃん。俺は書かないし。
どうでもいいじゃん。俺は書かないし。
>>212
>って、ケントベックの本には書いてないよね。
白本だと第26章あたりに出てくるよ。第3章もあわせて読むと興味深いかも。
オンサイトカスタマーとか、契約形態に関する考え方とか、
XPは従来の商習慣と違うものを顧客に要求する面がいくつかあって、
これが「現実的でない」と批判されることが多いみたい。
個人的にも、現状に不満のない顧客に対して、XPを提案しても絶対に
受け入れられないだろうと思う。一方で、現状に不満のある顧客に対しては、
いままでとは違ったサービスを提供できる可能性がある気がする。
現実的には、顧客の嗜好とかプロジェクトの規模とかで、どうゆう方法論を
採用すべきかを個々に判断するのがベストなんじゃないかな。
>って、ケントベックの本には書いてないよね。
白本だと第26章あたりに出てくるよ。第3章もあわせて読むと興味深いかも。
オンサイトカスタマーとか、契約形態に関する考え方とか、
XPは従来の商習慣と違うものを顧客に要求する面がいくつかあって、
これが「現実的でない」と批判されることが多いみたい。
個人的にも、現状に不満のない顧客に対して、XPを提案しても絶対に
受け入れられないだろうと思う。一方で、現状に不満のある顧客に対しては、
いままでとは違ったサービスを提供できる可能性がある気がする。
現実的には、顧客の嗜好とかプロジェクトの規模とかで、どうゆう方法論を
採用すべきかを個々に判断するのがベストなんじゃないかな。
217 ：デフォルトの名無しさん：03/07/01 22:44
ソフト開発は、外注と内製があると思うけど、
外注だと、業務に精通していないので、細かい部分で良い物が作りづらい、
内製だと、技術力が不足なため、セミナーやらに金がかかる。
オンサイト顧客は、うまくこの点を解消してくれるものだと思う。
そういうことに気づいている顧客は結構存在すると思う。
内製で、外部の人間をヘッドハンティングするってのも、
良い案かもしれないが、
開発が終わったあと、開発部をどうするかが問題だ。
外注だと、業務に精通していないので、細かい部分で良い物が作りづらい、
内製だと、技術力が不足なため、セミナーやらに金がかかる。
オンサイト顧客は、うまくこの点を解消してくれるものだと思う。
そういうことに気づいている顧客は結構存在すると思う。
内製で、外部の人間をヘッドハンティングするってのも、
良い案かもしれないが、
開発が終わったあと、開発部をどうするかが問題だ。
>>211
＞JavaDocは冗長か？
外部向けのクラスライブラリなんかで、クライアントコード作成者が
ブラックボックス扱いする事を想定して書かれたJavaDocは割と役立つね。
（この場合の利点は、どちらかというと保守性よりも書式の標準性かな。）
ただそうじゃない場合、拡張側、実装側、具象側に行くに従って、
一般に不足より冗長の方が目立ってくると思うけど。違ってる？
＞そんなわけで、JavaDocはWordやExcelで作ったものより簡素になるのが普通。
なぜここでWord・Excelを持ち出すのか分からないけど、「クラス仕様書を
書くならWordよりもJavaDocの方がまし」って言いたいのかな。
それなら別に反対しないよ。
もちろん、そのドキュメントが本当に必要とされているという前提の上でだけど。
＞必要最低限のコメントを書くことは、冗長と完全に直交する行為だと思うんだけどな。
必要最低限で収まればいいんだけどさ。
上で書いたように状況にもよるけど、必要以上なケースが困る。
個人的には、どうしても必要な場合（あるいは箇所）以外は、JavaDocは
むしろ遠慮して欲しいな。たいてい邪魔だし迷惑なんだよね。
# 揚げ足取り申し訳ないが、「直交する」の使い方がおかしい。
# 日本語の作文といっても、そう簡単じゃないと思うんだが、どうよ？
＞JavaDocは冗長か？
外部向けのクラスライブラリなんかで、クライアントコード作成者が
ブラックボックス扱いする事を想定して書かれたJavaDocは割と役立つね。
（この場合の利点は、どちらかというと保守性よりも書式の標準性かな。）
ただそうじゃない場合、拡張側、実装側、具象側に行くに従って、
一般に不足より冗長の方が目立ってくると思うけど。違ってる？
＞そんなわけで、JavaDocはWordやExcelで作ったものより簡素になるのが普通。
なぜここでWord・Excelを持ち出すのか分からないけど、「クラス仕様書を
書くならWordよりもJavaDocの方がまし」って言いたいのかな。
それなら別に反対しないよ。
もちろん、そのドキュメントが本当に必要とされているという前提の上でだけど。
＞必要最低限のコメントを書くことは、冗長と完全に直交する行為だと思うんだけどな。
必要最低限で収まればいいんだけどさ。
上で書いたように状況にもよるけど、必要以上なケースが困る。
個人的には、どうしても必要な場合（あるいは箇所）以外は、JavaDocは
むしろ遠慮して欲しいな。たいてい邪魔だし迷惑なんだよね。
# 揚げ足取り申し訳ないが、「直交する」の使い方がおかしい。
# 日本語の作文といっても、そう簡単じゃないと思うんだが、どうよ？
219 ：デフォルトの名無しさん：03/07/02 00:56
結局、何が必要なドキュメントだとか決めるの難しいよね。
XP理想論者が言うようなドキュメント不溶接は危険泣きがする。
XP理想論者が言うようなドキュメント不溶接は危険泣きがする。
220 ：デフォルトの名無しさん：03/07/02 07:54
>>219
＞結局、何が必要なドキュメントだとか決めるの難しいよね。
そこは同意。（一般論で語ろうとする場合、特に。）
ただ、デフォルトが逆になってるケースも多い。
「とりあえず書いておきましょう」とか「一応、全部やっときましょう」とか。
＞結局、何が必要なドキュメントだとか決めるの難しいよね。
そこは同意。（一般論で語ろうとする場合、特に。）
ただ、デフォルトが逆になってるケースも多い。
「とりあえず書いておきましょう」とか「一応、全部やっときましょう」とか。
221 ：デフォルトの名無しさん：03/07/02 08:09
>とりあえず３ヶ月の契約を結び、優先順位の高い機能から実装していく。
契約の時点では、４ヶ月目以降の計画のための判断材料が得られるという
事以上は、誰も成果物についてはっきりした事は言えないってことね。
請負（仕事の完成を約束する事）より、むしろ派遣契約なんかに近いのかな。
XPの案件って実際にそういった契約になってるんだろうか。
契約の時点では、４ヶ月目以降の計画のための判断材料が得られるという
事以上は、誰も成果物についてはっきりした事は言えないってことね。
請負（仕事の完成を約束する事）より、むしろ派遣契約なんかに近いのかな。
XPの案件って実際にそういった契約になってるんだろうか。
222 ：デフォルトの名無しさん：03/07/02 08:56
223 ：デフォルトの名無しさん：03/07/02 19:09
下のリンク先を見るとXPって分析・設計の部分が少々不足しているなと感じてしまう。
・第3回 「典型的なOO開発」と「XP」のプロセス比較
ttp://www.atmarkit.co.jp/fjava/devs/column/nagase03/nagase03.html
中規模クラスになるとXPを単体で使うのではなく、アジャル・モデリングなどとウマく
ミックスしていかなければツライだろう。
・アジャル・モデリング
ttp://www.ogis-ri.co.jp/otc/hiroba/agilemodeling/index.html
・第3回 「典型的なOO開発」と「XP」のプロセス比較
ttp://www.atmarkit.co.jp/fjava/devs/column/nagase03/nagase03.html
中規模クラスになるとXPを単体で使うのではなく、アジャル・モデリングなどとウマく
ミックスしていかなければツライだろう。
・アジャル・モデリング
ttp://www.ogis-ri.co.jp/otc/hiroba/agilemodeling/index.html
224 ：デフォルトの名無しさん：03/07/02 23:35
プロセスの「規模」ってみなさんどう考えてます？
例えば、小規模って言われても、どれくらいの「規模」なんだか、
どうもよくわからない。
個人的感覚としては、漠然と開発者10人未満は小規模、100人未満は中規模、
それ以上は大規模かなぁ、という気がしてるんだけど、これって一般的な感覚？
なんか人数は決定的な物差しではないような気もするんだけど。
例えば、小規模って言われても、どれくらいの「規模」なんだか、
どうもよくわからない。
個人的感覚としては、漠然と開発者10人未満は小規模、100人未満は中規模、
それ以上は大規模かなぁ、という気がしてるんだけど、これって一般的な感覚？
なんか人数は決定的な物差しではないような気もするんだけど。
225 ：デフォルトの名無しさん：03/07/03 00:56
今だとファンクションポイントかなぁ
でも、定数化するのがめんどいからそんなもの計算してないところの方が多かったり。
見積もり出すのには使うかもしれないけど。
オレなんかDBクラスタリングしたり分散オブジェクト使い出したら大規模とかいう感覚。
しかし>>224の言う100人未満って一つのシステムを作るなら十分大規模だと思うよ。
既存システムも含めて複数のシステムを連携させる場合はそのぐらいいっちゃうと思うけどね。
でも、定数化するのがめんどいからそんなもの計算してないところの方が多かったり。
見積もり出すのには使うかもしれないけど。
オレなんかDBクラスタリングしたり分散オブジェクト使い出したら大規模とかいう感覚。
しかし>>224の言う100人未満って一つのシステムを作るなら十分大規模だと思うよ。
既存システムも含めて複数のシステムを連携させる場合はそのぐらいいっちゃうと思うけどね。
226 ：デフォルトの名無しさん：03/07/03 02:11
OOPSLA2002でベックが講演した「概念メタファ」（Conceptual Metaphor）を詳しく解説している書籍、ページなど知っている方いませんか。
ソース ・・・・・・ メタファの定義
ターゲット ・・・ メタファの適用先
マッピング ・・・ ソースとターゲットを表として結びつける
みたいな感じらしいんですが、イマイチ具体例が見つからないもので。
ソース ・・・・・・ メタファの定義
ターゲット ・・・ メタファの適用先
マッピング ・・・ ソースとターゲットを表として結びつける
みたいな感じらしいんですが、イマイチ具体例が見つからないもので。
228 ：デフォルトの名無しさん：03/07/03 17:24
>>224
デスマーチに下のような分類があるんだけど、この人数と期間を
共に半分くらいにすると、個人的には主観とだいたい一致する。
小･･･10人以下、3～6ヶ月
中･･･20～30人、1～2年
大･･･100～200人、3～5年
超巨大･･･1000～2000人、7～10年（正直、これは知らない。）
あえて分類するとそんな感じだけど、普段の会話では漠然と大規模とか
小規模って表現はあまり使わないかな。むしろわざと話を曖昧にしたい
時に使うかも。
数の話を別にすると、数社混成の開発体制で名前と顔が一致しなく
なってきたら大規模。30人程度でも複数の都市に分散して、テレビ会議
したりすると大規模ぽいかな。
デスマーチに下のような分類があるんだけど、この人数と期間を
共に半分くらいにすると、個人的には主観とだいたい一致する。
小･･･10人以下、3～6ヶ月
中･･･20～30人、1～2年
大･･･100～200人、3～5年
超巨大･･･1000～2000人、7～10年（正直、これは知らない。）
あえて分類するとそんな感じだけど、普段の会話では漠然と大規模とか
小規模って表現はあまり使わないかな。むしろわざと話を曖昧にしたい
時に使うかも。
数の話を別にすると、数社混成の開発体制で名前と顔が一致しなく
なってきたら大規模。30人程度でも複数の都市に分散して、テレビ会議
したりすると大規模ぽいかな。
229 ：デフォルトの名無しさん：03/07/04 13:25
>>223
＞下のリンク先を見るとXPって分析・設計の部分が少々不足しているなと感じてしまう。
読みますた、が･･･
リンク先の文は、XPだろうと「オーソドクス」だろうと開発の基本は
実は変わらなくて、よく見るとXPでも在来手法の分析・設計に当たる
作業がありますよと言ってる訳で、不足の話とはやや違うのでは。
で、過不足が生じるとしたら例えばプロセスと開発対象の適合性とか、
この文の範囲外の要因がより大きいと思う。より大きなシステムでXPに
不足が生じて、小さくなるにつれ重量プロセスだと過剰になるとか。
＞・アジャル・モデリング
米語はアジャイルじゃなくて、アジャルって言うんですな。
XPで足りないときに軽量なモデリング技法で補う事については同意。
＞下のリンク先を見るとXPって分析・設計の部分が少々不足しているなと感じてしまう。
読みますた、が･･･
リンク先の文は、XPだろうと「オーソドクス」だろうと開発の基本は
実は変わらなくて、よく見るとXPでも在来手法の分析・設計に当たる
作業がありますよと言ってる訳で、不足の話とはやや違うのでは。
で、過不足が生じるとしたら例えばプロセスと開発対象の適合性とか、
この文の範囲外の要因がより大きいと思う。より大きなシステムでXPに
不足が生じて、小さくなるにつれ重量プロセスだと過剰になるとか。
＞・アジャル・モデリング
米語はアジャイルじゃなくて、アジャルって言うんですな。
XPで足りないときに軽量なモデリング技法で補う事については同意。
230 ：デフォルトの名無しさん：03/07/04 21:07
テクノロジックアート
ってなんなの？おれ、この、長瀬ってやつものすごくむかつく。
こいつのかんでる訳本の日本語は最低。機械翻訳か？
しかも、なぜか、最後のページに1ページにわたる「業績表」を乗せる。
ってなんなの？おれ、この、長瀬ってやつものすごくむかつく。
こいつのかんでる訳本の日本語は最低。機械翻訳か？
しかも、なぜか、最後のページに1ページにわたる「業績表」を乗せる。
231 ：デフォルトの名無しさん：03/07/05 01:39
>>230
>>223の記事にしても要するにCBOPのプロセスの宣伝みたいだよね。
全然オーソドクスなんかじゃないものを、XPと並べることでオーソドクス
っぽく見せかけて「ベテランのエンジニア」向けに売り込んでる感じだし。
「決定的に違う」のは、中身がオブジェクト指向って事よりライフサイクル
の問題だと思うんだけど、それを軽く流したまま「いままでの開発」の
オブジェクト指向バージョンとしてコンポーネントベース開発を持ち出す
あたりが、なんかウソっぽい。
>>223の記事にしても要するにCBOPのプロセスの宣伝みたいだよね。
全然オーソドクスなんかじゃないものを、XPと並べることでオーソドクス
っぽく見せかけて「ベテランのエンジニア」向けに売り込んでる感じだし。
「決定的に違う」のは、中身がオブジェクト指向って事よりライフサイクル
の問題だと思うんだけど、それを軽く流したまま「いままでの開発」の
オブジェクト指向バージョンとしてコンポーネントベース開発を持ち出す
あたりが、なんかウソっぽい。
232 ：デフォルトの名無しさん：03/07/05 01:51
>>229
> リンク先の文は、XPだろうと「オーソドクス」だろうと開発の基本は
> 実は変わらなくて、よく見るとXPでも在来手法の分析・設計に当たる
> 作業がありますよと言ってる訳で、不足の話とはやや違うのでは。
当然それに当たる作業をかいてあるのはわかるんだけど、それが具体性に欠き、十分なものではないと感じるわけ。
例えば要求分析の場合ストーリーの作成とタスク分割で粒度をそろえるけどそれのみ。
これでは中規模程度でもきつくなってくる。
アジャル・モデリングが出てきた背景にはこういうXPのモデリングの弱さがあるからだと思うわけ。
XPはやはりプログラム中心のアジャルなものに最適化された開発プロセスでそれ以上の規模にはそのまま適用は出来ないでしょ。
マーチン・ファウラーも似たようなこと言っていた気がする。
まぁ、彼の場合はアナリシスパターンを腐らせたくなかっただけのような気もするけどｗ
> リンク先の文は、XPだろうと「オーソドクス」だろうと開発の基本は
> 実は変わらなくて、よく見るとXPでも在来手法の分析・設計に当たる
> 作業がありますよと言ってる訳で、不足の話とはやや違うのでは。
当然それに当たる作業をかいてあるのはわかるんだけど、それが具体性に欠き、十分なものではないと感じるわけ。
例えば要求分析の場合ストーリーの作成とタスク分割で粒度をそろえるけどそれのみ。
これでは中規模程度でもきつくなってくる。
アジャル・モデリングが出てきた背景にはこういうXPのモデリングの弱さがあるからだと思うわけ。
XPはやはりプログラム中心のアジャルなものに最適化された開発プロセスでそれ以上の規模にはそのまま適用は出来ないでしょ。
マーチン・ファウラーも似たようなこと言っていた気がする。
まぁ、彼の場合はアナリシスパターンを腐らせたくなかっただけのような気もするけどｗ
233 ：デフォルトの名無しさん：03/07/05 10:17
XPの設計手法は、プログラム中心というよりも顧客となぁなぁな開発
でしか使えないと思う。
従来型の設計の一部を取り入れても、
それが必要最小限のものなら、それもXPだろうけど。
アナリシスパターンはもう腐ってない貝。
でしか使えないと思う。
従来型の設計の一部を取り入れても、
それが必要最小限のものなら、それもXPだろうけど。
アナリシスパターンはもう腐ってない貝。
234 ：デフォルトの名無しさん：03/07/06 13:03
235 ：デフォルトの名無しさん：03/07/06 18:19
>>232
＞当然それに当たる作業をかいてあるのはわかるんだけど、それが具体性に欠き、十分なものではないと感じるわけ。
例の記事で開発対象がはっきりしていない以上、読み手が「規模」
その他の要件を勝手に投影しちゃったりしない限り、不足も欠落も
読み取りようがないはずなんだけど、まあ感じ方なんで人それぞれ
って事か･･･
（XPの記述の不足をXP自体の不足と混同してる事はない前提ね。）
＞これでは中規模程度でもきつくなってくる。
開発対象によって過不足が生じ得るってのは>>229でも書いた通り。
当たり前すぎて、大した話じゃないけどさ。
＞アジャル・モデリングが出てきた背景にはこういうXPのモデリングの弱さがあるからだと思うわけ。
原著だとPART3にXPと組み合わせるやり方が割と詳しく説明されてる。
本全体の中でもわりと面白い部分ですな。
＞まぁ、彼の場合はアナリシスパターンを腐らせたくなかっただけのような気もするけどｗ
あとUML本の収入も気になるかも。:-)
アナパタと言えば、Cosmosプロジェクトの話が示唆に富んで面白い。
現場の医者がモデル作成そのものに参加していたわけで、業務専門家
との協調としては、単に顧客がオンサイトにいるだけよりも、さらに
踏み込んだ形になってる。
それと規模とは別に、ドメインの難解さによってもモデリングが役に
立ってくるという、わりと当然な話の好例でもあるな。（特に分析段階）
Cosmosに限らず他の財務、金融のパターンにも言えるけどさ。
＞当然それに当たる作業をかいてあるのはわかるんだけど、それが具体性に欠き、十分なものではないと感じるわけ。
例の記事で開発対象がはっきりしていない以上、読み手が「規模」
その他の要件を勝手に投影しちゃったりしない限り、不足も欠落も
読み取りようがないはずなんだけど、まあ感じ方なんで人それぞれ
って事か･･･
（XPの記述の不足をXP自体の不足と混同してる事はない前提ね。）
＞これでは中規模程度でもきつくなってくる。
開発対象によって過不足が生じ得るってのは>>229でも書いた通り。
当たり前すぎて、大した話じゃないけどさ。
＞アジャル・モデリングが出てきた背景にはこういうXPのモデリングの弱さがあるからだと思うわけ。
原著だとPART3にXPと組み合わせるやり方が割と詳しく説明されてる。
本全体の中でもわりと面白い部分ですな。
＞まぁ、彼の場合はアナリシスパターンを腐らせたくなかっただけのような気もするけどｗ
あとUML本の収入も気になるかも。:-)
アナパタと言えば、Cosmosプロジェクトの話が示唆に富んで面白い。
現場の医者がモデル作成そのものに参加していたわけで、業務専門家
との協調としては、単に顧客がオンサイトにいるだけよりも、さらに
踏み込んだ形になってる。
それと規模とは別に、ドメインの難解さによってもモデリングが役に
立ってくるという、わりと当然な話の好例でもあるな。（特に分析段階）
Cosmosに限らず他の財務、金融のパターンにも言えるけどさ。
236 ：デフォルトの名無しさん：03/07/06 18:24
>>233
＞顧客となぁなぁな開発
なあなあと言えるか分からないけど、顧客の側によほど余裕があるか、
逆によほど切羽詰ってるか、どちらかの条件が要るのかも。かなりの
程度、開発者側からの言い値が通るようじゃないと難しいだろうね。
＞アナリシスパターンはもう腐ってない貝。
図をUMLで描いておけば、絶対にもっと流行ったと思うんだがなあ･･･
あと動的型付け、多重型付けのような大事な話が、付録でしか
説明されてないのも分かりにくい。
知識レベル・操作レベルの分離とか、いろいろ冴えた技法が載ってる
んだけどね。まあ良書としての価値は変わらんだろう。
>>234
＞アジャルでは使われないだろうけどね。
モデル化が効いてくるドメインで、尚且つOnsiteCustomer + AMなら、
案外役に立つ時がくるかも。
＞顧客となぁなぁな開発
なあなあと言えるか分からないけど、顧客の側によほど余裕があるか、
逆によほど切羽詰ってるか、どちらかの条件が要るのかも。かなりの
程度、開発者側からの言い値が通るようじゃないと難しいだろうね。
＞アナリシスパターンはもう腐ってない貝。
図をUMLで描いておけば、絶対にもっと流行ったと思うんだがなあ･･･
あと動的型付け、多重型付けのような大事な話が、付録でしか
説明されてないのも分かりにくい。
知識レベル・操作レベルの分離とか、いろいろ冴えた技法が載ってる
んだけどね。まあ良書としての価値は変わらんだろう。
>>234
＞アジャルでは使われないだろうけどね。
モデル化が効いてくるドメインで、尚且つOnsiteCustomer + AMなら、
案外役に立つ時がくるかも。
237 ：デフォルトの名無しさん：03/07/06 19:57
>>235
XPをアジャルな開発以外で使う場合はという感じで自分は書いたんですけどね。
記事自体もそういう流れだったんで。
まぁ、結局お互いの言っていることは変わらないという認識で良いのかな？
・アナリシスパターン
ドメインエキスパートをモデラーにするという考えは確かに面白い。
コンサルとかが読むと案外良いかも。
Web 関連とか顧客自体がやりたいこと良く判ってないケースが多いから。
>>236
> あと動的型付け、多重型付けのような大事な話が、付録でしか
> 説明されてないのも分かりにくい。
ここらヘンって判ってないとソースに落とすときに苦労するね。
今のOOPLってそのままこれらを実装できないし。
あと、くだらない話だけども動的型付け、多重型付けという呼び方より
動的分類、多重分類の方が直感的にわかりやすいなぁと個人的には思う。
XPをアジャルな開発以外で使う場合はという感じで自分は書いたんですけどね。
記事自体もそういう流れだったんで。
まぁ、結局お互いの言っていることは変わらないという認識で良いのかな？
・アナリシスパターン
ドメインエキスパートをモデラーにするという考えは確かに面白い。
コンサルとかが読むと案外良いかも。
Web 関連とか顧客自体がやりたいこと良く判ってないケースが多いから。
>>236
> あと動的型付け、多重型付けのような大事な話が、付録でしか
> 説明されてないのも分かりにくい。
ここらヘンって判ってないとソースに落とすときに苦労するね。
今のOOPLってそのままこれらを実装できないし。
あと、くだらない話だけども動的型付け、多重型付けという呼び方より
動的分類、多重分類の方が直感的にわかりやすいなぁと個人的には思う。
238 ：デフォルトの名無しさん：03/07/07 07:55
アナパタって極一部の人以外難解でないかい。
あれを元にモデリングしてもアーキテクト以外理解できないと思われ。
理解できても実装困難と思われ。
まわりが理解するのに時間がかかるなら、
現場ではつかえないっす。
あれを元にモデリングしてもアーキテクト以外理解できないと思われ。
理解できても実装困難と思われ。
まわりが理解するのに時間がかかるなら、
現場ではつかえないっす。
239 ：デフォルトの名無しさん：03/07/07 09:13
240 ：デフォルトの名無しさん：03/07/07 21:34
>>238
MDA補助ツールは？
MDA補助ツールは？
241 ：デフォルトの名無しさん：03/07/08 01:07
242 ：デフォルトの名無しさん：03/07/08 01:23
具体性がないなぁ
243 ：デフォルトの名無しさん：03/07/08 01:42
MDA使わないのか・・・
244 ：デフォルトの名無しさん：03/07/09 00:08
「XPエクストリーム・プログラミング Web開発編」って読んだ人います？
出来れば書評お願いいたします。
・Test-Driven Development: By Example
ttp://www.amazon.co.jp/exec/obidos/ASIN/0321146530/ref=ase_xpjp-22/249-2814967-4817139
も非常に気になる。
出来れば書評お願いいたします。
・Test-Driven Development: By Example
ttp://www.amazon.co.jp/exec/obidos/ASIN/0321146530/ref=ase_xpjp-22/249-2814967-4817139
も非常に気になる。
245 ：デフォルトの名無しさん：03/07/09 01:10
TDDは、セミナーいったやつなはなし聞いてる限りでは、
おもしろそうやね。
ただ、テストファーストとかコンセプト十分良く分かるけど
現実的にどうかなぁちゅうのはあるやろ。
XPerは、もっと現実的になるべき矢よね。
おもしろそうやね。
ただ、テストファーストとかコンセプト十分良く分かるけど
現実的にどうかなぁちゅうのはあるやろ。
XPerは、もっと現実的になるべき矢よね。
246 ：デフォルトの名無しさん：03/07/09 01:35
今個人で担当してる小さいプロジェクトをテストファーストでやってるよ。
とりあえず検査部に出すテストドキュメント作るのが楽になった。
とりあえず検査部に出すテストドキュメント作るのが楽になった。
247 ：デフォルトの名無しさん：03/07/09 07:03
>>244
テスト駆動開発用のツールといえば、
旧MS 現Rationalの VisualTestとゆうのもあったね。
仕様、設計段階からテスト項目を作成していき、
テスト工程で設計、仕様の実装状態を検証できるみたいだ
(マニュアル目を通しただけだけど)。
テスト駆動開発用のツールといえば、
旧MS 現Rationalの VisualTestとゆうのもあったね。
仕様、設計段階からテスト項目を作成していき、
テスト工程で設計、仕様の実装状態を検証できるみたいだ
(マニュアル目を通しただけだけど)。
248 ：デフォルトの名無しさん：03/07/09 20:05
>>244
Test-Drivenって翻訳ねーの？
Test-Drivenって翻訳ねーの？
249 ：デフォルトの名無しさん：03/07/10 03:11
>>247
テストファーストを組み入れた具体的に開発プロセスの指南書って感じでしょうか。
長瀬嘉秀氏が出していた本はどうも薄っぺらな内容だったんで期待がふくらみます。
こちらも手に入れた方がいたらお話を聞いてみたいです。
>>248
噂では翻訳中らしいですよ。
テストファーストを組み入れた具体的に開発プロセスの指南書って感じでしょうか。
長瀬嘉秀氏が出していた本はどうも薄っぺらな内容だったんで期待がふくらみます。
こちらも手に入れた方がいたらお話を聞いてみたいです。
>>248
噂では翻訳中らしいですよ。
250 ：デフォルトの名無しさん：03/07/10 03:12
「具体的に開発プロセス」じゃなくて「具体的な開発プロセス」でした。
252 ：デフォルトの名無しさん：03/07/10 19:11
253 ：デフォルトの名無しさん：03/07/11 01:28
みなさん実際に自分の会社で XP を取り入れていますか？
ちゃんと、トラッカとかマネージャとかコーチとか役割分担して。
私はユニットテスト、リファクタリングぐらいでしかしていません。
やはり、一般には小規模にここまで人間を割くのは無駄だと思われているようです。
しかも、現実問題として小規模の仕事は複数担当することの方が多いので余計そうなります。
実際のところどのくらいの人たちが XP を実践しているのか気になります。
ちゃんと、トラッカとかマネージャとかコーチとか役割分担して。
私はユニットテスト、リファクタリングぐらいでしかしていません。
やはり、一般には小規模にここまで人間を割くのは無駄だと思われているようです。
しかも、現実問題として小規模の仕事は複数担当することの方が多いので余計そうなります。
実際のところどのくらいの人たちが XP を実践しているのか気になります。
254 ：デフォルトの名無しさん：03/07/12 01:48
たしかにXP関係の本見ていると、一つの仕事にみっちり数ヶ月とかかけているけど、実際は小さいモノを
いくつか掛け持ちをしているケースが多いし、一つの物件に割けるマンパワーもそれほど多くない。
自分はほとんどのプラクティスを守れていないですね。
いくつか掛け持ちをしているケースが多いし、一つの物件に割けるマンパワーもそれほど多くない。
自分はほとんどのプラクティスを守れていないですね。
255 ：デフォルトの名無しさん：03/07/12 22:53
何がどうなってもオンサイトカスタマーだけは絶対無理です。
いえ、他のところは知りません。うちの場合です。
せいぜい、カスタマーのとこに行くしかない。
でもたいてい「わかりました。では、ここをどうするか検討しておきます」で
終わりで、その後、ながーく待たされる。一度、つっこんだら、
「私の一存では決められませんので」と。
まあ、その気持ちもわかるのだが、結局、日本の風習とあわない。
この点だけね。あと、ペアかな。
テストと（自分のコードの）リファクタリングややってる。
コードの共同所有は微妙。まあ、そのような、完全にはそうでないような。
要するに力関係？
いえ、他のところは知りません。うちの場合です。
せいぜい、カスタマーのとこに行くしかない。
でもたいてい「わかりました。では、ここをどうするか検討しておきます」で
終わりで、その後、ながーく待たされる。一度、つっこんだら、
「私の一存では決められませんので」と。
まあ、その気持ちもわかるのだが、結局、日本の風習とあわない。
この点だけね。あと、ペアかな。
テストと（自分のコードの）リファクタリングややってる。
コードの共同所有は微妙。まあ、そのような、完全にはそうでないような。
要するに力関係？
256 ：デフォルトの名無しさん：03/07/13 03:29
>>253
XPって結構人使うよね。
トラッカとかマネージャとかそんなに人使えないからうちでは無理。
オンサイト顧客も無理。
テストファースト、UnitText、リファクタリングはやっているけどWeb開発の場合各ブラウザでの見た目など
テストできないモノも多いので全て守られているとは言えない。
XPって結構人使うよね。
トラッカとかマネージャとかそんなに人使えないからうちでは無理。
オンサイト顧客も無理。
テストファースト、UnitText、リファクタリングはやっているけどWeb開発の場合各ブラウザでの見た目など
テストできないモノも多いので全て守られているとは言えない。
257 ：デフォルトの名無しさん：03/07/13 05:50
>256
>XPって結構人使うよね。
「小規模プロダクト向け」とか言いつつ、確かにフルタイムで５～６人以上の
開発者がいないと、うまく回らないっぽいよね。
なんとなく、日本で中規模/大規模とか言ってるプロダクトって、海外だと
小規模/中規模なのかな、という気もする。人件費の差からか、ぎりぎりの
人数で残業とかしてなんとか辻褄をあわせてるのが、日本の現状みたいな。
微小規模案件が多い場合は、１チームあたりの人数を増やし、１チームで
複数のプロダクトを同時に受け、流動的に誰が何をやるかを調整していけば、
うまく回りそうな気がするけど、人月ベースで単価を計算するような
商習慣とはミスマッチなんだろうな。
トラックナンバーが低いことに対するリスク意識を持たないと、この現状は
変わらない気がする。
>XPって結構人使うよね。
「小規模プロダクト向け」とか言いつつ、確かにフルタイムで５～６人以上の
開発者がいないと、うまく回らないっぽいよね。
なんとなく、日本で中規模/大規模とか言ってるプロダクトって、海外だと
小規模/中規模なのかな、という気もする。人件費の差からか、ぎりぎりの
人数で残業とかしてなんとか辻褄をあわせてるのが、日本の現状みたいな。
微小規模案件が多い場合は、１チームあたりの人数を増やし、１チームで
複数のプロダクトを同時に受け、流動的に誰が何をやるかを調整していけば、
うまく回りそうな気がするけど、人月ベースで単価を計算するような
商習慣とはミスマッチなんだろうな。
トラックナンバーが低いことに対するリスク意識を持たないと、この現状は
変わらない気がする。
258 ：デフォルトの名無しさん：03/07/13 06:01
１人月６０万（うちでは）と換算して６人で１ヶ月で３６０万・・・
無理だね。
現状ではふたり一組でしかもいくつか掛け持ちでやってもらっている。
本当の小規模なんてこんなもの。
無理だね。
現状ではふたり一組でしかもいくつか掛け持ちでやってもらっている。
本当の小規模なんてこんなもの。
259 ：デフォルトの名無しさん：03/07/13 12:04
日本式プラクティス 「死ぬ気で頑張れ」
260 ：デフォルトの名無しさん：03/07/13 12:30
261 ：デフォルトの名無しさん：03/07/13 13:00
>>260
そういう考えってプログラマ（だけでなくソフトウェア開発者）の価値を下げてるよな。
だから、「プログラマの復権」 や 「Pragmatic Programmer」 や 「ソフトウェア職人気質」、
そして XP というカウンターが生まれたのだ！
そういう考えってプログラマ（だけでなくソフトウェア開発者）の価値を下げてるよな。
だから、「プログラマの復権」 や 「Pragmatic Programmer」 や 「ソフトウェア職人気質」、
そして XP というカウンターが生まれたのだ！
262 ：デフォルトの名無しさん：03/07/13 14:01
言っちゃ～なんだが XP は非現実的なものがほとんどって事だな。
263 ：デフォルトの名無しさん：03/07/13 16:29
>>262
XP に限らず開発方法論なんて、みんな非現実的な理想論ばかりだよ。
今までは経営者寄りの理想論や、管理者寄りの理想論ばかりだったけど、
XP は割とプログラマ寄りの理想論を唱えたところが新しい。
XP に限らず開発方法論なんて、みんな非現実的な理想論ばかりだよ。
今までは経営者寄りの理想論や、管理者寄りの理想論ばかりだったけど、
XP は割とプログラマ寄りの理想論を唱えたところが新しい。
264 ：デフォルトの名無しさん：03/07/13 17:08
>>263
それにしても XP は無理なものが多すぎ。
オンサイトカスタマーなんて出来るところほぼ無いだろ。
小規模開発用のプロセスなのに色々細かく役割分担してイヤに人数食うし。
だいたい XP 方式での契約が非現実的だよ既に。
作った分だけ金を払ってもらうなんて言う契約日本じゃまず取れない。
プログラム部分のプロセスはとても良いと思うんだけどね。
それにしても XP は無理なものが多すぎ。
オンサイトカスタマーなんて出来るところほぼ無いだろ。
小規模開発用のプロセスなのに色々細かく役割分担してイヤに人数食うし。
だいたい XP 方式での契約が非現実的だよ既に。
作った分だけ金を払ってもらうなんて言う契約日本じゃまず取れない。
プログラム部分のプロセスはとても良いと思うんだけどね。
265 ：デフォルトの名無しさん：03/07/13 17:17
気合で全部作るといっておいて納期内には作れませんでしたよりも、
納期内にはこれだけなら作れますがどうしますかというプロセスなんだけど。
納期内にはこれだけなら作れますがどうしますかというプロセスなんだけど。
266 ：デフォルトの名無しさん：03/07/13 17:32
そういうもんなのか。
漏れは内部システム作る部署にいて、相手が他部署の担当者なんで、
その辺の融通が利くといえば利く。
漏れは内部システム作る部署にいて、相手が他部署の担当者なんで、
その辺の融通が利くといえば利く。
268 ：デフォルトの名無しさん：03/07/13 18:36
269 ：デフォルトの名無しさん：03/07/13 18:43
現状を肯定できる現場にいるなら、現状のままでいくのが一番いいと思うよ。
あと、XP 以外のアジャイルプロセスは、オンサイトカスタマーのような
過激な要素は少ないから、もうちょっと現実的に思えるものがあるかも。
あと、XP 以外のアジャイルプロセスは、オンサイトカスタマーのような
過激な要素は少ないから、もうちょっと現実的に思えるものがあるかも。
271 ：デフォルトの名無しさん：03/07/13 19:15
272 ：デフォルトの名無しさん：03/07/13 22:11
>>266
そうだね
プラクティスを完全に適用するのは難しい
それはXPを試した人からよく聞く
でも xpの目的は
「４つの価値を最大にする」事なんで
プラクティスに、こだわらなくてもいいのでは
extreme って「極端」とか「過激」って意味だよ
慣習と合わないのは当然
そうだね
プラクティスを完全に適用するのは難しい
それはXPを試した人からよく聞く
でも xpの目的は
「４つの価値を最大にする」事なんで
プラクティスに、こだわらなくてもいいのでは
extreme って「極端」とか「過激」って意味だよ
慣習と合わないのは当然
で、
このスレの人たちの立場は３つにわかれてると思う
XP否定派
実践できないXPは机上の空論だ！
XP希望派
なんとか周りに広める方法ありませんか～？
XP発展派
XPの考えを生かした新たなプロセスはないか？
みんな根っこの考えは同じで
紙一重の違いだ
このスレの人たちの立場は３つにわかれてると思う
XP否定派
実践できないXPは机上の空論だ！
XP希望派
なんとか周りに広める方法ありませんか～？
XP発展派
XPの考えを生かした新たなプロセスはないか？
みんな根っこの考えは同じで
紙一重の違いだ
274 ：デフォルトの名無しさん：03/07/14 00:49
そんないい加減なわけ方しないでくれ。
しかも全部レイヤーが違う気がするが。
しかも全部レイヤーが違う気がするが。
275 ：デフォルトの名無しさん：03/07/14 01:22
276 ：デフォルトの名無しさん：03/07/14 01:26
紙一重と十二単くらい違う。
277 ：デフォルトの名無しさん：03/07/14 05:40
あんまり詳しくないんだけど「請負」でも「派遣」でもない、
「SES」とかいう契約形態だと XP と相性よさげな気がするんだけど、
こうゆうのは一般的ではないの？
「SES」とかいう契約形態だと XP と相性よさげな気がするんだけど、
こうゆうのは一般的ではないの？
278 ：デフォルトの名無しさん：03/07/15 00:23
要するに、なんだかんだいって今でも仕事取ってこれる恵まれた会社にいる奴が
XP にケチつけている一方で、すでにやばいことになってる会社にいるやつが、
ありもしない希望を XP に見出しているだけなんじゃねぇのかな。
技術力だのプロセスだのよりも、コネだか遠い過去の実績だのが重視されるのが
今の日本の現状なわけだろ。契約取る上で、開発プロセスなんて誰も
気にしていないのが現実。
XP にケチつけている一方で、すでにやばいことになってる会社にいるやつが、
ありもしない希望を XP に見出しているだけなんじゃねぇのかな。
技術力だのプロセスだのよりも、コネだか遠い過去の実績だのが重視されるのが
今の日本の現状なわけだろ。契約取る上で、開発プロセスなんて誰も
気にしていないのが現実。
279 ：デフォルトの名無しさん：03/07/15 01:25
確かに開発プロセスなんぞ誰も気にしないが契約形態はもの凄く気にする。
それが XP のネック。
それが XP のネック。
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
281 ：デフォルトの名無しさん：03/07/15 22:47
漏れのお気に入りなんであげとくよ。
282 ：デフォルトの名無しさん：03/07/16 21:25
XP祭りいく人
283 ：デフォルトの名無しさん：03/07/16 21:58
別にXPのスレってわけじゃないんだがな。
なんでXPにだけ粘着する香具師多いんだろ・・・
なんでXPにだけ粘着する香具師多いんだろ・・・
284 ：デフォルトの名無しさん：03/07/16 23:17
アジャプロの中で一番有名だからってのと、兄弟スレだったXPスレが落ちたからだと思われ
285 ：デフォルトの名無しさん：03/07/17 12:48
286 ：デフォルトの名無しさん：03/07/19 02:50
祭りネタない？
287 ：デフォルトの名無しさん：03/07/19 05:07
XP 実行したくても ISO の壁があって実行できない・・・
288 ：デフォルトの名無しさん：03/07/19 20:47
本当にそれはISOの壁なのか？
ISOを理解してない組織の壁ではないのか？
ISOを理解してない組織の壁ではないのか？
289 ：デフォルトの名無しさん：03/07/19 20:57
XPなんて日本じゃ効率悪いだけだよ
290 ：デフォルトの名無しさん：03/07/19 23:33
またまた馬鹿でも言える曖昧な話を得意げに・・・
実際に馬鹿なんだろうけど。
実際に馬鹿なんだろうけど。
291 ：デフォルトの名無しさん：03/07/20 00:08
ISO9001って結構カスタマイズ効くんじゃないの？
292 ：デフォルトの名無しさん：03/07/20 12:35
293 ：デフォルトの名無しさん：03/07/21 02:45
確かに、ISO9001 と XP (に限らずアジャイル全般) は排他的なものではないけれど、
価値観に大きな違いがあるので、ISO9001 を推進したがる人は XP を
評価しないし、XP 推進波は ISO9001 の必要性をあまり認めないと思う。
なので、両方をやろうとするとメンバー間での宗教論争が発生する
危険があるんじゃないかなぁ。
まぁ、そんなつまらんことで喧嘩しちゃうような組織は、何を持ってきても
うまくいかないのかもしれんけどね。
価値観に大きな違いがあるので、ISO9001 を推進したがる人は XP を
評価しないし、XP 推進波は ISO9001 の必要性をあまり認めないと思う。
なので、両方をやろうとするとメンバー間での宗教論争が発生する
危険があるんじゃないかなぁ。
まぁ、そんなつまらんことで喧嘩しちゃうような組織は、何を持ってきても
うまくいかないのかもしれんけどね。
294 ：293：03/07/26 02:09
すまん。俺が悪かった(T-T
このスレ埋もれさせるのは惜しいので、誰か話題をつなげてくだされ。
このスレ埋もれさせるのは惜しいので、誰か話題をつなげてくだされ。
295 ：デフォルトの名無しさん：03/07/26 09:02
>>294
いやいや、実際>>293の通りだと思うよ。
大規模なプロジェクト中心（漏れの職場じゃないけどな）にやってるところは
XPを理解出来ても使えないと判断されちゃうでしょ。そういうもんだよ。
逆にそういう所で無理にXPを使う必要も無いんじゃない？
いやいや、実際>>293の通りだと思うよ。
大規模なプロジェクト中心（漏れの職場じゃないけどな）にやってるところは
XPを理解出来ても使えないと判断されちゃうでしょ。そういうもんだよ。
逆にそういう所で無理にXPを使う必要も無いんじゃない？
296 ：デフォルトの名無しさん：03/07/26 13:53
45 ：仕様書無しさん ：03/07/26 13:12
XPの開発をしていると均一的でノッペリした歯車プログラマが出来上がるよな。
取り替えのきく、同じようなプログラマが大量生産される様はスターウォーズのクローン兵製造を想起させる。
確かに会社としてはこれほどありがたいことはないと思うんだが正直つまらない。
昔はもっと魅力的な職業に思えたんだがな。
色々強制される次代になってしまった。
いやはや。
XPの開発をしていると均一的でノッペリした歯車プログラマが出来上がるよな。
取り替えのきく、同じようなプログラマが大量生産される様はスターウォーズのクローン兵製造を想起させる。
確かに会社としてはこれほどありがたいことはないと思うんだが正直つまらない。
昔はもっと魅力的な職業に思えたんだがな。
色々強制される次代になってしまった。
いやはや。
あぼーん
あぼーん
300 ：デフォルトの名無しさん：03/07/28 01:14
>>293
＞確かに、ISO9001 と XP (に限らずアジャイル全般) は排他的なものではないけれど、
ISO9001の事ってよく知らないんだけど、例えばホワイトボードから
プリントアウトしたものとか、デジカメで撮った手書きダイアグラムとか
認められるんだろうか？
あとプロセスやドキュメント体系が、プロジェクトごとにチューニングされたり、
場合によっては新しくデザインされたりするのってありなのかな？
よくわからん。
＞確かに、ISO9001 と XP (に限らずアジャイル全般) は排他的なものではないけれど、
ISO9001の事ってよく知らないんだけど、例えばホワイトボードから
プリントアウトしたものとか、デジカメで撮った手書きダイアグラムとか
認められるんだろうか？
あとプロセスやドキュメント体系が、プロジェクトごとにチューニングされたり、
場合によっては新しくデザインされたりするのってありなのかな？
よくわからん。
301 ：デフォルトの名無しさん：03/07/29 08:58
俺もよくは知らないんだけど、顧客との打ち合わせなんかをしたときは、
ホワイトボードのプリントアウトをスキャンして、議事録と一緒に
管理してるよ。＜ISO9001 な今の職場
ただ、ISO9001 の指向は、各プロジェクトの共通的な要素を管理して、
過去の資料を参考に、あるていど長期的に品質の向上とかより良い
経営判断を行えるようにするってのが主眼な気がする。
なので、チューニングってのは、その会社なり組織なり毎に行うものであって、
プロジェクト毎に行うようなものではないんじゃないかなぁ。
ホワイトボードのプリントアウトをスキャンして、議事録と一緒に
管理してるよ。＜ISO9001 な今の職場
ただ、ISO9001 の指向は、各プロジェクトの共通的な要素を管理して、
過去の資料を参考に、あるていど長期的に品質の向上とかより良い
経営判断を行えるようにするってのが主眼な気がする。
なので、チューニングってのは、その会社なり組織なり毎に行うものであって、
プロジェクト毎に行うようなものではないんじゃないかなぁ。
302 ：デフォルトの名無しさん：03/07/29 10:31
手書きダイアグラムでもいいんだけど、そういった文書に対しては
より厳しい監査がなされる傾向があるそうだ。
「この文書を第３者が見ても理解できるようになっていますか？」
とかなんとか言って。
Officeソフトで綺麗に整形した文書なら簡単な監査で通してくれるって。
だから不適合くらうのが怖いのでみんなExcelでフォーマット作って清書している。
より厳しい監査がなされる傾向があるそうだ。
「この文書を第３者が見ても理解できるようになっていますか？」
とかなんとか言って。
Officeソフトで綺麗に整形した文書なら簡単な監査で通してくれるって。
だから不適合くらうのが怖いのでみんなExcelでフォーマット作って清書している。
303 ：デフォルトの名無しさん：03/07/29 21:02
やっぱり、XP的には壁になりそうだね。
304 ：デフォルトの名無しさん：03/07/29 23:24
>>301
＞ホワイトボードのプリントアウトをスキャンして、議事録と一緒に
＞管理してるよ。＜ISO9001 な今の職場
ホワイトボードのプリントアウトがあれば充分って訳じゃなくて、
やはり必須の議事録に付属する補足資料って感じだろうか。
>>302
＞「この文書を第３者が見ても理解できるようになっていますか？」
例えば何かの資格保持者（UMLとか）が検印するような仕組みにしたら、
説得力が増したりするのかな。
>>303
＞やっぱり、XP的には壁になりそうだね。
agile processの中では、むしろXPみたいにhigh-disciplineなタイプは
わりと向いてるような気がするなあ。
WFやUPみたいなheavy weightなプロセスと比べても、成果物や開発の
リズムが比較的平坦で均質な分、管理も監査もやり易そうだし、案外
相性が良いように見えないこともないんだが。
＞ホワイトボードのプリントアウトをスキャンして、議事録と一緒に
＞管理してるよ。＜ISO9001 な今の職場
ホワイトボードのプリントアウトがあれば充分って訳じゃなくて、
やはり必須の議事録に付属する補足資料って感じだろうか。
>>302
＞「この文書を第３者が見ても理解できるようになっていますか？」
例えば何かの資格保持者（UMLとか）が検印するような仕組みにしたら、
説得力が増したりするのかな。
>>303
＞やっぱり、XP的には壁になりそうだね。
agile processの中では、むしろXPみたいにhigh-disciplineなタイプは
わりと向いてるような気がするなあ。
WFやUPみたいなheavy weightなプロセスと比べても、成果物や開発の
リズムが比較的平坦で均質な分、管理も監査もやり易そうだし、案外
相性が良いように見えないこともないんだが。
>>304
>ホワイトボードのプリントアウトがあれば充分って訳じゃなくて、
>やはり必須の議事録に付属する補足資料って感じだろうか。
ISO9001 ってなんか公的な認定機関があって、半年だか一年毎に社内の
全プロジェクトの中から、なんらかの基準でピックアップされた一部の
プロジェクトが、その審査対象となるのね＜うちの職場の場合
でもって、審査対象として選ばれたプロジェクトは、ある程度過去に遡って
議事録が生成して、「主：議事録、副：プリントアウト」という形で体裁を整えてるみたい。
関わったことないからよくしらんけど。
議事録にまとめられた時点で「第三者的視点からのわかりやすさ」は増加するかも
しれないけど、「会議に参加した人の記憶を呼び覚ます」という効果はホワイトボードの
プリントアウトの方が優れているような気がする。
どちらを重視すべきかは、ケースバイケースなんだろうな。きっと。
>ホワイトボードのプリントアウトがあれば充分って訳じゃなくて、
>やはり必須の議事録に付属する補足資料って感じだろうか。
ISO9001 ってなんか公的な認定機関があって、半年だか一年毎に社内の
全プロジェクトの中から、なんらかの基準でピックアップされた一部の
プロジェクトが、その審査対象となるのね＜うちの職場の場合
でもって、審査対象として選ばれたプロジェクトは、ある程度過去に遡って
議事録が生成して、「主：議事録、副：プリントアウト」という形で体裁を整えてるみたい。
関わったことないからよくしらんけど。
議事録にまとめられた時点で「第三者的視点からのわかりやすさ」は増加するかも
しれないけど、「会議に参加した人の記憶を呼び覚ます」という効果はホワイトボードの
プリントアウトの方が優れているような気がする。
どちらを重視すべきかは、ケースバイケースなんだろうな。きっと。
（＾＾）
307 ：デフォルトの名無しさん：03/08/03 22:32
どっかの一部署か小さな会社のようなこじんまりしたグループで、
他と差をつけるためにagile processを謳って短期、低コスト、
低リスクな開発を図ったとして、そうしたチームにこそISO9001みたいな
認証が欲しいなあ。
このスレでも何回か挙がったような契約の問題とか、顧客との協調体制
作りのためにも、こういうお墨付きは持ってるだけでもかなり良い材料だと
思うんだが。
他と差をつけるためにagile processを謳って短期、低コスト、
低リスクな開発を図ったとして、そうしたチームにこそISO9001みたいな
認証が欲しいなあ。
このスレでも何回か挙がったような契約の問題とか、顧客との協調体制
作りのためにも、こういうお墨付きは持ってるだけでもかなり良い材料だと
思うんだが。
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
309 ：デフォルトの名無しさん：03/08/19 20:13
296に烈しく同意
310 ：デフォルトの名無しさん：03/08/19 23:23
>>296
「職人気質」に書いてあるのとは逆の感じみたいだけど、XPってそうなの？
「職人気質」に書いてあるのとは逆の感じみたいだけど、XPってそうなの？
311 ：デフォルトの名無しさん：03/08/20 00:44
312 ：デフォルトの名無しさん：03/08/20 02:54
おいおい・・・・・・
313 ：デフォルトの名無しさん：03/08/21 19:08
プラグラマは楽を追求する生き物なんだよ
314 ：デフォルトの名無しさん：03/08/23 03:43
そりゃ特定の一人にプロジェクトの命運をかけるのを避けようとすれば、
メンバー全員の価値がフラットになるように持っていくのがすじってものだろう。
誰か一人でも欠けたらプロジェクトあぼーんなんてやってられん。
メンバー全員の価値がフラットになるように持っていくのがすじってものだろう。
誰か一人でも欠けたらプロジェクトあぼーんなんてやってられん。
315 ：デフォルトの名無しさん：03/08/23 07:55
>>314
それもわかっていての>>296なんじゃないの？
まぁ、xp にしろデザパタにしろ熟練プログラマの編み出したものをタダ愚鈍に使っているだけの人間は
ずっと、フラットのままだろな。
模索をしなくなったらお終いだよ。
kent beck や GoF 側の人間にならなきゃね。
それもわかっていての>>296なんじゃないの？
まぁ、xp にしろデザパタにしろ熟練プログラマの編み出したものをタダ愚鈍に使っているだけの人間は
ずっと、フラットのままだろな。
模索をしなくなったらお終いだよ。
kent beck や GoF 側の人間にならなきゃね。
316 ：デフォルトの名無しさん：03/08/24 18:25
高学歴じゃないとなれません。
317 ：デフォルトの名無しさん：03/08/25 02:01
学歴は関係ないよ。
だって、昔のプログラマはプロセスやパターンが無い時代に自分なりにそれらを見つけ出し使っていたんだから。
実際にこれらが名前付けられて登場した時、あっ、これオレがやっている方法と一緒だと思ったことあるでしょ？
だって、昔のプログラマはプロセスやパターンが無い時代に自分なりにそれらを見つけ出し使っていたんだから。
実際にこれらが名前付けられて登場した時、あっ、これオレがやっている方法と一緒だと思ったことあるでしょ？
318 ：デフォルトの名無しさん：03/08/31 02:38
XPはUnitTestとリファクタリングを残して無くなるでしょう。
プロセスとしては非現実的なことが多すぎる。
プロセスとしては非現実的なことが多すぎる。
319 ：デフォルトの名無しさん：03/08/31 09:50
320 ：デフォルトの名無しさん：03/09/01 00:53
うちのXP信者が日曜日にスキーマコンパイラで生成された
Javaファイルを勝手にリファクタしてて欝。
月曜日会社行きたくない。。
Javaファイルを勝手にリファクタしてて欝。
月曜日会社行きたくない。。
321 ：デフォルトの名無しさん：03/09/01 00:57
会社をやめて旅に出ろ
322 ：デフォルトの名無しさん：03/09/01 05:45
>>318
XPは完璧なコミュニケーションを要求するけど（本当に理想のリファクタリングするなら理想像を共有しなきゃいけない）
そこまでのコミュニケーションをやろうとする人が（上司も部下も）いないんでしょう。
漏れが感じてる問題点は「コミュニケーション力の総量が足りていない」
皆はどうかな
XPは完璧なコミュニケーションを要求するけど（本当に理想のリファクタリングするなら理想像を共有しなきゃいけない）
そこまでのコミュニケーションをやろうとする人が（上司も部下も）いないんでしょう。
漏れが感じてる問題点は「コミュニケーション力の総量が足りていない」
皆はどうかな
323 ：デフォルトの名無しさん：03/09/01 07:34
そんな宗教的なこといわれてもねぇ。
XPをもっと軽くやろうよ。
XPをもっと軽くやろうよ。
324 ：デフォルトの名無しさん：03/09/02 00:09
計画ゲーム、小規模リリースなんて顧客の理解がなきゃ出来ないし、そんなに頻度に話し合いを設けなきゃならない契約を顧客は嫌う。
なんのためにアンタのところに仕事を投げているんだと憤慨するところもあるだろう。
自分にかかる負荷を軽減する意味合いも含めて投げている顧客にしてみれば当然の反応だろう。
ペアプログラミングも仕事が一つの場合なら良いが実際のところ複数を掛け持つ場合がほとんどなのでその場合は仕事を割ることになる。
結局、複数の仕事の場合全員が情報を共有するより分担を決めて割り振った方が理解も深く負荷も低くなる。
共同所有権も上記の理由により実現が難しい。
オンサイト顧客は喫煙室で笑い飛ばすネタとしては使えるかも。
週40時間は素早く多くの物件をこなさなきゃ大企業に対抗できない小さい会社には無理。
結論から言うとある程度力のある大きな企業が小規模、中規模開発をする時に効果が高いプロセス。
開発規模が同じだからと言って零細企業が真似をすると痛い目に遭う。
なんのためにアンタのところに仕事を投げているんだと憤慨するところもあるだろう。
自分にかかる負荷を軽減する意味合いも含めて投げている顧客にしてみれば当然の反応だろう。
ペアプログラミングも仕事が一つの場合なら良いが実際のところ複数を掛け持つ場合がほとんどなのでその場合は仕事を割ることになる。
結局、複数の仕事の場合全員が情報を共有するより分担を決めて割り振った方が理解も深く負荷も低くなる。
共同所有権も上記の理由により実現が難しい。
オンサイト顧客は喫煙室で笑い飛ばすネタとしては使えるかも。
週40時間は素早く多くの物件をこなさなきゃ大企業に対抗できない小さい会社には無理。
結論から言うとある程度力のある大きな企業が小規模、中規模開発をする時に効果が高いプロセス。
開発規模が同じだからと言って零細企業が真似をすると痛い目に遭う。
325 ：デフォルトの名無しさん：03/09/02 01:08
デスマーチは続くよどこまでも。
開発者も顧客もそれを望んでいるようだ。
開発者も顧客もそれを望んでいるようだ。
326 ：デフォルトの名無しさん：03/09/02 01:39
>>325
XP意外はデスマーチになると言う考えは如何なものかと。
XPは今のところ幾つかのプラクティスをつまんで既存のコンポーネントベースと組み合わせるのが無難でしょう。
アジャイルモデリングも取り込んでフットワークを軽くするのも手です。
XP意外はデスマーチになると言う考えは如何なものかと。
XPは今のところ幾つかのプラクティスをつまんで既存のコンポーネントベースと組み合わせるのが無難でしょう。
アジャイルモデリングも取り込んでフットワークを軽くするのも手です。
327 ：デフォルトの名無しさん：03/09/02 01:52
>>322
＞XPは完璧なコミュニケーションを要求するけど
これってどこかで定義されているの？
括弧内の前提からの帰結だとして、それはXP的に正しいの？
まあextremeって言うくらいだから極論じみてた方がそれっぽくて
良いのかも知らんが。
ちなみにコーバーンなんかは、完全なコミュニケーションなんて所詮
あり得ないという、至極当たり前なところから議論を始めてる。
現実を踏まえた上で少しでもAgileにしていこうというアプローチなんで、
結構参考になる。
＞XPは完璧なコミュニケーションを要求するけど
これってどこかで定義されているの？
括弧内の前提からの帰結だとして、それはXP的に正しいの？
まあextremeって言うくらいだから極論じみてた方がそれっぽくて
良いのかも知らんが。
ちなみにコーバーンなんかは、完全なコミュニケーションなんて所詮
あり得ないという、至極当たり前なところから議論を始めてる。
現実を踏まえた上で少しでもAgileにしていこうというアプローチなんで、
結構参考になる。
328 ：デフォルトの名無しさん：03/09/02 02:00
そう言えばコーバーンは読んでないなぁ
XPは過激すぎるのでちょっと読んでみるか
XPは過激すぎるのでちょっと読んでみるか
329 ：デフォルトの名無しさん：03/09/02 02:02
XP、Scrum、FDD、Crystal、ASD、LSD・・・
いったいどれが良いやら。
いったいどれが良いやら。
330 ：デフォルトの名無しさん：03/09/02 02:16
同じ人間に見えない。
ttp://www.fawcette.com/interviews/beck_cooper/kbeck.gif
ttp://www.ogis-ri.co.jp/otc/hiroba/specials/KentBeckXPseminar/xpjug/kent.jpg
ttp://www.martinfowler.com/articles/beck.jpg
ttp://www.fawcette.com/interviews/beck_cooper/kbeck.gif
ttp://www.ogis-ri.co.jp/otc/hiroba/specials/KentBeckXPseminar/xpjug/kent.jpg
ttp://www.martinfowler.com/articles/beck.jpg
331 ：デフォルトの名無しさん：03/09/02 03:12
332 ：デフォルトの名無しさん：03/09/02 07:17
小さな仕事を4つ受けるのやめて、4倍の規模の仕事をひとつ受ければ無問題。
XP は6人ぐらいのチームが数ヵ月専念する程度のプロジェクトが適用可能な
最小レベルであって、それより小さなプロジェクトには無理が多いと思う。
XP もまた銀の弾丸ではないわけだし。
XP は6人ぐらいのチームが数ヵ月専念する程度のプロジェクトが適用可能な
最小レベルであって、それより小さなプロジェクトには無理が多いと思う。
XP もまた銀の弾丸ではないわけだし。
333 ：デフォルトの名無しさん：03/09/02 20:14
334 ：デフォルトの名無しさん：03/09/03 04:39
おもろい記事みっけ
独CoCreate Software社，仮想ユーザーを設定し3次元CADを開発
http://dm.nikkeibp.co.jp/members/DM/DMNEWS/20030901/7/
～
同社は「eXtreme Programming」という手法を取り入れ，
同社の3次元CAD「OneSpace Designer 2004」を開発したという。
～
独CoCreate Software社，仮想ユーザーを設定し3次元CADを開発
http://dm.nikkeibp.co.jp/members/DM/DMNEWS/20030901/7/
～
同社は「eXtreme Programming」という手法を取り入れ，
同社の3次元CAD「OneSpace Designer 2004」を開発したという。
～
335 ：hn ◆iKwMOjCT4s ：03/09/04 01:55
>>324
> なんのためにアンタのところに仕事を投げているんだと憤慨するところもあるだろう。
> 自分にかかる負荷を軽減する意味合いも含めて投げている顧客にしてみれば当然の反応だろう。
話し合い無しでうまくいく試しなし。
話し合いの機会を作らない顧客は蹴れ。
そんな顧客を相手にしている時点で負け組。
> 週40時間は素早く多くの物件をこなさなきゃ大企業に対抗できない小さい会社には無理。
小さな会社がやるべきことは、いい顧客を掴むこと。
数をこなさなきゃダメっていうのは、負け組がさらに負ける戦略。
> なんのためにアンタのところに仕事を投げているんだと憤慨するところもあるだろう。
> 自分にかかる負荷を軽減する意味合いも含めて投げている顧客にしてみれば当然の反応だろう。
話し合い無しでうまくいく試しなし。
話し合いの機会を作らない顧客は蹴れ。
そんな顧客を相手にしている時点で負け組。
> 週40時間は素早く多くの物件をこなさなきゃ大企業に対抗できない小さい会社には無理。
小さな会社がやるべきことは、いい顧客を掴むこと。
数をこなさなきゃダメっていうのは、負け組がさらに負ける戦略。
336 ：hn ◆iKwMOjCT4s ：03/09/04 02:03
>>327
コードを書くときに求められる「コミュニケーション」というのは、
「ここ直したらどうよ？」と検討が始まって、結論が出て、皆が納得するすること。
と漏れは認識しとります。
コードの調整に関しては一定レベル以上のプログラマなら（技術的には）話はすぐにまとまる。
が、それを阻害する人間の感情的な要因がいくつかあるので、それを解決するだけのコミュニ
ケーション能力が開発に多くの人に足りてないなと。
コードを書くときに求められる「コミュニケーション」というのは、
「ここ直したらどうよ？」と検討が始まって、結論が出て、皆が納得するすること。
と漏れは認識しとります。
コードの調整に関しては一定レベル以上のプログラマなら（技術的には）話はすぐにまとまる。
が、それを阻害する人間の感情的な要因がいくつかあるので、それを解決するだけのコミュニ
ケーション能力が開発に多くの人に足りてないなと。
337 ：デフォルトの名無しさん：03/09/06 19:52
>>335
> 話し合いの機会を作らない顧客は蹴れ。
学生？
話し合いがないワケじゃない。
たいていは最初に全て決めるだけの話。
そう言う顧客は全部蹴るの？
オレは xp が実践出来なかろうと定期的に仕事を振ってくれて他の会社にも
紹介してくれるところを大事にするけど。
いま、xp が実践できるような契約や顧客なんて本当に数えるほどしかない。
自分は xp というプロセスが実践できないからって顧客を蹴ったりしないけどね。
> 小さな会社がやるべきことは、いい顧客を掴むこと。
> 数をこなさなきゃダメっていうのは、負け組がさらに負ける戦略。
食っていくと言うことが良く解っていない甘ちゃん的発想だね。
その良い顧客を掴むまでの間どうするのさ？
そしてどうやって仕事を探す？
現実問題として xp が実践できるような顧客まで辿り着くにはそれこそ色々な仕事を
こなして人脈を作らなくちゃならない。
プロセスに振り回されて仕事を選ぶなんて本末転倒。
> 話し合いの機会を作らない顧客は蹴れ。
学生？
話し合いがないワケじゃない。
たいていは最初に全て決めるだけの話。
そう言う顧客は全部蹴るの？
オレは xp が実践出来なかろうと定期的に仕事を振ってくれて他の会社にも
紹介してくれるところを大事にするけど。
いま、xp が実践できるような契約や顧客なんて本当に数えるほどしかない。
自分は xp というプロセスが実践できないからって顧客を蹴ったりしないけどね。
> 小さな会社がやるべきことは、いい顧客を掴むこと。
> 数をこなさなきゃダメっていうのは、負け組がさらに負ける戦略。
食っていくと言うことが良く解っていない甘ちゃん的発想だね。
その良い顧客を掴むまでの間どうするのさ？
そしてどうやって仕事を探す？
現実問題として xp が実践できるような顧客まで辿り着くにはそれこそ色々な仕事を
こなして人脈を作らなくちゃならない。
プロセスに振り回されて仕事を選ぶなんて本末転倒。
338 ：デフォルトの名無しさん：03/09/07 05:39
>>335
xpをできるような顧客が沢山いてしかもその顧客が毎回仕事をくれるような状態なら蹴りまくれるけどね:-P
xpをできるような顧客が沢山いてしかもその顧客が毎回仕事をくれるような状態なら蹴りまくれるけどね:-P
339 ：デフォルトの名無しさん：03/09/07 13:02
（´-`）.｡oO（335みたいな勘違い君を見るとXP信者ウザイという気持ちも解るな・・・
340 ：デフォルトの名無しさん：03/09/07 13:09
だいたいXPをほめる人には共通の経験があって
１．１０人前後のチームで開発している
２．頻繁な仕様変更で期間が大幅にのびた事がある
３．ドキュメント駆動でプログラムを作った事がある
上記のどれにも経験してない人には
説明しても拒否・否定される。
そういう人にはXPは非現実的にみえて
しょうがないんでしょうな
１．１０人前後のチームで開発している
２．頻繁な仕様変更で期間が大幅にのびた事がある
３．ドキュメント駆動でプログラムを作った事がある
上記のどれにも経験してない人には
説明しても拒否・否定される。
そういう人にはXPは非現実的にみえて
しょうがないんでしょうな
341 ：デフォルトの名無しさん：03/09/07 13:55
>>340
そんなの誰でも経験しているでしょうに。
XPが非現実的なのはあまりにも多くのことを顧客や環境に求めること。
だから>>318-319で挙がっているようなプロセスは別に非現実的とは思っていない。
と言うか熟練のプログラマなら昔からやっていること。
（´-`）.｡oO（やっぱりXPを盲信している人は何故非現実的と言われているのか解って無かったんだなぁ…）
そんなの誰でも経験しているでしょうに。
XPが非現実的なのはあまりにも多くのことを顧客や環境に求めること。
だから>>318-319で挙がっているようなプロセスは別に非現実的とは思っていない。
と言うか熟練のプログラマなら昔からやっていること。
（´-`）.｡oO（やっぱりXPを盲信している人は何故非現実的と言われているのか解って無かったんだなぁ…）
342 ：デフォルトの名無しさん：03/09/07 14:04
343 ：デフォルトの名無しさん：03/09/07 14:07
でもXPを「盲信」してる人は、実践した上でそう言ってるんじゃないの？
だったら（少なくとも当人にとっては）非現実的とは言えないと思うが
だったら（少なくとも当人にとっては）非現実的とは言えないと思うが
344 ：デフォルトの名無しさん：03/09/07 14:13
>>343
>>324が言っているように企業体力がある、認知度が高いような大きな企業なら実践が可能な場合がある。
あとは理解を示してくれる顧客が多い場合か。
しかし、これらはレアケースであってこれらを見て現実的だとはとても言えない。
>>324が言っているように企業体力がある、認知度が高いような大きな企業なら実践が可能な場合がある。
あとは理解を示してくれる顧客が多い場合か。
しかし、これらはレアケースであってこれらを見て現実的だとはとても言えない。
345 ：デフォルトの名無しさん：03/09/07 14:23
＞343
＞だったら（少なくとも当人にとっては）非現実的とは言えないと思うが
これってまさしく信者って感じだな（ｗ
パナウェーブのスカラー波みたいなものか？
＞だったら（少なくとも当人にとっては）非現実的とは言えないと思うが
これってまさしく信者って感じだな（ｗ
パナウェーブのスカラー波みたいなものか？
346 ：デフォルトの名無しさん：03/09/07 14:29
オレは別に本人にXPが合っていれば盲信しても良いと思うけどなあ
335みたいに実践しないのは負け組だとか言い出さないかぎりはね。
335みたいに実践しないのは負け組だとか言い出さないかぎりはね。
347 ：デフォルトの名無しさん：03/09/07 17:13
現状何も困ってないなら今までのやり方のままでいいんじゃない。
漏れは困ってるのでよりよい弾丸を探す/作る試みを続けてる。
漏れは困ってるのでよりよい弾丸を探す/作る試みを続けてる。
348 ：デフォルトの名無しさん：03/09/08 01:17
>>347
常に最前の方法を模索はするね。
xp はリファクタリングやUnitTestがIDEに統合されつつあるのでその部分だけは恩恵にあずかれそう。
プロセスとしては色々なアジャイル系をミックスして試すのがベターかな。
常に最前の方法を模索はするね。
xp はリファクタリングやUnitTestがIDEに統合されつつあるのでその部分だけは恩恵にあずかれそう。
プロセスとしては色々なアジャイル系をミックスして試すのがベターかな。
349 ：デフォルトの名無しさん：03/09/16 11:27
【チンコのレス】
〓〓〓〓〓
｜〓｜
｜〓｜
｜〓｜
(⌒⌒)
＼／
〓
【チンコお守りレス】このお守りを見たあなたは超超超幸せ者！
2週間以内に必ず彼氏・彼女が出来るよ！
すでにいる人は超～ラブラブ みんなが幸せになりますように…
そのかわりこのコピペを１時間以内に、5つ別のスレに貼り付けてね・・
でないと、あなたはインポや性病になります。
〓〓〓〓〓
｜〓｜
｜〓｜
｜〓｜
(⌒⌒)
＼／
〓
【チンコお守りレス】このお守りを見たあなたは超超超幸せ者！
2週間以内に必ず彼氏・彼女が出来るよ！
すでにいる人は超～ラブラブ みんなが幸せになりますように…
そのかわりこのコピペを１時間以内に、5つ別のスレに貼り付けてね・・
でないと、あなたはインポや性病になります。
350 ：デフォルトの名無しさん：03/09/16 19:26
XPのプラクティスに追加希望。
否定派にはとりあえず「ああ、もっとも、そのとおりだね」と口では言っておく。
否定派にはとりあえず「ああ、もっとも、そのとおりだね」と口では言っておく。
351 ：デフォルトの名無しさん：03/09/17 10:16
xpは有効なプラクティスだけど､なんでこれをわざわざ世間に
（Role Model Soft 社の人々は） 公開したのかね。
会社のノウハウとしてとっておけば、その会社は差別的優位性を
保てたんじゃないのかと。公開してその会社は一体どういう得を
するのかね。
（Role Model Soft 社の人々は） 公開したのかね。
会社のノウハウとしてとっておけば、その会社は差別的優位性を
保てたんじゃないのかと。公開してその会社は一体どういう得を
するのかね。
352 ：デフォルトの名無しさん：03/09/17 10:54
353 ：デフォルトの名無しさん：03/09/18 00:03
>>351
マジでそう言っているんだったらかなりおめでたい。
xp を公開したことにより信頼度、知名度を手に入れただろ。
それによって客の質も数も以前より増える。
当然、貰える額も変わってくるはずだ。
一流の会社はこぞって使おうとするだろうしその会社にとっても
宣伝になりエンドに安心を売ることが出来る。
>>352みたいな個人的なことだけじゃなく、会社としても相当潤う。
マジでそう言っているんだったらかなりおめでたい。
xp を公開したことにより信頼度、知名度を手に入れただろ。
それによって客の質も数も以前より増える。
当然、貰える額も変わってくるはずだ。
一流の会社はこぞって使おうとするだろうしその会社にとっても
宣伝になりエンドに安心を売ることが出来る。
>>352みたいな個人的なことだけじゃなく、会社としても相当潤う。
354 ：デフォルトの名無しさん：03/09/18 00:58
355 ：デフォルトの名無しさん：03/09/18 01:02
たとえば競馬予想ソフト。
本当に当たるなら自分で使えばいい。
ではなぜ当たる競馬予想ソフトを売るのか？
そこにカモがいるからだ。
本当に当たるなら自分で使えばいい。
ではなぜ当たる競馬予想ソフトを売るのか？
そこにカモがいるからだ。
356 ：デフォルトの名無しさん：03/09/18 07:43
このスレの住人もカモですか？
357 ：デフォルトの名無しさん：03/09/22 02:17
とりあえず今
「アジャイルソフトウェア開発スクラム」
読んでます
「アジャイルソフトウェア開発スクラム」
読んでます
358 ：デフォルトの名無しさん：03/09/23 16:56
とりあえず今
「アジャイルソフトウェア開発エコシステム」
読んでます
字ばっかし
「アジャイルソフトウェア開発エコシステム」
読んでます
字ばっかし
359 ：デフォルトの名無しさん：03/10/06 13:38
アジャイルって、ろくな開発方法手法もなく、設計もせず
でたらめな開発している人たちに免罪符を与えただけの
ような気がします。
でたらめ、似非アジャイルと正しくアジャイルを適用している
プロジェクトを区別する方法を教えていただけませんか？
でたらめな開発している人たちに免罪符を与えただけの
ような気がします。
でたらめ、似非アジャイルと正しくアジャイルを適用している
プロジェクトを区別する方法を教えていただけませんか？
360 ：デフォルトの名無しさん：03/10/06 15:58
>>359
アジャイルソフトウェア宣言で示している４つの価値を重視しているかで
区別できるのではないですか？４つの価値とは以下のとおりです。
・個人と相互作用
・動作するソフトウェア
・ユーザとの協調
・変化への対応
ちなみに、これらと比較して価値が小さくなるものとして以下が挙げられています。
・プロセスやツール
・包括的なドキュメント
・契約交渉
・計画に従うこと
つまり、プロセスやツールを軽量にし、包括的なドキュメントを残さず、
詳細で長期的な契約交渉を行わず、当初の計画から外れた開発を
しているうえに、
個人の相互作用が少なく、動作するソフトウェアがなかなか生まれず、
ユーザとの協調もなおざりで、変化への対応力に乏しい
ような開発をしている場合は、似非アジャイルと呼んでいいと思います。
アジャイル開発＝手法なし、設計なし、管理なしじゃないんですけどね。
例えばXPなら重い規律をメンバーに課しています。
アジャイルソフトウェア宣言で示している４つの価値を重視しているかで
区別できるのではないですか？４つの価値とは以下のとおりです。
・個人と相互作用
・動作するソフトウェア
・ユーザとの協調
・変化への対応
ちなみに、これらと比較して価値が小さくなるものとして以下が挙げられています。
・プロセスやツール
・包括的なドキュメント
・契約交渉
・計画に従うこと
つまり、プロセスやツールを軽量にし、包括的なドキュメントを残さず、
詳細で長期的な契約交渉を行わず、当初の計画から外れた開発を
しているうえに、
個人の相互作用が少なく、動作するソフトウェアがなかなか生まれず、
ユーザとの協調もなおざりで、変化への対応力に乏しい
ような開発をしている場合は、似非アジャイルと呼んでいいと思います。
アジャイル開発＝手法なし、設計なし、管理なしじゃないんですけどね。
例えばXPなら重い規律をメンバーに課しています。
>>360
s/アジャイルソフトウェア宣言/アジャイルソフトウェア開発宣言/
s/アジャイルソフトウェア宣言/アジャイルソフトウェア開発宣言/
362 ：デフォルトの名無しさん：03/10/06 21:30
>>360
>つまり、プロセスやツールを軽量にし、包括的なドキュメントを残さず、
>詳細で長期的な契約交渉を行わず、当初の計画から外れた開発を
>しているうえに、
ここまでは今のプロジェクトがそうです。でも、
>個人の相互作用が少なく、
はどういうことかわからないんですけど、
>動作するソフトウェアがなかなか生まれず、
ユーザーと協調するために、週に２回は動作するアプリのリリース
を要求されています。
>ユーザとの協調もなおざりで、
ユーザーとの協調が第一です。
>変化への対応力に乏しい
変化に対応するのはPGたちの徹夜に頼っていますがそろそれ限界です。
>ような開発をしている場合は、似非アジャイルと呼んでいいと思います。
どうなんでしょうか？半分アジャイルなんですけど、こんな状態を推奨するのが今の最先端なんですか？やっぱり単なる現状追認にそれっぽい名前与えただけみたいなんですけど。
設計なし、ドキュメントなし、管理なし（あしたまでにリリースだそれいけやれいけって管理ならありますけど）で、これだと破たんするって言うと、いやアジャイル開発ではこういうやりかたでやることを推奨しているんです。って言われて反論できません。
なんでこんな状態でよいソフトウエアが生まれ、開発者がハッピーになれるのか疑問です。
>つまり、プロセスやツールを軽量にし、包括的なドキュメントを残さず、
>詳細で長期的な契約交渉を行わず、当初の計画から外れた開発を
>しているうえに、
ここまでは今のプロジェクトがそうです。でも、
>個人の相互作用が少なく、
はどういうことかわからないんですけど、
>動作するソフトウェアがなかなか生まれず、
ユーザーと協調するために、週に２回は動作するアプリのリリース
を要求されています。
>ユーザとの協調もなおざりで、
ユーザーとの協調が第一です。
>変化への対応力に乏しい
変化に対応するのはPGたちの徹夜に頼っていますがそろそれ限界です。
>ような開発をしている場合は、似非アジャイルと呼んでいいと思います。
どうなんでしょうか？半分アジャイルなんですけど、こんな状態を推奨するのが今の最先端なんですか？やっぱり単なる現状追認にそれっぽい名前与えただけみたいなんですけど。
設計なし、ドキュメントなし、管理なし（あしたまでにリリースだそれいけやれいけって管理ならありますけど）で、これだと破たんするって言うと、いやアジャイル開発ではこういうやりかたでやることを推奨しているんです。って言われて反論できません。
なんでこんな状態でよいソフトウエアが生まれ、開発者がハッピーになれるのか疑問です。
363 ：デフォルトの名無しさん：03/10/06 22:16
364 ：デフォルトの名無しさん：03/10/06 23:38
>>363
読みました。ありがとうございます。ここでやはり疑問があります。
アジャイル開発過程では、包括的なドキュメント作成は重視されない
とありますが、それでは、
顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか？
あるいは、それを設計者にどのように伝えるのでしょうか？
そして、設計結果が顧客の仕様を満たしているかどうかをどのように
判断するのでしょうか？
設計者の設計内容をどのように実装者につたえるのでしょうか？
そして、どのようにその実装結果を検証（試験）するのでしょうか？
他にも疑問は多々有り、アジャイル開発を行うことは結局実装者の
負担を増大させるばかりか、過去においてはそれが管理者等の混乱
によるものであるとみなされていたものが、現代ではアジャイル開発
でやっているからで正しいことなのであるという免罪符になっている
のではないか思っています。
そして、アジャイル開発であってなお、実装者の負担減につながる
方法を知りたいと切実に求めています。
読みました。ありがとうございます。ここでやはり疑問があります。
アジャイル開発過程では、包括的なドキュメント作成は重視されない
とありますが、それでは、
顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか？
あるいは、それを設計者にどのように伝えるのでしょうか？
そして、設計結果が顧客の仕様を満たしているかどうかをどのように
判断するのでしょうか？
設計者の設計内容をどのように実装者につたえるのでしょうか？
そして、どのようにその実装結果を検証（試験）するのでしょうか？
他にも疑問は多々有り、アジャイル開発を行うことは結局実装者の
負担を増大させるばかりか、過去においてはそれが管理者等の混乱
によるものであるとみなされていたものが、現代ではアジャイル開発
でやっているからで正しいことなのであるという免罪符になっている
のではないか思っています。
そして、アジャイル開発であってなお、実装者の負担減につながる
方法を知りたいと切実に求めています。
365 ：デフォルトの名無しさん：03/10/07 10:34
>顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか？
>あるいは、それを設計者にどのように伝えるのでしょうか？
口頭、図、文章などを用いたインタビューによって。
>そして、設計結果が顧客の仕様を満たしているかどうかをどのように
>判断するのでしょうか？
XPの場合は、受け入れテストによって。顧客が作れれば最高ですが、
まずありえないので、顧客の言葉をテストに翻訳して顧客と確認する、
ということになるでしょう。
>設計者の設計内容をどのように実装者につたえるのでしょうか？
>そして、どのようにその実装結果を検証（試験）するのでしょうか？
設計者と実装者を分けている段階で、アジャイルでは無いと思われ。
実装結果を検証（試験）は、さっき作った受け入れテストと、顧客への
リリースによるフィードバックでしょうね。
>によるものであるとみなされていたものが、現代ではアジャイル開発
>でやっているからで正しいことなのであるという免罪符になっている
>のではないか思っています。
『現代では』というのが拡大しすぎだと思いますが、少なくともあなたの
会社では免罪符として用いているだけだと思います。
そして、その原因の一つが、実装者であるあなた達が、自分が強制され
ていると感じているプロセス（アジャイル）の文献すら一切調べていない
ことにあるでしょう。
ちょっと関連書籍を読んでみれば、今やっているのが実はアジャイルで
ないのは明らかなはずです。
>あるいは、それを設計者にどのように伝えるのでしょうか？
口頭、図、文章などを用いたインタビューによって。
>そして、設計結果が顧客の仕様を満たしているかどうかをどのように
>判断するのでしょうか？
XPの場合は、受け入れテストによって。顧客が作れれば最高ですが、
まずありえないので、顧客の言葉をテストに翻訳して顧客と確認する、
ということになるでしょう。
>設計者の設計内容をどのように実装者につたえるのでしょうか？
>そして、どのようにその実装結果を検証（試験）するのでしょうか？
設計者と実装者を分けている段階で、アジャイルでは無いと思われ。
実装結果を検証（試験）は、さっき作った受け入れテストと、顧客への
リリースによるフィードバックでしょうね。
>によるものであるとみなされていたものが、現代ではアジャイル開発
>でやっているからで正しいことなのであるという免罪符になっている
>のではないか思っています。
『現代では』というのが拡大しすぎだと思いますが、少なくともあなたの
会社では免罪符として用いているだけだと思います。
そして、その原因の一つが、実装者であるあなた達が、自分が強制され
ていると感じているプロセス（アジャイル）の文献すら一切調べていない
ことにあるでしょう。
ちょっと関連書籍を読んでみれば、今やっているのが実はアジャイルで
ないのは明らかなはずです。
366 ：デフォルトの名無しさん：03/10/07 23:01
＞顧客の仕様要求と製作するシステムをどのように一致させるのでしょうか？
＞あるいは、それを設計者にどのように伝えるのでしょうか？
＞そして、設計結果が顧客の仕様を満たしているかどうかをどのように
＞判断するのでしょうか？
ドキュメント書いて、レビューやれば良いじゃん。
だれか駄目って言ってんの？
だけど、包括性にこだわり過ぎるのは良くないかもね。
そんな感じ。わかった？
＞あるいは、それを設計者にどのように伝えるのでしょうか？
＞そして、設計結果が顧客の仕様を満たしているかどうかをどのように
＞判断するのでしょうか？
ドキュメント書いて、レビューやれば良いじゃん。
だれか駄目って言ってんの？
だけど、包括性にこだわり過ぎるのは良くないかもね。
そんな感じ。わかった？
367 ：デフォルトの名無しさん：03/10/08 15:32
>>366
>ドキュメント書いて、レビューやれば良いじゃん。
>だれか駄目って言ってんの？
プロマネ兼SE。
仕様書ないから、プログラム作れないって言ったら。
最初に説明してある。作れないはずはないって言われた。
>ドキュメント書いて、レビューやれば良いじゃん。
>だれか駄目って言ってんの？
プロマネ兼SE。
仕様書ないから、プログラム作れないって言ったら。
最初に説明してある。作れないはずはないって言われた。
368 ：デフォルトの名無しさん：03/10/08 15:34
>>365
>そして、その原因の一つが、実装者であるあなた達が、自分が強制され
>ていると感じているプロセス（アジャイル）の文献すら一切調べていない
>ことにあるでしょう。
そんなヒマありません。アジャイルプロセスでは毎日毎日地獄のような
納期に追われて、睡眠時間を削るだけです。
>そして、その原因の一つが、実装者であるあなた達が、自分が強制され
>ていると感じているプロセス（アジャイル）の文献すら一切調べていない
>ことにあるでしょう。
そんなヒマありません。アジャイルプロセスでは毎日毎日地獄のような
納期に追われて、睡眠時間を削るだけです。
369 ：デフォルトの名無しさん：03/10/08 15:51
何かさ、むちゃくちゃな調理法をしてるのに
「この飯がまずいのは素材が腐ってるからだ」
って言ってるようなものだよね
「この飯がまずいのは素材が腐ってるからだ」
って言ってるようなものだよね
370 ：デフォルトの名無しさん：03/10/08 17:15
368です。365さん、ごめんなさい。
こんなことは365さんに言うべきではないですね。せっかく親切に教えて
下さっているのに。いうべきとしたらこの方法を採用したPMになんです
けど、こうしてもらえないと開発できないと言ったらアジャイルではそう
いうやりかたはやらないと言われて、アジャイルなんてその言葉しかしら
なかったものですから、なんの反論もできず、困ってしまったのです。
それでみなさんに助けてもらって、そんなのアジャイルじゃないのに自分
の都合のいいところだけアジャイルだって言われても開発できないよって
反論したかったのです。
でも、せっかくですから、少しは勉強したいのですが、１冊だけでざっと
すぐに読めるような解説書はなにかありますでしょうか？金曜日には本屋
の開いている時間に都心に出ることができるはずなので、一冊購入してこ
ようと思います。
よろしくお願いします。
こんなことは365さんに言うべきではないですね。せっかく親切に教えて
下さっているのに。いうべきとしたらこの方法を採用したPMになんです
けど、こうしてもらえないと開発できないと言ったらアジャイルではそう
いうやりかたはやらないと言われて、アジャイルなんてその言葉しかしら
なかったものですから、なんの反論もできず、困ってしまったのです。
それでみなさんに助けてもらって、そんなのアジャイルじゃないのに自分
の都合のいいところだけアジャイルだって言われても開発できないよって
反論したかったのです。
でも、せっかくですから、少しは勉強したいのですが、１冊だけでざっと
すぐに読めるような解説書はなにかありますでしょうか？金曜日には本屋
の開いている時間に都心に出ることができるはずなので、一冊購入してこ
ようと思います。
よろしくお願いします。
>>368
>そんなヒマありません。アジャイルプロセスでは毎日毎日地獄のような
>納期に追われて、睡眠時間を削るだけです。
だから、それはアジャイルじゃないですって。
>>370
本当に本屋に行く時間もなくて、２ｃｈする時間はあるってなら、
ここで得られる情報でも十分じゃないの？
http://objectclub.esm.co.jp/eXtremeProgramming/
それよりも、
>アジャイルなんてその言葉しかしら
>なかったものですから、なんの反論もできず、困ってしまったのです。
よく知らない方法論の名前を出されただけで反論できないんじゃ、
これから先も同じ事繰り返すだけだと思うけど。
次は「Ｌｙｅｅではこうする」って言われそう。
>そんなヒマありません。アジャイルプロセスでは毎日毎日地獄のような
>納期に追われて、睡眠時間を削るだけです。
だから、それはアジャイルじゃないですって。
>>370
本当に本屋に行く時間もなくて、２ｃｈする時間はあるってなら、
ここで得られる情報でも十分じゃないの？
http://objectclub.esm.co.jp/eXtremeProgramming/
それよりも、
>アジャイルなんてその言葉しかしら
>なかったものですから、なんの反論もできず、困ってしまったのです。
よく知らない方法論の名前を出されただけで反論できないんじゃ、
これから先も同じ事繰り返すだけだと思うけど。
次は「Ｌｙｅｅではこうする」って言われそう。
372 ：デフォルトの名無しさん：03/10/08 23:16
362のプロジェクトがデスマってるのと、
用いてるプロセスがアジャイルかどうかっていう点との
因果関係が薄いような気がするんですけどね。
362のPMが仕切ったら、ウォータフォールでもデスマになると思う。
ウォータフォールで宿命的に発生する「予想外の」手戻りが原因で。
用いてるプロセスがアジャイルかどうかっていう点との
因果関係が薄いような気がするんですけどね。
362のPMが仕切ったら、ウォータフォールでもデスマになると思う。
ウォータフォールで宿命的に発生する「予想外の」手戻りが原因で。
373 ：デフォルトの名無しさん：03/10/09 00:48
>>372
>ウォータフォールで宿命的に発生する「予想外の」手戻りが原因で。
日々、変わってゆくお客さまのご要望をシステムに取り入れるため
アジャイルでないと対応してゆけないのだそうですので、
はじめからウォーターフォールは無理だそうです。
>ウォータフォールで宿命的に発生する「予想外の」手戻りが原因で。
日々、変わってゆくお客さまのご要望をシステムに取り入れるため
アジャイルでないと対応してゆけないのだそうですので、
はじめからウォーターフォールは無理だそうです。
374 ：デフォルトの名無しさん：03/10/09 00:50
>>371
>本当に本屋に行く時間もなくて、２ｃｈする時間はあるってなら、
>ここで得られる情報でも十分じゃないの？
>http://objectclub.esm.co.jp/eXtremeProgramming/
週に一回くらいは打合せのため本屋のある都心を経由するので
本屋に行く時間はあります。でもいつでもアクセスできるわけでは
ありません。
ということでご紹介いただいたサイトを見させていただきます。
>本当に本屋に行く時間もなくて、２ｃｈする時間はあるってなら、
>ここで得られる情報でも十分じゃないの？
>http://objectclub.esm.co.jp/eXtremeProgramming/
週に一回くらいは打合せのため本屋のある都心を経由するので
本屋に行く時間はあります。でもいつでもアクセスできるわけでは
ありません。
ということでご紹介いただいたサイトを見させていただきます。
375 ：デフォルトの名無しさん：03/10/09 01:02
376 ：デフォルトの名無しさん：03/10/09 01:27
>>371
＞次は「Ｌｙｅｅではこうする」って言われそう。
禿ﾜﾗﾀw
>>374
雑誌の特集なんかも手軽で良いかもしれない。このスレだと>>5
のJavaWorldのバックナンバーとか。2002年11月号か。一年も
昔のやつですまんが。ちょっと気持ち悪い煽り記事だけど、我慢して
読むととりあえず概要が掴めるし、キーワードも拾えると思う。
そんで用語、術語に少し馴染んだら、次はやはり定番のGoogleかな。
>>1とかにあるリンクでも良いし。ネットだけでもかなり情報あるよ。
そんで何となく分かった気になってきたら、好きなプロセスを選んで、
解説本なんかを買ってみるのも良いかも。
ちなみに入門用としてはXPは実は余り向いてない気がするんだがね。
やはり素人にはお勧めできないというか。どうせ中堅以上の技術者には
浮ついた流行に見えるだろうし、厨房には刺激が強過ぎるし。
まあデスマーチもいつかは終わるし、がんがれね。
# >>371氏のリンクに「設計の終焉?」ってあるけど、それ面白いよ。
＞次は「Ｌｙｅｅではこうする」って言われそう。
禿ﾜﾗﾀw
>>374
雑誌の特集なんかも手軽で良いかもしれない。このスレだと>>5
のJavaWorldのバックナンバーとか。2002年11月号か。一年も
昔のやつですまんが。ちょっと気持ち悪い煽り記事だけど、我慢して
読むととりあえず概要が掴めるし、キーワードも拾えると思う。
そんで用語、術語に少し馴染んだら、次はやはり定番のGoogleかな。
>>1とかにあるリンクでも良いし。ネットだけでもかなり情報あるよ。
そんで何となく分かった気になってきたら、好きなプロセスを選んで、
解説本なんかを買ってみるのも良いかも。
ちなみに入門用としてはXPは実は余り向いてない気がするんだがね。
やはり素人にはお勧めできないというか。どうせ中堅以上の技術者には
浮ついた流行に見えるだろうし、厨房には刺激が強過ぎるし。
まあデスマーチもいつかは終わるし、がんがれね。
# >>371氏のリンクに「設計の終焉?」ってあるけど、それ面白いよ。
377 ：デフォルトの名無しさん：03/10/09 15:26
>>360
>・動作するソフトウェア
を重視するけど
>・プロセスやツール
は重視しないってのはやっぱり嘘っぽい。
昔、友人と面白い映画はどうすれば作れる勝手言うのを
議論したことがある。色々話をした後で最後になって一人が
「そういう設定とかにこだわる必要ないんじゃないのかな。
べつにそういうことやらなくても面白い映画は面白いんだから
結局面白い映画を作ればそれが面白いんだよ」って。
確かにそれは事実だが、だからその面白い映画をどうすれば
作れるかを議論していたのだ。この結論ではどうすれば面白
映画を作れるのか結局わからないってことになる。
動作するソフトウエアを作ることが目的で、そのために有効な
プロセスやツールを探している人に対して、「プロセスやツール
は重要ではない。結局動作するソフトウエアを作ることが大切だ」
なんて言っても何の助けにもならない。
>・動作するソフトウェア
を重視するけど
>・プロセスやツール
は重視しないってのはやっぱり嘘っぽい。
昔、友人と面白い映画はどうすれば作れる勝手言うのを
議論したことがある。色々話をした後で最後になって一人が
「そういう設定とかにこだわる必要ないんじゃないのかな。
べつにそういうことやらなくても面白い映画は面白いんだから
結局面白い映画を作ればそれが面白いんだよ」って。
確かにそれは事実だが、だからその面白い映画をどうすれば
作れるかを議論していたのだ。この結論ではどうすれば面白
映画を作れるのか結局わからないってことになる。
動作するソフトウエアを作ることが目的で、そのために有効な
プロセスやツールを探している人に対して、「プロセスやツール
は重要ではない。結局動作するソフトウエアを作ることが大切だ」
なんて言っても何の助けにもならない。
378 ：デフォルトの名無しさん：03/10/09 15:37
[Agile ソフトウェア開発宣言]
我々は、自ら Agile 開発を実践するとともに、
人々が Agile 開発を実践するための支援を通じて、
より優れたソフトウェア開発方法を見つけようとしている。
この活動を通じて、我々は、
人と人同士の相互作用を、プロセスやツールよりも
動くソフトウェアを、包括的なドキュメントよりも
顧客との協力を、契約交渉よりも
変化に対応することを、計画に従うことよりも
尊重するに至った。
これは、右側にある項目の価値を認めつつも、
左側にある項目の価値をより一層重視する、ということである。
我々は、自ら Agile 開発を実践するとともに、
人々が Agile 開発を実践するための支援を通じて、
より優れたソフトウェア開発方法を見つけようとしている。
この活動を通じて、我々は、
人と人同士の相互作用を、プロセスやツールよりも
動くソフトウェアを、包括的なドキュメントよりも
顧客との協力を、契約交渉よりも
変化に対応することを、計画に従うことよりも
尊重するに至った。
これは、右側にある項目の価値を認めつつも、
左側にある項目の価値をより一層重視する、ということである。
379 ：デフォルトの名無しさん：03/10/09 18:24
380 ：デフォルトの名無しさん：03/10/09 21:14
381 ：デフォルトの名無しさん：03/10/09 22:30
>>379
agile はメタプロセスだからね
agile はメタプロセスだからね
382 ：デフォルトの名無しさん：03/10/11 00:05
>>379
優れた方法論はない。
「メリット・デメリットが異なる方法論」が
たくさんできるだけ。
あとはケースバイケース（期間・人数・関係者のスキル等）で
好きな奴を選べ。
とりあえず仲間とXPやってみましたが、
「滝モデルとは別の意味で効率悪そ～」というのが感想です。
優れた方法論はない。
「メリット・デメリットが異なる方法論」が
たくさんできるだけ。
あとはケースバイケース（期間・人数・関係者のスキル等）で
好きな奴を選べ。
とりあえず仲間とXPやってみましたが、
「滝モデルとは別の意味で効率悪そ～」というのが感想です。
383 ：デフォルトの名無しさん：03/10/11 00:37
384 ：デフォルトの名無しさん：03/10/11 12:46
UPとRUPのちがいってなんですか？（ラショナルが考えたUPとかのレベルでなく）
ゔ〲〰ゔ〲〰乜勹〰ス
386 ：デフォルトの名無しさん：03/10/11 12:49
>>384
同じものでしょ。
同じものでしょ。
387 ：デフォルトの名無しさん：03/10/11 13:13
では、スパイラル開発と反復型開発は？
388 ：デフォルトの名無しさん：03/10/11 14:59
389 ：デフォルトの名無しさん：03/10/11 20:50
で結局 382 は 383 の質問から逃げたわけ？
XPだとコードを書けない状況にされてしまう。
テストだ～。リファクタリングだ～。て感じで。
それが手戻りを楽にするためなのは
わかってるんだけど、
「どれだけ利用するかわからない傷害保険に
強制的にはいらされてる気分。」
というと心情が伝わるかな？
あとペアプロでパートナーと意見を合わせるのが
かなり大変。新人とか全然違うチームの人が
ペアだと自分の考えを説明するだけで疲れる。
なのでXPをいきなり製品開発に試しても
・たぶん失敗してRUPに変えるか
・多残業するか
どっちかなんだろーな。と思った。
テストだ～。リファクタリングだ～。て感じで。
それが手戻りを楽にするためなのは
わかってるんだけど、
「どれだけ利用するかわからない傷害保険に
強制的にはいらされてる気分。」
というと心情が伝わるかな？
あとペアプロでパートナーと意見を合わせるのが
かなり大変。新人とか全然違うチームの人が
ペアだと自分の考えを説明するだけで疲れる。
なのでXPをいきなり製品開発に試しても
・たぶん失敗してRUPに変えるか
・多残業するか
どっちかなんだろーな。と思った。
391 ：デフォルトの名無しさん：03/10/11 22:43
テストもリファクタリングもコード書きなんだがなあ。
やってみればわかるけど効果も明らかだし。
やってみればわかるけど効果も明らかだし。
滝モデルの利点は
素人にわかりやすい事
導入時の難しさで比較すると
XP＞縛りのキツイ滝＞縛りのゆる～い滝≒開発プロセスがない
今は小さいグループなのでゆる～い滝でやってるんですが
そこでいきなりXPを実践するのは難しかった
逆に「ドキュメント駆動の厳しい滝モデル」でやってる人達のほうが
XPをやりやすいと思います。
素人にわかりやすい事
導入時の難しさで比較すると
XP＞縛りのキツイ滝＞縛りのゆる～い滝≒開発プロセスがない
今は小さいグループなのでゆる～い滝でやってるんですが
そこでいきなりXPを実践するのは難しかった
逆に「ドキュメント駆動の厳しい滝モデル」でやってる人達のほうが
XPをやりやすいと思います。
393 ：デフォルトの名無しさん：03/10/11 23:10
ごめん訂正
話し合いで時間を浪費する割合が多かった
・MVCにするにはどっちのクラス構成がいいか
・テストしやすい作りはどっちかなのか
・なぜテストをするのか
・なぜリファクタリングをするのか
といった感じで毎回ペアで話あってた
話し合いで時間を浪費する割合が多かった
・MVCにするにはどっちのクラス構成がいいか
・テストしやすい作りはどっちかなのか
・なぜテストをするのか
・なぜリファクタリングをするのか
といった感じで毎回ペアで話あってた
394 ：デフォルトの名無しさん：03/10/11 23:17
それは単に新しいことをやったので、それに慣れるための時間がかかったということでは。
現状維持以外の何をやるにしてもそのコストは必要かと。
現状維持以外の何をやるにしてもそのコストは必要かと。
395 ：デフォルトの名無しさん：03/10/12 00:05
そりゃイニシャルコストは何する時にもあるし実際に382がXPだと思ってやっていたことも不慣れだから
効率の悪いテストやしなくて良いリファクタリングをしている可能性もあるわけでそれを持ってしてXPをかって
に納得して判断下されても。
382の言っているXPのデメリットには何一つ納得できる物はないよ。
せめて324位のことは言ってくれ。
効率の悪いテストやしなくて良いリファクタリングをしている可能性もあるわけでそれを持ってしてXPをかって
に納得して判断下されても。
382の言っているXPのデメリットには何一つ納得できる物はないよ。
せめて324位のことは言ってくれ。
396 ：デフォルトの名無しさん：03/10/12 12:09
ペアプロもうやだ…
397 ：デフォルトの名無しさん：03/10/12 19:22
>>390
「感じ」だとか「心情」だとか漠然としすぎて、それじゃ単なるボヤキの
域を出ないでしょう。
と言うか、どうもよく理解しないまま幾つかのプラクティスをいい加減に
適用したふりをして、XPをやった事にしただけのように読めちゃう。
「XPやりました」って言いたかっただけと違うのかと。
＞あとペアプロでパートナーと意見を合わせるのが
＞かなり大変。新人とか全然違うチームの人が
＞ペアだと自分の考えを説明するだけで疲れる。
チーム内のメンバと意見を合わせるのが大変、疲れるというのを
理由にXPが失敗するというなら、じゃあ他のプロセスなら容易なのか
（或は逆に、意識合わせを端から度外視してるのか）といった疑問
が湧く。
CommunicationはExtremeValuesの筆頭でもあるはずなのに、それが
大変だからといってペアプロ批判するのは、最初から何か意識が
ズレていると言うか、分かってないように見える。
「感じ」だとか「心情」だとか漠然としすぎて、それじゃ単なるボヤキの
域を出ないでしょう。
と言うか、どうもよく理解しないまま幾つかのプラクティスをいい加減に
適用したふりをして、XPをやった事にしただけのように読めちゃう。
「XPやりました」って言いたかっただけと違うのかと。
＞あとペアプロでパートナーと意見を合わせるのが
＞かなり大変。新人とか全然違うチームの人が
＞ペアだと自分の考えを説明するだけで疲れる。
チーム内のメンバと意見を合わせるのが大変、疲れるというのを
理由にXPが失敗するというなら、じゃあ他のプロセスなら容易なのか
（或は逆に、意識合わせを端から度外視してるのか）といった疑問
が湧く。
CommunicationはExtremeValuesの筆頭でもあるはずなのに、それが
大変だからといってペアプロ批判するのは、最初から何か意識が
ズレていると言うか、分かってないように見える。
398 ：デフォルトの名無しさん：03/10/12 19:23
(続)
＞なのでXPをいきなり製品開発に試しても
「いきなり」試そうとしてるのは>>390氏の勝手であって、XP自体とは
関係ないでしょうな。何事も実績や経験が足りない事は段階的で
控えめなアプローチが望ましいでしょう。
＞・たぶん失敗してRUPに変えるか
失敗したXPを途中でRUPに切り換えるって適切？てか、できるの？
＞・多残業するか
プロジェクト開始前に多残業って言えるのは、そういうスケジュールを
組んでいるからでは。始める前にそんな事を言う位なら、あらかじめ
その分見積もって日程を考えるべきでしょう。
それともエンドも要員も固定のプロジェクトで、XPだけが多残業を
もたらすと言ってるのかな？だとすると総工数でXPがRUPや
ウォーターフォールを上回ることになるけど、そうなの？
＞なのでXPをいきなり製品開発に試しても
「いきなり」試そうとしてるのは>>390氏の勝手であって、XP自体とは
関係ないでしょうな。何事も実績や経験が足りない事は段階的で
控えめなアプローチが望ましいでしょう。
＞・たぶん失敗してRUPに変えるか
失敗したXPを途中でRUPに切り換えるって適切？てか、できるの？
＞・多残業するか
プロジェクト開始前に多残業って言えるのは、そういうスケジュールを
組んでいるからでは。始める前にそんな事を言う位なら、あらかじめ
その分見積もって日程を考えるべきでしょう。
それともエンドも要員も固定のプロジェクトで、XPだけが多残業を
もたらすと言ってるのかな？だとすると総工数でXPがRUPや
ウォーターフォールを上回ることになるけど、そうなの？
399 ：デフォルトの名無しさん：03/10/12 19:29
>>393
どの部分への訂正か分からないけど、
＞話し合いで時間を浪費する割合が多かった
＞
＞・MVCにするにはどっちのクラス構成がいいか
＞・テストしやすい作りはどっちかなのか
こういうのを時間の浪費と言うだろうか。
ベターな設計にするためにはどのみち対話が必要だろうし、書いた本人
以外は障害発生まで誰もソースを読まないような状況を避けられるし、
むしろ必要な話し合いだと思うけど。
それとも設計書を書いてレビュー、書き直して再レビュー、承認後に
設計書をクローズしてコーディング着手、書いたらソースレビュー
といった手順の方が能率的と言いたいですか？
＞・なぜテストをするのか
＞・なぜリファクタリングをするのか
これは事前に意識合わせしておくべき事で、ペアプロ中に蒸し返す
話題ではないでしょうな。
どの部分への訂正か分からないけど、
＞話し合いで時間を浪費する割合が多かった
＞
＞・MVCにするにはどっちのクラス構成がいいか
＞・テストしやすい作りはどっちかなのか
こういうのを時間の浪費と言うだろうか。
ベターな設計にするためにはどのみち対話が必要だろうし、書いた本人
以外は障害発生まで誰もソースを読まないような状況を避けられるし、
むしろ必要な話し合いだと思うけど。
それとも設計書を書いてレビュー、書き直して再レビュー、承認後に
設計書をクローズしてコーディング着手、書いたらソースレビュー
といった手順の方が能率的と言いたいですか？
＞・なぜテストをするのか
＞・なぜリファクタリングをするのか
これは事前に意識合わせしておくべき事で、ペアプロ中に蒸し返す
話題ではないでしょうな。
400 ：デフォルトの名無しさん：03/10/12 19:36
>>390
思うようにコードかけないのはまだ自分の設計能力やコーディング力が足りないから。
また、ペアプロが大変なのはしょうがない。あれは疲れる。
ただしペアを組んで同時にコードを記述することによる利点（品質、教育など）は長期的に見てプロジェクトに貢献することは間違いない。
あと話は変わるが、ペアプロの利点で品質の向上をあげる人が多いけれども、プロジェクトの人員の入れ替わりに対応する
リスクヘッジみたいなところがマネジメント的にはもっと重要な利点だと思う。
連続徹夜で一人や二人が氏んでもプロジェクトが続行できるから。
思うようにコードかけないのはまだ自分の設計能力やコーディング力が足りないから。
また、ペアプロが大変なのはしょうがない。あれは疲れる。
ただしペアを組んで同時にコードを記述することによる利点（品質、教育など）は長期的に見てプロジェクトに貢献することは間違いない。
あと話は変わるが、ペアプロの利点で品質の向上をあげる人が多いけれども、プロジェクトの人員の入れ替わりに対応する
リスクヘッジみたいなところがマネジメント的にはもっと重要な利点だと思う。
連続徹夜で一人や二人が氏んでもプロジェクトが続行できるから。
401 ：デフォルトの名無しさん：03/10/13 19:54
実際にXPの壁となるのは「契約」と「環境」
中小企業にはツラい。
中小企業にはツラい。
402 ：デフォルトの名無しさん：03/10/14 03:40
XPの実践に不可欠なものがあると感じている。それはカリスマプログラマだ。
それもプログラマから見たカリスマではなくて、顧客から見たカリスマね。
要するに、Kentあたりだから契約だ環境だ何だというようなことも、顧客が
言うことを聞いてくれるような気がする。根本的に彼らはXP以前から比較的
良質な顧客を捕まえてこれる状態にあったことが大きいのではないかと
思うんだよな。これをカリスマ不在のところがやろうとしたら、会社の看板か
体力が必要ということになる気がする。ところがそういう会社は組織の弊害に
囚われていてXPの導入なんて無理ってことになるんだろう。
何というか、XP導入以前にプログラマとしてすごい連中の集まりにならないと
いかんというニワトリタマゴな話になってしまう気がしているんだよな・・。
それもプログラマから見たカリスマではなくて、顧客から見たカリスマね。
要するに、Kentあたりだから契約だ環境だ何だというようなことも、顧客が
言うことを聞いてくれるような気がする。根本的に彼らはXP以前から比較的
良質な顧客を捕まえてこれる状態にあったことが大きいのではないかと
思うんだよな。これをカリスマ不在のところがやろうとしたら、会社の看板か
体力が必要ということになる気がする。ところがそういう会社は組織の弊害に
囚われていてXPの導入なんて無理ってことになるんだろう。
何というか、XP導入以前にプログラマとしてすごい連中の集まりにならないと
いかんというニワトリタマゴな話になってしまう気がしているんだよな・・。
403 ：デフォルトの名無しさん：03/10/14 21:42
有名じゃないけどちゃんとXPやってる人知ってるよ？
心配する気持ちも分かるけど、そんなことないと思う。
職業人として信頼できる人間なら、別にカリスマ性は要らないでしょ。
心配する気持ちも分かるけど、そんなことないと思う。
職業人として信頼できる人間なら、別にカリスマ性は要らないでしょ。
404 ：デフォルトの名無しさん：03/10/14 23:56
>>403
402はおそらくネタでしょ。
しかし、XPの契約はなかなか難しいのも事実。
そのXPをやっている人はかなり特殊だとおもう。
「信頼」を会社の大きさで見るところが多いからね。
あと、顧客としては勘定がすぐに出ない契約は稟議が通りにくいという面があるから嫌がられる。
環境の方はまぁどうにもならないだろうね。
会社の上の人間や会社・部署の体質が全てを決めてしまうから。
入札が複数あったりする場合、営業は無理なスケジューリングで無理矢理取ろうとしたり
人員配分が無茶苦茶だったり、ISOでドキュメント死ぬほど書くような決め事がしてあったり・・・
そこまで酷くなくても大小なにかと問題があって実践が難しい。
日本という土壌にどうも微妙にかみ合わない。
出来るところだけ切り取って使うのがうまいXPの活用法かも。
とりあえず、上記に左右されないテストとリファクタリングから入っていくしかないね。
402はおそらくネタでしょ。
しかし、XPの契約はなかなか難しいのも事実。
そのXPをやっている人はかなり特殊だとおもう。
「信頼」を会社の大きさで見るところが多いからね。
あと、顧客としては勘定がすぐに出ない契約は稟議が通りにくいという面があるから嫌がられる。
環境の方はまぁどうにもならないだろうね。
会社の上の人間や会社・部署の体質が全てを決めてしまうから。
入札が複数あったりする場合、営業は無理なスケジューリングで無理矢理取ろうとしたり
人員配分が無茶苦茶だったり、ISOでドキュメント死ぬほど書くような決め事がしてあったり・・・
そこまで酷くなくても大小なにかと問題があって実践が難しい。
日本という土壌にどうも微妙にかみ合わない。
出来るところだけ切り取って使うのがうまいXPの活用法かも。
とりあえず、上記に左右されないテストとリファクタリングから入っていくしかないね。
405 ：デフォルトの名無しさん：03/10/15 06:38
XPはデスマーチの入り口
406 ：デフォルトの名無しさん：03/10/15 10:38
ウォータフォールや非オブジェクト指向開発と比べればデスマーチに遭遇する確率、
デスマーチタイムにかかっている期間も短い。
デスマーチタイムにかかっている期間も短い。
407 ：デフォルトの名無しさん：03/10/15 21:05
＞連続徹夜で一人や二人が氏んでもプロジェクトが続行できるから。
連続徹夜でペアプロって･･･、おっそろしいなあ。
例えば、思った通りの進捗が無くて焦った初心者XPチームが、
XPが重荷になってきて「仕方なく」何かのプラクティスを反古に
するとしたら、たぶんSustainablePace辺りが最初に捨てられそう。
そうなってくると泊り込みでペアプロとかあり得るわけか･･･
死なないまでも、各メンバの疲弊した脳内に予期せぬ感情が芽生え
たりはするかもな。
連続徹夜でペアプロって･･･、おっそろしいなあ。
例えば、思った通りの進捗が無くて焦った初心者XPチームが、
XPが重荷になってきて「仕方なく」何かのプラクティスを反古に
するとしたら、たぶんSustainablePace辺りが最初に捨てられそう。
そうなってくると泊り込みでペアプロとかあり得るわけか･･･
死なないまでも、各メンバの疲弊した脳内に予期せぬ感情が芽生え
たりはするかもな。
408 ：デフォルトの名無しさん：03/10/15 22:15
409 ：デフォルトの名無しさん：03/10/18 11:27
会社でXPかRUPの開発方法試したいんだけど、みんな知らないか本で勉強中って程度
なんです。
皆さんどういう風に会社（またはチーム）に開発方法を浸透させていくんですか？
なんです。
皆さんどういう風に会社（またはチーム）に開発方法を浸透させていくんですか？
410 ：デフォルトの名無しさん：03/10/18 13:42
無理矢理型に嵌めるしかないだろう
411 ：デフォルトの名無しさん：03/10/18 14:00
何を始めるにもトップに立って先導する人間がいない限りダメ。
新しいプロセスを持ち込みたいならキミが勉強してある程度理解してから引っ張っていけ。
そういう立場にいないならそういう立場の人間を説得しろ。
新しいプロセスを持ち込みたいならキミが勉強してある程度理解してから引っ張っていけ。
そういう立場にいないならそういう立場の人間を説得しろ。
412 ：デフォルトの名無しさん：03/10/18 21:57
とりあえず409は
ピアソンのXPシリーズを全巻熟読しろ
話はそれからだ。
ピアソンのXPシリーズを全巻熟読しろ
話はそれからだ。
413 ：デフォルトの名無しさん：03/10/19 01:26
>>409
XPとかRUPって正反対のように見えて、high-disciplineって事と
iterative and incrementalって事の二つの大きな共通点があるね。
high-disciplineは何とかなるかもしれないけど、I&Iはどうだろう？
まだまだiterativeどころかincrementalですらない案件も多いだろうしさ。
当たり前だけど、開発部隊の外部、特に顧客関係のマネージメントや
契約形態について権限をもってる人達との協調は必須でしょう。
契約以前の段階で、見積書とか作業計画表とかがウォータフォール
前提になってる場合、後から反復型にすると話が違うって事になるしさ。
とりあえず営業担当者に、ウォーターフォール型のプロセスが唯一の
選択肢って訳じゃない事を認知してもらうのが最初だろうね。
話はそれからかな。
XPとかRUPって正反対のように見えて、high-disciplineって事と
iterative and incrementalって事の二つの大きな共通点があるね。
high-disciplineは何とかなるかもしれないけど、I&Iはどうだろう？
まだまだiterativeどころかincrementalですらない案件も多いだろうしさ。
当たり前だけど、開発部隊の外部、特に顧客関係のマネージメントや
契約形態について権限をもってる人達との協調は必須でしょう。
契約以前の段階で、見積書とか作業計画表とかがウォータフォール
前提になってる場合、後から反復型にすると話が違うって事になるしさ。
とりあえず営業担当者に、ウォーターフォール型のプロセスが唯一の
選択肢って訳じゃない事を認知してもらうのが最初だろうね。
話はそれからかな。
414 ：デフォルトの名無しさん：03/10/19 06:17
>>414
確かに顧客の理解なしにやるのはSE失格だね。
確かに顧客の理解なしにやるのはSE失格だね。
415 ：デフォルトの名無しさん：03/10/19 06:47
●●●マスコミの 「盗聴／盗撮」 は許されるの？その６●●● http://natto.2ch.net/mass/kako/1000/10003/1000393251.html
783 名前： 郵便屋 投稿日： 01/10/12 07:22 ID:eqc3p.xc
>だからさー、ドラマや小説のネタにして誰にどういうメリットがあるの？
メリットがあるかないか、というより、嫌がらせや脅しが目的だろ。
嫉妬や妬みのようなくだらない理由で嫌がらせする人っていっぱいいるよ。
普通はありえないと思うだろうけど。
変な不祥事が連発しておこることが事件に取り上げられてるけど。
世の中くだらない個人的感情で仕事をする馬鹿な人がいっぱい、いるんだろうと思う。
969 名前： 文責：名無しさん 投稿日： 01/11/04 13:30 ID:nZuvB+Z1
>>951
関係者というのは、盗聴された私と親しい間柄にある人や、知人のことです。
たとえば家族とか、電話で話した人、家で話題にした人、友人等です。
家族が知人と電話で話した内容がネタになった事があったり、知人の名前が
ドラマに使われたりします。
970 名前： 967 投稿日： 01/11/04 13:52 ID:v3mAO06V
>>969
あるね。最低だな。最近じゃ不治てれびとか。業界内の遊び感覚でやってると思うね。
783 名前： 郵便屋 投稿日： 01/10/12 07:22 ID:eqc3p.xc
>だからさー、ドラマや小説のネタにして誰にどういうメリットがあるの？
メリットがあるかないか、というより、嫌がらせや脅しが目的だろ。
嫉妬や妬みのようなくだらない理由で嫌がらせする人っていっぱいいるよ。
普通はありえないと思うだろうけど。
変な不祥事が連発しておこることが事件に取り上げられてるけど。
世の中くだらない個人的感情で仕事をする馬鹿な人がいっぱい、いるんだろうと思う。
969 名前： 文責：名無しさん 投稿日： 01/11/04 13:30 ID:nZuvB+Z1
>>951
関係者というのは、盗聴された私と親しい間柄にある人や、知人のことです。
たとえば家族とか、電話で話した人、家で話題にした人、友人等です。
家族が知人と電話で話した内容がネタになった事があったり、知人の名前が
ドラマに使われたりします。
970 名前： 967 投稿日： 01/11/04 13:52 ID:v3mAO06V
>>969
あるね。最低だな。最近じゃ不治てれびとか。業界内の遊び感覚でやってると思うね。
416 ：デフォルトの名無しさん：03/10/19 06:51
>>412
ﾋﾟｱｿﾝshineﾊｹｰﾝ
ﾋﾟｱｿﾝshineﾊｹｰﾝ
417 ：デフォルトの名無しさん：03/10/19 06:56
418 ：デフォルトの名無しさん：03/10/19 20:39
Fine scale feedback
1. TestDrivenDevelopment
2. PlanningGame
3. WholeTeam
4. PairProgramming
Continuous process rather than batch
5. ContinuousIntegration
6. DesignImprovement
7. SmallReleases
Shared understanding
8. SimpleDesign
9. SystemMetaphor
10. CollectiveCodeOwnership
11. CodingStandard
Programmer welfare
12. SustainablePace
1. TestDrivenDevelopment
2. PlanningGame
3. WholeTeam
4. PairProgramming
Continuous process rather than batch
5. ContinuousIntegration
6. DesignImprovement
7. SmallReleases
Shared understanding
8. SimpleDesign
9. SystemMetaphor
10. CollectiveCodeOwnership
11. CodingStandard
Programmer welfare
12. SustainablePace
419 ：デフォルトの名無しさん：03/10/20 22:19
板違いすれ違いだったらごめんなさい
よく「人月で計算するのはよくない」とききますが、ではどういう風に見積もるんですか？
よく「人月で計算するのはよくない」とききますが、ではどういう風に見積もるんですか？
420 ：デフォルトの名無しさん：03/10/20 22:22
匹月
421 ：デフォルトの名無しさん：03/10/20 22:50
>>420
ありがとうございます。ちなみに「匹」は犬でしょうか？
ありがとうございます。ちなみに「匹」は犬でしょうか？
422 ：デフォルトの名無しさん：03/10/20 23:37
423 ：デフォルトの名無しさん：03/10/21 01:18
Function Point
424 ：デフォルトの名無しさん：03/10/21 03:34
おまえら、工数の見積もり技術ないのかよ...。
人に頼るな。
あとプロセスの設計というのも忘れるな。
だからレビューが大事なんだぞ。
人に頼るな。
あとプロセスの設計というのも忘れるな。
だからレビューが大事なんだぞ。
425 ：デフォルトの名無しさん：03/10/21 07:47
>>424
どうやって勉強するの？良い本でもあればしえてくれよ
どうやって勉強するの？良い本でもあればしえてくれよ
426 ：デフォルトの名無しさん：03/10/21 10:15
>>419
人月で表すのは別に悪くないが、人月は足し算できないから計算できない。
例えば、1人月の作業と、2人月の作業を合わせても3人月になるかどうかは
それぞれの作業の内容と｢人」を誰にするかによる。
逆に言えば、1人月＋2人月＝3人月になるように作業を分割して人を割り振って
いれば、人月で計算しても構わない。
人月で表すのは別に悪くないが、人月は足し算できないから計算できない。
例えば、1人月の作業と、2人月の作業を合わせても3人月になるかどうかは
それぞれの作業の内容と｢人」を誰にするかによる。
逆に言えば、1人月＋2人月＝3人月になるように作業を分割して人を割り振って
いれば、人月で計算しても構わない。
427 ：デフォルトの名無しさん：03/10/21 11:25
Function Pointは実際有効なのかな
428 ：デフォルトの名無しさん：03/10/21 12:49
429 ：デフォルトの名無しさん：03/10/21 12:51
因みに、開発／研究／未踏案件と製造案件は別にして考えてくれ。
ファンクションポイントもいいけどユースケースからでも算出できるだろ。
精度良くやれば。
ファンクションポイントもいいけどユースケースからでも算出できるだろ。
精度良くやれば。
430 ：デフォルトの名無しさん：03/10/21 17:27
>>428
勉強はいるだろ。
とりあえずFPの本でもよめば？
あとは、データを蓄えて、予測。
精度が高いデータである必要はない。
精度が高いデータをとるのは工数がかかるからな。
必要な精度で。
という意味では428の精度が「良い」という表現がいいな。
勉強はいるだろ。
とりあえずFPの本でもよめば？
あとは、データを蓄えて、予測。
精度が高いデータである必要はない。
精度が高いデータをとるのは工数がかかるからな。
必要な精度で。
という意味では428の精度が「良い」という表現がいいな。
431 ：デフォルトの名無しさん：03/10/21 17:27
432 ：デフォルトの名無しさん：03/10/21 19:54
人月以外の単位か・・・
予想総成果物の文字数なんかが、客観的で良さげだな。
あと文字数から打鍵数を割り出して、キーダウン一回の
平均エネルギーを掛けたら、ジュールとか使えちゃうな。
うわ、なんか我ながら凄え科学的。
ｶｺｲｲ、俺。
予想総成果物の文字数なんかが、客観的で良さげだな。
あと文字数から打鍵数を割り出して、キーダウン一回の
平均エネルギーを掛けたら、ジュールとか使えちゃうな。
うわ、なんか我ながら凄え科学的。
ｶｺｲｲ、俺。
433 ：デフォルトの名無しさん：03/10/22 00:54
さりげなく答えたつもりが誰も反応してくれない可哀想な>>423
434 ：デフォルトの名無しさん：03/10/22 09:31
ファンクションポイントについて素人向けに簡潔に説明してくれ
435 ：デフォルトの名無しさん：03/10/22 18:20
>>434
機能ごとにポイントをつけて、その合計で見積もる方法。
参照系は3ポイントで5画面=15ポイント
更新系は10ポイントで3画面=30ポイント
あわせて45ポイントで、1ポイント10万円として450万円とか見積もる。
機能ごとにポイントをつけて、その合計で見積もる方法。
参照系は3ポイントで5画面=15ポイント
更新系は10ポイントで3画面=30ポイント
あわせて45ポイントで、1ポイント10万円として450万円とか見積もる。
436 ：デフォルトの名無しさん：03/10/22 21:17
437 ：デフォルトの名無しさん：03/10/22 21:23
>>435
人月と本質的にどう違うのか、よく分からない。
尺貫法とメートル法みたいに、単位だけの違い？
てかそもそも、あまり変わらないって事の説明なんだろうか。
あと、そのポイントって四則演算が適用できるのかな。
人月と本質的にどう違うのか、よく分からない。
尺貫法とメートル法みたいに、単位だけの違い？
てかそもそも、あまり変わらないって事の説明なんだろうか。
あと、そのポイントって四則演算が適用できるのかな。
438 ：デフォルトの名無しさん：03/10/22 21:28
439 ：435：03/10/22 22:32
>>436
ぼり杉かどうかは、作るものによって違うでしょ。
1ポイントがいくらになっても構わない。
画面がどういう単位かもわからないわけだし。
>>437
線形かってこと？
過去のデータに近い規模であれば線形とみなせる、ってことじゃないのかな。
どんな見積もり方法も、過去のデータと近い内容・規模であることが前提だと思う。
人月は単位であって、方法論ではないからね。
ぼり杉かどうかは、作るものによって違うでしょ。
1ポイントがいくらになっても構わない。
画面がどういう単位かもわからないわけだし。
>>437
線形かってこと？
過去のデータに近い規模であれば線形とみなせる、ってことじゃないのかな。
どんな見積もり方法も、過去のデータと近い内容・規模であることが前提だと思う。
人月は単位であって、方法論ではないからね。
440 ：デフォルトの名無しさん：03/10/22 22:37
どっちにせよ経験則から適当に出すだけで、根拠は頭の中にしかないけれど、
数値や式があるとそれっぽく見えて読んだ方もなんとなく納得できるってことかと。
数値や式があるとそれっぽく見えて読んだ方もなんとなく納得できるってことかと。
441 ：デフォルトの名無しさん：03/10/22 23:24
>>435
帳票系は何ポイント？
帳票系は何ポイント？
442 ：デフォルトの名無しさん：03/10/23 00:09
>>439
＞線形かってこと？
ポイントと人月が、係数一個で交換可能な単なる比例なら、あるファンクションを
評価するのに最初から人月を単位としても結局同じだろうと思った。つまり
>>419（俺じゃないけど）の問いには、「FP法を使うなら人月でもOK」って言えると。
ただ、ちょっとググってみたら、言語にも環境にも依存しないって謳ってる
のが分かった。そもそも抽象度が違うって事で自己解決したよ。
＞線形かってこと？
ポイントと人月が、係数一個で交換可能な単なる比例なら、あるファンクションを
評価するのに最初から人月を単位としても結局同じだろうと思った。つまり
>>419（俺じゃないけど）の問いには、「FP法を使うなら人月でもOK」って言えると。
ただ、ちょっとググってみたら、言語にも環境にも依存しないって謳ってる
のが分かった。そもそも抽象度が違うって事で自己解決したよ。
443 ：デフォルトの名無しさん：03/10/23 00:19
見つけたんで、ついでに貼っとくか。
『Dr.ユースケースの “ユースケース人生相談”
ファンクションポイントとユースケースには
どんな関係があるんですか？ 』
http://www.atmarkit.co.jp/fjava/devs/redge10/redge10.html
タイトルはふざけてるけど、中身はまとも。てか、やや難解。
『Dr.ユースケースの “ユースケース人生相談”
ファンクションポイントとユースケースには
どんな関係があるんですか？ 』
http://www.atmarkit.co.jp/fjava/devs/redge10/redge10.html
タイトルはふざけてるけど、中身はまとも。てか、やや難解。
444 ：435：03/10/23 10:24
計算結果が人月になるのはかまわないが、人月で計算するのはよくない。
445 ：435：03/10/23 10:25
ひさしぶりにFPの本手に取ったけど、直接的には見積もりの方法ではなくて、機能性の計測のための方法論のようだ。
446 ：デフォルトの名無しさん：03/10/23 11:24
>>444
御意。
人月の扱いの難しいところは、一旦人月に換算したら、
その人月を逆に変換してはいけないところでしょう。
人月の単位に落とした時点で、対象の複雑性や依存性等の
情報が抜け落ちてしまうから。
まあ、そういう情報を抜いて、単純に表せるのが人月の良い所
なんだけど。
御意。
人月の扱いの難しいところは、一旦人月に換算したら、
その人月を逆に変換してはいけないところでしょう。
人月の単位に落とした時点で、対象の複雑性や依存性等の
情報が抜け落ちてしまうから。
まあ、そういう情報を抜いて、単純に表せるのが人月の良い所
なんだけど。
447 ：435：03/10/23 12:05
>>446
結局人月というのは、金額の単位なんだよね。
結局人月というのは、金額の単位なんだよね。
448 ：デフォルトの名無しさん：03/10/23 16:45
ユースケース・サンタマリア
449 ：デフォルトの名無しさん：03/10/24 00:39
>>448
ｽﾘｰｱﾐｰｺﾞ!
ｽﾘｰｱﾐｰｺﾞ!
450 ：デフォルトの名無しさん：03/10/24 09:48
面白おかしい
451 ：デフォルトの名無しさん：03/10/25 13:27
開発プロセスつながりで、
ICONIXっていうのはどうでしょうか？
RUPとXPの間で、実は一番現実的じゃないかと思うのだが。
ICONIXっていうのはどうでしょうか？
RUPとXPの間で、実は一番現実的じゃないかと思うのだが。
452 ：デフォルトの名無しさん：03/10/25 23:06
>>451
『Applying Use Case Driven Object Modeling with UML』って本で
前提にしてるプロセスがICONIXだった。プロセスの勉強じゃなく、
ユースケース上手くなりたくて使ってた参考書なんだけど。
現実性云々を考えると課題はやはり、ICONIXもi&iを前提としてる辺り
じゃないかな。ICONIXを現実的と言うには、まず初めに反復型開発に
ついて現実的と言えてなきゃならないでしょう。（既にRUPなんかで
成功してる所が軽量化のために、って話なら問題無いだろうけどさ。）
ただこのウォータフォールの拘束だけクリアしちゃうと、導入し易い
部類には見える。ユースケースとかooa-d-pとかの一般的な技術が
まあまあ不自由無いレベルに達してさえいれば、プロセス固有の
ジャーゴンとかドグマとか少なくて、習得コストも抑えられそうだし。
敷居の低さも、開発プロセスの重要なファクターだと思う秋の夜長。
『Applying Use Case Driven Object Modeling with UML』って本で
前提にしてるプロセスがICONIXだった。プロセスの勉強じゃなく、
ユースケース上手くなりたくて使ってた参考書なんだけど。
現実性云々を考えると課題はやはり、ICONIXもi&iを前提としてる辺り
じゃないかな。ICONIXを現実的と言うには、まず初めに反復型開発に
ついて現実的と言えてなきゃならないでしょう。（既にRUPなんかで
成功してる所が軽量化のために、って話なら問題無いだろうけどさ。）
ただこのウォータフォールの拘束だけクリアしちゃうと、導入し易い
部類には見える。ユースケースとかooa-d-pとかの一般的な技術が
まあまあ不自由無いレベルに達してさえいれば、プロセス固有の
ジャーゴンとかドグマとか少なくて、習得コストも抑えられそうだし。
敷居の低さも、開発プロセスの重要なファクターだと思う秋の夜長。
453 ：デフォルトの名無しさん：03/10/30 02:52
コレ読んだ人居る？
長瀬 嘉秀 訳だから躊躇しているんだが。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894717115/ref=ase_xpjp-22/249-6525190-2768302
長瀬 嘉秀 訳だから躊躇しているんだが。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894717115/ref=ase_xpjp-22/249-6525190-2768302
454 ：デフォルトの名無しさん：03/10/30 10:32
455 ：デフォルトの名無しさん：03/10/30 17:27
テクノロジックアートは原著を読む大切さを啓蒙していると思われ
456 ：デフォルトの名無しさん：03/10/30 18:49
技術書を原書で読むメリット
http://d.hatena.ne.jp/neverbird/20031027#p1
http://d.hatena.ne.jp/neverbird/20031027#p1
457 ：デフォルトの名無しさん：03/10/30 23:46
紙の本はもちろんだけど、翻訳に頼る人ってやはりネット上のリソースも
活用できてないんだろうか。むしろ、その方がもったいないな。
活用できてないんだろうか。むしろ、その方がもったいないな。
458 ：デフォルトの名無しさん：03/10/30 23:56
原著は高い場合があるんだよね。
More Effective C++を買おうと思ったが、Amazonだと4910円もする。
訳書だと3800円…
More Effective C++を買おうと思ったが、Amazonだと4910円もする。
訳書だと3800円…
459 ：デフォルトの名無しさん：03/10/31 00:42
>>454
変じゃないなら購入してみるよ。
速く翻訳されないかと待っていたし。
たしかに英語読めると情報量が全然違うだろうなぁ
だが今じゃなかなか勉強する機会も時間も取れなくて。
学生のうちに勉強しておけば良かった・・・
変じゃないなら購入してみるよ。
速く翻訳されないかと待っていたし。
たしかに英語読めると情報量が全然違うだろうなぁ
だが今じゃなかなか勉強する機会も時間も取れなくて。
学生のうちに勉強しておけば良かった・・・
460 ：デフォルトの名無しさん：03/10/31 12:29
461 ：デフォルトの名無しさん：03/10/31 12:42
More Effective C++ の原著って、amazon.comで$44.99もするのか
462 ：デフォルトの名無しさん：03/11/03 01:57
>>413
なし崩し型もあるよ、、、たぶん。
ユーザー（営業）に早いとこプロトタイプをわたす。すると向こうから変更の希望が
「必ず」でてくるので以下 iterative に進行させる、と。進捗の情報が頻繁に届く
状態で、しかも希望を次々と聞いてくれる（ような気がする）となれば気分を悪くする
ユーザーはほとんどいない。といいなあ。
逆につんぼ状態で納期が来ていきなりまだできてません、とかいうのが一番怒る
のは確実だが。
ただし、よくわからないので出来上がったものを黙って受け取るような楽な顧客が
うるさくいろいろ言い出すという副作用はありそう。
なし崩し型もあるよ、、、たぶん。
ユーザー（営業）に早いとこプロトタイプをわたす。すると向こうから変更の希望が
「必ず」でてくるので以下 iterative に進行させる、と。進捗の情報が頻繁に届く
状態で、しかも希望を次々と聞いてくれる（ような気がする）となれば気分を悪くする
ユーザーはほとんどいない。といいなあ。
逆につんぼ状態で納期が来ていきなりまだできてません、とかいうのが一番怒る
のは確実だが。
ただし、よくわからないので出来上がったものを黙って受け取るような楽な顧客が
うるさくいろいろ言い出すという副作用はありそう。
463 ：デフォルトの名無しさん：03/11/03 06:45
>>462
そんなプロジェクト管理できるわけないだろ。
そんなプロジェクト管理できるわけないだろ。
464 ：デフォルトの名無しさん：03/11/03 11:31
>>463
朝釣りごくろうさまです。m(__)m
朝釣りごくろうさまです。m(__)m
465 ：デフォルトの名無しさん：03/11/03 13:30
>>462
客からの要望が出る量・速度
が
それを実装して見せるための実装量・速度
より大きい場合は全然対応してくれないし完成度も低い。
納期に仕様を満たしているものも出せない。
と客の不満全開で最悪の結果となる。
客からの要望が出る量・速度
が
それを実装して見せるための実装量・速度
より大きい場合は全然対応してくれないし完成度も低い。
納期に仕様を満たしているものも出せない。
と客の不満全開で最悪の結果となる。
466 ：デフォルトの名無しさん：03/11/03 15:04
>>465
ひかえめに言って、おまえは「氏ね」
ひかえめに言って、おまえは「氏ね」
467 ：デフォルトの名無しさん：03/11/03 22:20
468 ：デフォルトの名無しさん：03/11/04 00:31
>>465
そうならないように、「計画ゲーム」で主導権をとれる準備しないとねー。世の中楽じゃない。
そうならないように、「計画ゲーム」で主導権をとれる準備しないとねー。世の中楽じゃない。
469 ：デフォルトの名無しさん：03/11/05 08:44
手っ取り早く、かつ要所はしっかり押さえてる繰り返し型開発プロセスの本
てないですか？
アジャイル、UP問いませんが、1冊でまとまってほしい。
てないですか？
アジャイル、UP問いませんが、1冊でまとまってほしい。
470 ：デフォルトの名無しさん：03/11/05 09:01
>>469 XP本の緑、紅、紫 あたりがおすすめ
471 ：デフォルトの名無しさん：03/11/05 21:53
『Agile and Iterative Development』
http://www.amazon.co.jp/exec/obidos/ASIN/0131111558/250-6971824-9058617
http://www.amazon.co.jp/exec/obidos/ASIN/0131111558/250-6971824-9058617
472 ：デフォルトの名無しさん：03/11/05 22:45
XPのペアプロって１日中やるんですか？
たまには１人で勉強しながら
コーディングもやりたいんですが
ひょっとしてペアプロする人は
勉強する必要のない達人ばっかなんでしょうか
たまには１人で勉強しながら
コーディングもやりたいんですが
ひょっとしてペアプロする人は
勉強する必要のない達人ばっかなんでしょうか
473 ：デフォルトの名無しさん：03/11/05 22:53
>>472
二人で勉強するんでは(笑)
二人で勉強するんでは(笑)
474 ：デフォルトの名無しさん：03/11/05 23:02
お勉強は家とか学校でやってくれ。邪魔。
475 ：デフォルトの名無しさん：03/11/05 23:20
476 ：デフォルトの名無しさん：03/11/05 23:27
>>475
うちはやってますが。
うちはやってますが。
477 ：デフォルトの名無しさん：03/11/05 23:28
478 ：デフォルトの名無しさん：03/11/05 23:44
>>477
うちではやってるって。
うちではやってるって。
479 ：デフォルトの名無しさん：03/11/05 23:53
480 ：デフォルトの名無しさん：03/11/05 23:58
481 ：デフォルトの名無しさん：03/11/05 23:58
477=479か？
最近馬鹿ばかりでホント疲れるニャー。
最近馬鹿ばかりでホント疲れるニャー。
482 ：デフォルトの名無しさん：03/11/05 23:59
>>480
違うよ。規定で社名は出せないが。
違うよ。規定で社名は出せないが。
483 ：デフォルトの名無しさん：03/11/06 00:23
484 ：デフォルトの名無しさん：03/11/06 00:27
485 ：デフォルトの名無しさん：03/11/06 00:27
>>481
仕事の規模、リリース間隔、ストーリーの単位も教えて頂けると嬉しい。
仕事の規模、リリース間隔、ストーリーの単位も教えて頂けると嬉しい。
486 ：デフォルトの名無しさん：03/11/06 00:27
なんだ口だけか。
487 ：デフォルトの名無しさん：03/11/06 00:29
やっている、やっているっての一点張りで口調も厨くさく具体例は何一つ無し。
あほくさ。
あほくさ。
488 ：デフォルトの名無しさん：03/11/06 00:29
どっかのスレにも書いたが、ほんと君たち（？）論理的思考訓練をしたほうがいいよ。
489 ：デフォルトの名無しさん：03/11/06 00:30
馬鹿はスルーの方向で
490 ：デフォルトの名無しさん：03/11/06 00:35
491 ：デフォルトの名無しさん：03/11/06 00:36
484がXPと思ってやっているのは実は全然XPじゃ無いに2000ﾍﾞｯｸ
492 ：デフォルトの名無しさん：03/11/06 00:39
493 ：デフォルトの名無しさん：03/11/06 00:42
ペアプロをけなす人は
何を理由にしているんでしょう？
過去スレ読んだけど
いまいちわかりませんでした
風習にあわないから？
馬鹿・新人に足引っ張られたから？
何を理由にしているんでしょう？
過去スレ読んだけど
いまいちわかりませんでした
風習にあわないから？
馬鹿・新人に足引っ張られたから？
494 ：デフォルトの名無しさん：03/11/06 00:49
>>493
実践しやすく失敗しやすいから。
実践しやすく失敗しやすいから。
495 ：デフォルトの名無しさん：03/11/06 01:14
>>493
貶すと言うより環境が出来てない場合が多い。
日本のオフィス環境でXPの求めるオープンな環境が作りにくかったりする。
XP白本にあるような速い結合マシンが部屋の中央にあって机に区切りはなく広々とした自由に動ける
そんな環境は作れるところが少ない。
あとは開発人数の兼ね合いもある。
少人数で回している零細企業だとペアプロやってられない場合がある。
仕事を掛け持ちしている場合など無理でしょ。
それとこれはちょっと個人的意見なのでアレだけどやっぱプログラマは偏屈なヤツが多いでしょ。
協調性も欠けているし、幼稚だったり、酷いのになると三日くらい風呂に入らないﾔﾂもいる。
そんなﾔﾂと密着して仕事したくないよｗ
まぁ、出来る環境になったらやるけどね。
貶すと言うより環境が出来てない場合が多い。
日本のオフィス環境でXPの求めるオープンな環境が作りにくかったりする。
XP白本にあるような速い結合マシンが部屋の中央にあって机に区切りはなく広々とした自由に動ける
そんな環境は作れるところが少ない。
あとは開発人数の兼ね合いもある。
少人数で回している零細企業だとペアプロやってられない場合がある。
仕事を掛け持ちしている場合など無理でしょ。
それとこれはちょっと個人的意見なのでアレだけどやっぱプログラマは偏屈なヤツが多いでしょ。
協調性も欠けているし、幼稚だったり、酷いのになると三日くらい風呂に入らないﾔﾂもいる。
そんなﾔﾂと密着して仕事したくないよｗ
まぁ、出来る環境になったらやるけどね。
496 ：デフォルトの名無しさん：03/11/06 05:19
perlベースのプログラム開発でもXPは適用できますか？
どの辺が問題になりそうでしょうか？
テスティングフレームワークは一応存在するみたいですが...。
どの辺が問題になりそうでしょうか？
テスティングフレームワークは一応存在するみたいですが...。
497 ：デフォルトの名無しさん：03/11/06 06:48
>>496
悪いコードを書かれやすい故に、OOに詳しいコーチが他の言語より重要な役割を果たすだろう
プログラマのモチベーションを維持するのが難しいだろう。
将来性の無い、キャリアにならない言語で書くプロジェクトは、プログラマの動機付けをうまくやるマネージャが必要になる。
リファクタリングにかかるコストを他の言語より多く時間をとる必要があるだろう
命名規則の統一に他の言語に比べたら苦労するだろう
--
言語という観点からすると、こんなところだと思います。
悪いコードを書かれやすい故に、OOに詳しいコーチが他の言語より重要な役割を果たすだろう
プログラマのモチベーションを維持するのが難しいだろう。
将来性の無い、キャリアにならない言語で書くプロジェクトは、プログラマの動機付けをうまくやるマネージャが必要になる。
リファクタリングにかかるコストを他の言語より多く時間をとる必要があるだろう
命名規則の統一に他の言語に比べたら苦労するだろう
--
言語という観点からすると、こんなところだと思います。
498 ：デフォルトの名無しさん：03/11/06 08:05
うちでもペアプロやってるよ。全社あげてではなく、うちの部署だけだけどね。
499 ：デフォルトの名無しさん：03/11/06 08:13
このスレは、日本の現場事情に詳しい人ばかりですね（ｗ
500 ：497：03/11/06 08:51
まぁ実を言うとほとんど関係ないだろうがな プログラマ次第だ
501 ：デフォルトの名無しさん：03/11/06 14:59
想像力が足りないのか、ペアプロって非現実的に思えてどうしてもネタに思えてしまうんです。
実際にやっている所を全然想像できない。
特定のバグを見つけるために１時間くらいわきにたって一緒に検討するっていうのは
何回か経験ありますが、実装をしかも何時間もの時間さらに何週間もそのシーンを
やるのは気持ち悪いなあって持ってしまいます。
べつに煽るつもりはないんですけど、現実問題として実際にやっているシーンを想像できるように、ペアプログラミングの典型的１日とか教えてもらえませんでしょうか？
実際にやっている所を全然想像できない。
特定のバグを見つけるために１時間くらいわきにたって一緒に検討するっていうのは
何回か経験ありますが、実装をしかも何時間もの時間さらに何週間もそのシーンを
やるのは気持ち悪いなあって持ってしまいます。
べつに煽るつもりはないんですけど、現実問題として実際にやっているシーンを想像できるように、ペアプログラミングの典型的１日とか教えてもらえませんでしょうか？
502 ：デフォルトの名無しさん：03/11/06 21:29
ペアプログラミングの雰囲気は
このへんで伝わると思う
http://agileware.jp/articles/xp/xpepisode-kansai.html
http://www.objectclub.jp/eXtremeProgramming/StackTDD.pdf
気持ち悪い？
このへんで伝わると思う
http://agileware.jp/articles/xp/xpepisode-kansai.html
http://www.objectclub.jp/eXtremeProgramming/StackTDD.pdf
気持ち悪い？
503 ：デフォルトの名無しさん：03/11/06 21:56
>>501
ペアプロの本でも買ったら？
ペアプロの本でも買ったら？
504 ：デフォルトの名無しさん：03/11/06 22:19
SRAではやってるらしいよ。ひょっとして>>476はSRAの人じゃ？
505 ：デフォルトの名無しさん：03/11/07 01:00
506 ：デフォルトの名無しさん：03/11/07 01:19
どうして、みんなやりもせずにプラクティスを限定したがってるのかわからない。
やってみないとわからないと思うけど。たしかに業務でやるにはいろいろな障害・障壁があるだろうけど。
やってみないとわからないと思うけど。たしかに業務でやるにはいろいろな障害・障壁があるだろうけど。
507 ：デフォルトの名無しさん：03/11/07 01:23
俺の会社では週40時間をやってる。
別名サービス残業制。
別名サービス残業制。
508 ：デフォルトの名無しさん：03/11/07 01:26
週40時間だけど、このごろは「最適ペース」と名前を変えている。
週80時間労働を無理なく1年続けられるのなら、XPのプラクティスを実現できてるよ。
週80時間労働を無理なく1年続けられるのなら、XPのプラクティスを実現できてるよ。
509 ：デフォルトの名無しさん：03/11/07 01:26
時代はSCRUM
510 ：デフォルトの名無しさん：03/11/07 01:58
511 ：デフォルトの名無しさん：03/11/07 05:34
補修案件じゃPerl使うことって多いよね。
512 ：デフォルトの名無しさん：03/11/07 06:41
513 ：デフォルトの名無しさん：03/11/07 06:58
このクソスレっぽいスレタイどうにかなりませんか？＞1
514 ：デフォルトの名無しさん：03/11/07 09:13
>>510
うちではやってますが。
うちではやってますが。
515 ：デフォルトの名無しさん：03/11/07 09:28
516 ：デフォルトの名無しさん：03/11/07 09:31
>>515
検索してください。たぶん入れないと思うけど。
検索してください。たぶん入れないと思うけど。
517 ：デフォルトの名無しさん：03/11/07 09:35
なぜ入れないと思うのですか？
518 ：デフォルトの名無しさん：03/11/07 10:49
519 ：デフォルトの名無しさん：03/11/07 11:56
NECソフトウェア北陸
http://www.hnes.co.jp/documents/swkaihatu/01.htm
Technologic Arts
http://www.tech-arts.co.jp/top.h
秀逸なのは↓
NEC情報システムズ
http://www.nis.co.jp/solution/enterprise_omcs/business_application/
> 特徴
> お客様独自の強みを活かしたビジネスモデル（コアコンピタンス）に対応
> XPライクに少数精鋭チームによるイテレーションシップ開発手法を適用
> 最新のオープンアーキテクチャ（Java/J2EE)を活用し、短納期で柔軟な情報システムを構築
> 情報システムの企画から構築・運用の中で、お客様が必要とするサービスをご提供
これを特徴と言えるのが凄い
http://www.hnes.co.jp/documents/swkaihatu/01.htm
Technologic Arts
http://www.tech-arts.co.jp/top.h
秀逸なのは↓
NEC情報システムズ
http://www.nis.co.jp/solution/enterprise_omcs/business_application/
> 特徴
> お客様独自の強みを活かしたビジネスモデル（コアコンピタンス）に対応
> XPライクに少数精鋭チームによるイテレーションシップ開発手法を適用
> 最新のオープンアーキテクチャ（Java/J2EE)を活用し、短納期で柔軟な情報システムを構築
> 情報システムの企画から構築・運用の中で、お客様が必要とするサービスをご提供
これを特徴と言えるのが凄い
520 ：デフォルトの名無しさん：03/11/07 13:12
521 ：デフォルトの名無しさん：03/11/08 17:45
>>503
本とかでは実体験的な話がないので全然現実に置き換えられません。
>>502
ありがとうございます。でも、特定の問題事案のときの一断面だけ
切り出してくるのはそういう問題解決手法もあるってだけで、
一日８時間の枠の中で実際に体験している人の話が聞きたいんです。
例えば、始業時間は前日に打ち合わせているの？二人がそろうまで
何していて、いつはじめるかはお互い顔を見つめあって、「じゃあ
やる？」とかするの？
一つのクラス設計決まっていて、クラス名／メソッド名とか決まった段階で
実装はじめたら、そうそう話をすることもないと思うんだけど、３０分とか
黙々とタイプをうつのを横で覗いているだけ？それも嫌だけど、逆に大して
重要でもないことをいちいち口出されたら、やるきなくなるような気がする
んだけど。
とか
本とかでは実体験的な話がないので全然現実に置き換えられません。
>>502
ありがとうございます。でも、特定の問題事案のときの一断面だけ
切り出してくるのはそういう問題解決手法もあるってだけで、
一日８時間の枠の中で実際に体験している人の話が聞きたいんです。
例えば、始業時間は前日に打ち合わせているの？二人がそろうまで
何していて、いつはじめるかはお互い顔を見つめあって、「じゃあ
やる？」とかするの？
一つのクラス設計決まっていて、クラス名／メソッド名とか決まった段階で
実装はじめたら、そうそう話をすることもないと思うんだけど、３０分とか
黙々とタイプをうつのを横で覗いているだけ？それも嫌だけど、逆に大して
重要でもないことをいちいち口出されたら、やるきなくなるような気がする
んだけど。
とか
522 ：デフォルトの名無しさん：03/11/08 19:35
>>521
ウォータフォール開発を前提とするなら、ペアプログラミングのメリットは下がると思います。
ペアプログラミングは常にレビューを行うという意図を含んでますから、
できあがってレビュー済みの仕様書に従って実装するという作業をペアでやっても
効果は低いでしょう。
一方、テスト駆動で開発し、同時にシンプルな方向への設計の変更を奨励している場合、
ペアプログラミングの効果はより高くなります。テストケースの提案とかシンプルな設計への
変更方法とか考えることが多い分誤りや適切でない解を含みやすいので、
常にレビューを行うことで誤りを減らしより適切な解を発見することが期待できます。
ウォータフォール前提で考えるのなら、私も終日ペアプロは無駄が多いと思います。
私は、ペアプログラミングはXPなどのアジャイルプロセス向けのプログラミングスタイルだと思っています。
ウォータフォール開発を前提とするなら、ペアプログラミングのメリットは下がると思います。
ペアプログラミングは常にレビューを行うという意図を含んでますから、
できあがってレビュー済みの仕様書に従って実装するという作業をペアでやっても
効果は低いでしょう。
一方、テスト駆動で開発し、同時にシンプルな方向への設計の変更を奨励している場合、
ペアプログラミングの効果はより高くなります。テストケースの提案とかシンプルな設計への
変更方法とか考えることが多い分誤りや適切でない解を含みやすいので、
常にレビューを行うことで誤りを減らしより適切な解を発見することが期待できます。
ウォータフォール前提で考えるのなら、私も終日ペアプロは無駄が多いと思います。
私は、ペアプログラミングはXPなどのアジャイルプロセス向けのプログラミングスタイルだと思っています。
523 ：デフォルトの名無しさん：03/11/08 21:05
>>522
えーっとつまり、仕様を考えながらプログラミングしているってことでしょうか？
仕様議論10分→テスト方案議論10分→テストコード実装5分
→メソッド名とか実装ロジックとか議論10分→コード実装5分
→実行デバッグ10分→休憩10分
みたいな？
えーっとつまり、仕様を考えながらプログラミングしているってことでしょうか？
仕様議論10分→テスト方案議論10分→テストコード実装5分
→メソッド名とか実装ロジックとか議論10分→コード実装5分
→実行デバッグ10分→休憩10分
みたいな？
524 ：デフォルトの名無しさん：03/11/08 21:39
ウォータフォール前提というなら、ペアプロだけじゃなくリファクタリングと
xUnitも中途半端な効力しか得られないだろうね。
両方とも今までに何回か、XPの産物のうち残るものとしてこのスレで
挙がったけど、最低限、反復型開発でないと小技の域を出ないし、
むしろ余計な手間になりかねない。
やはりプロセス抜きには語れない。
xUnitも中途半端な効力しか得られないだろうね。
両方とも今までに何回か、XPの産物のうち残るものとしてこのスレで
挙がったけど、最低限、反復型開発でないと小技の域を出ないし、
むしろ余計な手間になりかねない。
やはりプロセス抜きには語れない。
525 ：デフォルトの名無しさん：03/11/08 23:30
526 ：デフォルトの名無しさん：03/11/08 23:33
>>525
ウォーターフォールでのリファクタリングの妥当性と、xUnitの正当性は誰が検証・レビューするのだ？
ウォーターフォールでのリファクタリングの妥当性と、xUnitの正当性は誰が検証・レビューするのだ？
527 ：デフォルトの名無しさん：03/11/09 00:13
>>526
それがウォーターフォールと反復型開発の差だと本気で言ってるの？
ペアプロかそうでないかの差だというならほんの少しくらいは解ってやっても良いけど。
それにしたってUnitTestとリファクタリングが中途半端な効果しか得られないと言うのはあまりにも物を知らなすぎ。
これらはこのような専門用語になる前から使われてきた技術だよ。
プロセスにほとんど左右されない。
開発スピードも遅くなんかならない。
それがウォーターフォールと反復型開発の差だと本気で言ってるの？
ペアプロかそうでないかの差だというならほんの少しくらいは解ってやっても良いけど。
それにしたってUnitTestとリファクタリングが中途半端な効果しか得られないと言うのはあまりにも物を知らなすぎ。
これらはこのような専門用語になる前から使われてきた技術だよ。
プロセスにほとんど左右されない。
開発スピードも遅くなんかならない。
528 ：デフォルトの名無しさん：03/11/09 00:17
>>526
テストする項目、リファクタリングするタイミングにはある程度法則がある。
とりあえずこの本でも読んでおけ。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894717115/ref%3Dase%5Fxpjp-22/250-2049071-6912228
中途半端なんて事はない。
テストする項目、リファクタリングするタイミングにはある程度法則がある。
とりあえずこの本でも読んでおけ。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894717115/ref%3Dase%5Fxpjp-22/250-2049071-6912228
中途半端なんて事はない。
529 ：デフォルトの名無しさん：03/11/09 00:54
524って中途半端だといっている割にその理由が全く書いてないね。
俺は524ではないのだが、それはそれとして。
ウォーターフォールというプロセスとペアプロというXPの一プラクティスを並列に
並べて語るから、何を言おうとしているのかよくわからないが、少なくとも言える事は、
コーディングとレビュー、テストが独立して行われるウォーターフォールでは、
xUnitやリファクタリングの有効性は、XPで行うよりも有効性が劣ると思う。
やってみればわかることだが、それらの妥当性を独立したレビューでチェックすることは
ペアプロに比べればはるかに煩雑になり、工数もかかる。
つまり、それらはプロセス抜きには語れない。
ウォーターフォールというプロセスとペアプロというXPの一プラクティスを並列に
並べて語るから、何を言おうとしているのかよくわからないが、少なくとも言える事は、
コーディングとレビュー、テストが独立して行われるウォーターフォールでは、
xUnitやリファクタリングの有効性は、XPで行うよりも有効性が劣ると思う。
やってみればわかることだが、それらの妥当性を独立したレビューでチェックすることは
ペアプロに比べればはるかに煩雑になり、工数もかかる。
つまり、それらはプロセス抜きには語れない。
531 ：デフォルトの名無しさん：03/11/09 01:16
>>530
プロセスとペアプロを並べて語っているのは524。
UnitTestとリファクタリングをすればテストが独立になるなんて事はないと思うけど。
それ以外の解答は>>528が書いたとおり。
どのプロセスにも取り入れられてプラスになる。
>>530の指摘はウォーターフォール全体の指摘であってウォーターフォールに
UnitTestとリファクタリングを取り入れた時の指摘にはならない。
> 最低限、反復型開発でないと小技の域を出ないし、
> むしろ余計な手間になりかねない。
この裏付けになんてなりようがない。
XPを盲信する人はここらヘンの感覚を変えないと誰もついてこないと思うよ。
何度も言うけどUnitTestとリファクタリングは昔からやってたことだからね。
独立して使うと中途半端とか言ったら怒られるよｗ
プロセスとペアプロを並べて語っているのは524。
UnitTestとリファクタリングをすればテストが独立になるなんて事はないと思うけど。
それ以外の解答は>>528が書いたとおり。
どのプロセスにも取り入れられてプラスになる。
>>530の指摘はウォーターフォール全体の指摘であってウォーターフォールに
UnitTestとリファクタリングを取り入れた時の指摘にはならない。
> 最低限、反復型開発でないと小技の域を出ないし、
> むしろ余計な手間になりかねない。
この裏付けになんてなりようがない。
XPを盲信する人はここらヘンの感覚を変えないと誰もついてこないと思うよ。
何度も言うけどUnitTestとリファクタリングは昔からやってたことだからね。
独立して使うと中途半端とか言ったら怒られるよｗ
532 ：デフォルトの名無しさん：03/11/09 01:25
＞妥当性を独立したレビューでチェック
とりあえず、動くカタチに実装
↓
重複を外していく
↓
似たような実装が来た
↓
クラス抽出などetc
↓
…
知らないうちにデザパタとかの良い形になっている。
モデリングとかはまた別の話。
とりあえず、動くカタチに実装
↓
重複を外していく
↓
似たような実装が来た
↓
クラス抽出などetc
↓
…
知らないうちにデザパタとかの良い形になっている。
モデリングとかはまた別の話。
>>531
誰もマイナスになるとは言っていないけど。
で、もろもろの論点を捨て去って（それらに関しては俺はあまり興味ない）、
ペアプロでやらなかったUnitTestとリファクタリングの妥当性・品質のチェックは
誰がいつやるのだ？
誰もマイナスになるとは言っていないけど。
で、もろもろの論点を捨て去って（それらに関しては俺はあまり興味ない）、
ペアプロでやらなかったUnitTestとリファクタリングの妥当性・品質のチェックは
誰がいつやるのだ？
534 ：デフォルトの名無しさん：03/11/09 01:35
どうも話がうまく伝わらないから別の言い方で説明しておく。
TDDやリファクタリングは正しく実行されればもちろんどんなプロセスでも
コードの品質を高めたり、妥当性の保障となるが、それらが正しく実行され
たかどうかのチェックは、プロセス抜きには語れないだろうということ。
TDDやリファクタリングは正しく実行されればもちろんどんなプロセスでも
コードの品質を高めたり、妥当性の保障となるが、それらが正しく実行され
たかどうかのチェックは、プロセス抜きには語れないだろうということ。
535 ：デフォルトの名無しさん：03/11/09 01:52
>>533
> 妥当性・品質のチェック
具体的にそれは何？
論点がずれそうなのでたとえ話でお願いしたいが。
UnitTestする物には法則がある、ある程度の経験則もあるが学習できるレベルだ。
今は書籍も沢山あるのでかなりマニュアル化されつつある。
GUI関係、DB関係、制御関係など専門的なテスティングも方法論がある。
リファクタリングの方も小さいレベルのリファクタリングをしていけば大きな問題になることはない。
リファクタリングの方法論もファウラーの本を読めば解ると思うがほとんどマニュアル化されてる。
ただ、大きな変更を行う時にはその枝葉がかなり増えるので妥当性を考える必要が出てくる。
これは、いろんな意見をまとめた方が良いだろう。
それより大きなレベルはモデリングでするべき。
と、ここまで書いたがこれらはペアプロを否定するものではない。
テストもベテランと組むことにより専門分野の法論を全体に染み渡らせることが可能で技術の底上げになる。
ナレッジの共有はどの分野でもこれから必要になっていくと思うよ。
>>534
> それらが正しく実行されたかどうかのチェック
この実行とは何を指すのか。
これだと、ただのマネージメントの世界だと思うけど違う？
トラッカとかコーチとか。
なんか、論点がずれてきてるなぁ
何が言いたいのか良く解らない。
それはUnitTestやリファクタリングに限った事じゃないだろ。
> 妥当性・品質のチェック
具体的にそれは何？
論点がずれそうなのでたとえ話でお願いしたいが。
UnitTestする物には法則がある、ある程度の経験則もあるが学習できるレベルだ。
今は書籍も沢山あるのでかなりマニュアル化されつつある。
GUI関係、DB関係、制御関係など専門的なテスティングも方法論がある。
リファクタリングの方も小さいレベルのリファクタリングをしていけば大きな問題になることはない。
リファクタリングの方法論もファウラーの本を読めば解ると思うがほとんどマニュアル化されてる。
ただ、大きな変更を行う時にはその枝葉がかなり増えるので妥当性を考える必要が出てくる。
これは、いろんな意見をまとめた方が良いだろう。
それより大きなレベルはモデリングでするべき。
と、ここまで書いたがこれらはペアプロを否定するものではない。
テストもベテランと組むことにより専門分野の法論を全体に染み渡らせることが可能で技術の底上げになる。
ナレッジの共有はどの分野でもこれから必要になっていくと思うよ。
>>534
> それらが正しく実行されたかどうかのチェック
この実行とは何を指すのか。
これだと、ただのマネージメントの世界だと思うけど違う？
トラッカとかコーチとか。
なんか、論点がずれてきてるなぁ
何が言いたいのか良く解らない。
それはUnitTestやリファクタリングに限った事じゃないだろ。
536 ：デフォルトの名無しさん：03/11/09 02:03
>>535
まず最初に言っておきたいのは、TDDやリファクタリングそのものの有用性
（絶対的価値）や方法論ではない。
その組織が行ってきた既存のプロセスにどのようにTDDやリファクタリングを
組み入れ、そしてそれらはプロセス全体から見たときにどのような価値をもつ
のかということを議論したい。つまり「プロセス抜きには語れない」というのは
そういうこと。
またその組織が今まで「単体テストフェース」をどのように実行し、どのように
それをレビューしてきたかによっても（ここは意図的にあいまいな記述にしてる）、
TDDやリファクタリングの価値は変わってくる。
まず最初に言っておきたいのは、TDDやリファクタリングそのものの有用性
（絶対的価値）や方法論ではない。
その組織が行ってきた既存のプロセスにどのようにTDDやリファクタリングを
組み入れ、そしてそれらはプロセス全体から見たときにどのような価値をもつ
のかということを議論したい。つまり「プロセス抜きには語れない」というのは
そういうこと。
またその組織が今まで「単体テストフェース」をどのように実行し、どのように
それをレビューしてきたかによっても（ここは意図的にあいまいな記述にしてる）、
TDDやリファクタリングの価値は変わってくる。
537 ：デフォルトの名無しさん：03/11/09 02:04
TDDの本読んだんだけどカニンガムってペアプロしてんのかな。
なんかしてないような気もしないでもない。
なんかしてないような気もしないでもない。
538 ：デフォルトの名無しさん：03/11/09 02:10
正当性・妥当性についてちょっと説明する。
リファクタリング：
・そのリファクタリングが、それをする前と意味的に変わりは無いかどうかという妥当性
・そのリファクタリングをする必然性があったかどうかという妥当性
これはちょっと前に/.jpで話題になった「趣味のリファクタリングはしてはいけない」というようなこと
UnitTest：
・あるUnitTestが正しくコーディングされているかどうか（＝正当性）
・理想的なUnitTest全体に対するカバレッジが妥当なものかどうか
・テストされていない部分はそれが妥当かどうか(C1カバレッジレベルで）
・そのテストは正しい環境で正しくテストしたのかどうか（＝正当性）
とまぁ、こんな感じかな。
リファクタリング：
・そのリファクタリングが、それをする前と意味的に変わりは無いかどうかという妥当性
・そのリファクタリングをする必然性があったかどうかという妥当性
これはちょっと前に/.jpで話題になった「趣味のリファクタリングはしてはいけない」というようなこと
UnitTest：
・あるUnitTestが正しくコーディングされているかどうか（＝正当性）
・理想的なUnitTest全体に対するカバレッジが妥当なものかどうか
・テストされていない部分はそれが妥当かどうか(C1カバレッジレベルで）
・そのテストは正しい環境で正しくテストしたのかどうか（＝正当性）
とまぁ、こんな感じかな。
539 ：デフォルトの名無しさん：03/11/09 02:13
>>536
> またその組織が今まで「単体テストフェース」をどのように実行し、どのように
> それをレビューしてきたかによっても（ここは意図的にあいまいな記述にしてる）、
> TDDやリファクタリングの価値は変わってくる。
TDD知っているなら解ると思うけどフェーズっていうレベルじゃないよアレは。
kent も言っていたが最終的に境目など無くなってしまう。
実装のフェーズと融合してしまっているんだな。
なので、実装フェーズにそのまま組み入れることが可能になる。
結合テスト、受け入れテストなどは従来の方法をそのまま使っても構わない。
ただ、この時にはかなりの品質になっていると思われる。
> またその組織が今まで「単体テストフェース」をどのように実行し、どのように
> それをレビューしてきたかによっても（ここは意図的にあいまいな記述にしてる）、
> TDDやリファクタリングの価値は変わってくる。
TDD知っているなら解ると思うけどフェーズっていうレベルじゃないよアレは。
kent も言っていたが最終的に境目など無くなってしまう。
実装のフェーズと融合してしまっているんだな。
なので、実装フェーズにそのまま組み入れることが可能になる。
結合テスト、受け入れテストなどは従来の方法をそのまま使っても構わない。
ただ、この時にはかなりの品質になっていると思われる。
540 ：デフォルトの名無しさん：03/11/09 02:13
特にUnitTestに関しては、第三者が後付で独立したレビューを行おうとすれば、
それはレビューしながらテストをコーディングし実行するペアプロに比べれば
明らかに大変な作業だということがわかると思う。
しかも、レビューがNGだった場合のOKまでの絶望的な道のりは、やったものに
しかわからないかもしれない。
UnitTestを導入したからすべてがばら色に変わるわけではない。
ただし、プログラマ全員がUnitTestに精通していた場合は話は別。
それはレビューしながらテストをコーディングし実行するペアプロに比べれば
明らかに大変な作業だということがわかると思う。
しかも、レビューがNGだった場合のOKまでの絶望的な道のりは、やったものに
しかわからないかもしれない。
UnitTestを導入したからすべてがばら色に変わるわけではない。
ただし、プログラマ全員がUnitTestに精通していた場合は話は別。
541 ：デフォルトの名無しさん：03/11/09 02:15
542 ：デフォルトの名無しさん：03/11/09 02:27
543 ：デフォルトの名無しさん：03/11/09 02:35
結論：
やらんよりマシ
やらんよりマシ
545 ：デフォルトの名無しさん：03/11/09 02:39
>>544
あっ、そうなんだ。
Agile Process 以前の単体テストってどんなことやってました？
自分のところはせいぜい機能毎のテストでした。
サーバサイドなので意外に楽だったり。
GUI系はツラそうですね。
あっ、そうなんだ。
Agile Process 以前の単体テストってどんなことやってました？
自分のところはせいぜい機能毎のテストでした。
サーバサイドなので意外に楽だったり。
GUI系はツラそうですね。
>>545
以前からC0カバレッジを実現するテストコードは書いてました。
Un*xのアプリなんかでmake testとかmake checkとかやると実行されるようなもの。
後でリグレッションテストができるようにもしてました。
Rational社のテストツールが買えるようになってからは、pure coverage、purifyを
使ってました。4年くらい前からだったかな？今でもたまに使いますが。
以前からC0カバレッジを実現するテストコードは書いてました。
Un*xのアプリなんかでmake testとかmake checkとかやると実行されるようなもの。
後でリグレッションテストができるようにもしてました。
Rational社のテストツールが買えるようになってからは、pure coverage、purifyを
使ってました。4年くらい前からだったかな？今でもたまに使いますが。
547 ：デフォルトの名無しさん：03/11/09 03:04
>>546
ツラそうですね、それは。
うちなんかメチャいい加減だｗ
やったとしてもc2が精々かな。
xpはホントにコーディングしながらのテストですよね。
ぱっとテストを作って要らなくなったらぱっとテストを消すようなもっと気軽な感じがします。
ここらヘンも Agile な感覚なんでしょうね。
ツラそうですね、それは。
うちなんかメチャいい加減だｗ
やったとしてもc2が精々かな。
xpはホントにコーディングしながらのテストですよね。
ぱっとテストを作って要らなくなったらぱっとテストを消すようなもっと気軽な感じがします。
ここらヘンも Agile な感覚なんでしょうね。
548 ：デフォルトの名無しさん：03/11/09 03:23
c0とかc1とかc2って何？
もちろんぐぐったさ。
もちろんぐぐったさ。
549 ：デフォルトの名無しさん：03/11/09 03:33
>>541
今までの妥当性を見て設計していくというテストと既に質が違うんだから妥当性は？
とか同じ並びで聞かれてもUnitTest勉強してねとしか言えないよ。
切り替えはテストフェーズからロジック部分のテストを削除、残りのストーリー的なテストのみを行う。
リグレッションテストはテストスウィートで行えばいい。
早い話テストもその場で必要な物を作るというアジャイルな形態でしょ。
まぁ、もう話たくないみたいだからこれで終わるけど。
ただ横から入ってきてそう言う打ち切り方は正直失礼だと思うよ。
今までの妥当性を見て設計していくというテストと既に質が違うんだから妥当性は？
とか同じ並びで聞かれてもUnitTest勉強してねとしか言えないよ。
切り替えはテストフェーズからロジック部分のテストを削除、残りのストーリー的なテストのみを行う。
リグレッションテストはテストスウィートで行えばいい。
早い話テストもその場で必要な物を作るというアジャイルな形態でしょ。
まぁ、もう話たくないみたいだからこれで終わるけど。
ただ横から入ってきてそう言う打ち切り方は正直失礼だと思うよ。
550 ：デフォルトの名無しさん：03/11/09 03:39
>>549
お前の読解力の無さに呆れたんだろ（ｗ
お前の読解力の無さに呆れたんだろ（ｗ
551 ：デフォルトの名無しさん：03/11/09 03:43
ツマラン煽りは要らんよ。
どうせ煽るならこのスレ的な話題で煽れ。
どうせ煽るならこのスレ的な話題で煽れ。
552 ：デフォルトの名無しさん：03/11/09 03:44
553 ：デフォルトの名無しさん：03/11/09 03:45
>>552
相手してあげるから具体的にどうぞ。
相手してあげるから具体的にどうぞ。
554 ：デフォルトの名無しさん：03/11/09 03:47
horayo
> リグレッションテストはテストスウィートで行えばいい。
> リグレッションテストはテストスウィートで行えばいい。
555 ：デフォルトの名無しさん：03/11/09 03:48
mouiccyo
>切り替えはテストフェーズからロジック部分のテストを削除、残りのストーリー的なテストのみを行う。
>切り替えはテストフェーズからロジック部分のテストを削除、残りのストーリー的なテストのみを行う。
556 ：デフォルトの名無しさん：03/11/09 03:49
それが？
557 ：デフォルトの名無しさん：03/11/09 03:50
sarani
>UnitTestする物には法則がある、ある程度の経験則もあるが学習できるレベルだ。
>UnitTestする物には法則がある、ある程度の経験則もあるが学習できるレベルだ。
558 ：デフォルトの名無しさん：03/11/09 03:51
559 ：デフォルトの名無しさん：03/11/09 03:53
UnitTestがunit testじゃなくてUnitTestなのはどういう意味？
560 ：デフォルトの名無しさん：03/11/09 03:53
はぁ、引用張って何したいんだか。
ツマラン煽りを要らないって言ったのにねぇ
ツマラン煽りを要らないって言ったのにねぇ
561 ：デフォルトの名無しさん：03/11/09 03:53
つーか、>>524の意味がわかっていない段階で、お前はアフォ
562 ：デフォルトの名無しさん：03/11/09 03:54
>ツマラン煽りを要らないって言ったのにねぇ
日本語ネイティブじゃないんでしょ？
日本語ネイティブじゃないんでしょ？
563 ：デフォルトの名無しさん：03/11/09 03:56
あと１０分待ってまともな煽りがないようなら相手しないから
564 ：デフォルトの名無しさん：03/11/09 03:56
はっきり言って、話がかみ合わないのはお前がアフォだからだと思うぞ（ｗ
565 ：デフォルトの名無しさん：03/11/09 03:58
しかたないなぁ、特別だぞ？
>今までの妥当性を見て設計していくというテストと既に質が違うんだから妥当性は？
>とか同じ並びで聞かれてもUnitTest勉強してねとしか言えないよ。
主語は何？
>今までの妥当性を見て設計していくというテストと既に質が違うんだから妥当性は？
>とか同じ並びで聞かれてもUnitTest勉強してねとしか言えないよ。
主語は何？
566 ：デフォルトの名無しさん：03/11/09 04:00
あー、やめたやめた、お前の文章を添削してやっても、俺には何の利益にもならん（ｗ
567 ：デフォルトの名無しさん：03/11/09 04:00
568 ：デフォルトの名無しさん：03/11/09 04:05
UnitTestって単体テストって意味じゃなくて、一般的な
テストプログラムの意味なのか？あるいはXP用語として
wikiっぽくUnitTestって書いてるのか？
テストプログラムの意味なのか？あるいはXP用語として
wikiっぽくUnitTestって書いてるのか？
569 ：デフォルトの名無しさん：03/11/09 04:06
570 ：デフォルトの名無しさん：03/11/09 04:08
571 ：デフォルトの名無しさん：03/11/09 09:23
>>548
おいらもぐぐってみた。
http://www.google.com/search?q=%E3%83%86%E3%82%B9%E3%83%88+C0+C1+C2
命令網羅とか条件網羅とかを言い換えただけね。
おいらもぐぐってみた。
http://www.google.com/search?q=%E3%83%86%E3%82%B9%E3%83%88+C0+C1+C2
命令網羅とか条件網羅とかを言い換えただけね。
なんか荒れてるな。
中途半端って言葉が気に障ったのか。
XPが引き上げたレベルまでの効果は得られないって言ってるだけなのに。
ソース変更が禁止されたらMercilessなリファクタリングなんて無理だろう。
なんでムキになるのかわからん。
中途半端って言葉が気に障ったのか。
XPが引き上げたレベルまでの効果は得られないって言ってるだけなのに。
ソース変更が禁止されたらMercilessなリファクタリングなんて無理だろう。
なんでムキになるのかわからん。
573 ：デフォルトの名無しさん：03/11/09 12:21
>>569
なんでおまえはそんなに自身満々なんだ。
正しい日本語でも普及させていってくれ、じゃなくて、少しはわかりやすい文章を書く努力をしろよ。
俺も話がかみ合ってない原因は、おまえの読解力の無さと文章力のなさのほうにあると思うぞ。
まーおまえはこのコメントも煽りと取るんだろうがな。
なんでおまえはそんなに自身満々なんだ。
正しい日本語でも普及させていってくれ、じゃなくて、少しはわかりやすい文章を書く努力をしろよ。
俺も話がかみ合ってない原因は、おまえの読解力の無さと文章力のなさのほうにあると思うぞ。
まーおまえはこのコメントも煽りと取るんだろうがな。
574 ：デフォルトの名無しさん：03/11/09 12:35
>>527
> プロセスにほとんど左右されない。
> 開発スピードも遅くなんかならない。
本気でそんなこと言ってるの？仕事でxUnitを使ったことある？リファクタリングをしたことある？
君の隣の席の斉藤君が書いた10Kステップのテストコードにバグが無いことを誰が証明してくれるの？
> プロセスにほとんど左右されない。
> 開発スピードも遅くなんかならない。
本気でそんなこと言ってるの？仕事でxUnitを使ったことある？リファクタリングをしたことある？
君の隣の席の斉藤君が書いた10Kステップのテストコードにバグが無いことを誰が証明してくれるの？
575 ：デフォルトの名無しさん：03/11/09 14:25
>>572
> XPが引き上げたレベルまでの効果は得られないって言ってるだけなのに。
524の
> 最低限、反復型開発でないと小技の域を出ないし、
> むしろ余計な手間になりかねない。
からはどうしてもそうは読み取れないけど。
「余計な手間になりかねない」という言葉は普通マイナスになると言っていると捉えられるが。
そして、Agile Process なら解るが反復型開発にとくくるところも謎だ。
ウォーターフォールとの対比でリリース期間の話をしているんだろ？
リリース期間でUnitTestやリファクタリングの効果が左右されるかと言われれば答えはNOだ。
もし反復型開発が Agile Process の事を言っているなら言葉を間違えたね。
>>574
UnitTestの粒度を考えれ。
気になるんならコードレビューでも何でもすればいい。
その際も UnitTest の存在からコードは従来よりも格段に読みやすくなっていると思うけどね。
あと、開発スピードが遅くなる理由が書いてないが。
まさか、全くテストをしない開発からのシフトを言っているんじゃないよな。
> XPが引き上げたレベルまでの効果は得られないって言ってるだけなのに。
524の
> 最低限、反復型開発でないと小技の域を出ないし、
> むしろ余計な手間になりかねない。
からはどうしてもそうは読み取れないけど。
「余計な手間になりかねない」という言葉は普通マイナスになると言っていると捉えられるが。
そして、Agile Process なら解るが反復型開発にとくくるところも謎だ。
ウォーターフォールとの対比でリリース期間の話をしているんだろ？
リリース期間でUnitTestやリファクタリングの効果が左右されるかと言われれば答えはNOだ。
もし反復型開発が Agile Process の事を言っているなら言葉を間違えたね。
>>574
UnitTestの粒度を考えれ。
気になるんならコードレビューでも何でもすればいい。
その際も UnitTest の存在からコードは従来よりも格段に読みやすくなっていると思うけどね。
あと、開発スピードが遅くなる理由が書いてないが。
まさか、全くテストをしない開発からのシフトを言っているんじゃないよな。
576 ：デフォルトの名無しさん：03/11/09 15:27
この議論もう良いよ。
両者とも必死すぎ。
両者とも必死すぎ。
577 ：デフォルトの名無しさん：03/11/09 16:37
揚げ足の取り合いuzeeee
578 ：デフォルトの名無しさん：03/11/09 18:22
579 ：デフォルトの名無しさん：03/11/09 19:26
反復型開発つーと従来のスパイラル開発も含まれちゃうね。
コンポーネンスベースも結局スパイラルに開発するし。
コンポーネンスベースも結局スパイラルに開発するし。
>>575
＞「余計な手間になりかねない」という言葉は普通マイナスになると言っていると捉えられるが。
余計な手間を避けるためには、少なくともコーディングと単体テストが
一体の期間として扱われるように調整するべきじゃないのかな。
コーディングフェーズと単体テストフェーズが、ソース凍結をはさんで
分離されてるような日程だったら無駄が生じると思うんだがね。
＞そして、Agile Process なら解るが反復型開発にとくくるところも謎だ。
＞ウォーターフォールとの対比でリリース期間の話をしているんだろ？
反復型開発って言ってるのに、なぜ勝手にAgile Processに絞るのか謎。
あとウォーターフォールの対比で何故リリース期間の話になるのかも分からん。
対比というなら文字通りの一回性と繰り返しがまず一点、次に成果物の
変更の可否が次の一点と捉えるのが普通だと思うんだが。
＞「余計な手間になりかねない」という言葉は普通マイナスになると言っていると捉えられるが。
余計な手間を避けるためには、少なくともコーディングと単体テストが
一体の期間として扱われるように調整するべきじゃないのかな。
コーディングフェーズと単体テストフェーズが、ソース凍結をはさんで
分離されてるような日程だったら無駄が生じると思うんだがね。
＞そして、Agile Process なら解るが反復型開発にとくくるところも謎だ。
＞ウォーターフォールとの対比でリリース期間の話をしているんだろ？
反復型開発って言ってるのに、なぜ勝手にAgile Processに絞るのか謎。
あとウォーターフォールの対比で何故リリース期間の話になるのかも分からん。
対比というなら文字通りの一回性と繰り返しがまず一点、次に成果物の
変更の可否が次の一点と捉えるのが普通だと思うんだが。
581 ：デフォルトの名無しさん：03/11/09 19:59
>>576-578
まあ必死になったり揚げ足取り合ったりするのは見苦しいけど、テーマは
別に変じゃないと思うんだがね。簡単に言うと、xUnit/リファクタリング
の効果とプロセスは、どんな風に関係するのかって話なわけで。
とりあえず、こんな風に興奮しちゃう人がいる程度には、例の入門書が
面白そうだってことが分かったよ。
まあ必死になったり揚げ足取り合ったりするのは見苦しいけど、テーマは
別に変じゃないと思うんだがね。簡単に言うと、xUnit/リファクタリング
の効果とプロセスは、どんな風に関係するのかって話なわけで。
とりあえず、こんな風に興奮しちゃう人がいる程度には、例の入門書が
面白そうだってことが分かったよ。
582 ：デフォルトの名無しさん：03/11/09 20:07
>>579
いわゆるスパイラルって漸進型であっても反復型じゃない思うんだが。
下の掲示板のcockburnのレスにこんなのがある
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=42&t=000161
＞"Incremental" means "add onto".
＞"Iterative" means "alter".
この定義が全てとは思わないけど、割と自然じゃない？
いわゆるスパイラルって漸進型であっても反復型じゃない思うんだが。
下の掲示板のcockburnのレスにこんなのがある
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=42&t=000161
＞"Incremental" means "add onto".
＞"Iterative" means "alter".
この定義が全てとは思わないけど、割と自然じゃない？
583 ：デフォルトの名無しさん：03/11/09 20:09
なんか言い訳じみてきたな
どっちもボロを隠すためにかなり必死だｗ
恥ずかしいね～
どっちもボロを隠すためにかなり必死だｗ
恥ずかしいね～
584 ：デフォルトの名無しさん：03/11/09 20:23
なんでこうもみんな煽り風味なんだろうか。
両者とも相手を見下して放してるから性質が悪い。
精神的に子供過ぎる。
両者とも相手を見下して放してるから性質が悪い。
精神的に子供過ぎる。
585 ：デフォルトの名無しさん：03/11/09 20:44
>>582
ttp://www.atmarkit.co.jp/fjava/devs/process01/process01.html
＞ スパイラル型のバリエーションとして、「反復型（イテラティブ）」プロセスと
＞「漸増型（インクリメンタル）」プロセスと呼ばれるものがあります。反復型では、
＞1サイクルでシステム全体を薄く仕上げて前サイクルの成果にオーバーラップ
＞させていきます。一方の漸増型では、1サイクルでシステムの明確に分離された
＞一塊のモジュール群（これを1インクリメント＝増分）を前サイクルの結果に上乗
＞せしていくイメージです。
ttp://www.atmarkit.co.jp/fjava/devs/process01/process01.html
＞ スパイラル型のバリエーションとして、「反復型（イテラティブ）」プロセスと
＞「漸増型（インクリメンタル）」プロセスと呼ばれるものがあります。反復型では、
＞1サイクルでシステム全体を薄く仕上げて前サイクルの成果にオーバーラップ
＞させていきます。一方の漸増型では、1サイクルでシステムの明確に分離された
＞一塊のモジュール群（これを1インクリメント＝増分）を前サイクルの結果に上乗
＞せしていくイメージです。
586 ：デフォルトの名無しさん：03/11/10 01:23
>>585
582 の cockburn 氏の言っていることと同じでしょ。
582 の cockburn 氏の言っていることと同じでしょ。
587 ：デフォルトの名無しさん：03/11/10 01:43
588 ：デフォルトの名無しさん：03/11/10 01:46
>>581
対立している一方は、プロセスなんか関係ないと結論付けちゃってるから、
全然議論になってない。
例の入門書ってTDDのこと？あれあんまりよく無かったよ。
xUnitとリファクタリングを全く知らない人にはいいかもしれないけど、
知ってる人にとっては目新しいことはほとんど無い。
対立している一方は、プロセスなんか関係ないと結論付けちゃってるから、
全然議論になってない。
例の入門書ってTDDのこと？あれあんまりよく無かったよ。
xUnitとリファクタリングを全く知らない人にはいいかもしれないけど、
知ってる人にとっては目新しいことはほとんど無い。
589 ：デフォルトの名無しさん：03/11/10 01:58
590 ：デフォルトの名無しさん：03/11/10 02:04
>>589
xUnitもリファクタリングも知らない真の入門者には、別の意味でお勧めできない。
ある程度の知識がないと、内容をよく理解できないと思う。
それからPythonを使って説明してるのは失敗だったと思うね。
xUnitもリファクタリングも知らない真の入門者には、別の意味でお勧めできない。
ある程度の知識がないと、内容をよく理解できないと思う。
それからPythonを使って説明してるのは失敗だったと思うね。
591 ：デフォルトの名無しさん：03/11/10 02:09
>>590
???
???
>>591
なにがわからんのかがわからん。
なにがわからんのかがわからん。
593 ：デフォルトの名無しさん：03/11/10 08:45
>>591
ﾋﾟﾄﾎﾝ
ﾋﾟﾄﾎﾝ
594 ：デフォルトの名無しさん：03/11/10 10:39
>>588
>例の入門書ってTDDのこと？あれあんまりよく無かったよ。
>xUnitとリファクタリングを全く知らない人にはいいかもしれないけど、
>知ってる人にとっては目新しいことはほとんど無い。
そうか？俺は面白かったが。
特に、テストファーストとTDDの違いが良く分かったよ。
テストファーストの時は、「setのテストとgetのテストを両方やるのか？」
なんて考えたりもしたが、TDDではそもそもそんなことが問題にはならない
ってことが分かった。
あと、staticメソッドの実装をテストケースの中にやってしまう、ってのも驚いたね。
>例の入門書ってTDDのこと？あれあんまりよく無かったよ。
>xUnitとリファクタリングを全く知らない人にはいいかもしれないけど、
>知ってる人にとっては目新しいことはほとんど無い。
そうか？俺は面白かったが。
特に、テストファーストとTDDの違いが良く分かったよ。
テストファーストの時は、「setのテストとgetのテストを両方やるのか？」
なんて考えたりもしたが、TDDではそもそもそんなことが問題にはならない
ってことが分かった。
あと、staticメソッドの実装をテストケースの中にやってしまう、ってのも驚いたね。
595 ：デフォルトの名無しさん：03/11/10 15:16
>>594
> テストファーストの時は、「setのテストとgetのテストを両方やるのか？」
> なんて考えたりもしたが、TDDではそもそもそんなことが問題にはならない
> ってことが分かった。
前から問題ではなかったけど。
> あと、staticメソッドの実装をテストケースの中にやってしまう、ってのも驚いたね。
どこの話ですか？記憶にないんだけど・・・
> テストファーストの時は、「setのテストとgetのテストを両方やるのか？」
> なんて考えたりもしたが、TDDではそもそもそんなことが問題にはならない
> ってことが分かった。
前から問題ではなかったけど。
> あと、staticメソッドの実装をテストケースの中にやってしまう、ってのも驚いたね。
どこの話ですか？記憶にないんだけど・・・
596 ：デフォルトの名無しさん：03/11/10 16:18
>>594
つまりきみみたいな読者層しか為にならないということなんじゃ？
つまりきみみたいな読者層しか為にならないということなんじゃ？
>>595
>前から問題ではなかったけど。
それを自信をもって問題はないと言えなかったんだよ。
>> あと、staticメソッドの実装をテストケースの中にやってしまう、ってのも驚いたね。
>どこの話ですか？記憶にないんだけど・・・
p153
>前から問題ではなかったけど。
それを自信をもって問題はないと言えなかったんだよ。
>> あと、staticメソッドの実装をテストケースの中にやってしまう、ってのも驚いたね。
>どこの話ですか？記憶にないんだけど・・・
p153
>>596
>つまりきみみたいな読者層しか為にならないということなんじゃ？
違うね。俺みたいな読者層には為になるっていうことなんだよ。
そして俺は「xUnitとリファクタリングを全く知らない人」ではない。
>つまりきみみたいな読者層しか為にならないということなんじゃ？
違うね。俺みたいな読者層には為になるっていうことなんだよ。
そして俺は「xUnitとリファクタリングを全く知らない人」ではない。
599 ：デフォルトの名無しさん：03/11/10 19:15
また馬鹿の登場かよ
600 ：デフォルトの名無しさん：03/11/10 19:32
>>597
p153にはstaticメソッドの話題は無いように見えるが…
p153にはstaticメソッドの話題は無いように見えるが…
602 ：デフォルトの名無しさん：03/11/11 09:42
604 ：デフォルトの名無しさん：03/11/11 13:10
>>603
訳はだれ？
訳はだれ？
605 ：デフォルトの名無しさん：03/11/11 13:31
>>604
長瀬＆テクノロジックアート…
長瀬＆テクノロジックアート…
606 ：デフォルトの名無しさん：03/11/12 00:05
流せグループはこれだけたたかれて、いったいどう思ってるんだろうね？
いくならんでも、もう耳に入ってるだろう。
いくならんでも、もう耳に入ってるだろう。
607 ：デフォルトの名無しさん：03/11/12 01:02
>>607
しかし、こんな訳でも無いよりはマシ。
原書が良ければ多少訳が不味くても何とかなるってことだな。
# 最近は、使い捨てコードはUnitTestの中に書いて、
# 正式なクラスに移す前に捨ててしまいます。
しかし、こんな訳でも無いよりはマシ。
原書が良ければ多少訳が不味くても何とかなるってことだな。
# 最近は、使い捨てコードはUnitTestの中に書いて、
# 正式なクラスに移す前に捨ててしまいます。
609 ：デフォルトの名無しさん：03/11/13 00:35
つーか、翻訳自体は儲からないんだけどな。
610 ：デフォルトの名無しさん：03/11/15 01:11
「テスト駆動開発入門」
これの話ですよね?
これの話ですよね?
611 ：デフォルトの名無しさん：03/11/15 03:18
But how do we get to clean code that works? Many forces drive us away
from clean code, and even from code that works. Without taking too much
counsel of our fears, here's what we do: we drive development with automated
test, a style of development called Test-Driven Development (TDD).
しかし、動作するきれいなコードをどのようにして作るのだろうか？多くのフォースによりきれい
なコード、さらには動作するコードから遠ざけれれる。自動テスト、TDD（テスト駆動開発）と呼ば
れる開発スタイルにより、不安を少なくして開発できる。
しかし、どうやって動作するコードをきれいに保つのだろうか？多くの力がきれいな
コードから、ましてや動くことからさえも遠ざけてしまう。自動テストを使えば、多くの
不安なしに開発が出来る。この開発スタイルがテスト駆動開発（ＴＤＤ）である。
from clean code, and even from code that works. Without taking too much
counsel of our fears, here's what we do: we drive development with automated
test, a style of development called Test-Driven Development (TDD).
しかし、動作するきれいなコードをどのようにして作るのだろうか？多くのフォースによりきれい
なコード、さらには動作するコードから遠ざけれれる。自動テスト、TDD（テスト駆動開発）と呼ば
れる開発スタイルにより、不安を少なくして開発できる。
しかし、どうやって動作するコードをきれいに保つのだろうか？多くの力がきれいな
コードから、ましてや動くことからさえも遠ざけてしまう。自動テストを使えば、多くの
不安なしに開発が出来る。この開発スタイルがテスト駆動開発（ＴＤＤ）である。
612 ：デフォルトの名無しさん：03/11/15 03:50
漏れも原書買うかな。でも原書の方が高いんだよねー
613 ：デフォルトの名無しさん：03/11/15 07:16
XP やユニットテストに最近興味を持って、ファウラーの「リファクタリング」かベックの
「テスト駆動開発入門」 のどちらかを読もうと思っているのですが、最初に読むなら
どっちがお勧めですか?
「テスト駆動開発入門」 のどちらかを読もうと思っているのですが、最初に読むなら
どっちがお勧めですか?
614 ：デフォルトの名無しさん：03/11/15 10:48
>>613
どちらもお勧めできない。ほかのXP本を買え。
どちらもお勧めできない。ほかのXP本を買え。
615 ：デフォルトの名無しさん：03/11/15 12:29
616 ：デフォルトの名無しさん：03/11/15 12:55
>>615
リファクタリングは完全なテストが存在するのが前提だから、最初にリファクタリングを読むのはきついと思う。
リファクタリングは完全なテストが存在するのが前提だから、最初にリファクタリングを読むのはきついと思う。
617 ：デフォルトの名無しさん：03/11/15 13:32
>>613
その二者択一なの？
XPに興味を持ったならまず>>614じゃ無いけどとりあえずXP白本を買った方が良いと思う。
その後に Fowler の Refactoring かな？
>>615
Smalltalk Best Practice Patterns はその名の通り smalltalk の手法の解説なので
勧める時はそこらヘンの事情も説明した方が良い。
>>616
いや、実際にコーディングするならまだしもリファクタリングのカタログとしての
知識を仕入れるのにテストの有無は関係ないと思う。
TDD入門は所々にリファクタリングの用語や手法を知っているという前提で書か
れてる箇所があるのでやはり Refactoring が先じゃないかな。
まあ、どちらにしてもXP本シリーズが先だと思うけどね。
その二者択一なの？
XPに興味を持ったならまず>>614じゃ無いけどとりあえずXP白本を買った方が良いと思う。
その後に Fowler の Refactoring かな？
>>615
Smalltalk Best Practice Patterns はその名の通り smalltalk の手法の解説なので
勧める時はそこらヘンの事情も説明した方が良い。
>>616
いや、実際にコーディングするならまだしもリファクタリングのカタログとしての
知識を仕入れるのにテストの有無は関係ないと思う。
TDD入門は所々にリファクタリングの用語や手法を知っているという前提で書か
れてる箇所があるのでやはり Refactoring が先じゃないかな。
まあ、どちらにしてもXP本シリーズが先だと思うけどね。
618 ：デフォルトの名無しさん：03/11/15 16:08
>>614,617
禿同
禿同
619 ：デフォルトの名無しさん：03/11/15 17:16
620 ：デフォルトの名無しさん：03/11/15 22:06
白本も長瀬な罠
621 ：デフォルトの名無しさん：03/11/16 12:06
白本じゃなくて黒本じゃだめでつか？
622 ：デフォルトの名無しさん：03/11/16 13:12
>>621
白本読まないと黒本楽しめないよ？
白本読まないと黒本楽しめないよ？
623 ：デフォルトの名無しさん：03/11/16 13:13
黒本ってこれ？
「XPエクストリームプログラミング懐疑編」
「XPエクストリームプログラミング懐疑編」
624 ：デフォルトの名無しさん：03/11/16 14:53
「JavaによるExtreme Programming クックブック」
ってどうですか？
ってどうですか？
625 ：デフォルトの名無しさん：03/11/17 20:32
626 ：デフォルトの名無しさん：03/11/17 23:46
627 ：デフォルトの名無しさん：03/11/20 00:12
おいらは、TDD 読むよりも先にリファクタリングを先に読んだ方がいいと思う。
リファクタリングは、小規模であれば、テストなしでもある程度実行できるので、
比較的とっつきやすい。あと、IDE にリファクタリング機能が付いてるものが
増えつつあるので、基本的なところだけでも早めに理解しておいた方がお得。
一方で TDD は、「レッドバー -> グリーンバー -> リファクタリング」のリ
ズムが重要なので、リファクタリングの知識がないとすぐに行き詰まる気がす
る。
しかしまぁ、順番はともかく両方読むのがベスト。
白本は翻訳の出来も悪いが、内容的にもすでに古いので無理に読まなくてもい
いんじゃないかなぁ。XP やるなら読んでおいたほうが more better ではある
けど、もはや必読ではなくなりつつある気が。
リファクタリングは、小規模であれば、テストなしでもある程度実行できるので、
比較的とっつきやすい。あと、IDE にリファクタリング機能が付いてるものが
増えつつあるので、基本的なところだけでも早めに理解しておいた方がお得。
一方で TDD は、「レッドバー -> グリーンバー -> リファクタリング」のリ
ズムが重要なので、リファクタリングの知識がないとすぐに行き詰まる気がす
る。
しかしまぁ、順番はともかく両方読むのがベスト。
白本は翻訳の出来も悪いが、内容的にもすでに古いので無理に読まなくてもい
いんじゃないかなぁ。XP やるなら読んでおいたほうが more better ではある
けど、もはや必読ではなくなりつつある気が。
628 ：デフォルトの名無しさん：03/11/20 10:33
>>627
おれもリファクタリングが先の方が良いと思う。
ただしそれは、自分がそうだっただけだけど。
リファクタリングにも数ページUnitTestについて書いてあるし。
でも、リファクタリングでのUnitTestの役割と、TDDでのUnitTestの役割は
違う印象があるから、TDDから始めるとどうなるのか興味がある。
（Kentの娘はTDDしかコードの書き方を知らないそうだが）
おれもリファクタリングが先の方が良いと思う。
ただしそれは、自分がそうだっただけだけど。
リファクタリングにも数ページUnitTestについて書いてあるし。
でも、リファクタリングでのUnitTestの役割と、TDDでのUnitTestの役割は
違う印象があるから、TDDから始めるとどうなるのか興味がある。
（Kentの娘はTDDしかコードの書き方を知らないそうだが）
629 ：デフォルトの名無しさん：03/11/22 14:34
630 ：デフォルトの名無しさん：03/11/24 03:30
TDD読んだけど何あれ？
テスト通すためにあんな下らないソース埋め込まなきゃならないの？
テストが通るまでコード書いて通ったら次へ行くという形じゃないのか？
あれじゃ次に行くタイミングを失敗したら変なコードが残りまくりだろ。
定数にしている部分を直すのを忘れるなんて事日常でありそうだぞ。
人間はミスをするという考えに元付いてやっているんじゃなかったのか？
あんなに無理矢理テストをパスさせる必要性が解らん。
あほくさ。
テスト通すためにあんな下らないソース埋め込まなきゃならないの？
テストが通るまでコード書いて通ったら次へ行くという形じゃないのか？
あれじゃ次に行くタイミングを失敗したら変なコードが残りまくりだろ。
定数にしている部分を直すのを忘れるなんて事日常でありそうだぞ。
人間はミスをするという考えに元付いてやっているんじゃなかったのか？
あんなに無理矢理テストをパスさせる必要性が解らん。
あほくさ。
631 ：デフォルトの名無しさん：03/11/24 04:10
わからなかったらやらなくていいよ。誰も困らないし。
それに君がどんなスタイルでコーディングしようが、
誰も興味ないから、もうこのスレ来ないでね。
それに君がどんなスタイルでコーディングしようが、
誰も興味ないから、もうこのスレ来ないでね。
632 ：デフォルトの名無しさん：03/11/24 04:25
633 ：デフォルトの名無しさん：03/11/24 15:52
634 ：デフォルトの名無しさん：03/11/24 16:26
>>633
なんかレスがメチャクチャ厨っぽいんだけどｗ
ここって Agile Process はすべて肯定しないといちゃいけないのか？
XP も TDD も Scrum も FDD も Crystal も ASD も LSD も？
おかしいと思っても意見書いたらダメで全部の Agile Process を肯定するのか？
おかしいだろそれは。
オレは TDD も納得する意見があれば別に否定しないし逆に使うかも知れない。
そういう意見も無しに出てけとか氏ねとかはないと思うがね。
なんかレスがメチャクチャ厨っぽいんだけどｗ
ここって Agile Process はすべて肯定しないといちゃいけないのか？
XP も TDD も Scrum も FDD も Crystal も ASD も LSD も？
おかしいと思っても意見書いたらダメで全部の Agile Process を肯定するのか？
おかしいだろそれは。
オレは TDD も納得する意見があれば別に否定しないし逆に使うかも知れない。
そういう意見も無しに出てけとか氏ねとかはないと思うがね。
635 ：デフォルトの名無しさん：03/11/24 17:16
ここは信者が多いからね。
否定されると否応なしに『氏ね』なんだろうなｗ
否定されると否応なしに『氏ね』なんだろうなｗ
636 ：デフォルトの名無しさん：03/11/24 18:17
637 ：デフォルトの名無しさん：03/11/24 18:26
638 ：デフォルトの名無しさん：03/11/24 21:26
読んでないから知らんけど、TDDって新しい「Agile Process」なのか？
>>634の列挙を見るとそんな感じに見えるんだが。
Agile Modelingのようにプロセス自体とは別ものだと思ってたよ。
>>634の列挙を見るとそんな感じに見えるんだが。
Agile Modelingのようにプロセス自体とは別ものだと思ってたよ。
639 ：デフォルトの名無しさん：03/11/24 22:18
で、結局まともな意見は何一つ無いわけだ。
これじゃ beck も可哀想だｗ
自分達の使うものをちゃんと消化出来てない証拠だろ。
>>636
どこがまともじゃないんだ？
ちゃんと問題点を挙げているだろ。
これじゃ beck も可哀想だｗ
自分達の使うものをちゃんと消化出来てない証拠だろ。
>>636
どこがまともじゃないんだ？
ちゃんと問題点を挙げているだろ。
640 ：デフォルトの名無しさん：03/11/24 23:33
>>634じゃないけど、で、どうなの？
読んでないから知らんけど>>634氏によると、不適切な暫定コードが
あってもずっとグリーンバーで、その暫定コードが残らないための頼りが
プログラマの注意力しかないって事なんだよね。そうなん？それは嫌だ。
>>634氏の誤読だとしても、疑問自体はシンプルだし何より互いに実物
持ってるし、ちゃんと読解した人ならページ数を示して正しい解釈に導く
とかできそうなものだけど。
読んでないから知らんけど>>634氏によると、不適切な暫定コードが
あってもずっとグリーンバーで、その暫定コードが残らないための頼りが
プログラマの注意力しかないって事なんだよね。そうなん？それは嫌だ。
>>634氏の誤読だとしても、疑問自体はシンプルだし何より互いに実物
持ってるし、ちゃんと読解した人ならページ数を示して正しい解釈に導く
とかできそうなものだけど。
641 ：デフォルトの名無しさん：03/11/24 23:42
642 ：デフォルトの名無しさん：03/11/24 23:59
643 ：デフォルトの名無しさん：03/11/25 01:03
>>639
お前が「問題点」としている単なる疑問の答えは、すべてTDDの本に載っている。
わからないとすればそれはお前の理解力の足りなさのせいだ。
質問したいなら具体的に質問しろ。
議論したいならまともな意見を書け。
具にもつかない疑問を垂れ流しておいて「質問に答えられないのか、それじゃ議論にならん」
じゃそれこそ議論にならん。
>>640
なんでいちいちページをあげてアフォの疑問を解決してやらねば
ならないのかわからん。
興味が無かったり、やりかたがわからないんなら使わなければ
いいだけのことでは？
お前が「問題点」としている単なる疑問の答えは、すべてTDDの本に載っている。
わからないとすればそれはお前の理解力の足りなさのせいだ。
質問したいなら具体的に質問しろ。
議論したいならまともな意見を書け。
具にもつかない疑問を垂れ流しておいて「質問に答えられないのか、それじゃ議論にならん」
じゃそれこそ議論にならん。
>>640
なんでいちいちページをあげてアフォの疑問を解決してやらねば
ならないのかわからん。
興味が無かったり、やりかたがわからないんなら使わなければ
いいだけのことでは？
644 ：デフォルトの名無しさん：03/11/25 01:06
>>640
> 読んでないから知らんけど>>634氏によると、不適切な暫定コードが
> あってもずっとグリーンバーで、その暫定コードが残らないための頼りが
> プログラマの注意力しかないって事なんだよね。そうなん？それは嫌だ。
そのとおり。
それが嫌ならTDDはするな。
> 読んでないから知らんけど>>634氏によると、不適切な暫定コードが
> あってもずっとグリーンバーで、その暫定コードが残らないための頼りが
> プログラマの注意力しかないって事なんだよね。そうなん？それは嫌だ。
そのとおり。
それが嫌ならTDDはするな。
645 ：デフォルトの名無しさん：03/11/25 01:12
>>630
>テスト通すためにあんな下らないソース埋め込まなきゃならないの？
Yes
>テストが通るまでコード書いて通ったら次へ行くという形じゃないのか？
No
>あれじゃ次に行くタイミングを失敗したら変なコードが残りまくりだろ。
Yes
>定数にしている部分を直すのを忘れるなんて事日常でありそうだぞ。
Yes
>人間はミスをするという考えに元付いてやっているんじゃなかったのか？
No
>あんなに無理矢理テストをパスさせる必要性が解らん。
それがTDDだ。
全部答えてやったぞ。
>テスト通すためにあんな下らないソース埋め込まなきゃならないの？
Yes
>テストが通るまでコード書いて通ったら次へ行くという形じゃないのか？
No
>あれじゃ次に行くタイミングを失敗したら変なコードが残りまくりだろ。
Yes
>定数にしている部分を直すのを忘れるなんて事日常でありそうだぞ。
Yes
>人間はミスをするという考えに元付いてやっているんじゃなかったのか？
No
>あんなに無理矢理テストをパスさせる必要性が解らん。
それがTDDだ。
全部答えてやったぞ。
646 ：デフォルトの名無しさん：03/11/25 01:21
手元に原書しかないのでページ数を示せないが、
定数にしている部分を直すのを忘れるというミスは、
十分なテストケースを書くことで防ぐんだと理解してる。
テストケースはテストの仕様書であると同時に製品コードの仕様でもある。
件の本では、テストケースと平行して紙か何かに実装したテストケースを書いていて、
これで実装した仕様の一覧を管理してた。各章にあるよね？
あと、テストを通すだけの無駄なコードを書いているという点だけど、
あれは問題を簡単にするためのもので、実際の開発では
不要だと思えば省いてイイと解釈している。
件の本でも「ここはスピードアップする」とか何とか断って
テストを通すだけのコードを書くのを省いてるだろ？
「引数xが13～19の範囲ならtrue、そうでないならfalseを返す」
なんて単純なメソッドで、return (x >= 13) && (X <= 19);と実装すればいいことが
すぐに分かるようなら、いきなりそう書いてxに12、13、19、20を与えるテストケースを
書けばいい。
それが思いつかないようならテストケースとでっち上げのコードを書く。
テストケースとそれを満たす実装をごりごり書いているうちに
カバレッジ100%の実装が手にはいるっていう寸法だ。
ところで、TDDではテストケースがクラスの仕様と同じ意味を持つ、
と俺は理解しているんだが、
このテストケース＝クラスの仕様書がソフトウェアの要求仕様を
満たしているのか、という疑問が当然湧いてくるけど、
それについては答えてないよな。まあ、それはレイヤーが違ってことなんだろ。
これは別にTDDに限らず存在するわけで。
定数にしている部分を直すのを忘れるというミスは、
十分なテストケースを書くことで防ぐんだと理解してる。
テストケースはテストの仕様書であると同時に製品コードの仕様でもある。
件の本では、テストケースと平行して紙か何かに実装したテストケースを書いていて、
これで実装した仕様の一覧を管理してた。各章にあるよね？
あと、テストを通すだけの無駄なコードを書いているという点だけど、
あれは問題を簡単にするためのもので、実際の開発では
不要だと思えば省いてイイと解釈している。
件の本でも「ここはスピードアップする」とか何とか断って
テストを通すだけのコードを書くのを省いてるだろ？
「引数xが13～19の範囲ならtrue、そうでないならfalseを返す」
なんて単純なメソッドで、return (x >= 13) && (X <= 19);と実装すればいいことが
すぐに分かるようなら、いきなりそう書いてxに12、13、19、20を与えるテストケースを
書けばいい。
それが思いつかないようならテストケースとでっち上げのコードを書く。
テストケースとそれを満たす実装をごりごり書いているうちに
カバレッジ100%の実装が手にはいるっていう寸法だ。
ところで、TDDではテストケースがクラスの仕様と同じ意味を持つ、
と俺は理解しているんだが、
このテストケース＝クラスの仕様書がソフトウェアの要求仕様を
満たしているのか、という疑問が当然湧いてくるけど、
それについては答えてないよな。まあ、それはレイヤーが違ってことなんだろ。
これは別にTDDに限らず存在するわけで。
647 ：デフォルトの名無しさん：03/11/25 01:32
>646
>手元に原書しかないのでページ数を示せないが、
「手元に原書しかない」と「ページ数を示せない」の因果関係が解らん。
>手元に原書しかないのでページ数を示せないが、
「手元に原書しかない」と「ページ数を示せない」の因果関係が解らん。
648 ：デフォルトの名無しさん：03/11/25 01:32
>>646
それを補うのがペアプロ
それを補うのがペアプロ
649 ：デフォルトの名無しさん：03/11/25 01:33
>>647
真性馬鹿登場。荒らすなよ？
真性馬鹿登場。荒らすなよ？
650 ：デフォルトの名無しさん：03/11/25 01:37
>649
なんで手元に原書しかないとページ数示せないんだよ？
答えろやｳﾞｫｹ
なんで手元に原書しかないとページ数示せないんだよ？
答えろやｳﾞｫｹ
651 ：デフォルトの名無しさん：03/11/25 01:48
>>643-645
はいはい、さよなら。
いつまでも厨っぽいレスしててください。
>>646
> テストケースと平行して紙か何かに実装したテストケースを書いていて、
> これで実装した仕様の一覧を管理してた。各章にあるよね？
これはXPで言うところのストーリーカードに当たると思うんだけどこれでテストケースのミスを防げるものかな？
>>640の言うようにその暫定コードが残らないための頼りが プログラマ注意力しかないって言う問題は残ると思うけど。
テストを分割して粒度を小さくしていけば多少は防げるかも知れないけどねまぁ、そこらヘンの天秤は微妙だ。
> あと、テストを通すだけの無駄なコードを書いているという点だけど、
> あれは問題を簡単にするためのもので、実際の開発では
> 不要だと思えば省いてイイと解釈している。
自分はそうは思っていない。
荒れ野役割はテストがちゃんと機能することを実証するものだと考えている。
インターフェースの確定と言えばいいかな。
だからもしTDDをするなら省いてはいけないだろう。
beck 異常に定規でしこたま手を叩かれる。
あのスピードアップは本の特性上のモノで鵜呑みにしてはならないだろうただ上記のインターフェースの確定がダミーコード残留と天秤にかけて勝るのもなのか自分は疑問だな。
ダミーコードで通しても良いが次の瞬間それを全部削除するくらいの意識がないと本当の意味でのTDDとは言えないと思う。
> ところで、TDDではテストケースがクラスの仕様と同じ意味を持つ、
> と俺は理解しているんだが、
これは同意。
まぁ、言うようにレイヤーが違うが。
ここは受け入れテストで解決する問題。
はいはい、さよなら。
いつまでも厨っぽいレスしててください。
>>646
> テストケースと平行して紙か何かに実装したテストケースを書いていて、
> これで実装した仕様の一覧を管理してた。各章にあるよね？
これはXPで言うところのストーリーカードに当たると思うんだけどこれでテストケースのミスを防げるものかな？
>>640の言うようにその暫定コードが残らないための頼りが プログラマ注意力しかないって言う問題は残ると思うけど。
テストを分割して粒度を小さくしていけば多少は防げるかも知れないけどねまぁ、そこらヘンの天秤は微妙だ。
> あと、テストを通すだけの無駄なコードを書いているという点だけど、
> あれは問題を簡単にするためのもので、実際の開発では
> 不要だと思えば省いてイイと解釈している。
自分はそうは思っていない。
荒れ野役割はテストがちゃんと機能することを実証するものだと考えている。
インターフェースの確定と言えばいいかな。
だからもしTDDをするなら省いてはいけないだろう。
beck 異常に定規でしこたま手を叩かれる。
あのスピードアップは本の特性上のモノで鵜呑みにしてはならないだろうただ上記のインターフェースの確定がダミーコード残留と天秤にかけて勝るのもなのか自分は疑問だな。
ダミーコードで通しても良いが次の瞬間それを全部削除するくらいの意識がないと本当の意味でのTDDとは言えないと思う。
> ところで、TDDではテストケースがクラスの仕様と同じ意味を持つ、
> と俺は理解しているんだが、
これは同意。
まぁ、言うようにレイヤーが違うが。
ここは受け入れテストで解決する問題。
652 ：デフォルトの名無しさん：03/11/25 01:49
荒れ野役割はテストがちゃんと機能することを実証するものだと考えている。
↓
あれの役割はテストがちゃんと機能することを実証するものだと考えている。
↓
あれの役割はテストがちゃんと機能することを実証するものだと考えている。
653 ：デフォルトの名無しさん：03/11/25 02:12
こんな感じか
1.テストケースを書く
2.ダミーコードを書く⇒緑／テストケースとの連携を確立
3.ダミーコードを消す。⇒赤／不完全なコードをはじく事を実証
4.本物のコードを書く⇒緑／コードが正しい事を実証
2と3が充分にくっ付いていてアトミックな動きなら、悪くないな。
てか全面的にではないにせよ普段やってるかも。
1.テストケースを書く
2.ダミーコードを書く⇒緑／テストケースとの連携を確立
3.ダミーコードを消す。⇒赤／不完全なコードをはじく事を実証
4.本物のコードを書く⇒緑／コードが正しい事を実証
2と3が充分にくっ付いていてアトミックな動きなら、悪くないな。
てか全面的にではないにせよ普段やってるかも。
654 ：デフォルトの名無しさん：03/11/25 02:47
>>653
そう、そんな感じ。
コストも消すだけだからほとんど無いし。
あと、TDD でいけば論理上カバレッジ100%になるとは思うんだけど本当にそううまくいくかねぇ
テストケースの取捨選択で切り捨てるものを見極める目がないと結構ドツボにハマりそう。
ここらは経験だろうな。
そう、そんな感じ。
コストも消すだけだからほとんど無いし。
あと、TDD でいけば論理上カバレッジ100%になるとは思うんだけど本当にそううまくいくかねぇ
テストケースの取捨選択で切り捨てるものを見極める目がないと結構ドツボにハマりそう。
ここらは経験だろうな。
655 ：デフォルトの名無しさん：03/11/25 03:17
>>651
荒らすのが目的なら来ないでくれまいか。
荒らすのが目的なら来ないでくれまいか。
>>651
そうではなくて、本当に議論するのが目的なら、名前に番号でも入れてくれ。
本当に>>630=>>651なのか？もしそうだとしたら、>>630は釣りと言われても
しかたないような書き込みだったぞ。
そうではなくて、本当に議論するのが目的なら、名前に番号でも入れてくれ。
本当に>>630=>>651なのか？もしそうだとしたら、>>630は釣りと言われても
しかたないような書き込みだったぞ。
657 ：デフォルトの名無しさん：03/11/25 03:36
ただグチャグチャ言っているだけの外野はなんなんだろ。
毒にも薬にもならないチャチャはハッキリ言って邪魔。
646や651の方が見てて面白い。
毒にも薬にもならないチャチャはハッキリ言って邪魔。
646や651の方が見てて面白い。
658 ：デフォルトの名無しさん：03/11/25 03:43
659 ：デフォルトの名無しさん：03/11/25 03:46
660 ：デフォルトの名無しさん：03/11/25 03:49
>>655-657
お前らみんな邪魔なんだけど。氏んでくれる？
お前らみんな邪魔なんだけど。氏んでくれる？
661 ：デフォルトの名無しさん：03/11/25 03:52
こんな真夜中にごくろうさまでつm(__)m
662 ：デフォルトの名無しさん：03/11/25 04:14
>>659
ダミーコード消す手法なんか書いてあったか？
ダミーコード消す手法なんか書いてあったか？
663 ：デフォルトの名無しさん：03/11/25 04:16
>>660
2chが邪魔と・・・
2chが邪魔と・・・
664 ：デフォルトの名無しさん：03/11/25 04:57
665 ：デフォルトの名無しさん：03/11/25 05:47
俺の読んだ TDD はこんな流れだった気がする。
1. テストを書く -> テスト対象が未実装なのでコンパイルエラー
2. コンパイルが通るだけの最低限の実装を書く -> レッドバーになる
3. テストが通る最も簡単な実装を書く -> グリーンバー
4. いーかげんな実装でテストがパスしてしまうようであれば、テストが不十
分なのでテストを追加する(三角測量とかいう表現)
5. 3と4を何回か繰り返し、十分なテストと、それにパスできる実装が実現で
きたら、リファクタリングを行い、冗長性とかわかりづらい表現を取り除く
リファクタリングフェイズで、あらためてソースを見直すので、原則的には後
で取り除くべきことを記憶しておかねば*ならない*ということはないはず。
実装時にちょっと気を使えば余計なリファクタリングの手間が減るじゃん、と
か思うかもしれないが、後から見直すことによって気がつくことも多いので、
必ず最後にリファクタリングを行うべし、ということだと思う。
テストを書くときと、実装を書くときと、リファクタリングをするときで、仮
想的に人格を使い分けることが求められるので、「あほくさ」と思う人もいる
んだろうな、という気はする。
1. テストを書く -> テスト対象が未実装なのでコンパイルエラー
2. コンパイルが通るだけの最低限の実装を書く -> レッドバーになる
3. テストが通る最も簡単な実装を書く -> グリーンバー
4. いーかげんな実装でテストがパスしてしまうようであれば、テストが不十
分なのでテストを追加する(三角測量とかいう表現)
5. 3と4を何回か繰り返し、十分なテストと、それにパスできる実装が実現で
きたら、リファクタリングを行い、冗長性とかわかりづらい表現を取り除く
リファクタリングフェイズで、あらためてソースを見直すので、原則的には後
で取り除くべきことを記憶しておかねば*ならない*ということはないはず。
実装時にちょっと気を使えば余計なリファクタリングの手間が減るじゃん、と
か思うかもしれないが、後から見直すことによって気がつくことも多いので、
必ず最後にリファクタリングを行うべし、ということだと思う。
テストを書くときと、実装を書くときと、リファクタリングをするときで、仮
想的に人格を使い分けることが求められるので、「あほくさ」と思う人もいる
んだろうな、という気はする。
666 ：デフォルトの名無しさん：03/11/25 06:07
>>665
ちょっと違うと思う。リファクタリングはもっと頻繁に行われる。
1. テストを作成する
2. コンパイルできるようにする
3. 実行して、失敗を確認する
4. 動作させる
5. 重複を取り除く
というのがTDDのフェーズで、TDDのマントラに対応させると
Red(1-3)/Green(4)/Refactor(5)
だと書かれてる。
>>665の4は5.重複を取り除くに含まれると俺は思います。
TDDで言う"Refactor"と、『リファクタリング』のrefactoringはレイヤーが違うと思う。
ちょっと違うと思う。リファクタリングはもっと頻繁に行われる。
1. テストを作成する
2. コンパイルできるようにする
3. 実行して、失敗を確認する
4. 動作させる
5. 重複を取り除く
というのがTDDのフェーズで、TDDのマントラに対応させると
Red(1-3)/Green(4)/Refactor(5)
だと書かれてる。
>>665の4は5.重複を取り除くに含まれると俺は思います。
TDDで言う"Refactor"と、『リファクタリング』のrefactoringはレイヤーが違うと思う。
667 ：デフォルトの名無しさん：03/11/25 06:21
ところで、"Test Driven Development: A Practical Guide"買った人いる？
俺はAmazonのClayton Carneyのレビューが気になるんだけど、とりあえずオーダーしたよ。
他の三人は星５つなんだけどなあ…
俺はAmazonのClayton Carneyのレビューが気になるんだけど、とりあえずオーダーしたよ。
他の三人は星５つなんだけどなあ…
668 ：デフォルトの名無しさん：03/11/25 12:54
つーか、お前ら手元に本があるんだったらもう一回読み直せよ。
いくら訳がひどいといっても、お前らの読解力はなさすぎだぞ。
その上で、「ここの解釈はどう？」みたいな話をやってくれよ。
特に>>651,653、お前らだ。「どこが間違ってるか指摘しなよ」なんて
厨っぽいこと言う前に、もう一回TDDを読み直せ。
いくら訳がひどいといっても、お前らの読解力はなさすぎだぞ。
その上で、「ここの解釈はどう？」みたいな話をやってくれよ。
特に>>651,653、お前らだ。「どこが間違ってるか指摘しなよ」なんて
厨っぽいこと言う前に、もう一回TDDを読み直せ。
669 ：デフォルトの名無しさん：03/11/25 13:17
>>651
>beck 異常に定規でしこたま手を叩かれる。
定規で手を叩かれるのは、テストより先に実装を考えようとした場合。
TDDの粒度を自分のペースに制御することについては、しつこいぐらい書いてあるだろ。
>beck 異常に定規でしこたま手を叩かれる。
定規で手を叩かれるのは、テストより先に実装を考えようとした場合。
TDDの粒度を自分のペースに制御することについては、しつこいぐらい書いてあるだろ。
670 ：デフォルトの名無しさん：03/11/25 13:18
>>651,653から「どこが間違ってるか指摘しなよ」という意見が読み取れる
668の読解力もたいしたものだ。レス番号の間違いだと好意的に解釈したいが。
668の読解力もたいしたものだ。レス番号の間違いだと好意的に解釈したいが。
671 ：デフォルトの名無しさん：03/11/25 13:21
どうして>>630のような馬鹿は自分が絶対真理がわかっているみたいな勘違いをするんだろうねぇ。
議論にならないのは、自分がスタートラインに立ててないからだと気づかないんだろうか。
ちょっといじられると逆切れして暴れちゃうし。
議論にならないのは、自分がスタートラインに立ててないからだと気づかないんだろうか。
ちょっといじられると逆切れして暴れちゃうし。
672 ：デフォルトの名無しさん：03/11/25 13:25
>>670
いや番号はあっている。
彼らは根本的な誤読をしているからTDDの再読を勧めるのだけれど、
そのように書くと「どこが間違ってるか具体的に指摘しろ」ってことに
なりがちで、されにあきれてスルーすると「やっぱり指摘できないじゃないか」
という流れになるのは火を見るより明らか。
最近そういう奴らがおおいから。ム板でもマ板でも。
いや番号はあっている。
彼らは根本的な誤読をしているからTDDの再読を勧めるのだけれど、
そのように書くと「どこが間違ってるか具体的に指摘しろ」ってことに
なりがちで、されにあきれてスルーすると「やっぱり指摘できないじゃないか」
という流れになるのは火を見るより明らか。
最近そういう奴らがおおいから。ム板でもマ板でも。
673 ：デフォルトの名無しさん：03/11/25 13:29
頼むから荒れる要因になるような書き込みはしないでくれ。
674 ：デフォルトの名無しさん：03/11/25 13:32
TDDはいったんGreenにしたら、その状態を保って以降の作業をすることが
大事なんだよ。それぐらい読み取れよ。
大事なんだよ。それぐらい読み取れよ。
675 ：デフォルトの名無しさん：03/11/25 13:40
つーか、>>630=>>651じゃないでしょ。テストを通すためにあらゆる罪を犯すことについて>>630は
>テスト通すためにあんな下らないソース埋め込まなきゃならないの？
と書いているが、>>651は
>荒れ野役割はテストがちゃんと機能することを実証するものだと考えている。
>インターフェースの確定と言えばいいかな。
って書いてるよ。
>テスト通すためにあんな下らないソース埋め込まなきゃならないの？
と書いているが、>>651は
>荒れ野役割はテストがちゃんと機能することを実証するものだと考えている。
>インターフェースの確定と言えばいいかな。
って書いてるよ。
676 ：デフォルトの名無しさん：03/11/25 13:44
>>653はTDD読んでないんじゃないの？
677 ：デフォルトの名無しさん：03/11/25 13:49
678 ：デフォルトの名無しさん：03/11/25 13:55
>>646
> あと、テストを通すだけの無駄なコードを書いているという点だけど、
> あれは問題を簡単にするためのもので、実際の開発では
> 不要だと思えば省いてイイと解釈している。
TDDは「不安を可能な限り取り除くメソッド」だからコードの実装に数分以上
かかるようなら、テストを通すためのコードを先に書いとけ、ってことだと思う。
「なかなかグリーンになんねー」じゃなくて、最初にグリーンにしといて「う、レッド
になっちまった」の方が、誤りを検出しやすいってことだと思う。
> あと、テストを通すだけの無駄なコードを書いているという点だけど、
> あれは問題を簡単にするためのもので、実際の開発では
> 不要だと思えば省いてイイと解釈している。
TDDは「不安を可能な限り取り除くメソッド」だからコードの実装に数分以上
かかるようなら、テストを通すためのコードを先に書いとけ、ってことだと思う。
「なかなかグリーンになんねー」じゃなくて、最初にグリーンにしといて「う、レッド
になっちまった」の方が、誤りを検出しやすいってことだと思う。
679 ：デフォルトの名無しさん：03/11/25 14:05
680 ：デフォルトの名無しさん：03/11/25 14:14
681 ：デフォルトの名無しさん：03/11/25 14:24
嵐の悪寒・・・
682 ：デフォルトの名無しさん：03/11/25 14:29
g/TDD/d
もうこのスレではTDDの話題禁止！
もうこのスレではTDDの話題禁止！
683 ：デフォルトの名無しさん：03/11/25 14:35
なんか500番台の不毛な議論と似てるね。
参加してるメンバーも同じようなメンバーじゃないの？ﾔﾚﾔﾚ
参加してるメンバーも同じようなメンバーじゃないの？ﾔﾚﾔﾚ
684 ：デフォルトの名無しさん：03/11/25 15:41
>>630が一番馬鹿っぽい。
685 ：デフォルトの名無しさん：03/11/25 15:51
もうやめろって。痛いよ。
686 ：デフォルトの名無しさん：03/11/25 16:24
sarasiage
687 ：デフォルトの名無しさん：03/11/25 16:52
Kent Beckのエピソード持ち出してる人痛いね。
688 ：デフォルトの名無しさん：03/11/25 21:02
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
いつまでも厨っぽいレスしててください。
689 ：デフォルトの名無しさん：03/11/25 21:17
カバレッジ100%にするなんてどう考えても人間のやることじゃないよね。
691 ：デフォルトの名無しさん：03/11/25 21:45
>>680
カバレッジ解ってる？
カバレッジ解ってる？
692 ：デフォルトの名無しさん：03/11/25 21:48
もう揚げ足取りはやめような？
693 ：デフォルトの名無しさん：03/11/25 21:56
言葉少なでレスが誰に対するものなのかさっぱりわからない。
みなさん議論下手糞ですね。
そもそも匿名同士の議論なんて無理なのかもしれませんが。
議論する人、コテハンとかトリップ付けるってのどうですか？
もちろん名無しさんによるｼﾞｻｸｼﾞｴﾝ援護射撃もありです。
最低限レス番号は必ず指定して欲しいです。
みなさん議論下手糞ですね。
そもそも匿名同士の議論なんて無理なのかもしれませんが。
議論する人、コテハンとかトリップ付けるってのどうですか？
もちろん名無しさんによるｼﾞｻｸｼﾞｴﾝ援護射撃もありです。
最低限レス番号は必ず指定して欲しいです。
694 ：デフォルトの名無しさん：03/11/25 21:57
>>690
ではお前の想像は完全に間違ってる。Q.E.D.
ではお前の想像は完全に間違ってる。Q.E.D.
695 ：デフォルトの名無しさん：03/11/25 22:00
>>693
つーか、相手が馬鹿すぎて議論にならないんですが。
つーか、相手が馬鹿すぎて議論にならないんですが。
どうやれば100%にならないというのだ？
TDDでやれば100%にならないはずはないだろうが。
TDDでやれば100%にならないはずはないだろうが。
あー、ひょっとしてTDDを正しく実践できれば100%のカバレッジになるが、
「正しく実践できるかどうか」がわからないので、100%のカバレッジにならない
かもしれないということか？
だとしたら、それはその通りで、正しく実践できなければ100%のカバレッジには
ならない。
「正しく実践できるかどうか」がわからないので、100%のカバレッジにならない
かもしれないということか？
だとしたら、それはその通りで、正しく実践できなければ100%のカバレッジには
ならない。
698 ：デフォルトの名無しさん：03/11/25 22:19
しばらく680のワンマンショーをお楽しみください。
699 ：デフォルトの名無しさん：03/11/25 22:21
>>693
>言葉少なでレスが誰に対するものなのかさっぱりわからない。
>みなさん議論下手糞ですね。
>そもそも匿名同士の議論なんて無理なのかもしれませんが。
基本的に議論のスキルがないだけでしょ。
論理的思考能力にも欠けてるみたいだし。
アフォばっか。
>言葉少なでレスが誰に対するものなのかさっぱりわからない。
>みなさん議論下手糞ですね。
>そもそも匿名同士の議論なんて無理なのかもしれませんが。
基本的に議論のスキルがないだけでしょ。
論理的思考能力にも欠けてるみたいだし。
アフォばっか。
700 ：デフォルトの名無しさん：03/11/25 22:21
>>698
お前マジいらん。氏んで。
お前マジいらん。氏んで。
701 ：デフォルトの名無しさん：03/11/25 22:28
カバレッジは100%にしようと思わなければ、どのようなメソドロジーでも100%にはならない。
702 ：デフォルトの名無しさん：03/11/25 22:32
ひまだねぇ、みんな。
君らが知りたいことは全部本に書かれてるよ。
つーか本嫁、ヴォケ。スレを汚すな。
君らが知りたいことは全部本に書かれてるよ。
つーか本嫁、ヴォケ。スレを汚すな。
703 ：デフォルトの名無しさん：03/11/25 22:33
>>700,702
お前らもいらない。芯でいいよ。
お前らもいらない。芯でいいよ。
704 ：デフォルトの名無しさん：03/11/25 22:34
705 ：デフォルトの名無しさん：03/11/25 22:38
「すれ立てるまでもない質問」スレも連休中ひどかったが、ここも酷いね。
俺はム板のスレは少ししか見ないが、ひょとして他のスレもこんなかんじ
なのかなぁ。前はもうちょっとまともだったような気がするんだけど。
俺はム板のスレは少ししか見ないが、ひょとして他のスレもこんなかんじ
なのかなぁ。前はもうちょっとまともだったような気がするんだけど。
>>694、>>704
そんなムキになるなよ。
>>653は>>651へのレスだから。
信者はとりあえず置いといて、同じような議論がc2.comにもあった。
http://c2.com/cgi/wiki?TestDrivenDevelopment
JohnRusk? worries one danger of TestDrivenDevelopment is that
developers may _not_ take that step that you take. I.e. developers
may stay with overly concrete code that satisfies the tests but not
the "real" requirements.
で、本来UnitTestはPass/Fail/Fakedの３ステートを持つべきだとか、
なかなか面白い話が載ってる。
ちなみに>>646の「十分なテストケース」は否定してPairProgrammingを
あげてる箇所もあった（>>648のように）。単体では不十分なプラクティスが
互いを補う好例という事らしい。この辺り、TDDの独立性を主張する人が
いたら対立点になるだろうな。
ま何となく分かってきたし、本は要りそうにないな。
そんなムキになるなよ。
>>653は>>651へのレスだから。
信者はとりあえず置いといて、同じような議論がc2.comにもあった。
http://c2.com/cgi/wiki?TestDrivenDevelopment
JohnRusk? worries one danger of TestDrivenDevelopment is that
developers may _not_ take that step that you take. I.e. developers
may stay with overly concrete code that satisfies the tests but not
the "real" requirements.
で、本来UnitTestはPass/Fail/Fakedの３ステートを持つべきだとか、
なかなか面白い話が載ってる。
ちなみに>>646の「十分なテストケース」は否定してPairProgrammingを
あげてる箇所もあった（>>648のように）。単体では不十分なプラクティスが
互いを補う好例という事らしい。この辺り、TDDの独立性を主張する人が
いたら対立点になるだろうな。
ま何となく分かってきたし、本は要りそうにないな。
707 ：デフォルトの名無しさん：03/11/25 22:57
XPで組んだとしても例えば、二人して徹夜して神が降りたコード書いて
バグ埋めこんだら結局デスマーチですよね。
結局何人に増えようが同じ事です。
そもそも塵芥戦術は不実雨の得意とする戦略なんで、真似したくないですよね。
バグ埋めこんだら結局デスマーチですよね。
結局何人に増えようが同じ事です。
そもそも塵芥戦術は不実雨の得意とする戦略なんで、真似したくないですよね。
708 ：デフォルトの名無しさん：03/11/25 22:58
ようするに、お前らデスマの最中にXPがどうとか夢みたいなこと言ってないで
目の前の仕事を片付けろってこった。
しょせんXPなんて顧客と上司が納得するわきゃないんだしよ。
XPもアジャイルもRUPも死滅！これからもこの先もWFで決まり！
目の前の仕事を片付けろってこった。
しょせんXPなんて顧客と上司が納得するわきゃないんだしよ。
XPもアジャイルもRUPも死滅！これからもこの先もWFで決まり！
709 ：デフォルトの名無しさん：03/11/25 22:59
結論が、出てしまいましたね。
>>705
ボヤキは良いから、なんか意見書け。
てか俺と一緒にTesting Patterns丸暗記しようぜ。
AbstractTest CoverTheGraph
CodeUnitTestFirst DefectSeeding
EncapsulateNewForTestability ExpectedResult
GuruWritesAutomatedTest JournallingPattern
MockObject MutationTesting
OptimizationUnitTest RandomTesting
ShuntPattern SupportingUnitTest
TacticalTesting TestBoundaryConditions
TestEnvironments TestEverythingThatCouldPossiblyBreak
TestEveryRefactoring TestingErrorHandling
TestNull TestOverridesNow
TestPrintedOutput TestTransactions
TestsAsScaffolding TouchstoneBuild
UnitTestAsTickler UnitTestDelegator
UnitTestingJavaEvents VirtualClock
AsynchronousUnitTesting BigBangTesting
CodeAndFix GuruChecksOutput
TestByReleasing TestingByPokingAround
TestInQuality TestOnlyWhatWorks
TestOnlyPositively
TestDatabase
ボヤキは良いから、なんか意見書け。
てか俺と一緒にTesting Patterns丸暗記しようぜ。
AbstractTest CoverTheGraph
CodeUnitTestFirst DefectSeeding
EncapsulateNewForTestability ExpectedResult
GuruWritesAutomatedTest JournallingPattern
MockObject MutationTesting
OptimizationUnitTest RandomTesting
ShuntPattern SupportingUnitTest
TacticalTesting TestBoundaryConditions
TestEnvironments TestEverythingThatCouldPossiblyBreak
TestEveryRefactoring TestingErrorHandling
TestNull TestOverridesNow
TestPrintedOutput TestTransactions
TestsAsScaffolding TouchstoneBuild
UnitTestAsTickler UnitTestDelegator
UnitTestingJavaEvents VirtualClock
AsynchronousUnitTesting BigBangTesting
CodeAndFix GuruChecksOutput
TestByReleasing TestingByPokingAround
TestInQuality TestOnlyWhatWorks
TestOnlyPositively
TestDatabase
711 ：デフォルトの名無しさん：03/11/25 23:00
＞二人して徹夜
この時点でデスマーチって、
い わ な い か ？
この時点でデスマーチって、
い わ な い か ？
712 ：デフォルトの名無しさん：03/11/25 23:03
もうテストなんていいから、
デ ス マ ー チ や ら な い か ？
デ ス マ ー チ や ら な い か ？
713 ：デフォルトの名無しさん：03/11/25 23:04
ベアプロなんて無理。
同僚となんか気持ち悪くてできない。
XPはもうこの時点で破綻している。
同僚となんか気持ち悪くてできない。
XPはもうこの時点で破綻している。
714 ：デフォルトの名無しさん：03/11/25 23:07
それは言えてる。
XPはファンタジーなんだって思う。
本買う奴って指輪物語とか読んでるだろ。
ｷｼｮｲ
XPはファンタジーなんだって思う。
本買う奴って指輪物語とか読んでるだろ。
ｷｼｮｲ
715 ：デフォルトの名無しさん：03/11/25 23:09
716 ：デフォルトの名無しさん：03/11/25 23:12
715
発想が短絡的だな。
貧乏人でも図書館とか使えるだろ。
身元を証明できない様な橋の下の住人とかだな。
発想が短絡的だな。
貧乏人でも図書館とか使えるだろ。
身元を証明できない様な橋の下の住人とかだな。
717 ：デフォルトの名無しさん：03/11/25 23:14
つーかさ、プログラムも流れ作業にできないの？
ISOに準拠とか。そういう基準を満たす努力だけしてればいいんだよ。
役に立つかどうかも判らない方法論の本なんか読んでも飯は食えないよ。
ISOに準拠とか。そういう基準を満たす努力だけしてればいいんだよ。
役に立つかどうかも判らない方法論の本なんか読んでも飯は食えないよ。
718 ：デフォルトの名無しさん：03/11/25 23:16
流し読みしたけど結局>>653と>>651が一番マトモに議論してるじゃん。
他はもう盲信しているだけの考えることを投げた奴等ばかりだな。
常にテストの粒度を最低限に出来ると思いこんでいるのもイタい。
これじゃ実践的で柔軟な対処は出来ないだろう。
先にテストをパスさせる方法はこういう場合のイリーガルな揺れに弱い。
他はもう盲信しているだけの考えることを投げた奴等ばかりだな。
常にテストの粒度を最低限に出来ると思いこんでいるのもイタい。
これじゃ実践的で柔軟な対処は出来ないだろう。
先にテストをパスさせる方法はこういう場合のイリーガルな揺れに弱い。
719 ：デフォルトの名無しさん：03/11/25 23:16
カバレッジ100%と仕様を満たすのとは違うからな。
720 ：デフォルトの名無しさん：03/11/25 23:18
>>718
よくわからんが、どっちかの自作自演と見た。
よくわからんが、どっちかの自作自演と見た。
721 ：デフォルトの名無しさん：03/11/25 23:21
>>713
議論のやり方を勉強してから出直したほうがいいよ。
議論のやり方を勉強してから出直したほうがいいよ。
722 ：デフォルトの名無しさん：03/11/25 23:22
723 ：デフォルトの名無しさん：03/11/25 23:35
あ～らら。
誰か、まともな意見のポインタ張ってくれない？
読む気にならん。
誰か、まともな意見のポインタ張ってくれない？
読む気にならん。
724 ：デフォルトの名無しさん：03/11/25 23:38
725 ：デフォルトの名無しさん：03/11/25 23:42
長文＝ある程度解っている
短文＝ただの煽り屑
だいたい合ってる？
短文＝ただの煽り屑
だいたい合ってる？
726 ：デフォルトの名無しさん：03/11/25 23:44
727 ：デフォルトの名無しさん：03/11/25 23:46
＞710
その Testing Patterns ってどこに載ってるの？
ひょっとして本でてる？
その Testing Patterns ってどこに載ってるの？
ひょっとして本でてる？
728 ：デフォルトの名無しさん：03/11/25 23:49
729 ：デフォルトの名無しさん：03/11/25 23:50
開発プロセス（ＸＰ、ＲＵＰに限らず）導入の正当化をどう説明していますか？
この度、客先に常駐して社内の情報システムの開発を請け負うことになりました。
企業文化とでもいうのでしょうか業務が動けばいいという考えが強いです。
すでにデータベースはプロパーの方が先走って作成しまっており
無数の責任の所在が不明なプログラムが右往左往しながら
うまく動かないところは人海戦術で無理矢理運用しているという状態です。
このような状態で他の部署のシステムと連携してしまったらしく
今動いているところはそのままの仕様でお願いすると提言されました。
問題なのはこの状態が異常だという認識がまったく無いということです。
開発プロセスの適用はおろかドキュメント作るのも無駄な作業だというレベルです。
提示される要求定義について論議する場を与えられず困惑しています。
この要求にある機能の影響範囲を聞いたのですが「煩わしい、業務の邪魔だ」と一喝されます。
要求定義書というものの内容の粒度が大きいものから細かすぎるものまで混在しています。
この要求定義書から実装をせまられます。
不明なところは手で運用したり個別にメールで対応しＳＱＬ直打ちで対応すればよいとのこと。
開発プロセスの重要性を説明したのですが業務に対して直接作用するものではないので
無駄な作業だと頑として異を唱え続けています。論議する場を与えてくれません。
こうしている間にもプロパーの方々が次々にプログラムを作ってます（品質は最低）。
ここで説明した開発プロセスはＸＰとかＲＵＰとかいった具体的なものではなく
「システム開発とは何ぞや。プロジェクトとは何ぞや」を重点的に説明しました。
この会社、一般の人からみると名の知れた堅実な企業ですよ。
この度、客先に常駐して社内の情報システムの開発を請け負うことになりました。
企業文化とでもいうのでしょうか業務が動けばいいという考えが強いです。
すでにデータベースはプロパーの方が先走って作成しまっており
無数の責任の所在が不明なプログラムが右往左往しながら
うまく動かないところは人海戦術で無理矢理運用しているという状態です。
このような状態で他の部署のシステムと連携してしまったらしく
今動いているところはそのままの仕様でお願いすると提言されました。
問題なのはこの状態が異常だという認識がまったく無いということです。
開発プロセスの適用はおろかドキュメント作るのも無駄な作業だというレベルです。
提示される要求定義について論議する場を与えられず困惑しています。
この要求にある機能の影響範囲を聞いたのですが「煩わしい、業務の邪魔だ」と一喝されます。
要求定義書というものの内容の粒度が大きいものから細かすぎるものまで混在しています。
この要求定義書から実装をせまられます。
不明なところは手で運用したり個別にメールで対応しＳＱＬ直打ちで対応すればよいとのこと。
開発プロセスの重要性を説明したのですが業務に対して直接作用するものではないので
無駄な作業だと頑として異を唱え続けています。論議する場を与えてくれません。
こうしている間にもプロパーの方々が次々にプログラムを作ってます（品質は最低）。
ここで説明した開発プロセスはＸＰとかＲＵＰとかいった具体的なものではなく
「システム開発とは何ぞや。プロジェクトとは何ぞや」を重点的に説明しました。
この会社、一般の人からみると名の知れた堅実な企業ですよ。
730 ：デフォルトの名無しさん：03/11/26 00:00
おまい以外が異常と認識してないなら問題なし。
社内業務で無駄な工数増やすこともない。
社内業務で無駄な工数増やすこともない。
731 ：デフォルトの名無しさん：03/11/26 00:01
>>729
なんかウチの会社のような・・・汗
個人でリファクタリングをするぐらいが精々だと思いますよ。
最後まで情報の齟齬でもたつくので時間も取れず、まともなテストケースを書いてる時間は貰えないでしょう。
粒度が大きくなりTDDすらおそらく実践出来ない。
でも、現実として多いですよこういう企業。
なんかウチの会社のような・・・汗
個人でリファクタリングをするぐらいが精々だと思いますよ。
最後まで情報の齟齬でもたつくので時間も取れず、まともなテストケースを書いてる時間は貰えないでしょう。
粒度が大きくなりTDDすらおそらく実践出来ない。
でも、現実として多いですよこういう企業。
732 ：デフォルトの名無しさん：03/11/26 00:02
>>730
ドカティな意見だね。
ドカティな意見だね。
733 ：デフォルトの名無しさん：03/11/26 00:03
手書きからデータ入力ぐらいのパラダイムシフトを見せ付けないと
効果ないと思われ。まずはゲリラ的に実践すれ。
効果ないと思われ。まずはゲリラ的に実践すれ。
734 ：デフォルトの名無しさん：03/11/26 00:04
690へのまともな意見まだぁ～
735 ：デフォルトの名無しさん：03/11/26 00:05
似たようなもんか。
じゃあ手書きからバッチジョブぐらいでどうだ。
じゃあ手書きからバッチジョブぐらいでどうだ。
736 ：デフォルトの名無しさん：03/11/26 00:06
734=690
名無しって便利やねー
名無しって便利やねー
737 ：デフォルトの名無しさん：03/11/26 00:07
738 ：デフォルトの名無しさん：03/11/26 00:09
739 ：デフォルトの名無しさん：03/11/26 00:15
740 ：デフォルトの名無しさん：03/11/26 00:16
738=734=690
何の意見を聞きたいんだ
何の意見を聞きたいんだ
それに690はTDDに関して酷い勘違いをしているし、本を読むつもりもないそうだから、
TDDに関しても議論する余地だしなし。
TDDに関しても議論する余地だしなし。
742 ：デフォルトの名無しさん：03/11/26 00:17
だしなしって何だよ俺。
余地なしだし、だな。
余地なしだし、だな。
743 ：デフォルトの名無しさん：03/11/26 00:20
判るのは690が恥知らずの粘着って事ぐらい
744 ：729：03/11/26 00:20
あらゆる業務遂行者が個別に抱えている問題を直接持ち寄せられ実装を依頼されます。
「今週中までにデータつくりたいので木曜日の昼までにプログラム作ってくれ」とか。
利用者からの電話は鳴りまくりその都度対応しているのが目立ちます。
利用者のメールサーバのデータがトンでも
「復元できないので再送してもらってください」など運用もずさんです。
問題がさらなる問題を発生させるどうしようもない状態です。
上の人に理解と協力を求めているのですが
どうも現状の混沌とした状態を維持するのが手一杯です。
それを解決させるためにあなたたちに今回の仕事をお願いしたんだから何とかしろと非協力的です。
今回の開発を正当化するところからはじめないと駄目なようです。
ノウハウ本などの情報と経験則から得た知識から知恵を搾り出し
話の持っていき方なども考慮しつつ説明しているのですが
建設的な作業だと察すると不機嫌になり破壊的な論議にもっていこうとします。
すでに行き詰まってしまいました。
よきアドバイスを願います。
「今週中までにデータつくりたいので木曜日の昼までにプログラム作ってくれ」とか。
利用者からの電話は鳴りまくりその都度対応しているのが目立ちます。
利用者のメールサーバのデータがトンでも
「復元できないので再送してもらってください」など運用もずさんです。
問題がさらなる問題を発生させるどうしようもない状態です。
上の人に理解と協力を求めているのですが
どうも現状の混沌とした状態を維持するのが手一杯です。
それを解決させるためにあなたたちに今回の仕事をお願いしたんだから何とかしろと非協力的です。
今回の開発を正当化するところからはじめないと駄目なようです。
ノウハウ本などの情報と経験則から得た知識から知恵を搾り出し
話の持っていき方なども考慮しつつ説明しているのですが
建設的な作業だと察すると不機嫌になり破壊的な論議にもっていこうとします。
すでに行き詰まってしまいました。
よきアドバイスを願います。
745 ：デフォルトの名無しさん：03/11/26 00:22
みんな「粒度」でこのスレ検索してごらんよ。面白いから。
746 ：デフォルトの名無しさん：03/11/26 00:22
>>740
だから 690 じゃ無いってのｗ
690 の考えるテストとチミ達が信じてやまない（盲信？） TDD のぶつかり合いを見たい訳よ。
今のままだと 690 のワンサイドだよ？
わかる？
チミ達下らないことしか言ってないしね。
だから 690 じゃ無いってのｗ
690 の考えるテストとチミ達が信じてやまない（盲信？） TDD のぶつかり合いを見たい訳よ。
今のままだと 690 のワンサイドだよ？
わかる？
チミ達下らないことしか言ってないしね。
747 ：デフォルトの名無しさん：03/11/26 00:23
>>744
「できません」って言えないのか
「できません」って言えないのか
748 ：デフォルトの名無しさん：03/11/26 00:24
>>747
小学生？
小学生？
749 ：デフォルトの名無しさん：03/11/26 00:25
750 ：デフォルトの名無しさん：03/11/26 00:25
>>746
チミ達って、おまえ偉そうだな
チミ達って、おまえ偉そうだな
751 ：デフォルトの名無しさん：03/11/26 00:25
>>748
つまり精神的に苦痛だと。
つまり精神的に苦痛だと。
752 ：デフォルトの名無しさん：03/11/26 00:25
>>750
いや、ちょっと面白いかなと思ってｗ
いや、ちょっと面白いかなと思ってｗ
753 ：デフォルトの名無しさん：03/11/26 00:25
>>746
どうでもいいけど、君の意見でも690に献上して差し上げたら？
どうでもいいけど、君の意見でも690に献上して差し上げたら？
754 ：デフォルトの名無しさん：03/11/26 00:27
>>753
つき合ってくれる？
つき合ってくれる？
>>746
論点が無いんだから、議論しようが無いんだが。
論点が無いんだから、議論しようが無いんだが。
756 ：デフォルトの名無しさん：03/11/26 00:29
746=738=734=690
しつこく本読めって言われてるんだから、一度読めば？
話が進展しそうにない気がするけど。
しつこく本読めって言われてるんだから、一度読めば？
話が進展しそうにない気がするけど。
757 ：デフォルトの名無しさん：03/11/26 00:29
「妄信してる」と言っている本人が思考停止していることが多い。今回もそんな感じ。
758 ：729：03/11/26 00:31
>>747
このような状態では開発は始められないと伝えています。
担当者レベルから直接依頼されるものにも保留にしています。
今の業務を回せと目先の利益を求められるつつ、
この混沌とした状態を何とか解決しろと滅茶苦茶です。
業務分析に協力してくれるひとは居ません。
このような状態では開発は始められないと伝えています。
担当者レベルから直接依頼されるものにも保留にしています。
今の業務を回せと目先の利益を求められるつつ、
この混沌とした状態を何とか解決しろと滅茶苦茶です。
業務分析に協力してくれるひとは居ません。
759 ：デフォルトの名無しさん：03/11/26 00:32
>>755
ぱっとこのスレ読んだ感じだけど TDD はグリーンバーにしてから本実装なんでしょ？
違ったか？ようわからんがそのはずだｗ
それに対して690(651も？)はそれ以外でもやり方あるんじゃねぇかゴルァ！！って言ってる・・・ような気がする。
とりあえずアカに一回戻せや！！みたいな。
706 でテストの状態を示したりいろいろな方法論を提示しているわけだから、それを盲信するチミ達は
それに立ち向かわなきゃアカン！！アカンがな！！
って事。
ちょっと、はっちゃけ過ぎた、ﾃﾍｯ
ぱっとこのスレ読んだ感じだけど TDD はグリーンバーにしてから本実装なんでしょ？
違ったか？ようわからんがそのはずだｗ
それに対して690(651も？)はそれ以外でもやり方あるんじゃねぇかゴルァ！！って言ってる・・・ような気がする。
とりあえずアカに一回戻せや！！みたいな。
706 でテストの状態を示したりいろいろな方法論を提示しているわけだから、それを盲信するチミ達は
それに立ち向かわなきゃアカン！！アカンがな！！
って事。
ちょっと、はっちゃけ過ぎた、ﾃﾍｯ
760 ：デフォルトの名無しさん：03/11/26 00:34
>>756
ヽ(`Д´)ﾉ ﾀﾞｶﾗﾁｶﾞｳｯﾃｲｯﾃﾙﾀﾞﾛ!!
ヽ(`Д´)ﾉ ﾀﾞｶﾗﾁｶﾞｳｯﾃｲｯﾃﾙﾀﾞﾛ!!
761 ：デフォルトの名無しさん：03/11/26 00:36
>>759
>ぱっとこのスレ読んだ感じだけど TDD はグリーンバーにしてから本実装なんでしょ？
>違ったか？ようわからんがそのはずだｗ
あってる。
>それに対して690(651も？)はそれ以外でもやり方あるんじゃねぇかゴルァ！！って言ってる・・・ような気がする。
>とりあえずアカに一回戻せや！！みたいな。
>706 でテストの状態を示したりいろいろな方法論を提示しているわけだから、それを盲信するチミ達は
>それに立ち向かわなきゃアカン！！アカンがな！！
アカに一回戻したかったら戻せばいいじゃない。
誰もそうすることに反論はしていないと思うよ。
ただそれはTDDとは違うと言う話であって、TDDと「それ以外のやり方」の優劣を議論
したいのだったら、それなりの問題提起をしてくれないとお話にならないんだけど。
>ぱっとこのスレ読んだ感じだけど TDD はグリーンバーにしてから本実装なんでしょ？
>違ったか？ようわからんがそのはずだｗ
あってる。
>それに対して690(651も？)はそれ以外でもやり方あるんじゃねぇかゴルァ！！って言ってる・・・ような気がする。
>とりあえずアカに一回戻せや！！みたいな。
>706 でテストの状態を示したりいろいろな方法論を提示しているわけだから、それを盲信するチミ達は
>それに立ち向かわなきゃアカン！！アカンがな！！
アカに一回戻したかったら戻せばいいじゃない。
誰もそうすることに反論はしていないと思うよ。
ただそれはTDDとは違うと言う話であって、TDDと「それ以外のやり方」の優劣を議論
したいのだったら、それなりの問題提起をしてくれないとお話にならないんだけど。
763 ：デフォルトの名無しさん：03/11/26 00:40
やっぱテストと開発って同時進行だよなあ。
うーん・・
うーん・・
764 ：デフォルトの名無しさん：03/11/26 00:41
765 ：デフォルトの名無しさん：03/11/26 00:41
>>762
> アカに一回戻したかったら戻せばいいじゃない。
> 誰もそうすることに反論はしていないと思うよ。
ウソーン！！
みんな突っ込んでたじゃん！！
> ただそれはTDDとは違うと言う話であって、TDDと「それ以外のやり方」の優劣を議論
> したいのだったら、それなりの問題提起をしてくれないとお話にならないんだけど。
706のリンク先じゃダメ？
> アカに一回戻したかったら戻せばいいじゃない。
> 誰もそうすることに反論はしていないと思うよ。
ウソーン！！
みんな突っ込んでたじゃん！！
> ただそれはTDDとは違うと言う話であって、TDDと「それ以外のやり方」の優劣を議論
> したいのだったら、それなりの問題提起をしてくれないとお話にならないんだけど。
706のリンク先じゃダメ？
766 ：デフォルトの名無しさん：03/11/26 00:45
>>764
それじゃツマランだろうに。
それにTDDには別に反感持ってないし本も持ってないしｗ
でも、だいたいｸﾞｸﾞってどういうものか解ったけどね。
ただ、盲信っぷりが凄いんでその信心がどこから沸いてくるのかは興味がある。
それじゃツマランだろうに。
それにTDDには別に反感持ってないし本も持ってないしｗ
でも、だいたいｸﾞｸﾞってどういうものか解ったけどね。
ただ、盲信っぷりが凄いんでその信心がどこから沸いてくるのかは興味がある。
767 ：729：03/11/26 00:45
>>729です。
・開発プロセスや新技術導入を正当化するには？
異を唱える人にはどう説明すればよいか？
・システム開発において
運用部門の協力が必要ということを理解してもらうには？
・人海戦術をモットーとする指導者とどう説得するべきか？
・イレギュラーパターンを処理すること＝高い評価という文化とどう向き合うか？
・開発プロセスや新技術導入を正当化するには？
異を唱える人にはどう説明すればよいか？
・システム開発において
運用部門の協力が必要ということを理解してもらうには？
・人海戦術をモットーとする指導者とどう説得するべきか？
・イレギュラーパターンを処理すること＝高い評価という文化とどう向き合うか？
>>765
>>653のことか？あれはTDDをそのように実行するという話だと思われたからつっこまれたんでしょ。
全く違う話だったら、>>653の通りやりたければやればいいじゃん。
>706のリンク先じゃダメ？
そのリンク先の内容について議論したいんだったら君がすれば？
どうして他人を引っ張り込みたいのかわからん。
>>653のことか？あれはTDDをそのように実行するという話だと思われたからつっこまれたんでしょ。
全く違う話だったら、>>653の通りやりたければやればいいじゃん。
>706のリンク先じゃダメ？
そのリンク先の内容について議論したいんだったら君がすれば？
どうして他人を引っ張り込みたいのかわからん。
>>766
俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
770 ：デフォルトの名無しさん：03/11/26 00:54
690の粘着はまだ続くのか。
正直TDDの信仰とかどうでもいい。
正直TDDの信仰とかどうでもいい。
771 ：デフォルトの名無しさん：03/11/26 00:57
> 異を唱える人にはどう説明すればよいか？
そいつを辞めさせる
> 運用部門の協力が必要ということを理解してもらうには？
賄賂を渡す
>・人海戦術をモットーとする指導者とどう説得するべきか？
体を売る
>・イレギュラーパターンを処理すること＝高い評価という文化とどう向き合うか？
高い評価を受けている奴を辞めさせる
そいつを辞めさせる
> 運用部門の協力が必要ということを理解してもらうには？
賄賂を渡す
>・人海戦術をモットーとする指導者とどう説得するべきか？
体を売る
>・イレギュラーパターンを処理すること＝高い評価という文化とどう向き合うか？
高い評価を受けている奴を辞めさせる
772 ：デフォルトの名無しさん：03/11/26 00:59
773 ：デフォルトの名無しさん：03/11/26 01:02
>>768
ツマラン！！お前の話はツマラン！！
ってのはさておき、話を変えてTDDって実践してる？
それだけ聞きたい。
反論もしないんでそれだけ教えてくれ！！
あと、常に今のプロセスが最前かどうか気になったりしない？
気にならないなら良いけど・・・
> 俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
えっ・・・マジデソウオモッテルンデツカ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ツマラン！！お前の話はツマラン！！
ってのはさておき、話を変えてTDDって実践してる？
それだけ聞きたい。
反論もしないんでそれだけ教えてくれ！！
あと、常に今のプロセスが最前かどうか気になったりしない？
気にならないなら良いけど・・・
> 俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
えっ・・・マジデソウオモッテルンデツカ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
774 ：デフォルトの名無しさん：03/11/26 01:03
なんか、異常な人だね
775 ：デフォルトの名無しさん：03/11/26 01:04
776 ：デフォルトの名無しさん：03/11/26 01:13
自演じゃないなら、690はとっくに寝たか逃げたんじゃないか？
>>773
>ってのはさておき、話を変えてTDDって実践してる？
>それだけ聞きたい。
自分ひとりでは実践したりしなかったり。
周りに広めようとは思わない。面倒だし。
> あと、常に今のプロセスが最前かどうか気になったりしない？
気にならない。
>> 俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
>えっ・・・マジデソウオモッテルンデツカ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
見解の相違だな。たいていの場合は○○を知らない人が○○について語ってる人を
「○○の信者」って言ってるに過ぎない場合が多いし。それにその人が信者であろうが
なかろうが、議論の妨げにはならないし、俺には関係ないことだし。
「○○の信者」なんてネガティブな話するより「○○のエバンジェリスト」って評価してあげたら？
>ってのはさておき、話を変えてTDDって実践してる？
>それだけ聞きたい。
自分ひとりでは実践したりしなかったり。
周りに広めようとは思わない。面倒だし。
> あと、常に今のプロセスが最前かどうか気になったりしない？
気にならない。
>> 俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
>えっ・・・マジデソウオモッテルンデツカ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
見解の相違だな。たいていの場合は○○を知らない人が○○について語ってる人を
「○○の信者」って言ってるに過ぎない場合が多いし。それにその人が信者であろうが
なかろうが、議論の妨げにはならないし、俺には関係ないことだし。
「○○の信者」なんてネガティブな話するより「○○のエバンジェリスト」って評価してあげたら？
778 ：デフォルトの名無しさん：03/11/26 12:39
>ってのはさておき、話を変えてTDDって実践してる？
してるよ。癖になるよ。
>あと、常に今のプロセスが最前かどうか気になったりしない？
最前の意味が分からんけど、別に気にならないな。
>> 俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
>えっ・・・マジデソウオモッテルンデツカ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
俺も妄信者はここに出てきて無いと思うんだけど。
TDD本を読まずにTDD本の批判議論に首を突っ込もうとする奴を非難しているだけじゃねーの？
してるよ。癖になるよ。
>あと、常に今のプロセスが最前かどうか気になったりしない？
最前の意味が分からんけど、別に気にならないな。
>> 俺が見る限りTDDを妄信しているような奴はいないと思うけど。偏見じゃないの？
>えっ・・・マジデソウオモッテルンデツカ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
俺も妄信者はここに出てきて無いと思うんだけど。
TDD本を読まずにTDD本の批判議論に首を突っ込もうとする奴を非難しているだけじゃねーの？
779 ：デフォルトの名無しさん：03/11/26 13:27
>>706
お前の方がムキになってるように見えるが。
それに、自分に意見してくる奴を「信者だから」と切り捨てる態度はかっこ悪い。
「信者だから」などといわずに、ちゃんと反論しろよ。
それから「TDDの独立性」って何？
お前の方がムキになってるように見えるが。
それに、自分に意見してくる奴を「信者だから」と切り捨てる態度はかっこ悪い。
「信者だから」などといわずに、ちゃんと反論しろよ。
それから「TDDの独立性」って何？
780 ：デフォルトの名無しさん：03/11/26 13:30
つーか、>>630はどこ行ったんだよ？
781 ：デフォルトの名無しさん：03/11/26 13:40
782 ：デフォルトの名無しさん：03/11/26 13:55
>>780
恥ずかしくて出てこれないんでしょ
恥ずかしくて出てこれないんでしょ
783 ：デフォルトの名無しさん：03/11/26 21:46
>>777
実践したりしなかったりかぁ
まぁそんなもんだよな～
> してるよ。癖になるよ。
おぉ～！！癖になるか！！
どんな感じよ。
例の「テスト中毒」ってやつか？
で、十分細かい（なんだ気取って言うと粒度が小さいだっけか？）テストか？
それで、予想だとソースよりテストの方がデカくなりそうだがどうだ？
ぜひ、ぜひ教えてくれ！！
> 最前の意味が分からんけど、別に気にならないな。
タイポしちゃたＹＯ－！！
本当は『最善』のって書きたかったんじゃ～
ほら、常に疑問を持っていたいじゃん。
「本当にこれが一番効率が良いのか？もっと良い方法があるんじゃないのか？」
とかさ。
ベックもいろいろ考えて常に、あーなんだその開発方法を流動的に変えてきているような気もするしさ。
ってひょっとして変えてない？
まぁ、いいや。
> TDD本を読まずにTDD本の批判議論に首を突っ込もうとする奴を非難しているだけじゃねーの？
本読まなくったってだいたいｸﾞｸﾞって解ったって言ってるじゃんよー
TDD自体そんなに中身なさそうじゃんかー
>>781
だから、違うっちゅーてるだろーに！！
ウギャーーーーーーー！！
実践したりしなかったりかぁ
まぁそんなもんだよな～
> してるよ。癖になるよ。
おぉ～！！癖になるか！！
どんな感じよ。
例の「テスト中毒」ってやつか？
で、十分細かい（なんだ気取って言うと粒度が小さいだっけか？）テストか？
それで、予想だとソースよりテストの方がデカくなりそうだがどうだ？
ぜひ、ぜひ教えてくれ！！
> 最前の意味が分からんけど、別に気にならないな。
タイポしちゃたＹＯ－！！
本当は『最善』のって書きたかったんじゃ～
ほら、常に疑問を持っていたいじゃん。
「本当にこれが一番効率が良いのか？もっと良い方法があるんじゃないのか？」
とかさ。
ベックもいろいろ考えて常に、あーなんだその開発方法を流動的に変えてきているような気もするしさ。
ってひょっとして変えてない？
まぁ、いいや。
> TDD本を読まずにTDD本の批判議論に首を突っ込もうとする奴を非難しているだけじゃねーの？
本読まなくったってだいたいｸﾞｸﾞって解ったって言ってるじゃんよー
TDD自体そんなに中身なさそうじゃんかー
>>781
だから、違うっちゅーてるだろーに！！
ウギャーーーーーーー！！
784 ：デフォルトの名無しさん：03/11/26 21:48
よくみたら781に含まれてなかった・・・
スマソ、781よ。
とりあえず、粒度の小さいクソでもしてくるよ（鹿系）
スマソ、781よ。
とりあえず、粒度の小さいクソでもしてくるよ（鹿系）
785 ：デフォルトの名無しさん：03/11/26 22:08
>>783
>> TDD本を読まずにTDD本の批判議論に首を突っ込もうとする奴を非難しているだけじゃねーの？
>本読まなくったってだいたいｸﾞｸﾞって解ったって言ってるじゃんよー
>TDD自体そんなに中身なさそうじゃんかー
そいつがいわれなき中傷をしさえしなければ読んで無くても問題ない。
>>630みたいなのにつきあおうとすれば、こちらがいちいち相手の間違いを
正してやる必要がある。それにそういう奴に限って、なぜだか自分の知識や
論理的思考能力や文章能力に自信があって、手が付けられんのだよ。
たいてい荒らすだけ荒らして、捨て台詞はいて消えるのがオチだろ？
>> TDD本を読まずにTDD本の批判議論に首を突っ込もうとする奴を非難しているだけじゃねーの？
>本読まなくったってだいたいｸﾞｸﾞって解ったって言ってるじゃんよー
>TDD自体そんなに中身なさそうじゃんかー
そいつがいわれなき中傷をしさえしなければ読んで無くても問題ない。
>>630みたいなのにつきあおうとすれば、こちらがいちいち相手の間違いを
正してやる必要がある。それにそういう奴に限って、なぜだか自分の知識や
論理的思考能力や文章能力に自信があって、手が付けられんのだよ。
たいてい荒らすだけ荒らして、捨て台詞はいて消えるのがオチだろ？
786 ：デフォルトの名無しさん：03/11/26 22:18
>>784
>で、十分細かい（なんだ気取って言うと粒度が小さいだっけか？）テストか？
なんでこれを知りたいのかわからん。
粒度の細かいテストを書けば細かくなるし、そうしなければそうならない。
それだけのことでしょ？ただし後者のやり方はTDDではないけどね。
>それで、予想だとソースよりテストの方がデカくなりそうだがどうだ？
普通は「テストコード>=ソースコード」くらいになるよ。
>で、十分細かい（なんだ気取って言うと粒度が小さいだっけか？）テストか？
なんでこれを知りたいのかわからん。
粒度の細かいテストを書けば細かくなるし、そうしなければそうならない。
それだけのことでしょ？ただし後者のやり方はTDDではないけどね。
>それで、予想だとソースよりテストの方がデカくなりそうだがどうだ？
普通は「テストコード>=ソースコード」くらいになるよ。
787 ：デフォルトの名無しさん：03/11/27 00:02
あー、783でまたミスしてもうた・・・
４行目以降は778へのレス。
まぁ、普通解るからいっかー
>>785
2chなんだからあの程度普通じゃん。
違うの？
見ているかぎりここの住人って非常に耐性無いように感じるんだよなー
もっと頭の切れるﾔﾂが出てきてスパッとやったら見てて面白かったのに。
たまにいるじゃん、そう言うヤツ。
颯爽と現れるクールでスマートなナイスガイにオレはシビレル憧れる～
>>785
> >で、十分細かい（なんだ気取って言うと粒度が小さいだっけか？）テストか？
>
> なんでこれを知りたいのかわからん。
それはさー、このスレ見てると
『カバレッジ１００％！！添加物いっさい無し！！』
みたいなのが書いてあるからさー
c1/c2通すんだったら細かくせにゃならん！！
お前に娘はやらん！！
って感じなワケでしょー
どのレヴェルまで細かくしているのかオジサン気になっちゃるんだわ。
まぁ、まだ若いけど。
最低限全てのメソッドには通すと思うんだけど、例外とかスレッドや通信の処理とかいろいろテスト入れていくと
結構とんでもないことに・・・ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
> 普通は「テストコード>=ソースコード」くらいになるよ。
万行単位のコードだと地獄を見そう。
４行目以降は778へのレス。
まぁ、普通解るからいっかー
>>785
2chなんだからあの程度普通じゃん。
違うの？
見ているかぎりここの住人って非常に耐性無いように感じるんだよなー
もっと頭の切れるﾔﾂが出てきてスパッとやったら見てて面白かったのに。
たまにいるじゃん、そう言うヤツ。
颯爽と現れるクールでスマートなナイスガイにオレはシビレル憧れる～
>>785
> >で、十分細かい（なんだ気取って言うと粒度が小さいだっけか？）テストか？
>
> なんでこれを知りたいのかわからん。
それはさー、このスレ見てると
『カバレッジ１００％！！添加物いっさい無し！！』
みたいなのが書いてあるからさー
c1/c2通すんだったら細かくせにゃならん！！
お前に娘はやらん！！
って感じなワケでしょー
どのレヴェルまで細かくしているのかオジサン気になっちゃるんだわ。
まぁ、まだ若いけど。
最低限全てのメソッドには通すと思うんだけど、例外とかスレッドや通信の処理とかいろいろテスト入れていくと
結構とんでもないことに・・・ (((((;ﾟДﾟ)))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
> 普通は「テストコード>=ソースコード」くらいになるよ。
万行単位のコードだと地獄を見そう。
788 ：デフォルトの名無しさん：03/11/27 00:12
文体がきもい
789 ：デフォルトの名無しさん：03/11/27 00:16
790 ：デフォルトの名無しさん：03/11/27 00:21
791 ：デフォルトの名無しさん：03/11/27 00:30
792 ：デフォルトの名無しさん：03/11/27 00:31
>>788
なんだとーこの野郎やるかー
キシャー！！
>>789
なんだとーこの野郎やるかー
キシャー！！
ところでチミはなんでこのスレにいるのよ。
>>790
> だから俺が>>631でスパッとやってやっただろ。
自画自賛（・A・）ｶｺﾜﾙｲ!!
じゃー、TDD者同士が普段TDDを実践して感じる疑問とかぶつけ合えよー
お前らﾂﾏﾗﾝよー
ﾂｯｺﾐだけはそんなにﾘｷ入れても面白くないじゃろー
なんだとーこの野郎やるかー
キシャー！！
>>789
なんだとーこの野郎やるかー
キシャー！！
ところでチミはなんでこのスレにいるのよ。
>>790
> だから俺が>>631でスパッとやってやっただろ。
自画自賛（・A・）ｶｺﾜﾙｲ!!
じゃー、TDD者同士が普段TDDを実践して感じる疑問とかぶつけ合えよー
お前らﾂﾏﾗﾝよー
ﾂｯｺﾐだけはそんなにﾘｷ入れても面白くないじゃろー
793 ：デフォルトの名無しさん：03/11/27 00:32
つーか、なんでみんなそんなに煽り口調なんだＹＯ！！
それじゃ女の子に嫌われちゃうぜ！！
それじゃ女の子に嫌われちゃうぜ！！
794 ：デフォルトの名無しさん：03/11/27 02:19
>>792
>じゃー、TDD者同士が普段TDDを実践して感じる疑問とかぶつけ合えよー
なぜ「じゃー」になるのかわからん。
TDDのこともっと知りたいの？何で本読まないの？
TDDの偉い人とめぐり合いたければ、xp-jpをヲチして問題提起すれば？
>じゃー、TDD者同士が普段TDDを実践して感じる疑問とかぶつけ合えよー
なぜ「じゃー」になるのかわからん。
TDDのこともっと知りたいの？何で本読まないの？
TDDの偉い人とめぐり合いたければ、xp-jpをヲチして問題提起すれば？
795 ：デフォルトの名無しさん：03/11/27 09:22
>>794
あんまり友達いないでしょ？
あんまり友達いないでしょ？
796 ：デフォルトの名無しさん：03/11/27 10:59
レベル低すぎ。ﾔﾚﾔﾚ
797 ：デフォルトの名無しさん：03/11/27 11:40
798 ：デフォルトの名無しさん：03/11/27 11:47
>>787
>『カバレッジ１００％！！添加物いっさい無し！！』
>みたいなのが書いてあるからさー
>c1/c2通すんだったら細かくせにゃならん！！
お前がいつもやっている後付のテストの枠組みから発想の転換ができなければ、
いつまでたってもその疑問は解消しないと思うぞ。
ほかの奴も言ってるが、まず本読んで実践してみろよ。結局のところ、その答えは
お前がどうするかによるということがわかるはずだ。
銀の弾なんて存在しないんだよ。
>『カバレッジ１００％！！添加物いっさい無し！！』
>みたいなのが書いてあるからさー
>c1/c2通すんだったら細かくせにゃならん！！
お前がいつもやっている後付のテストの枠組みから発想の転換ができなければ、
いつまでたってもその疑問は解消しないと思うぞ。
ほかの奴も言ってるが、まず本読んで実践してみろよ。結局のところ、その答えは
お前がどうするかによるということがわかるはずだ。
銀の弾なんて存在しないんだよ。
799 ：デフォルトの名無しさん：03/11/27 14:42
ぜんぜん話は変わるけど、Java以外の言語（C#やVB）でのプロジェクトで
TDDってやってる？
リファクタリングツールやテスティングフレームワークがカバーする範囲を
考えると、基本的な部分（NUnit、VBUnitなど）しかないJava以外の言語で
TDDをするのは結構難しい気がしてるんだが。
だれかやってる人いない？
TDDってやってる？
リファクタリングツールやテスティングフレームワークがカバーする範囲を
考えると、基本的な部分（NUnit、VBUnitなど）しかないJava以外の言語で
TDDをするのは結構難しい気がしてるんだが。
だれかやってる人いない？
800 ：デフォルトの名無しさん：03/11/27 20:50
C++でやってるがテスティングフレームワークはCppUnitやboost::test*があるしな
(前は前者、今は後者使ってる)
リファクタリングは「重複を取り除く」ときね。確かに手作業で面倒だけど
テストがあるからまあなんとかなってるよ。
(前は前者、今は後者使ってる)
リファクタリングは「重複を取り除く」ときね。確かに手作業で面倒だけど
テストがあるからまあなんとかなってるよ。
801 ：デフォルトの名無しさん：03/11/27 20:51
漏れも全然話は変わるんだけど>>138を見てホワイトボードがちょっと欲しくなったんだよ。
んでこれとかどうよ？
ttp://www.optics.co.jp/frereboard.html
ttp://www.dragon-net.co.jp/s_info/others/wbp/wbp.htm
欲しいのはマグネット無しのどこでも貼れるタイプなんだよ。
PCの筐体横についぺたぺた付箋貼ってしまうもんでね。
喪舞らも何か良さげなもんあったら上げてくれよ。
んでこれとかどうよ？
ttp://www.optics.co.jp/frereboard.html
ttp://www.dragon-net.co.jp/s_info/others/wbp/wbp.htm
欲しいのはマグネット無しのどこでも貼れるタイプなんだよ。
PCの筐体横についぺたぺた付箋貼ってしまうもんでね。
喪舞らも何か良さげなもんあったら上げてくれよ。
802 ：デフォルトの名無しさん：03/11/29 00:26
会社ならともかく自宅で貼る所なんかねーよ
803 ：デフォルトの名無しさん：03/11/29 06:16
>>801
freeboardは持ってる
イレーザで消す時に起きる静電気でくっつくので
接着テープとかいらないのはメリット
逆にイレーザを使わないと
1週間ぐらいで剥がれるのがデメリット
移動式ホワイトボードとしては
値段も安いし、いいと思う
>>802
凸凹してるとこでもくっつくので
壁紙の上とかドアに貼れるよ
freeboardは持ってる
イレーザで消す時に起きる静電気でくっつくので
接着テープとかいらないのはメリット
逆にイレーザを使わないと
1週間ぐらいで剥がれるのがデメリット
移動式ホワイトボードとしては
値段も安いし、いいと思う
>>802
凸凹してるとこでもくっつくので
壁紙の上とかドアに貼れるよ
804 ：デフォルトの名無しさん：03/11/29 10:38
>>803
それって、ほこりとかゴミとかつかないんですか？
それって、ほこりとかゴミとかつかないんですか？
805 ：デフォルトの名無しさん：03/11/29 15:14
806 ：デフォルトの名無しさん：03/11/29 15:55
イレーザで消すときに静電気がおきるのなら、イレーザで消すときに
もっともホコリやゴミがつくと思うのだが。
もっともホコリやゴミがつくと思うのだが。
807 ：デフォルトの名無しさん：03/11/29 17:57
知らない人は
セルロイドの下敷きとかを
イメージしてるんだろうけど
静電気はそんなに強くない
頭を近づけても毛が逆立ったりりしないよ
セルロイドの下敷きとかを
イメージしてるんだろうけど
静電気はそんなに強くない
頭を近づけても毛が逆立ったりりしないよ
808 ：デフォルトの名無しさん：03/12/02 01:45
809 ：デフォルトの名無しさん：03/12/02 07:23
どんなアジャイルネタかと思ったら。
文房具か。アジャイル話よりためになる。
文房具か。アジャイル話よりためになる。
810 ：デフォルトの名無しさん：03/12/03 16:37
XPは制約が多すぎる。
本当に実践できている人なんていないでしょ。
onsite customer とか顧客を馬鹿にしているとしか思えない。
プログラマー視点の自分にしか都合の良くない（負担が少ない）プロセス。
本当に実践できている人なんていないでしょ。
onsite customer とか顧客を馬鹿にしているとしか思えない。
プログラマー視点の自分にしか都合の良くない（負担が少ない）プロセス。
811 ：デフォルトの名無しさん：03/12/03 20:48
>>810
チームごとクライアントのところにいっちゃえばいいんだよ。
チームごとクライアントのところにいっちゃえばいいんだよ。
812 ：デフォルトの名無しさん：03/12/03 20:49
>>811
なんだ、いつもやってることじゃん
なんだ、いつもやってることじゃん
"Testing Extreme Programming"斜め読み完了（2時間）。
この本の目的は、以下の通り。
* Convince current XP practitioners that a tester has a valid role on the team
* Convince testing and quality assurance professionals that XP offers
solutions to some of their worst problems
* Convince both groups that testers are needed just as much in an XP
project as in a traditional development project
* Provide enough detail and practical example to allow you to either perfrom
the XP tester role yourself or work productively with a tester on
your team, whether you're an XP newbie or veteran, tester, programmer,
guide, customer, or manager
これから精読することにしますが、今現在、某SDKのテスターをやっている私には非常に
参考になりそうな予感です。
また"acceptance test"についても詳しく説明されています。XP本を全部読んだわけじゃ
ないんですが、この"acceptance testに関しては「それって何？」「どうやるの？」と
いう疑問を持っている人が多いんじゃないかと思いますが、そんな人におすすめです。
ちなみにこの本はXPの"Unit Test"をどうやるかという話ではありません。念のため。
誰か読んだ人います？
この本の目的は、以下の通り。
* Convince current XP practitioners that a tester has a valid role on the team
* Convince testing and quality assurance professionals that XP offers
solutions to some of their worst problems
* Convince both groups that testers are needed just as much in an XP
project as in a traditional development project
* Provide enough detail and practical example to allow you to either perfrom
the XP tester role yourself or work productively with a tester on
your team, whether you're an XP newbie or veteran, tester, programmer,
guide, customer, or manager
これから精読することにしますが、今現在、某SDKのテスターをやっている私には非常に
参考になりそうな予感です。
また"acceptance test"についても詳しく説明されています。XP本を全部読んだわけじゃ
ないんですが、この"acceptance testに関しては「それって何？」「どうやるの？」と
いう疑問を持っている人が多いんじゃないかと思いますが、そんな人におすすめです。
ちなみにこの本はXPの"Unit Test"をどうやるかという話ではありません。念のため。
誰か読んだ人います？
814 ：デフォルトの名無しさん：03/12/11 00:13
815 ：デフォルトの名無しさん：03/12/11 03:42
こ
参
ま
な
い
ち
誰
ﾊｧ?
参
ま
な
い
ち
誰
ﾊｧ?
816 ：デフォルトの名無しさん：03/12/11 11:23
>>815
氏ね、糞ガキ
氏ね、糞ガキ
817 ：デフォルトの名無しさん：03/12/11 19:26
いまさら縦読みネタですか……………………。
818 ：デフォルトの名無しさん：03/12/11 19:58
だからこそ、だ。
819 ：デフォルトの名無しさん：03/12/11 21:42
ウィービングってことですね？(・∀・)
820 ：デフォルトの名無しさん：03/12/11 22:21
XPのAcceptance Testって顧客が書くことになってたんだっけ？
821 ：質問：03/12/14 11:07
DBにinsertやupdate、deleteするプログラムは、
どうやってテストユニットを作ればいいのでしょうか？
どうやってテストユニットを作ればいいのでしょうか？
822 ：デフォルトの名無しさん：03/12/14 11:10
DbUnit
823 ：デフォルトの名無しさん：03/12/14 12:04
824 ：デフォルトの名無しさん：03/12/14 13:37
>>821
新規に作成したプログラムなら xUnit を使って、
テストデータを insert, update, delete するだけのことで、
あまり悩むことはないとおもう。
すでにある DB に対してアクセスする場合は、
マスター DB のコピーを毎回とってきて
テストを実行すればよい。
すでにある DB のスキーマを変更するようなときのテストは
ttp://martinfowler.com/dbrefact/
これでも読んで頑張ってくれ。
新規に作成したプログラムなら xUnit を使って、
テストデータを insert, update, delete するだけのことで、
あまり悩むことはないとおもう。
すでにある DB に対してアクセスする場合は、
マスター DB のコピーを毎回とってきて
テストを実行すればよい。
すでにある DB のスキーマを変更するようなときのテストは
ttp://martinfowler.com/dbrefact/
これでも読んで頑張ってくれ。
825 ：デフォルトの名無しさん：03/12/14 18:17
データベースにアクセスしないようにすればいい
826 ：デフォルトの名無しさん：03/12/14 18:25
微妙に深いレスだな。
827 ：821：03/12/15 07:34
えーと、要するに、DBのデータを更新するプログラムの場合、
結果として正しくDBのデータが書き換えられたかどうかを
確認する必要があるわけで、そこで新たに、select文を発行して
値を比較する、deleteの場合は一件も検索されないことを
確認するのかどうか、聞きたかったんですけど。
結果として正しくDBのデータが書き換えられたかどうかを
確認する必要があるわけで、そこで新たに、select文を発行して
値を比較する、deleteの場合は一件も検索されないことを
確認するのかどうか、聞きたかったんですけど。
828 ：デフォルトの名無しさん：03/12/15 07:52
DBのデータを更新するプログラムの場合、結果として正しくDBのデータが
書き換えられたかどうかを確認する必要があるなら、新たにselectを発行
して値を比較したり、deleteの場合は一件も検索されないことを確認すればいいよ。
書き換えられたかどうかを確認する必要があるなら、新たにselectを発行
して値を比較したり、deleteの場合は一件も検索されないことを確認すればいいよ。
829 ：デフォルトの名無しさん：03/12/15 08:05
>>827
>821-825 は真っ当なレスだ。
The Dbunit Framework
ttp://dbunit.sourceforge.net/
Dbunitは、SQLの実行前と実行後の複数のテーブルのレコードをXMLで管理し、
初期化、比較、後始末の方法を提供する。
上記のページでもいいし、日本語がいいのなら
WEB+DB PRESS Vol.17に記事が載っている。
>825の言うことをやっているのがこれ。mock object。
ttp://www.mockobjects.com/wiki/
この一部としてJDBCドライバを提供している。
このドライバはAPI上ではSQLを受け取りそれっぽい結果を返すが、
実際にはDBサーバにSQLを送らずアサージョンを行う。
>624あたりが挙げた本に載ってたはず。
>821-825 は真っ当なレスだ。
The Dbunit Framework
ttp://dbunit.sourceforge.net/
Dbunitは、SQLの実行前と実行後の複数のテーブルのレコードをXMLで管理し、
初期化、比較、後始末の方法を提供する。
上記のページでもいいし、日本語がいいのなら
WEB+DB PRESS Vol.17に記事が載っている。
>825の言うことをやっているのがこれ。mock object。
ttp://www.mockobjects.com/wiki/
この一部としてJDBCドライバを提供している。
このドライバはAPI上ではSQLを受け取りそれっぽい結果を返すが、
実際にはDBサーバにSQLを送らずアサージョンを行う。
>624あたりが挙げた本に載ってたはず。
830 ：デフォルトの名無しさん：03/12/16 07:18
そんなんでテストしたことになるの？
831 ：デフォルトの名無しさん：03/12/16 12:03
832 ：デフォルトの名無しさん：03/12/16 22:42
833 ：デフォルトの名無しさん：03/12/17 00:10
>>832
勘違い君は氏んでいいよ
勘違い君は氏んでいいよ
834 ：デフォルトの名無しさん：03/12/17 03:04
もっぱら顧客側の人間です。
相手先に常駐して一緒にお仕事、なんてのはほとんど不可能です。
（やったこともありますが）
そもそも自分たちで開発するにはリソース（時間・人・技術）がないから
プロに外注しているのです。
発注した次の瞬間には別の仕事が待っています。
相手先に常駐して一緒にお仕事、なんてのはほとんど不可能です。
（やったこともありますが）
そもそも自分たちで開発するにはリソース（時間・人・技術）がないから
プロに外注しているのです。
発注した次の瞬間には別の仕事が待っています。
835 ：デフォルトの名無しさん：03/12/17 11:54
>>834
>そもそも自分たちで開発するにはリソース（時間・人・技術）がないから
>プロに外注しているのです。
本当にリソースがないなら、外注するより完成品を買ってきた方が良いですよ。
>発注した次の瞬間には別の仕事が待っています。
丸投げなら丸投げで良いですけど、顧客側が開発してほしいものではなく、
外注が開発したいものが出来上がってくるのは確実です。
>そもそも自分たちで開発するにはリソース（時間・人・技術）がないから
>プロに外注しているのです。
本当にリソースがないなら、外注するより完成品を買ってきた方が良いですよ。
>発注した次の瞬間には別の仕事が待っています。
丸投げなら丸投げで良いですけど、顧客側が開発してほしいものではなく、
外注が開発したいものが出来上がってくるのは確実です。
836 ：デフォルトの名無しさん：03/12/17 13:25
>>834
835みたいなのはほっといて私に仕事ください
835みたいなのはほっといて私に仕事ください
837 ：デフォルトの名無しさん：03/12/17 15:29
>>835
> 本当にリソースがないなら、外注するより完成品を買ってきた方が良いですよ。
パッケージソフトで済むなら既にそうしているだろ。
> 外注が開発したいものが出来上がってくるのは確実です。
現実それじゃ仕事がとれない。
経験が生きてくるわけだ。
馬鹿が多いねこのスレ。
> 本当にリソースがないなら、外注するより完成品を買ってきた方が良いですよ。
パッケージソフトで済むなら既にそうしているだろ。
> 外注が開発したいものが出来上がってくるのは確実です。
現実それじゃ仕事がとれない。
経験が生きてくるわけだ。
馬鹿が多いねこのスレ。
838 ：デフォルトの名無しさん：03/12/17 20:37
839 ：デフォルトの名無しさん：03/12/17 22:46
顧客を口八丁で丸め込んで、エンハンスだサポートだといって金を毟り取るのが
良い SE のあり方です。
良い SE のあり方です。
840 ：デフォルトの名無しさん：03/12/18 13:17
>>836の作りたいものや、
>>837の経験で作られたものや、
>>839に丸め込まれたものが
欲しいなら、それぞれに発注すればいいんじゃない？
そうでないなら、注文する方にも自分が欲しいものについて考えるコストは必須です。
どんな買い物だってそうでしょ？
>>837の経験で作られたものや、
>>839に丸め込まれたものが
欲しいなら、それぞれに発注すればいいんじゃない？
そうでないなら、注文する方にも自分が欲しいものについて考えるコストは必須です。
どんな買い物だってそうでしょ？
841 ：デフォルトの名無しさん：03/12/18 22:22
うーん、agile なのに up がスレタイに入ってるのは何故？
やってみたら激重なんですが･･･
やってみたら激重なんですが･･･
842 ：デフォルトの名無しさん：03/12/18 23:10
>>841
AMで軽くすればいいんだよ。
AMで軽くすればいいんだよ。
843 ：デフォルトの名無しさん：03/12/19 00:36
>>842
AMなんでつか？
AMなんでつか？
844 ：デフォルトの名無しさん：03/12/20 09:27
>>841
いまどき、UPやるとは、どんなコンサルにだまされたんだ。
いまどき、UPやるとは、どんなコンサルにだまされたんだ。
845 ：デフォルトの名無しさん：03/12/20 13:57
やっぱQPに勝るものはないな
846 ：デフォルトの名無しさん：04/02/02 23:25
2002年の時点ですでに、ここにペアプログラミングが！
http://hide.maruo.co.jp/software/com2hide.html
http://hide.maruo.co.jp/software/com2hide.html
847 ：デフォルトの名無しさん：04/02/03 19:28
848 ：デフォルトの名無しさん：04/02/06 19:10
2002年の時点でRS-232Cか(笑)
849 ：デフォルトの名無しさん：04/03/12 22:15
XPはウェブ、雑誌で学んでユニットテストを実践したりして遊んでます。
考え方とか大好きなのですが、誤訳の多さに白本を買いそびれたままなんです。
買う価値、あるかな？
考え方とか大好きなのですが、誤訳の多さに白本を買いそびれたままなんです。
買う価値、あるかな？
850 ：デフォルトの名無しさん：04/03/13 23:29
原著よめ
851 ：U ◆CZtFsGiu0c ：04/03/16 11:46
>>849
白本しかなかった頃ならともかく、今なら赤本あたりを読んだほうがいいと思う。
白本しかなかった頃ならともかく、今なら赤本あたりを読んだほうがいいと思う。
853 ：デフォルトの名無しさん：04/05/07 13:16
ユニットテストを始めてみたんだけど、ネットワークとかスレッドが絡むようなものってどうするべき？
ネットワーク関係はサーバーのユニットテストとクライアントのユニットテストを同時に起動するのがいい？
それともスレッドを使って同一プロセスでテストするのがいい？
スレッド使ってて関数内でセマフォ待ちやイベント待ちになる場合、
スレッドを起こすための別のスレッドをテスト内で生成すべき？
あとテスト対象アプリケーション内で利用しているちょっとした関数を
(IPアドレスでもドメイン名からでもin_addrに変換してくれる関数とか)
テスト内で使おうと思ったんだけど、テスト対象にこの関数が入ってる以上使うのはご法度？
それともその関数をテストした上で利用するならOK？
ネットワーク関係はサーバーのユニットテストとクライアントのユニットテストを同時に起動するのがいい？
それともスレッドを使って同一プロセスでテストするのがいい？
スレッド使ってて関数内でセマフォ待ちやイベント待ちになる場合、
スレッドを起こすための別のスレッドをテスト内で生成すべき？
あとテスト対象アプリケーション内で利用しているちょっとした関数を
(IPアドレスでもドメイン名からでもin_addrに変換してくれる関数とか)
テスト内で使おうと思ったんだけど、テスト対象にこの関数が入ってる以上使うのはご法度？
それともその関数をテストした上で利用するならOK？
854 ：デフォルトの名無しさん：04/05/07 13:23
855 ：デフォルトの名無しさん：04/05/07 13:27
>>853
テスト対象Aに依存した別の関数Bをテストする場合は
先にAのテストをし、次にBをテストするだけ。
依存関係を定義できるフレームワークなら、B用テストはA用テストに依存させることで
AがfailしたらBはテストがスキップされるようにできる。
テスト対象Aに依存した別の関数Bをテストする場合は
先にAのテストをし、次にBをテストするだけ。
依存関係を定義できるフレームワークなら、B用テストはA用テストに依存させることで
AがfailしたらBはテストがスキップされるようにできる。
856 ：デフォルトの名無しさん：04/05/08 03:38
kent beckのこの本って読む価値ありますか？
Smalltalk用の92個のパターン集らしいんですがちょっと気になります。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894717549/ref=pd_sxp_elt_l1/249-4226728-6547524
Smalltalk用の92個のパターン集らしいんですがちょっと気になります。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894717549/ref=pd_sxp_elt_l1/249-4226728-6547524
858 ：デフォルトの名無しさん：04/05/08 13:34
>>857
まあそういう部分はほとんどソケット関数自体のテストみたいになっちゃうし
テストする意義は薄いけど(各関数は1行とかの内容でしょ?)
漏れがやったときはlocalhost相手にして、非ブロッキングにして
相手側はテストケース内でソケット関数直で記述したオブジェクトを用意して
対向通信させたよ。
非ブロッキングにできないなら別スレッドにすることになるね。
ともかく別プログラム用意するのは繁雑になりすぎるし自動化が面倒になる。
名前引きなんかも一個、自ネットのアドレスで確認する程度でokでしょう。
まあそういう部分はほとんどソケット関数自体のテストみたいになっちゃうし
テストする意義は薄いけど(各関数は1行とかの内容でしょ?)
漏れがやったときはlocalhost相手にして、非ブロッキングにして
相手側はテストケース内でソケット関数直で記述したオブジェクトを用意して
対向通信させたよ。
非ブロッキングにできないなら別スレッドにすることになるね。
ともかく別プログラム用意するのは繁雑になりすぎるし自動化が面倒になる。
名前引きなんかも一個、自ネットのアドレスで確認する程度でokでしょう。
859 ：デフォルトの名無しさん：04/05/23 20:16
>>856
オレは役に立ったよ。
SBPPのJava版、Essential Java Styleっつーのもあるよ。概要はこちらへ。
http://www.alles.or.jp/~torutk/oojava/maneuver/2001/style/essentialJavaStyle.html
オレは役に立ったよ。
SBPPのJava版、Essential Java Styleっつーのもあるよ。概要はこちらへ。
http://www.alles.or.jp/~torutk/oojava/maneuver/2001/style/essentialJavaStyle.html
860 ：デフォルトの名無しさん：04/05/23 20:50
861 ：859：04/05/24 00:13
>>860
いろいろ、いい事も書いてたから、立ち読みして気に入ったら買ってみてもいいと思うよ。
いろいろ、いい事も書いてたから、立ち読みして気に入ったら買ってみてもいいと思うよ。
862 ：デフォルトの名無しさん：04/06/03 00:58
>>861
遅レスですが、買ってきました。
>>859読んだら必要ないと言うのは自分の暴言でした。
内容の質、量ともに全然別物ですね。
で、>>859のリンク先を読んでいて思ったんですが、 Double Dispatch の説明で混乱しています。
ttp://www.alles.or.jp/~torutk/oojava/maneuver/2001/style/essentialJavaStyle.html#doc1_71
SBPP では同じレイヤのオブジェクト同士の相互作用を例に出しているのに対して
リンク先では visitor を Double Dispatch として説明しています。
私としてはそれなら Dispatch Interpretation も visitor ではないかと思うのですがどうなのでしょうか。
ttp://www.alles.or.jp/~torutk/oojava/maneuver/2001/style/essentialJavaStyle.html#doc1_69
一般的な Double Dispatch の説明なら確かに二回 Dispatch が起こるので正しいように
思えますが、 Dispatch Interpretation も二回 Dispatch が起こっています。
SBPPの言う、Double Dispatch は双方向に Dispatch Interpretation がかかっている物を
指しているような気がしてなりません。
どうでしょうか？
遅レスですが、買ってきました。
>>859読んだら必要ないと言うのは自分の暴言でした。
内容の質、量ともに全然別物ですね。
で、>>859のリンク先を読んでいて思ったんですが、 Double Dispatch の説明で混乱しています。
ttp://www.alles.or.jp/~torutk/oojava/maneuver/2001/style/essentialJavaStyle.html#doc1_71
SBPP では同じレイヤのオブジェクト同士の相互作用を例に出しているのに対して
リンク先では visitor を Double Dispatch として説明しています。
私としてはそれなら Dispatch Interpretation も visitor ではないかと思うのですがどうなのでしょうか。
ttp://www.alles.or.jp/~torutk/oojava/maneuver/2001/style/essentialJavaStyle.html#doc1_69
一般的な Double Dispatch の説明なら確かに二回 Dispatch が起こるので正しいように
思えますが、 Dispatch Interpretation も二回 Dispatch が起こっています。
SBPPの言う、Double Dispatch は双方向に Dispatch Interpretation がかかっている物を
指しているような気がしてなりません。
どうでしょうか？
863 ：デフォルトの名無しさん：04/06/03 01:06
これだけだと何なので話題でも。
リファクタリングをしていくと良く自然と、デザインパターンやこれらの
形になると言いますが、それで詰まる事はないのでしょうか。
TDDの本で、ひらめきやアイディアのようなものが突如として
出てくる所があったような気がします。
やはり、そういう方法論（SBPPやデザインパターン）がリファクタリングの
中にも必要になってくる場面はあると考えるのは危険でしょうか。
リファクタリングをしていくと良く自然と、デザインパターンやこれらの
形になると言いますが、それで詰まる事はないのでしょうか。
TDDの本で、ひらめきやアイディアのようなものが突如として
出てくる所があったような気がします。
やはり、そういう方法論（SBPPやデザインパターン）がリファクタリングの
中にも必要になってくる場面はあると考えるのは危険でしょうか。
864 ：859：04/06/08 22:24
>>862
＞リンク先では visitor を Double Dispatch として説明しています。
＞私としてはそれなら Dispatch Interpretation も visitor ではないかと
＞思うのですがどうなのでしょうか。
Visitorパターンの中で Double Dispatchが使われているのであって、
Visitorパターン == Double Dispatchというわけではないんじゃないかな。
＞一般的な Double Dispatch の説明なら確かに二回 Dispatch が起こるので
＞正しいように思えますが、 Dispatch Interpretation も二回 Dispatch が
＞起こっています。
正確な用語の定義はわからんのですけど、仮に
Dispatch ==「呼び出すメソッドの振り分け」
とすると、
Dispatch Interpretationの例での Dispatchは、Order#processBy()での
一回のみじゃないかな。2回行われているのはDispatchじゃなく
Delegate(委譲)で。
# ここでは Dispatchの仕組みとして、if文を使用してる。
ちなみに、Double Dispatchの例での|Dispatchは、
Player#accept()と Visitor#visit() の2回行われている。
# ここでは Dispatchの仕組みとして、ポリモーフィズムを使用してる。
＞リンク先では visitor を Double Dispatch として説明しています。
＞私としてはそれなら Dispatch Interpretation も visitor ではないかと
＞思うのですがどうなのでしょうか。
Visitorパターンの中で Double Dispatchが使われているのであって、
Visitorパターン == Double Dispatchというわけではないんじゃないかな。
＞一般的な Double Dispatch の説明なら確かに二回 Dispatch が起こるので
＞正しいように思えますが、 Dispatch Interpretation も二回 Dispatch が
＞起こっています。
正確な用語の定義はわからんのですけど、仮に
Dispatch ==「呼び出すメソッドの振り分け」
とすると、
Dispatch Interpretationの例での Dispatchは、Order#processBy()での
一回のみじゃないかな。2回行われているのはDispatchじゃなく
Delegate(委譲)で。
# ここでは Dispatchの仕組みとして、if文を使用してる。
ちなみに、Double Dispatchの例での|Dispatchは、
Player#accept()と Visitor#visit() の2回行われている。
# ここでは Dispatchの仕組みとして、ポリモーフィズムを使用してる。
865 ：デフォルトの名無しさん：04/06/11 01:27
>>864
おつきあい頂きどうもです
Double Dispatch ですが私は「二つのオブジェクトの組み合わせにより
呼び出される関数が決定する」と考えています
>>859のサイトの例題では、Dispatch Interpretation では Order インスタンスの状態により
Double Dispatch では Visitor インターフェースを実装したクラスのポリモーフィズム
により、二回目の Dispatch が起こっていると思うのですが如何でしょうか
また、>>859は Visitor の説明としても不十分だと思います
Visitor と Visitable が強く結びついてしまい、１対１の関係にしかなりません
よって振り分けも基本的にはありません
Double Dispatch は m x n だけの組み合わせが存在するはずですがこれでは
一つの組み合わせ以外は全て失敗します
この場合は Visitor は QuaterbackVisitor ではなくて ScoreCounter などの名前にし
visitorメソッドのオーバーロード、もしくは instanceof などで各選手のポジションごとに
振り分けるのが Visitor パターンだと思います
他にも visitor メソッドの名前を呼び出すオブジェクトごとに変えるとか、Dispatch Interpretation
のように、オブジェクトの状態ごとに振り分けるとかがありますよね
おつきあい頂きどうもです
Double Dispatch ですが私は「二つのオブジェクトの組み合わせにより
呼び出される関数が決定する」と考えています
>>859のサイトの例題では、Dispatch Interpretation では Order インスタンスの状態により
Double Dispatch では Visitor インターフェースを実装したクラスのポリモーフィズム
により、二回目の Dispatch が起こっていると思うのですが如何でしょうか
また、>>859は Visitor の説明としても不十分だと思います
Visitor と Visitable が強く結びついてしまい、１対１の関係にしかなりません
よって振り分けも基本的にはありません
Double Dispatch は m x n だけの組み合わせが存在するはずですがこれでは
一つの組み合わせ以外は全て失敗します
この場合は Visitor は QuaterbackVisitor ではなくて ScoreCounter などの名前にし
visitorメソッドのオーバーロード、もしくは instanceof などで各選手のポジションごとに
振り分けるのが Visitor パターンだと思います
他にも visitor メソッドの名前を呼び出すオブジェクトごとに変えるとか、Dispatch Interpretation
のように、オブジェクトの状態ごとに振り分けるとかがありますよね
866 ：859：04/06/13 05:27
>>865
> Double Dispatch ですが私は「二つのオブジェクトの組み合わせにより
> 呼び出される関数が決定する」と考えています
これは同意です。
> >>859のサイトの例題では、Dispatch Interpretation では Order インスタンスの状態により
> Double Dispatch では Visitor インターフェースを実装したクラスのポリモーフィズム
> により、二回目の Dispatch が起こっていると思うのですが如何でしょうか
むむ、Dispatch Interpretationでも2回目の Dispatch が起こっているのではないか、ということかしらん?
> Double Dispatch ですが私は「二つのオブジェクトの組み合わせにより
> 呼び出される関数が決定する」と考えています
これは同意です。
> >>859のサイトの例題では、Dispatch Interpretation では Order インスタンスの状態により
> Double Dispatch では Visitor インターフェースを実装したクラスのポリモーフィズム
> により、二回目の Dispatch が起こっていると思うのですが如何でしょうか
むむ、Dispatch Interpretationでも2回目の Dispatch が起こっているのではないか、ということかしらん?
867 ：859：04/06/13 05:27
>>865
> また、>>859は Visitor の説明としても不十分だと思います
> Visitor と Visitable が強く結びついてしまい、１対１の関係にしかなりません
> よって振り分けも基本的にはありません
> Double Dispatch は m x n だけの組み合わせが存在するはずですがこれでは
> 一つの組み合わせ以外は全て失敗します
まず、859のリンク先が Visitorパターンの説明として不十分か否かについて。
今、手元にGoFが無いので Visitorパターンの正確な定義は忘れちゃったんだけど、
"Represent an operation to be performed on the elements of an object structure.
Visitor lets you define a new operation without changing the classes of the elements
on which it operates." (from http://c2.com/cgi/wiki?VisitorPattern)
これを Visitorの目的&定義とすれば、859の例は Visitorパターンと言えなくはないのかも。
# 自信ないけど...
次に、Double Dispatchについて。
これは865さんのおっしゃる通り、
> Visitor と Visitable が強く結びついてしまい、１対１の関係にしかなりません
ので、Double Dispatchの説明としては不適当に感じますねえ。
このへんは原著(http://www.amazon.co.jp/exec/obidos/ASIN/0130850861/249-8437831-6912336)の
ソースを見てみると、また違うのかもしれないですが。
> また、>>859は Visitor の説明としても不十分だと思います
> Visitor と Visitable が強く結びついてしまい、１対１の関係にしかなりません
> よって振り分けも基本的にはありません
> Double Dispatch は m x n だけの組み合わせが存在するはずですがこれでは
> 一つの組み合わせ以外は全て失敗します
まず、859のリンク先が Visitorパターンの説明として不十分か否かについて。
今、手元にGoFが無いので Visitorパターンの正確な定義は忘れちゃったんだけど、
"Represent an operation to be performed on the elements of an object structure.
Visitor lets you define a new operation without changing the classes of the elements
on which it operates." (from http://c2.com/cgi/wiki?VisitorPattern)
これを Visitorの目的&定義とすれば、859の例は Visitorパターンと言えなくはないのかも。
# 自信ないけど...
次に、Double Dispatchについて。
これは865さんのおっしゃる通り、
> Visitor と Visitable が強く結びついてしまい、１対１の関係にしかなりません
ので、Double Dispatchの説明としては不適当に感じますねえ。
このへんは原著(http://www.amazon.co.jp/exec/obidos/ASIN/0130850861/249-8437831-6912336)の
ソースを見てみると、また違うのかもしれないですが。
868 ：デフォルトの名無しさん：04/06/13 07:23
>>866-867
> むむ、Dispatch Interpretationでも2回目の Dispatch が起こっているのではないか、ということかしらん?
そう考えています
オーバーロードで振り分ける、オブジェクトの状態で振り分ける、と振り分ける方法は
違いますがこれも Doble Dispatch だと考えています
ただここで私の言った「二つのオブジェクトの組み合わせにより呼び出される関数が決定する」
と言う前提が実は「二つのクラスの組み合わせにより呼び出される関数が決定する」だと
Dispatch Interpretation は Doble Dispatch では無くなってしまいます
ここが悩んでいるところですね
クラスベースに固執する概念ではないと思うのでオブジェクトの組み合わせと思っているわけですが
理解が及んでいない事は確かです
> これを Visitorの目的&定義とすれば、859の例は Visitorパターンと言えなくはないのかも。
> # 自信ないけど...
Visitor の目的は元のクラスの実装を変えずに機能を追加する事だと思っています
なので、機能としては最低でも 1 x n になるはずですが>>859では 1 x 1 になってしまっています
呼び出し側で特定の Visitor に依存した記述をしているので既に元のクラスの実装を変えず
と言う部分に背きますし、それ以外呼べなくなるのでそもそも無意味じゃないでしょうか
> むむ、Dispatch Interpretationでも2回目の Dispatch が起こっているのではないか、ということかしらん?
そう考えています
オーバーロードで振り分ける、オブジェクトの状態で振り分ける、と振り分ける方法は
違いますがこれも Doble Dispatch だと考えています
ただここで私の言った「二つのオブジェクトの組み合わせにより呼び出される関数が決定する」
と言う前提が実は「二つのクラスの組み合わせにより呼び出される関数が決定する」だと
Dispatch Interpretation は Doble Dispatch では無くなってしまいます
ここが悩んでいるところですね
クラスベースに固執する概念ではないと思うのでオブジェクトの組み合わせと思っているわけですが
理解が及んでいない事は確かです
> これを Visitorの目的&定義とすれば、859の例は Visitorパターンと言えなくはないのかも。
> # 自信ないけど...
Visitor の目的は元のクラスの実装を変えずに機能を追加する事だと思っています
なので、機能としては最低でも 1 x n になるはずですが>>859では 1 x 1 になってしまっています
呼び出し側で特定の Visitor に依存した記述をしているので既に元のクラスの実装を変えず
と言う部分に背きますし、それ以外呼べなくなるのでそもそも無意味じゃないでしょうか
869 ：デフォルトの名無しさん：04/06/13 07:24
>>866-867
で、最初の問題に戻るのですが Visitor パターンだと関数の実装が Visitor になります
それに対し、SBPP の Doble Dispatch の例だと両方のクラスにお互いに実装を持っています
お互いのクラスが Visitor でありかつ Visitable であるわけですね
こういうのが SBPP における Doble Dispatch なのかなと思っていたのですが・・・
これはあんまり自信がありませんでして・・・
ただ例題としてこういう形になってしまっているようないないような気も・・・
しかし、それでは Dispatch Interpretation も同じになってしまうわけで・・・
と言う感じで悩んでいますｗ
で、最初の問題に戻るのですが Visitor パターンだと関数の実装が Visitor になります
それに対し、SBPP の Doble Dispatch の例だと両方のクラスにお互いに実装を持っています
お互いのクラスが Visitor でありかつ Visitable であるわけですね
こういうのが SBPP における Doble Dispatch なのかなと思っていたのですが・・・
これはあんまり自信がありませんでして・・・
ただ例題としてこういう形になってしまっているようないないような気も・・・
しかし、それでは Dispatch Interpretation も同じになってしまうわけで・・・
と言う感じで悩んでいますｗ
870 ：859：04/06/17 00:40
返信、遅くなりました。
まずは、重要じゃなさそうなところから。
>>868
> Visitor の目的は元のクラスの実装を変えずに機能を追加する事だと思っています
> なので、機能としては最低でも 1 x n になるはずですが>>859では 1 x 1 になってしまっています
> 呼び出し側で特定の Visitor に依存した記述をしているので既に元のクラスの実装を変えず
> と言う部分に背きますし、それ以外呼べなくなるのでそもそも無意味じゃないでしょうか
Quaterbackを変えずに機能追加できないかしら?
以下のような感じで。
// QBの平均スコアを求めるVisitor
public class QuaterbackAverageVisitor extends Visitor {
int totalScore = 0;
int count = 0;
public void visit(Visitable visitable) {
count++;
Quaterback qb = (Quaterback)visitable;
totalScore += qb.getNumberOfTDs() * 6 +
qb.getNumberOfCompletions();
}
public int getAverageScore() {
return totalScore / count;
}
}
QuaterBackVisitorは、訪問先(Visitable)をQuaterbackクラスに限定しているけど、
Quaterbackクラスでは訪問者(Visitor)を限定はしていないと思う。
よって、1×1じゃなくて１×Nじゃないかと。
とは言え、1×Nじゃあ、N×Nである Double Dispatchの例にはならないので、どちらにせよダメなんですが。
まずは、重要じゃなさそうなところから。
>>868
> Visitor の目的は元のクラスの実装を変えずに機能を追加する事だと思っています
> なので、機能としては最低でも 1 x n になるはずですが>>859では 1 x 1 になってしまっています
> 呼び出し側で特定の Visitor に依存した記述をしているので既に元のクラスの実装を変えず
> と言う部分に背きますし、それ以外呼べなくなるのでそもそも無意味じゃないでしょうか
Quaterbackを変えずに機能追加できないかしら?
以下のような感じで。
// QBの平均スコアを求めるVisitor
public class QuaterbackAverageVisitor extends Visitor {
int totalScore = 0;
int count = 0;
public void visit(Visitable visitable) {
count++;
Quaterback qb = (Quaterback)visitable;
totalScore += qb.getNumberOfTDs() * 6 +
qb.getNumberOfCompletions();
}
public int getAverageScore() {
return totalScore / count;
}
}
QuaterBackVisitorは、訪問先(Visitable)をQuaterbackクラスに限定しているけど、
Quaterbackクラスでは訪問者(Visitor)を限定はしていないと思う。
よって、1×1じゃなくて１×Nじゃないかと。
とは言え、1×Nじゃあ、N×Nである Double Dispatchの例にはならないので、どちらにせよダメなんですが。
871 ：デフォルトの名無しさん：04/06/17 02:21
>>870
読み間違っていました
おっしゃるとおり、1 x n になっていますね
なので Visitor の例としては問題ありませんでした
結局 Double Dispatch が何なのか解らなくなってきましたｗ
m x n の関係を持った Visitor って感じでしょうか
読み間違っていました
おっしゃるとおり、1 x n になっていますね
なので Visitor の例としては問題ありませんでした
結局 Double Dispatch が何なのか解らなくなってきましたｗ
m x n の関係を持った Visitor って感じでしょうか
うまく説明できないので、こんなサンプルはどうでしょう。> Double Dispatch
まず、以下のようなプログラムがあったとします。
----
# Ver.1
# 文書要素(bold, italic, フォーマットなし)の入った配列を HTMLに変換する
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
end
class Bold < Element
end
class Italic < Element
end
まず、以下のようなプログラムがあったとします。
----
# Ver.1
# 文書要素(bold, italic, フォーマットなし)の入った配列を HTMLに変換する
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
end
class Bold < Element
end
class Italic < Element
end
class HtmlPrinter
def print_plain(str)
print( str )
end
def print_bold(str)
print( "<b>" + str + "</b>" )
end
def print_italic(str)
print( "<i>" + str + "</i>" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
printer = HtmlPrinter.new
for e in elements
if e.is_a?( Plain )
printer.print_plain( e.content )
elsif e.is_a?( Bold )
printer.print_bold( e.content )
elsif e.is_a?( Italic )
printer.print_italic( e.content )
end
end
end
main
----
def print_plain(str)
print( str )
end
def print_bold(str)
print( "<b>" + str + "</b>" )
end
def print_italic(str)
print( "<i>" + str + "</i>" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
printer = HtmlPrinter.new
for e in elements
if e.is_a?( Plain )
printer.print_plain( e.content )
elsif e.is_a?( Bold )
printer.print_bold( e.content )
elsif e.is_a?( Italic )
printer.print_italic( e.content )
end
end
end
main
----
Ver.1では mainメソッド内のif文で Elementの型を解釈(型の値を調べ、それに応じた処理を行うこと)をしていたけど、Ver.2では Elementのサブクラスへ解釈(Interpretation)を振分け(Dispatch)るように変更。
----
# Ver.2
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
def print_on( printer )
printer.print_plain( self.content )
end
end
class Bold < Element
def print_on( printer )
printer.print_bold( self.content )
end
end
class Italic < Element
def print_on( printer )
printer.print_italic( self.content )
end
end
----
# Ver.2
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
def print_on( printer )
printer.print_plain( self.content )
end
end
class Bold < Element
def print_on( printer )
printer.print_bold( self.content )
end
end
class Italic < Element
def print_on( printer )
printer.print_italic( self.content )
end
end
class HtmlPrinter
def print_plain(str)
print( str )
end
def print_bold(str)
print( "<b>" + str + "</b>" )
end
def print_italic(str)
print( "<i>" + str + "</i>" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
printer = HtmlPrinter.new
for e in elements
e.print_on( printer )
end
end
main
----
def print_plain(str)
print( str )
end
def print_bold(str)
print( "<b>" + str + "</b>" )
end
def print_italic(str)
print( "<i>" + str + "</i>" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
printer = HtmlPrinter.new
for e in elements
e.print_on( printer )
end
end
main
----
ここで新たに Wikiフォーマットで出力できるように WikiPrinterを追加する。
----
# Ver.3
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
def print_on( printer )
if printer.is_a?( HtmlPrinter )
printer.print_html_plain( self.content )
elsif printer.is_a?( WikiPrinter )
printer.print_wiki_plain( self.content )
end
end
end
class Bold < Element
def print_on( printer )
if printer.is_a?( HtmlPrinter )
printer.print_html_bold( self.content )
elsif printer.is_a?( WikiPrinter )
printer.print_wiki_bold( self.content )
end
end
end
----
# Ver.3
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
def print_on( printer )
if printer.is_a?( HtmlPrinter )
printer.print_html_plain( self.content )
elsif printer.is_a?( WikiPrinter )
printer.print_wiki_plain( self.content )
end
end
end
class Bold < Element
def print_on( printer )
if printer.is_a?( HtmlPrinter )
printer.print_html_bold( self.content )
elsif printer.is_a?( WikiPrinter )
printer.print_wiki_bold( self.content )
end
end
end
class Italic < Element
def print_on( printer )
if printer.is_a?( HtmlPrinter )
printer.print_html_italic( self.content )
elsif printer.is_a?( WikiPrinter )
printer.print_wiki_italic( self.content )
end
end
end
class HtmlPrinter
def print_html_plain(str)
print( str )
end
def print_html_bold(str)
print( "<b>" + str + "</b>" )
end
def print_html_italic(str)
print( "<i>" + str + "</i>" )
end
end
def print_on( printer )
if printer.is_a?( HtmlPrinter )
printer.print_html_italic( self.content )
elsif printer.is_a?( WikiPrinter )
printer.print_wiki_italic( self.content )
end
end
end
class HtmlPrinter
def print_html_plain(str)
print( str )
end
def print_html_bold(str)
print( "<b>" + str + "</b>" )
end
def print_html_italic(str)
print( "<i>" + str + "</i>" )
end
end
# see http://fswiki.poi.jp/wiki.cgi?page=Help#p4
class WikiPrinter
def print_wiki_plain(str)
print( str )
end
def print_wiki_bold(str)
print( "'''" + str + "'''" )
end
def print_wiki_italic(str)
print( "''" + str + "''" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
# printer = HtmlPrinter.new
printer = WikiPrinter.new
for e in elements
e.print_on( printer )
end
end
main
----
class WikiPrinter
def print_wiki_plain(str)
print( str )
end
def print_wiki_bold(str)
print( "'''" + str + "'''" )
end
def print_wiki_italic(str)
print( "''" + str + "''" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
# printer = HtmlPrinter.new
printer = WikiPrinter.new
for e in elements
e.print_on( printer )
end
end
main
----
次に Elementクラス内で HTMLか Wikiかの解釈を Printerクラスで行うようにする。
で、この時点で Element#print_on メソッドの挙動はレシーバ(Elementのサブクラス)とメッセージの引数(Printerのサブクラス)の組み合わせに応じて処理が振り分けられます。つまり Double Dispatchが行われていると。
----
# Ver.4
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
def print_on( printer )
printer.print_plain( self.content )
end
end
class Bold < Element
def print_on( printer )
printer.print_bold( self.content )
end
end
class Italic < Element
def print_on( printer )
printer.print_italic( self.content )
end
end
で、この時点で Element#print_on メソッドの挙動はレシーバ(Elementのサブクラス)とメッセージの引数(Printerのサブクラス)の組み合わせに応じて処理が振り分けられます。つまり Double Dispatchが行われていると。
----
# Ver.4
class Element
def initialize(str)
@content = str
end
def content
return @content
end
end
class Plain < Element
def print_on( printer )
printer.print_plain( self.content )
end
end
class Bold < Element
def print_on( printer )
printer.print_bold( self.content )
end
end
class Italic < Element
def print_on( printer )
printer.print_italic( self.content )
end
end
class Printer
end
class HtmlPrinter < Printer
def print_plain(str)
print( str )
end
def print_bold(str)
print( "<b>" + str + "</b>" )
end
def print_italic(str)
print( "<i>" + str + "</i>" )
end
end
# see http://fswiki.poi.jp/wiki.cgi?page=Help#p4
class WikiPrinter < Printer
def print_plain(str)
print( str )
end
def print_bold(str)
print( "'''" + str + "'''" )
end
def print_italic(str)
print( "''" + str + "''" )
end
end
end
class HtmlPrinter < Printer
def print_plain(str)
print( str )
end
def print_bold(str)
print( "<b>" + str + "</b>" )
end
def print_italic(str)
print( "<i>" + str + "</i>" )
end
end
# see http://fswiki.poi.jp/wiki.cgi?page=Help#p4
class WikiPrinter < Printer
def print_plain(str)
print( str )
end
def print_bold(str)
print( "'''" + str + "'''" )
end
def print_italic(str)
print( "''" + str + "''" )
end
end
def main
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
# printer = HtmlPrinter.new
printer = WikiPrinter.new
for e in elements
e.print_on( printer )
end
end
main
----
elements = [
Plain.new("hoge"),
Bold.new("fuga"),
Italic.new("kuma-")
]
# printer = HtmlPrinter.new
printer = WikiPrinter.new
for e in elements
e.print_on( printer )
end
end
main
----
882 ：デフォルトの名無しさん：04/06/22 02:36
>> 859
んで、それが 【XP】 Agile Process 【UP】 と どう関係あんの？
んで、それが 【XP】 Agile Process 【UP】 と どう関係あんの？
>>882
ケントベックつながり。
ケントベックつながり。
884 ：デフォルトの名無しさん：04/07/02 00:47
>>872-881
大変ﾚｽが遅くなってしまって申し訳ございませんでした。
言い訳になりませんが、ここ四週間休みがありません。
徹夜＆一日14時間労働。
デスマーチ進行中です。
会社の体制はかえられないほど腐っているので自分の武器はテストとリファクタリングのみ。
誰か、他の武器をください。
閑話休題。
ソース読ませて頂きました。
リファクタリングの過程が面白いですね。
やっと、このスレの主題に沿ってきた感じです（他の人すみません）
で、読ませた頂いたところ、二つのオブジェクトのポリモーフィズムにより
二回メソッドの割り当てが行われるという感じでしょうか。
とすると、
> ただここで私の言った「二つのオブジェクトの組み合わせにより呼び出される関数が決定する」
> と言う前提が実は「二つのクラスの組み合わせにより呼び出される関数が決定する」だと
> Dispatch Interpretation は Doble Dispatch では無くなってしまいます
ここで言った、「二つのクラスの組み合わせにより呼び出される関数が決定する」が
Double Dispatch と考えて良さそうですね。
--関係ありませんが Ruby はめちゃくちゃ読みやすいですね。
--最近 Python も弄っているんですが、Ruby の方が読みやすい。
大変ﾚｽが遅くなってしまって申し訳ございませんでした。
言い訳になりませんが、ここ四週間休みがありません。
徹夜＆一日14時間労働。
デスマーチ進行中です。
会社の体制はかえられないほど腐っているので自分の武器はテストとリファクタリングのみ。
誰か、他の武器をください。
閑話休題。
ソース読ませて頂きました。
リファクタリングの過程が面白いですね。
やっと、このスレの主題に沿ってきた感じです（他の人すみません）
で、読ませた頂いたところ、二つのオブジェクトのポリモーフィズムにより
二回メソッドの割り当てが行われるという感じでしょうか。
とすると、
> ただここで私の言った「二つのオブジェクトの組み合わせにより呼び出される関数が決定する」
> と言う前提が実は「二つのクラスの組み合わせにより呼び出される関数が決定する」だと
> Dispatch Interpretation は Doble Dispatch では無くなってしまいます
ここで言った、「二つのクラスの組み合わせにより呼び出される関数が決定する」が
Double Dispatch と考えて良さそうですね。
--関係ありませんが Ruby はめちゃくちゃ読みやすいですね。
--最近 Python も弄っているんですが、Ruby の方が読みやすい。
885 ：デフォルトの名無しさん：04/07/02 02:03
886 ：デフォルトの名無しさん：04/07/02 02:06
>>885
なかなか再利用性の高いフレームワークを使った煽りですね。
なかなか再利用性の高いフレームワークを使った煽りですね。
887 ：デフォルトの名無しさん：04/07/02 03:54
ﾜﾗﾀｗ
>他の武器
カラダ
カラダ
>>885
デスマーチになるか否かはプロジェクトの1メンバーがアジャイルな開発を理解しているか否かでは決まらんと思うけど。
デスマーチになるか否かはプロジェクトの1メンバーがアジャイルな開発を理解しているか否かでは決まらんと思うけど。
890 ：デフォルトの名無しさん：04/07/04 01:02
>889
決まる(事がある)
決まる(事がある)
891 ：デフォルトの名無しさん：04/07/04 01:31
可能性を言い出したら切りがないぞ
そうそう、
「アジャイルソフトウェア開発の奥義」を買ってきた。
ロバートCマーティンの「Agile Software Development」を翻訳したもの。
アジャイルで翻訳と言えば、迷翻訳屋、長瀬&テクノロジックアートがしゃしゃり出てくる事で有名だけど、
安心してください、この本は瀬谷啓介さんという別な方が訳されてます。長瀬の「な」の字も出てきません。
まだ、最初の方しか読んでないけど、すげー良さげ。翻訳の質も悪くなさそうです。
5800円とちょっとお高めだけど、とりあえず立ち読みしてみてはどうでしょう。
* アジャイルソフトウェア開発の奥義
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/250-1254299-5538614
* Agile Software Development
http://www.amazon.co.jp/exec/obidos/ASIN/0135974445/
「アジャイルソフトウェア開発の奥義」を買ってきた。
ロバートCマーティンの「Agile Software Development」を翻訳したもの。
アジャイルで翻訳と言えば、迷翻訳屋、長瀬&テクノロジックアートがしゃしゃり出てくる事で有名だけど、
安心してください、この本は瀬谷啓介さんという別な方が訳されてます。長瀬の「な」の字も出てきません。
まだ、最初の方しか読んでないけど、すげー良さげ。翻訳の質も悪くなさそうです。
5800円とちょっとお高めだけど、とりあえず立ち読みしてみてはどうでしょう。
* アジャイルソフトウェア開発の奥義
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/250-1254299-5538614
* Agile Software Development
http://www.amazon.co.jp/exec/obidos/ASIN/0135974445/
>>884
>>>872-881
> 大変ﾚｽが遅くなってしまって申し訳ございませんでした。
> 言い訳になりませんが、ここ四週間休みがありません。
> 徹夜＆一日14時間労働。
> デスマーチ進行中です。
> 会社の体制はかえられないほど腐っているので自分の武器はテストとリファクタリングのみ。
> 誰か、他の武器をください。
お気になさらずに。まったり行きましょう。
ところで。
このままデスマーチが続くようでしたら
上司に「こんなスケジュールじゃ出来ね―よ」と噛み付いたほうが良いと思いますよ。
ただ噛み付くだけではだめで、論拠となるような数字を示して理詰めで攻めるのが効果的です。
自分の身を守れるのは自分だけですからね。
>>884さんがそうだというわけじゃなく、オレが常日頃思っていることなのですが、
理不尽な納期を決めたマネージャにもデスマーチの責任はあるかもしれませんが、
納期の理不尽さを知った上で「がんばってみます」と仕事を引き受けるプログラマの責任も重いと思うのです。
無理を承知で仕事を引き受けるのは無責任です。無理なときは無理と突っぱねることこそ本当の責任感だと思うのですよ。
つーことで、このスレを読んでる、デスマーチに従事しているプログラマ諸君は反旗をひるがえしなされ、気が向いたときにでも。
>>>872-881
> 大変ﾚｽが遅くなってしまって申し訳ございませんでした。
> 言い訳になりませんが、ここ四週間休みがありません。
> 徹夜＆一日14時間労働。
> デスマーチ進行中です。
> 会社の体制はかえられないほど腐っているので自分の武器はテストとリファクタリングのみ。
> 誰か、他の武器をください。
お気になさらずに。まったり行きましょう。
ところで。
このままデスマーチが続くようでしたら
上司に「こんなスケジュールじゃ出来ね―よ」と噛み付いたほうが良いと思いますよ。
ただ噛み付くだけではだめで、論拠となるような数字を示して理詰めで攻めるのが効果的です。
自分の身を守れるのは自分だけですからね。
>>884さんがそうだというわけじゃなく、オレが常日頃思っていることなのですが、
理不尽な納期を決めたマネージャにもデスマーチの責任はあるかもしれませんが、
納期の理不尽さを知った上で「がんばってみます」と仕事を引き受けるプログラマの責任も重いと思うのです。
無理を承知で仕事を引き受けるのは無責任です。無理なときは無理と突っぱねることこそ本当の責任感だと思うのですよ。
つーことで、このスレを読んでる、デスマーチに従事しているプログラマ諸君は反旗をひるがえしなされ、気が向いたときにでも。
>>884
> ここで言った、「二つのクラスの組み合わせにより呼び出される関数が決定する」が
> Double Dispatch と考えて良さそうですね。
うむ、そんなところだと思います。
> --関係ありませんが Ruby はめちゃくちゃ読みやすいですね。
> --最近 Python も弄っているんですが、Ruby の方が読みやすい。
むふふ。おすすめですよ＞Ruby
> ここで言った、「二つのクラスの組み合わせにより呼び出される関数が決定する」が
> Double Dispatch と考えて良さそうですね。
うむ、そんなところだと思います。
> --関係ありませんが Ruby はめちゃくちゃ読みやすいですね。
> --最近 Python も弄っているんですが、Ruby の方が読みやすい。
むふふ。おすすめですよ＞Ruby
896 ：デフォルトの名無しさん：04/07/17 16:28
日本でXP/アジャイル関連のセミナーに力入れてる会社っていったらどこでしょうね？
897 ：デフォルトの名無しさん：04/07/18 16:09
>>896
あめぞう君
あめぞう君
898 ：デフォルトの名無しさん：04/07/18 16:11
豆腐屋
豆蔵さんみてきましたけど、アジャイルつうよりＵＰ系の講座ですた。
900 ：デフォルトの名無しさん：04/07/26 20:24
「Agile」って言葉だけど
これ単に「eXtreme Programming」を丸く表現しただけなんだよね
XPを叩いて叩いてAgileとなる。丸くなって、切れ味が無い
これ単に「eXtreme Programming」を丸く表現しただけなんだよね
XPを叩いて叩いてAgileとなる。丸くなって、切れ味が無い
901 ：デフォルトの名無しさん：04/07/26 21:03
アージャイル様に逆らうとは何事だ！
902 ：デフォルトの名無しさん：04/07/26 21:23
>>900
（ﾟДﾟ）ﾊｧ？
（ﾟДﾟ）ﾊｧ？
903 ：デフォルトの名無しさん：04/07/27 00:37
あ!汁、だったんだが元々は
904 ：デフォルトの名無しさん：04/07/27 02:07
アジル
サリム・アブ・アジル
自爆テロの首謀者
サリム・アブ・アジル
自爆テロの首謀者
905 ：デフォルトの名無しさん：04/07/28 22:15
「スパイク」って語源はなんなんでしょうか？
906 ：デフォルトの名無しさん：04/07/28 22:46
そう言えば、ここでXP以外勉強しているヤツいる？
ASD とか Scrum とか Crystal とか、あと FDD か
何が良いのか解らんからメリット・デメリットの表とかあると良いんだよなぁ
ASD とか Scrum とか Crystal とか、あと FDD か
何が良いのか解らんからメリット・デメリットの表とかあると良いんだよなぁ
907 ：デフォルトの名無しさん：04/07/29 00:32
>905
崖登り
崖登り
908 ：デフォルトの名無しさん：04/07/29 23:24
>>906
メリットデメリットの表が載ってるかはわからないけど、この本なんてどう？
訳者が長瀬&テクノロジックアートなので、クソみたいな翻訳だろうけどね。
http://www.pearsoned.co.jp/washo/object/wa_obj74-j.shtml
メリットデメリットの表が載ってるかはわからないけど、この本なんてどう？
訳者が長瀬&テクノロジックアートなので、クソみたいな翻訳だろうけどね。
http://www.pearsoned.co.jp/washo/object/wa_obj74-j.shtml
909 ：デフォルトの名無しさん：04/07/29 23:35
「短期決戦型ソフトウェア開発」
http://www.amazon.co.jp/exec/obidos/ASIN/4795263159/ref=nosim
1988年に出版された本なんだけど、内容はモロにアジャイルな開発方法の手引書なんだよ。こんな本が15年以上前に出てたなんて驚き。
薄くてお値段もボチボチお手頃なので御一読をお勧めします。
http://www.amazon.co.jp/exec/obidos/ASIN/4795263159/ref=nosim
1988年に出版された本なんだけど、内容はモロにアジャイルな開発方法の手引書なんだよ。こんな本が15年以上前に出てたなんて驚き。
薄くてお値段もボチボチお手頃なので御一読をお勧めします。
910 ：デフォルトの名無しさん：04/07/29 23:55
911 ：デフォルトの名無しさん：04/08/01 14:11
XPの本読んでみたけど、問題点や欠点がたんまりあるな
それ以前に宗教じみていて、気色悪い
それ以前に宗教じみていて、気色悪い
912 ：デフォルトの名無しさん：04/08/01 14:13
欠点が無い開発手法なんて無いよ
913 ：デフォルトの名無しさん：04/08/01 15:06
>>912
無いだろうな
しかし、XPは多すぎる
これじゃ極小開発しか出来ないだろ
いや、極小も出来ないな
人を使いすぎる、ペアプログラミング、コーチ、トラッカ、マネージャ・・・
顧客まで巻き込む、プログラマに都合の良いエゴ開発プロセスだよこりゃ
無いだろうな
しかし、XPは多すぎる
これじゃ極小開発しか出来ないだろ
いや、極小も出来ないな
人を使いすぎる、ペアプログラミング、コーチ、トラッカ、マネージャ・・・
顧客まで巻き込む、プログラマに都合の良いエゴ開発プロセスだよこりゃ
914 ：デフォルトの名無しさん：04/08/01 15:15
>>913
元からターゲットとしては小規模開発だよ。
また、役割は同じ人が複数兼ねてもいい。
実際に開発しててそういう役割の人が大体いるでしょ？
それをプロセスの一部として明文化したということ。
顧客とのコミュニケーションも on site を除けば
理念として特異なところはないと思う。
元からターゲットとしては小規模開発だよ。
また、役割は同じ人が複数兼ねてもいい。
実際に開発しててそういう役割の人が大体いるでしょ？
それをプロセスの一部として明文化したということ。
顧客とのコミュニケーションも on site を除けば
理念として特異なところはないと思う。
915 ：デフォルトの名無しさん：04/08/01 15:40
>>914
役割を兼用できても、人を使いすぎるな
実際に作業をやる人間が二人単位だ
これじゃ、まともな分業も出来ない
顧客も毎回確認されたら堪ったものではない
送ってある仕様をちゃんと見ろと言いたくなるだろ
また、それ以前にXPの契約が取れるか？
顧客としては求めているもの最終見積もりが取れないのがいつまでも定まらないのは
稟議の問題なども通して困るだろ
それに、XPの設計をしない理念も応用性が低いな
リファクタリングとテストだけで望んだ形になる？
馬鹿なｗ
しかも、XPの主張はあのとても全て実践できるとは思えない12のプラクティスを
全て使わないと駄目だと明言している
つまみ食いは駄目だと
プログラマのエゴ開発プロセスと言われても仕方がないな
役割を兼用できても、人を使いすぎるな
実際に作業をやる人間が二人単位だ
これじゃ、まともな分業も出来ない
顧客も毎回確認されたら堪ったものではない
送ってある仕様をちゃんと見ろと言いたくなるだろ
また、それ以前にXPの契約が取れるか？
顧客としては求めているもの最終見積もりが取れないのがいつまでも定まらないのは
稟議の問題なども通して困るだろ
それに、XPの設計をしない理念も応用性が低いな
リファクタリングとテストだけで望んだ形になる？
馬鹿なｗ
しかも、XPの主張はあのとても全て実践できるとは思えない12のプラクティスを
全て使わないと駄目だと明言している
つまみ食いは駄目だと
プログラマのエゴ開発プロセスと言われても仕方がないな
916 ：デフォルトの名無しさん：04/08/01 15:42
日本語が変だ
> 顧客としては求めているもの最終見積もりが取れないのがいつまでも定まらないのは
顧客としては求めているものの最終的な見積もりがいつまでも定まらないのは
> 顧客としては求めているもの最終見積もりが取れないのがいつまでも定まらないのは
顧客としては求めているものの最終的な見積もりがいつまでも定まらないのは
917 ：デフォルトの名無しさん：04/08/01 16:15
なんでこうも話題がループしまくりなんだろうね？
918 ：デフォルトの名無しさん：04/08/01 16:16
>>915
＞役割を兼用できても、人を使いすぎるな
＞実際に作業をやる人間が二人単位だ
二人単位なのはペアプロだけだよ。
あとはその時々に応じて必要な役割をこなすだけという
ごく当たり前のことをするだけかと。
＞また、それ以前にXPの契約が取れるか？
＞顧客としては求めているもの最終見積もりが取れないのがいつまでも定まらないのは
＞稟議の問題なども通して困るだろ
まあ、現状 XP でやりますといって契約できるとは思わんが。
何か勘違いしてるのかもしれないけど XP も反復型開発の一種だよ。
最初からシステムの全部を作ろうとせずに、動くものを拡張していくというやり方。
XP での要求分析・設計の方法をざっと書いておくと以下のようになる。
1. 顧客を交えてシナリオ作成をする。シナリオとは UML を
使った開発に出てくるあれと似たようなもので、
システムによって実現したいことをユーザ視点で記述したもの
2. シナリオを分割してタスクリストを作成する。これはシナリオを実現する
ために必要な機能を開発者視点で記述したもの
3. タスクそれぞれに必要な開発期間を見積もる。
それを元にシナリオの開発に必要な開発期間も見積もる。
4. 顧客に機能とスケジュールのトレードオフをしてもらう。
3 の作業でシステムの部分ごとの開発期間が見積もられたので、
「全部やろうとしたらこれだけかかりますよ。
プライオリティの高い機能から作れば、
まずは動くものがこれくらいでできますよ」 と言える。
以後はイテレーションをする。
最初は顧客の要求に出ていた機能のうち、
お飾り的なやつや担当者の趣味のようなのは
4 の作業で後に追いやられるので、
実際にそこそこ動くのができると忘れてくれる。
＞役割を兼用できても、人を使いすぎるな
＞実際に作業をやる人間が二人単位だ
二人単位なのはペアプロだけだよ。
あとはその時々に応じて必要な役割をこなすだけという
ごく当たり前のことをするだけかと。
＞また、それ以前にXPの契約が取れるか？
＞顧客としては求めているもの最終見積もりが取れないのがいつまでも定まらないのは
＞稟議の問題なども通して困るだろ
まあ、現状 XP でやりますといって契約できるとは思わんが。
何か勘違いしてるのかもしれないけど XP も反復型開発の一種だよ。
最初からシステムの全部を作ろうとせずに、動くものを拡張していくというやり方。
XP での要求分析・設計の方法をざっと書いておくと以下のようになる。
1. 顧客を交えてシナリオ作成をする。シナリオとは UML を
使った開発に出てくるあれと似たようなもので、
システムによって実現したいことをユーザ視点で記述したもの
2. シナリオを分割してタスクリストを作成する。これはシナリオを実現する
ために必要な機能を開発者視点で記述したもの
3. タスクそれぞれに必要な開発期間を見積もる。
それを元にシナリオの開発に必要な開発期間も見積もる。
4. 顧客に機能とスケジュールのトレードオフをしてもらう。
3 の作業でシステムの部分ごとの開発期間が見積もられたので、
「全部やろうとしたらこれだけかかりますよ。
プライオリティの高い機能から作れば、
まずは動くものがこれくらいでできますよ」 と言える。
以後はイテレーションをする。
最初は顧客の要求に出ていた機能のうち、
お飾り的なやつや担当者の趣味のようなのは
4 の作業で後に追いやられるので、
実際にそこそこ動くのができると忘れてくれる。
919 ：デフォルトの名無しさん：04/08/01 16:20
>>915
＞それに、XPの設計をしない理念も応用性が低いな
＞リファクタリングとテストだけで望んだ形になる？
＞馬鹿なｗ
しないわけじゃなくて、無駄なドキュメント作成と
ドキュメントとコードの同期を取るための膨大な作業は最小にするってこと。
実際には クラス図やシーケンス図などいくつかの UML 図を
作った方が良いと思うが、原理主義的にはユニットテスト＝実装仕様となるので
設計と実装を分けてする必要はないよねってことになってる。
＞しかも、XPの主張はあのとても全て実践できるとは思えない12のプラクティスを
＞全て使わないと駄目だと明言している
＞つまみ食いは駄目だと
まあ、これも XP に限らずあらゆるソフトウェア開発プロセスは、
「上手くいかないのはプロセスをきちんと実践しないからだ」 と言うものです。
＞それに、XPの設計をしない理念も応用性が低いな
＞リファクタリングとテストだけで望んだ形になる？
＞馬鹿なｗ
しないわけじゃなくて、無駄なドキュメント作成と
ドキュメントとコードの同期を取るための膨大な作業は最小にするってこと。
実際には クラス図やシーケンス図などいくつかの UML 図を
作った方が良いと思うが、原理主義的にはユニットテスト＝実装仕様となるので
設計と実装を分けてする必要はないよねってことになってる。
＞しかも、XPの主張はあのとても全て実践できるとは思えない12のプラクティスを
＞全て使わないと駄目だと明言している
＞つまみ食いは駄目だと
まあ、これも XP に限らずあらゆるソフトウェア開発プロセスは、
「上手くいかないのはプロセスをきちんと実践しないからだ」 と言うものです。
920 ：デフォルトの名無しさん：04/08/01 16:33
>>918
そちらこそ勘違いをしていると思うが
> 実際に作業をやる人間が二人単位だ
これはちゃんとペアプロのことを指しているよｗ
コーチが二人とか馬鹿なことは思っていない
レイヤーの違うプログラムを分業をする場合、常に二人単位の人間を必要とする
これでは人を使いすぎると言っているわけだ
あと、XPは反復開発の一種だと言っているがそんなことは当然解っている
オレが話しているのは、XPが出来た分だけ料金を請求すると言うところだ
これじゃ顧客は困るだろう
これらがごく当たり前のことなのか？
よっぽど変なところで働いているんだな
あと、設計の件は、書類化のことを示している訳じゃない
設計するという行為自体を示している
UnitTest - リファクタリングで自然に最適な形になるとは思えない
修正が難しい形に流れてしまう可能性が高い
> 「上手くいかないのはプロセスをきちんと実践しないからだ」 と言うものです。
儒教的だなｗ
XPは道教的じゃ無かったのかい？
そちらこそ勘違いをしていると思うが
> 実際に作業をやる人間が二人単位だ
これはちゃんとペアプロのことを指しているよｗ
コーチが二人とか馬鹿なことは思っていない
レイヤーの違うプログラムを分業をする場合、常に二人単位の人間を必要とする
これでは人を使いすぎると言っているわけだ
あと、XPは反復開発の一種だと言っているがそんなことは当然解っている
オレが話しているのは、XPが出来た分だけ料金を請求すると言うところだ
これじゃ顧客は困るだろう
これらがごく当たり前のことなのか？
よっぽど変なところで働いているんだな
あと、設計の件は、書類化のことを示している訳じゃない
設計するという行為自体を示している
UnitTest - リファクタリングで自然に最適な形になるとは思えない
修正が難しい形に流れてしまう可能性が高い
> 「上手くいかないのはプロセスをきちんと実践しないからだ」 と言うものです。
儒教的だなｗ
XPは道教的じゃ無かったのかい？
921 ：デフォルトの名無しさん：04/08/01 16:49
>>920
＞レイヤーの違うプログラムを分業をする場合、常に二人単位の人間を必要とする
＞これでは人を使いすぎると言っているわけだ
んー人月増えるのはたしかだね。
複数人で集まってのソースレビュー作業が省けたりする部分はあるが。
ペアプロがコードの質の向上にどれくらい貢献するのかを
示すデータってのもあんまりないので難しいところだね。
＞あと、XPは反復開発の一種だと言っているがそんなことは当然解っている
＞オレが話しているのは、XPが出来た分だけ料金を請求すると言うところだ
＞これじゃ顧客は困るだろう
契約書のマジックで対応でしょ。
例えば第三イテレーションまででできるのを開発費にして、
そこからあとは保守費にするとかなんとか。
＞これらがごく当たり前のことなのか？
＞よっぽど変なところで働いているんだな
色々書いてるけど、俺は企業相手じゃなくてエンドユーザ相手に
ソフトウェア作る会社にいるから XP そのままは使ってないよ。
＞UnitTest - リファクタリングで自然に最適な形になるとは思えない
＞修正が難しい形に流れてしまう可能性が高い
何も考えずにコーディングに入るわけじゃなく、
シナリオ・タスク作成を先にやるけど。
＞レイヤーの違うプログラムを分業をする場合、常に二人単位の人間を必要とする
＞これでは人を使いすぎると言っているわけだ
んー人月増えるのはたしかだね。
複数人で集まってのソースレビュー作業が省けたりする部分はあるが。
ペアプロがコードの質の向上にどれくらい貢献するのかを
示すデータってのもあんまりないので難しいところだね。
＞あと、XPは反復開発の一種だと言っているがそんなことは当然解っている
＞オレが話しているのは、XPが出来た分だけ料金を請求すると言うところだ
＞これじゃ顧客は困るだろう
契約書のマジックで対応でしょ。
例えば第三イテレーションまででできるのを開発費にして、
そこからあとは保守費にするとかなんとか。
＞これらがごく当たり前のことなのか？
＞よっぽど変なところで働いているんだな
色々書いてるけど、俺は企業相手じゃなくてエンドユーザ相手に
ソフトウェア作る会社にいるから XP そのままは使ってないよ。
＞UnitTest - リファクタリングで自然に最適な形になるとは思えない
＞修正が難しい形に流れてしまう可能性が高い
何も考えずにコーディングに入るわけじゃなく、
シナリオ・タスク作成を先にやるけど。
922 ：デフォルトの名無しさん：04/08/01 16:59
>>921
> ペアプロがコードの質の向上にどれくらい貢献するのかを
> 示すデータってのもあんまりないので難しいところだね。
それ以前にそれだけの人員を確保できないところが多いだろ
実際に小規模開発を行うのは零細企業の割合が多いわけだからな
> 例えば第三イテレーションまででできるのを開発費にして、
> そこからあとは保守費にするとかなんとか。
顧客は第三イテレイーションで感性物だと思って、最初に全てのストーリーを
提示するだろう
その時に見積もれる？
結局普通の契約と同じで、これをした瞬間XPに大きな影を落とすわけだが
時間と金の誤差がかなり出るよ
しかし、それで進めなくてはならない
もうXPの根底が崩れるね
> 何も考えずにコーディングに入るわけじゃなく、
> シナリオ・タスク作成を先にやるけど。
シナリオはただの要件に近い、テスク分割はそれを作業単位にまとめただけ
コーディングレベルの設計にまで持って行けないな
XPでは「難しいことを先にやれ」と言っているが、それは計れるものなのかと疑問に思う
これが唯一、方向性を決めるものだと思うのだが、設計としては弱すぎる
> ペアプロがコードの質の向上にどれくらい貢献するのかを
> 示すデータってのもあんまりないので難しいところだね。
それ以前にそれだけの人員を確保できないところが多いだろ
実際に小規模開発を行うのは零細企業の割合が多いわけだからな
> 例えば第三イテレーションまででできるのを開発費にして、
> そこからあとは保守費にするとかなんとか。
顧客は第三イテレイーションで感性物だと思って、最初に全てのストーリーを
提示するだろう
その時に見積もれる？
結局普通の契約と同じで、これをした瞬間XPに大きな影を落とすわけだが
時間と金の誤差がかなり出るよ
しかし、それで進めなくてはならない
もうXPの根底が崩れるね
> 何も考えずにコーディングに入るわけじゃなく、
> シナリオ・タスク作成を先にやるけど。
シナリオはただの要件に近い、テスク分割はそれを作業単位にまとめただけ
コーディングレベルの設計にまで持って行けないな
XPでは「難しいことを先にやれ」と言っているが、それは計れるものなのかと疑問に思う
これが唯一、方向性を決めるものだと思うのだが、設計としては弱すぎる
923 ：デフォルトの名無しさん：04/08/01 17:04
>>921
あと、思ったのだがエンドユーザーがコンシューマーだったりした場合
具体的な顧客がいないのでストーリーの提示などどうするのだろう
フィードバックなども
これらはコンポーネントパッケージの開発やフレームワークにも言えるが
競技に縛り付けられている分、例外に弱そうだ
あと、思ったのだがエンドユーザーがコンシューマーだったりした場合
具体的な顧客がいないのでストーリーの提示などどうするのだろう
フィードバックなども
これらはコンポーネントパッケージの開発やフレームワークにも言えるが
競技に縛り付けられている分、例外に弱そうだ
924 ：デフォルトの名無しさん：04/08/02 19:31
>>915
＞それに、XPの設計をしない理念も応用性が低いな
＞リファクタリングとテストだけで望んだ形になる？
＞馬鹿なｗ
XPは設計をしない、はあなたの勘違い。
まあ、これを読んでみてよ。
http://blog.goo.ne.jp/ikkoan/d/20040708
おまけで IsDesignDead? の邦訳もどうぞ。
http://www.objectclub.jp/community/XP-jp/xp_relate/isdesigndead
＞それに、XPの設計をしない理念も応用性が低いな
＞リファクタリングとテストだけで望んだ形になる？
＞馬鹿なｗ
XPは設計をしない、はあなたの勘違い。
まあ、これを読んでみてよ。
http://blog.goo.ne.jp/ikkoan/d/20040708
おまけで IsDesignDead? の邦訳もどうぞ。
http://www.objectclub.jp/community/XP-jp/xp_relate/isdesigndead
925 ：デフォルトの名無しさん：04/08/02 19:55
>920
> UnitTest - リファクタリングで自然に最適な形になるとは思えない
> 修正が難しい形に流れてしまう可能性が高い
修正が難しい形に流れてしまう可能性が高いのは
「リファクタリングなし＆UnitTestingなし」の方だと思うけど。
リファクタリングされてないコードの修正は、
リファクタリングされてるコードに比べて修正が難しいのは明白だし、
テストのないコードの修正が、テストのあるコードに比べて、
臆病で既存のコードを迂回するような修正になりがち。
「動いてるコードに手をつけるな」という先人の教えがそれを証明しているよね。
既存のコードに手を付けない修正が重なることで設計が劣化していく様を見たことあるでしょ?
> UnitTest - リファクタリングで自然に最適な形になるとは思えない
> 修正が難しい形に流れてしまう可能性が高い
修正が難しい形に流れてしまう可能性が高いのは
「リファクタリングなし＆UnitTestingなし」の方だと思うけど。
リファクタリングされてないコードの修正は、
リファクタリングされてるコードに比べて修正が難しいのは明白だし、
テストのないコードの修正が、テストのあるコードに比べて、
臆病で既存のコードを迂回するような修正になりがち。
「動いてるコードに手をつけるな」という先人の教えがそれを証明しているよね。
既存のコードに手を付けない修正が重なることで設計が劣化していく様を見たことあるでしょ?
926 ：デフォルトの名無しさん：04/08/02 20:00
あと、XPではどのように設計&実装が行われているかを知るためにも
「アジャイルソフトウェア開発の奥義」
の６章の一読をお勧めします。＞920
「アジャイルソフトウェア開発の奥義」
の６章の一読をお勧めします。＞920
927 ：デフォルトの名無しさん：04/08/02 20:17
>>925
>既存のコードに手を付けない修正が重なることで設計が劣化していく様を見たことあるでしょ?
まあ、既存のコードは手を付けると途端に動かなくなる状態だったんだろうな。
きっと「なかなかバグが取れないね～」「動いた～」「はいおしまい」ってな感じで作られたんだろうな。
修正が原因で劣化したのではなく、もとから劣悪な設計だったのが修正時に露呈しただけ、とも言う。
>既存のコードに手を付けない修正が重なることで設計が劣化していく様を見たことあるでしょ?
まあ、既存のコードは手を付けると途端に動かなくなる状態だったんだろうな。
きっと「なかなかバグが取れないね～」「動いた～」「はいおしまい」ってな感じで作られたんだろうな。
修正が原因で劣化したのではなく、もとから劣悪な設計だったのが修正時に露呈しただけ、とも言う。
928 ：デフォルトの名無しさん：04/08/02 20:39
929 ：デフォルトの名無しさん：04/08/02 20:52
>>927
「動いてるコードに手をつけるな」が常識だった時代は確実にあったと思うんだけど。
http://www.ulsystems.co.jp/opinion/technical_report/archive/000006-2.html
---
「正しく動いているコードには触るな」
――従来はそれが常識でした。
---
なんてのもあるしね。
まともにコード書いたことあんの?＞927
「動いてるコードに手をつけるな」が常識だった時代は確実にあったと思うんだけど。
http://www.ulsystems.co.jp/opinion/technical_report/archive/000006-2.html
---
「正しく動いているコードには触るな」
――従来はそれが常識でした。
---
なんてのもあるしね。
まともにコード書いたことあんの?＞927
930 ：デフォルトの名無しさん：04/08/02 21:27
なんか帰ってきたら偉いレスが付いているな
いじめか？ｗ
>>924
そこの論文は当然読んでいる、って言うかXPの水色本の内容だろそれ
で、結論だがそれはファウラーのXP感でしかない
ベックの言うXPとは違うものだ
背景としては、ファウラーがモデラー養成業をしていた、UMLやアナリシスパターンに
尽力していたから、自分なりにカスタマイズしたXPを述べただけだ
オレはファウラーを支持するね
ベックは夢想家だ
>>925
よく嫁
誰が UnitTest - リファクタリング をしないと言った
これは名前が付いただけでウォーターフローでも使っていた技術だ（UnitTestは少し変わるが）
オレが問題にしているのは方向性も無しにこれだけで、ソースが適切な道に進むのかと言うことだ
「難しいことを先にやれ」が唯一方向性を付けるものだがそれだけでは問題がある
ソースという川が左右に分かれていく時、源流に近い位置で分かれた流れを逆流するのは難しいだろう
その意味でも設計が必要になる
Agile な設計がね
XPは（と言うよりベックは）それすら否定している向きがある
自分が苦手だからだ
下らん
>>926
高いよｗ
とりあえず、流し読みはするが
いじめか？ｗ
>>924
そこの論文は当然読んでいる、って言うかXPの水色本の内容だろそれ
で、結論だがそれはファウラーのXP感でしかない
ベックの言うXPとは違うものだ
背景としては、ファウラーがモデラー養成業をしていた、UMLやアナリシスパターンに
尽力していたから、自分なりにカスタマイズしたXPを述べただけだ
オレはファウラーを支持するね
ベックは夢想家だ
>>925
よく嫁
誰が UnitTest - リファクタリング をしないと言った
これは名前が付いただけでウォーターフローでも使っていた技術だ（UnitTestは少し変わるが）
オレが問題にしているのは方向性も無しにこれだけで、ソースが適切な道に進むのかと言うことだ
「難しいことを先にやれ」が唯一方向性を付けるものだがそれだけでは問題がある
ソースという川が左右に分かれていく時、源流に近い位置で分かれた流れを逆流するのは難しいだろう
その意味でも設計が必要になる
Agile な設計がね
XPは（と言うよりベックは）それすら否定している向きがある
自分が苦手だからだ
下らん
>>926
高いよｗ
とりあえず、流し読みはするが
931 ：デフォルトの名無しさん：04/08/02 21:28
ちなみに>>927はオレじゃないので勝手にやってください
932 ：デフォルトの名無しさん：04/08/03 02:03
>>930
>>＞それに、XPの設計をしない理念も応用性が低いな
>>＞リファクタリングとテストだけで望んだ形になる？
>>＞馬鹿なｗ
>>
>> XPは設計をしない、はあなたの勘違い。
>> まあ、これを読んでみてよ。
>
> >>924
> そこの論文は当然読んでいる、って言うかXPの水色本の内容だろそれ
> で、結論だがそれはファウラーのXP感でしかない
> ベックの言うXPとは違うものだ
> 背景としては、ファウラーがモデラー養成業をしていた、UMLやアナリシスパターンに
> 尽力していたから、自分なりにカスタマイズしたXPを述べただけだ
> オレはファウラーを支持するね
> ベックは夢想家だ
まず、930が言うところのファウラーのXPでは、
「XPでは(コーディング中に少しづつ行うか、コーディング前にまとめて行うかの違いはあるにせよ)設計は行われる。」
は同意なんだよね? つまり、
「テストを書く(プチ設計)→コードを書く(プチ設計)→リファクタリング(プチ設計)→テストを書く(プチ設計)→以下繰返し」
というXPの開発スタイルを「馬鹿なw」と一蹴はしない、と。
で、話をファウラーのXPとケント・ベックのXPに移すと、
「ファウラーの言うXPでは設計を行っていて、ケント・ベックの言うXPは設計を行っていない。」
ってことかしら。
# ケント・ベックそんなこと言ってたっけ? あとで調べてみます。
# 関係ないけど、「ベックは夢想家だ」はなんだかカッコイイね。
>>＞それに、XPの設計をしない理念も応用性が低いな
>>＞リファクタリングとテストだけで望んだ形になる？
>>＞馬鹿なｗ
>>
>> XPは設計をしない、はあなたの勘違い。
>> まあ、これを読んでみてよ。
>
> >>924
> そこの論文は当然読んでいる、って言うかXPの水色本の内容だろそれ
> で、結論だがそれはファウラーのXP感でしかない
> ベックの言うXPとは違うものだ
> 背景としては、ファウラーがモデラー養成業をしていた、UMLやアナリシスパターンに
> 尽力していたから、自分なりにカスタマイズしたXPを述べただけだ
> オレはファウラーを支持するね
> ベックは夢想家だ
まず、930が言うところのファウラーのXPでは、
「XPでは(コーディング中に少しづつ行うか、コーディング前にまとめて行うかの違いはあるにせよ)設計は行われる。」
は同意なんだよね? つまり、
「テストを書く(プチ設計)→コードを書く(プチ設計)→リファクタリング(プチ設計)→テストを書く(プチ設計)→以下繰返し」
というXPの開発スタイルを「馬鹿なw」と一蹴はしない、と。
で、話をファウラーのXPとケント・ベックのXPに移すと、
「ファウラーの言うXPでは設計を行っていて、ケント・ベックの言うXPは設計を行っていない。」
ってことかしら。
# ケント・ベックそんなこと言ってたっけ? あとで調べてみます。
# 関係ないけど、「ベックは夢想家だ」はなんだかカッコイイね。
933 ：デフォルトの名無しさん：04/08/03 02:47
>>930
> >>925
> よく嫁
> 誰が UnitTest - リファクタリング をしないと言った
ごめん、そうだね。
> オレが問題にしているのは方向性も無しにこれだけで、ソースが適切な道に進むのかと言うことだ
> 「難しいことを先にやれ」が唯一方向性を付けるものだがそれだけでは問題がある
> ソースという川が左右に分かれていく時、源流に近い位置で分かれた流れを逆流するのは難しいだろう
> その意味でも設計が必要になる
> Agile な設計がね
XPの設計のガイドラインは
> 「難しいことを先にやれ」
ではないんでない?
どっちかというと、
> 「なんとか動いて、最も無駄のないものをやれ」("Do the Simplest Thing that Could Possibly Work")
だと思うんだよね。
これを守っていれば、適切な道に進むかどうかは分からないけど、間違った道には進まないようになる。
XPの「シンプルデザイン」を川のメタファで言えば、源流に近い位置(設計の段階)で流れを分岐させるのではなく、
出来るだけ下流(必要になるときまで)で流れ分岐させるようにして、流れの逆流のコストを最小限にしようとしているんだと思う。
> >>925
> よく嫁
> 誰が UnitTest - リファクタリング をしないと言った
ごめん、そうだね。
> オレが問題にしているのは方向性も無しにこれだけで、ソースが適切な道に進むのかと言うことだ
> 「難しいことを先にやれ」が唯一方向性を付けるものだがそれだけでは問題がある
> ソースという川が左右に分かれていく時、源流に近い位置で分かれた流れを逆流するのは難しいだろう
> その意味でも設計が必要になる
> Agile な設計がね
XPの設計のガイドラインは
> 「難しいことを先にやれ」
ではないんでない?
どっちかというと、
> 「なんとか動いて、最も無駄のないものをやれ」("Do the Simplest Thing that Could Possibly Work")
だと思うんだよね。
これを守っていれば、適切な道に進むかどうかは分からないけど、間違った道には進まないようになる。
XPの「シンプルデザイン」を川のメタファで言えば、源流に近い位置(設計の段階)で流れを分岐させるのではなく、
出来るだけ下流(必要になるときまで)で流れ分岐させるようにして、流れの逆流のコストを最小限にしようとしているんだと思う。
934 ：デフォルトの名無しさん：04/08/03 21:25
>>915
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
あと、テスト駆動な開発を行っていると疎結合なプログラムになりやすい、というのもあるね。
なぜ疎結合になりやすいか?
結城さんの言葉(http://www.hyuki.com/dig/cgitest.html)を借りると
それから、ユニットテストしやすいモジュールを作ると、モジュール間の連携を
疎になるようにしようという気持ちが働きますね。低結合(low coupling)の心。
つまり、ユニットテストしやすいモジュール = 疎結合なモジュール = 良いモジュール、と。
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
あと、テスト駆動な開発を行っていると疎結合なプログラムになりやすい、というのもあるね。
なぜ疎結合になりやすいか?
結城さんの言葉(http://www.hyuki.com/dig/cgitest.html)を借りると
それから、ユニットテストしやすいモジュールを作ると、モジュール間の連携を
疎になるようにしようという気持ちが働きますね。低結合(low coupling)の心。
つまり、ユニットテストしやすいモジュール = 疎結合なモジュール = 良いモジュール、と。
935 ：デフォルトの名無しさん：04/08/03 22:33
>>933
> 「テストを書く(プチ設計)→コードを書く(プチ設計)→リファクタリング(プチ設計)→テストを書く(プチ設計)→以下繰返し」
> というXPの開発スタイルを「馬鹿なw」と一蹴はしない、と。
ぷち設計というものがどういうものなのか、解らないので答えられないな
ファイラーはUMLを使った設計すらしている
UMLを使えと言う意味ではないので誤解無きよう
あと、本家も一度覗いてみることを勧める
> > 「難しいことを先にやれ」
>
> ではないんでない?
> どっちかというと、
>
> > 「なんとか動いて、最も無駄のないものをやれ」("Do the Simplest Thing that Could Possibly Work")
>
> だと思うんだよね。
> これを守っていれば、適切な道に進むかどうかは分からないけど、間違った道には進まないようになる。
・worst things first（難しいことを先にやれ）
ttp://www.xprogramming.com/xpmag/an_open_approach.htm
かなり有名だと思うけどね
あとc2.comの議論もちゃんと読んでおけ
>>934
で、何度も言って絵いるように UnitTest - リファクタリングの流れは否定していない
それだけでは困難な問題が多い、または戻りが大きくなってしまうことが多々あると言うことだ
設計を行わないことのコストはファウラーが国際化対応問題で取り上げている
YAGNIの神への間違った信仰が狂信者を生んでいる
> 「テストを書く(プチ設計)→コードを書く(プチ設計)→リファクタリング(プチ設計)→テストを書く(プチ設計)→以下繰返し」
> というXPの開発スタイルを「馬鹿なw」と一蹴はしない、と。
ぷち設計というものがどういうものなのか、解らないので答えられないな
ファイラーはUMLを使った設計すらしている
UMLを使えと言う意味ではないので誤解無きよう
あと、本家も一度覗いてみることを勧める
> > 「難しいことを先にやれ」
>
> ではないんでない?
> どっちかというと、
>
> > 「なんとか動いて、最も無駄のないものをやれ」("Do the Simplest Thing that Could Possibly Work")
>
> だと思うんだよね。
> これを守っていれば、適切な道に進むかどうかは分からないけど、間違った道には進まないようになる。
・worst things first（難しいことを先にやれ）
ttp://www.xprogramming.com/xpmag/an_open_approach.htm
かなり有名だと思うけどね
あとc2.comの議論もちゃんと読んでおけ
>>934
で、何度も言って絵いるように UnitTest - リファクタリングの流れは否定していない
それだけでは困難な問題が多い、または戻りが大きくなってしまうことが多々あると言うことだ
設計を行わないことのコストはファウラーが国際化対応問題で取り上げている
YAGNIの神への間違った信仰が狂信者を生んでいる
936 ：デフォルトの名無しさん：04/08/03 23:56
YAGNI 至上主義は状況によって罠にハマるね
937 ：デフォルトの名無しさん：04/08/03 23:57
>>935
> ファイラーはUMLを使った設計すらしている
コーディング前のクラス図なんかのラフスケッチは当然やってます。
ファウラーに限った話じゃなくケント・ベックだってやっている話だよね。
> > > 「難しいことを先にやれ」
> > ではないんでない?
> > どっちかというと、
> > > 「なんとか動いて、最も無駄のないものをやれ」("Do the Simplest Thing that Could Possibly Work")
> > だと思うんだよね。
> > これを守っていれば、適切な道に進むかどうかは分からないけど、間違った道には進まないようになる。
> ・worst things first（難しいことを先にやれ）
> ttp://www.xprogramming.com/xpmag/an_open_approach.htm
>
> かなり有名だと思うけどね
設計の初期にハイリスクなタスクを持ってこよう、という話だよね。それは存じております。
で、「worst things first」の一番の理由はリスクヘッジだと思うんだけど、>>930を見ると
>オレが問題にしているのは方向性も無しにこれだけで、ソースが適切な道に進むのかと言うことだ
>「難しいことを先にやれ」が唯一方向性を付けるものだがそれだけでは問題がある
「worst things first」が設計の方向付け、ガイドラインだ、と言ってるように聞こえる。
で、設計のガイドラインは「worst things first」ではなく
「Do the Simplest Thing that Could Possibly Work」ではないのか、と申している次第です。
> ファイラーはUMLを使った設計すらしている
コーディング前のクラス図なんかのラフスケッチは当然やってます。
ファウラーに限った話じゃなくケント・ベックだってやっている話だよね。
> > > 「難しいことを先にやれ」
> > ではないんでない?
> > どっちかというと、
> > > 「なんとか動いて、最も無駄のないものをやれ」("Do the Simplest Thing that Could Possibly Work")
> > だと思うんだよね。
> > これを守っていれば、適切な道に進むかどうかは分からないけど、間違った道には進まないようになる。
> ・worst things first（難しいことを先にやれ）
> ttp://www.xprogramming.com/xpmag/an_open_approach.htm
>
> かなり有名だと思うけどね
設計の初期にハイリスクなタスクを持ってこよう、という話だよね。それは存じております。
で、「worst things first」の一番の理由はリスクヘッジだと思うんだけど、>>930を見ると
>オレが問題にしているのは方向性も無しにこれだけで、ソースが適切な道に進むのかと言うことだ
>「難しいことを先にやれ」が唯一方向性を付けるものだがそれだけでは問題がある
「worst things first」が設計の方向付け、ガイドラインだ、と言ってるように聞こえる。
で、設計のガイドラインは「worst things first」ではなく
「Do the Simplest Thing that Could Possibly Work」ではないのか、と申している次第です。
938 ：デフォルトの名無しさん：04/08/04 00:01
>>935
> >>934
> で、何度も言って絵いるように UnitTest - リファクタリングの流れは否定していない
> それだけでは困難な問題が多い、または戻りが大きくなってしまうことが多々あると言うことだ
> 設計を行わないことのコストはファウラーが国際化対応問題で取り上げている
大人数のプロジェクトにはXPはむいていないといわれるように、国際化等の大がかりなフレームワークが必要な状況にはXPはむいていないのかもしれないね。
けど、それを理由に
＞それに、XPの設計をしない理念も応用性が低いな
＞リファクタリングとテストだけで望んだ形になる？
＞馬鹿なｗ
というのは、どうかと思うけど。
この言い方では、あらゆる状況でXPの開発プロセスは使えないと言っているようにとれるよね。
裏を返せば、国際化対応のような状況以外ではXPは使える、ってファウラーも言ってるってことでしょ。
> YAGNIの神への間違った信仰が狂信者を生んでいる
YAGNIと国際化云々の話は別な話じゃないかしら。
> >>934
> で、何度も言って絵いるように UnitTest - リファクタリングの流れは否定していない
> それだけでは困難な問題が多い、または戻りが大きくなってしまうことが多々あると言うことだ
> 設計を行わないことのコストはファウラーが国際化対応問題で取り上げている
大人数のプロジェクトにはXPはむいていないといわれるように、国際化等の大がかりなフレームワークが必要な状況にはXPはむいていないのかもしれないね。
けど、それを理由に
＞それに、XPの設計をしない理念も応用性が低いな
＞リファクタリングとテストだけで望んだ形になる？
＞馬鹿なｗ
というのは、どうかと思うけど。
この言い方では、あらゆる状況でXPの開発プロセスは使えないと言っているようにとれるよね。
裏を返せば、国際化対応のような状況以外ではXPは使える、ってファウラーも言ってるってことでしょ。
> YAGNIの神への間違った信仰が狂信者を生んでいる
YAGNIと国際化云々の話は別な話じゃないかしら。
939 ：デフォルトの名無しさん：04/08/04 00:01
940 ：デフォルトの名無しさん：04/08/04 00:06
と、ここまで書いて思い出したんだけど、
>>935はファウラーの言うXPは認めているんだよね。で、ケント・ベックのいうXPはダメだと。
(ファウラーとケント・ベックの違いはまだ分かってないけど)それならおれ的にはこれ以上言うことは無いです。
>>935はファウラーの言うXPは認めているんだよね。で、ケント・ベックのいうXPはダメだと。
(ファウラーとケント・ベックの違いはまだ分かってないけど)それならおれ的にはこれ以上言うことは無いです。
941 ：デフォルトの名無しさん：04/08/04 00:34
>>937
> コーディング前のクラス図なんかのラフスケッチは当然やってます。
> ファウラーに限った話じゃなくケント・ベックだってやっている話だよね。
ベックはやってないよ
＞しかし、そこには「本当のXP実践者はダイアグラムなんか使わないのだ」と言う意味合いが濃厚に
＞出ている。このことは、Kent の様な人々がダイアグラムをまったく苦手としているという事実によって
＞裏打ちされる。実際、Kent が自分から、決められた表記法に基づいてソフトウェアの図を書いたところ
＞を私は見たことがない。
> 「worst things first」が設計の方向付け、ガイドラインだ、と言ってるように聞こえる。
> で、設計のガイドラインは「worst things first」ではなく
> 「Do the Simplest Thing that Could Possibly Work」ではないのか、と申している次第です。
それは設計のガイドラインではなく（タスク選択指標ではなく）、選択したタスクを実装する場合の方法だろ
TDD的に言えば、定数で置換えてとりあえず仮実装をする、そして一番シンプルな方法でそれを置換えて
実装をする。そう言う話だ。その後リファクタリングは言わなくても良いだろう。
そちらこそ解釈を間違えていると思うが如何か。
> コーディング前のクラス図なんかのラフスケッチは当然やってます。
> ファウラーに限った話じゃなくケント・ベックだってやっている話だよね。
ベックはやってないよ
＞しかし、そこには「本当のXP実践者はダイアグラムなんか使わないのだ」と言う意味合いが濃厚に
＞出ている。このことは、Kent の様な人々がダイアグラムをまったく苦手としているという事実によって
＞裏打ちされる。実際、Kent が自分から、決められた表記法に基づいてソフトウェアの図を書いたところ
＞を私は見たことがない。
> 「worst things first」が設計の方向付け、ガイドラインだ、と言ってるように聞こえる。
> で、設計のガイドラインは「worst things first」ではなく
> 「Do the Simplest Thing that Could Possibly Work」ではないのか、と申している次第です。
それは設計のガイドラインではなく（タスク選択指標ではなく）、選択したタスクを実装する場合の方法だろ
TDD的に言えば、定数で置換えてとりあえず仮実装をする、そして一番シンプルな方法でそれを置換えて
実装をする。そう言う話だ。その後リファクタリングは言わなくても良いだろう。
そちらこそ解釈を間違えていると思うが如何か。
942 ：デフォルトの名無しさん：04/08/04 00:35
>>938
> というのは、どうかと思うけど。
> この言い方では、あらゆる状況でXPの開発プロセスは使えないと言っているようにとれるよね。
> 裏を返せば、国際化対応のような状況以外ではXPは使える、ってファウラーも言ってるってことでしょ。
国際化はただの一例だ、それだけではない
レイヤーを意識した開発などは全て当てはまるだろう
> > YAGNIの神への間違った信仰が狂信者を生んでいる
> YAGNIと国際化云々の話は別な話じゃないかしら。
別じゃないだろ
また上記のように国際化だけの問題じゃない
> と、ここまで書いて思い出したんだけど、
> >>935はファウラーの言うXPは認めているんだよね。で、ケント・ベックのいうXPはダメだと。
> (ファウラーとケント・ベックの違いはまだ分かってないけど)それならおれ的にはこれ以上言うことは無いです。
別にファウラーのXPを認めるというスタンスじゃない
XPにはまだまだ多くの現実的な問題を抱えている（>>920>>922）
> というのは、どうかと思うけど。
> この言い方では、あらゆる状況でXPの開発プロセスは使えないと言っているようにとれるよね。
> 裏を返せば、国際化対応のような状況以外ではXPは使える、ってファウラーも言ってるってことでしょ。
国際化はただの一例だ、それだけではない
レイヤーを意識した開発などは全て当てはまるだろう
> > YAGNIの神への間違った信仰が狂信者を生んでいる
> YAGNIと国際化云々の話は別な話じゃないかしら。
別じゃないだろ
また上記のように国際化だけの問題じゃない
> と、ここまで書いて思い出したんだけど、
> >>935はファウラーの言うXPは認めているんだよね。で、ケント・ベックのいうXPはダメだと。
> (ファウラーとケント・ベックの違いはまだ分かってないけど)それならおれ的にはこれ以上言うことは無いです。
別にファウラーのXPを認めるというスタンスじゃない
XPにはまだまだ多くの現実的な問題を抱えている（>>920>>922）
943 ：デフォルトの名無しさん：04/08/04 00:39
ちょうど、勧められた本に面白い感想があったので載せよう
ttp://mag.autumn.org/Content.aspx?id=20040712170744
ttp://mag.autumn.org/Content.aspx?id=20040712170744
944 ：名無しさん＠Linuxザウルス：04/08/04 00:51
>>941
はぁ。
UMLは使ってなくても CRCカードは使ってるんじゃない。
http://c2.com/doc/oopsla89/paper.html
# Kent Beckはアップルにいたことあるのな。初めて知った。
はぁ。
UMLは使ってなくても CRCカードは使ってるんじゃない。
http://c2.com/doc/oopsla89/paper.html
# Kent Beckはアップルにいたことあるのな。初めて知った。
945 ：名無しさん＠Linuxザウルス：04/08/04 01:00
>>942
「国際化対」じゃなくて「国際化対応のような」って言ってるですよ。
脳内で
s/国際化対応のような/国際化等の大がかりなフレームワーク/g
してくだされ。
で、その上で
> 裏を返せば、国際化対応のような状況以外ではXPは使える、ってファウラーも言ってるってことでしょ。
についてはどうお思いですか?
「国際化対」じゃなくて「国際化対応のような」って言ってるですよ。
脳内で
s/国際化対応のような/国際化等の大がかりなフレームワーク/g
してくだされ。
で、その上で
> 裏を返せば、国際化対応のような状況以外ではXPは使える、ってファウラーも言ってるってことでしょ。
についてはどうお思いですか?
946 ：名無しさん＠Linuxザウルス：04/08/04 01:05
>>942
>> > YAGNIの神への間違った信仰が狂信者を生んでいる
>> YAGNIと国際化云々の話は別な話じゃないかしら。
>別じゃないだろ
>また上記のように国際化だけの問題じゃない
国際化等の大がかりなフレームワークと「YAGNIの神への間違った信仰」はどう話がつながっているの?
>> > YAGNIの神への間違った信仰が狂信者を生んでいる
>> YAGNIと国際化云々の話は別な話じゃないかしら。
>別じゃないだろ
>また上記のように国際化だけの問題じゃない
国際化等の大がかりなフレームワークと「YAGNIの神への間違った信仰」はどう話がつながっているの?
947 ：デフォルトの名無しさん：04/08/04 01:15
>>944
できれば、「はぁ」とか言って欲しくないものだが
> UMLは使ってなくても CRCカードは使ってるんじゃない。
>
> http://c2.com/doc/oopsla89/paper.htmlOpen
それはいつの記事だい？
近況のXPはCRCすら排除の方向にあるけど
>>945
何故大がかりなフレームワークになる
ここで問題なるのは影響が大きい問題の解決だ
規模の大きさではない
３～５層からなるソフトウェアの開発（１０人以下の小規模）でも問題になってくる
>>946
YAGNI への間違った信仰とは、設計が YAGNI を脅かすという思いこみから来る
また、>>941の
> > 「worst things first」が設計の方向付け、ガイドラインだ、と言ってるように聞こえる。
> > で、設計のガイドラインは「worst things first」ではなく
> > 「Do the Simplest Thing that Could Possibly Work」ではないのか、と申している次第です。
> それは設計のガイドラインではなく（タスク選択指標ではなく）、選択したタスクを実装する場合の方法だろ
> TDD的に言えば、定数で置換えてとりあえず仮実装をする、そして一番シンプルな方法でそれを置換えて
> 実装をする。そう言う話だ。その後リファクタリングは言わなくても良いだろう。
> そちらこそ解釈を間違えていると思うが如何か。
には、納得して頂いただけたのか気になるところだ
できれば、「はぁ」とか言って欲しくないものだが
> UMLは使ってなくても CRCカードは使ってるんじゃない。
>
> http://c2.com/doc/oopsla89/paper.htmlOpen
それはいつの記事だい？
近況のXPはCRCすら排除の方向にあるけど
>>945
何故大がかりなフレームワークになる
ここで問題なるのは影響が大きい問題の解決だ
規模の大きさではない
３～５層からなるソフトウェアの開発（１０人以下の小規模）でも問題になってくる
>>946
YAGNI への間違った信仰とは、設計が YAGNI を脅かすという思いこみから来る
また、>>941の
> > 「worst things first」が設計の方向付け、ガイドラインだ、と言ってるように聞こえる。
> > で、設計のガイドラインは「worst things first」ではなく
> > 「Do the Simplest Thing that Could Possibly Work」ではないのか、と申している次第です。
> それは設計のガイドラインではなく（タスク選択指標ではなく）、選択したタスクを実装する場合の方法だろ
> TDD的に言えば、定数で置換えてとりあえず仮実装をする、そして一番シンプルな方法でそれを置換えて
> 実装をする。そう言う話だ。その後リファクタリングは言わなくても良いだろう。
> そちらこそ解釈を間違えていると思うが如何か。
には、納得して頂いただけたのか気になるところだ
948 ：デフォルトの名無しさん：04/08/04 01:16
あと、>>943の感想も伺いたい
949 ：名無しさん＠Linuxザウルス：04/08/04 01:18
>>942
>別にファウラーのXPを認めるというスタンスじゃない
>XPにはまだまだ多くの現実的な問題を抱えている（>>920>>922）
XPにも問題がいろいろあるのは確かだね。その点は同意。
# >>920,922にはちょいちょい異論もあるけどそれは別の機会に。
が、それを理由にXPを全否定するのはどうかと思うね。
いくつかの問題が有ってなお XP導入のメリットは大きいとおれは考えている。
そういえば、942はXPに対してはどういうスタンスなの?
部分否定?
全否定?
915を見ると全否定のようにとれるが。
>別にファウラーのXPを認めるというスタンスじゃない
>XPにはまだまだ多くの現実的な問題を抱えている（>>920>>922）
XPにも問題がいろいろあるのは確かだね。その点は同意。
# >>920,922にはちょいちょい異論もあるけどそれは別の機会に。
が、それを理由にXPを全否定するのはどうかと思うね。
いくつかの問題が有ってなお XP導入のメリットは大きいとおれは考えている。
そういえば、942はXPに対してはどういうスタンスなの?
部分否定?
全否定?
915を見ると全否定のようにとれるが。
950 ：デフォルトの名無しさん：04/08/04 01:23
>>949
XPを全否定する理由はすべてのプラクティスの強制
全てを組み入れないと効果が出ないというスタンス
部分的に見て、業界への貢献度は
・インクリメンタル開発の普及
・テストファースト
・リファクタリング（メタ的な意味合い）
ただ、それなら一般的なアジャイル開発プロセスも支持できる
ASDなどはかなり柔軟性が高い
またインクリメンタル開発から、階層的開発への発展もあるだろう
XPを全否定する理由はすべてのプラクティスの強制
全てを組み入れないと効果が出ないというスタンス
部分的に見て、業界への貢献度は
・インクリメンタル開発の普及
・テストファースト
・リファクタリング（メタ的な意味合い）
ただ、それなら一般的なアジャイル開発プロセスも支持できる
ASDなどはかなり柔軟性が高い
またインクリメンタル開発から、階層的開発への発展もあるだろう
951 ：デフォルトの名無しさん：04/08/04 04:01
なんか、Ron Jeffriesの発言が、Kent Beck の発言に置き換えられているよう
な気がする。
な気がする。
952 ：デフォルトの名無しさん：04/08/04 10:07
>>947
> >>944
> できれば、「はぁ」とか言って欲しくないものだが
これは後悔してる。ごめんなさい。
>>941の
> >>937
> > コーディング前のクラス図なんかのラフスケッチは当然やってます。
> > ファウラーに限った話じゃなくケント・ベックだってやっている話だよね。
> ベックはやってないよ
>
> ＞しかし、そこには「本当のXP実践者はダイアグラムなんか使わないのだ」と言う意味合いが濃厚に
> ＞出ている。このことは、Kent の様な人々がダイアグラムをまったく苦手としているという事実によって
> ＞裏打ちされる。実際、Kent が自分から、決められた表記法に基づいてソフトウェアの図を書いたところを私は見たことがない。
の以下のところに注目。ケント・ベックはUMLやらなにやらを使ってないだけで図は描いているように読み取れる。
>決められた表記法に基づいてソフトウェアの図を書いたところを
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
繰り返すけど、ケント・ベックだってラフスケッチはやっていると思うよ。UMLみたいな表記法を使ってないだけで。
> >>944
> できれば、「はぁ」とか言って欲しくないものだが
これは後悔してる。ごめんなさい。
>>941の
> >>937
> > コーディング前のクラス図なんかのラフスケッチは当然やってます。
> > ファウラーに限った話じゃなくケント・ベックだってやっている話だよね。
> ベックはやってないよ
>
> ＞しかし、そこには「本当のXP実践者はダイアグラムなんか使わないのだ」と言う意味合いが濃厚に
> ＞出ている。このことは、Kent の様な人々がダイアグラムをまったく苦手としているという事実によって
> ＞裏打ちされる。実際、Kent が自分から、決められた表記法に基づいてソフトウェアの図を書いたところを私は見たことがない。
の以下のところに注目。ケント・ベックはUMLやらなにやらを使ってないだけで図は描いているように読み取れる。
>決められた表記法に基づいてソフトウェアの図を書いたところを
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
繰り返すけど、ケント・ベックだってラフスケッチはやっていると思うよ。UMLみたいな表記法を使ってないだけで。
953 ：デフォルトの名無しさん：04/08/04 10:24
>>943
> ちょうど、勧められた本に面白い感想があったので載せよう
> ttp://mag.autumn.org/Content.aspx?id=20040712170744
>と言うことは、この著者は頭ではXPを分かっているつもりでいながら、
>身体には古い常識が染み込んでいて、文章が矛盾して分裂してしまっている?
確かに矛盾しているように見える。
けど、この一文からのみで
> と言うことは、この著者は頭ではXPを分かっているつもりでいながら、
> 身体には古い常識が染み込んでいて、、文章が矛盾して分裂してしまっている?
っつーのは乱暴すぎるかと。
誤字がひとつあっただけで「こいつの日本語はなってない!!」と言うのと同じぐらい乱暴。
>>943はこのページで何を訴えようとしてますか?
> ちょうど、勧められた本に面白い感想があったので載せよう
> ttp://mag.autumn.org/Content.aspx?id=20040712170744
>と言うことは、この著者は頭ではXPを分かっているつもりでいながら、
>身体には古い常識が染み込んでいて、文章が矛盾して分裂してしまっている?
確かに矛盾しているように見える。
けど、この一文からのみで
> と言うことは、この著者は頭ではXPを分かっているつもりでいながら、
> 身体には古い常識が染み込んでいて、、文章が矛盾して分裂してしまっている?
っつーのは乱暴すぎるかと。
誤字がひとつあっただけで「こいつの日本語はなってない!!」と言うのと同じぐらい乱暴。
>>943はこのページで何を訴えようとしてますか?
954 ：デフォルトの名無しさん：04/08/04 13:41
>>935
> それだけでは困難な問題が多い、または戻りが大きくなってしまうことが多々あると言うことだ
> 設計を行わないことのコストはファウラーが国際化対応問題で取り上げている
>
> YAGNIの神への間違った信仰が狂信者を生んでいる
Continuous Design
http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
を見ると、>>935でいう「困難な問題」は杞憂のようだね。
事前設計した永続化層は最悪だった、とまで言っている。
---
I hedged my bets: I designed a layered architecture and persistence model up-front.
The persistence model was a disaster: it required a huge amount of code to do simple things.
Continuous design, however, was a roaring success.
The application, developed over 16 months by six people, had the best design I’d seen.
Bit by bit, continuous design fixed the persistence model too,
eventually giving us an elegant solution that was simple and flexible.
---
あと、ファウラーも Is Design Dead?(http://www.martinfowler.com/articles/designDead.html)で以下のように言っている。
---
A recent article by Jim Shore discusses some situations, including internationalization, where potential boundaries turned out not to be barriers after all.
---
これでもまだ
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
と言い続けますか?
> それだけでは困難な問題が多い、または戻りが大きくなってしまうことが多々あると言うことだ
> 設計を行わないことのコストはファウラーが国際化対応問題で取り上げている
>
> YAGNIの神への間違った信仰が狂信者を生んでいる
Continuous Design
http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
を見ると、>>935でいう「困難な問題」は杞憂のようだね。
事前設計した永続化層は最悪だった、とまで言っている。
---
I hedged my bets: I designed a layered architecture and persistence model up-front.
The persistence model was a disaster: it required a huge amount of code to do simple things.
Continuous design, however, was a roaring success.
The application, developed over 16 months by six people, had the best design I’d seen.
Bit by bit, continuous design fixed the persistence model too,
eventually giving us an elegant solution that was simple and flexible.
---
あと、ファウラーも Is Design Dead?(http://www.martinfowler.com/articles/designDead.html)で以下のように言っている。
---
A recent article by Jim Shore discusses some situations, including internationalization, where potential boundaries turned out not to be barriers after all.
---
これでもまだ
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
と言い続けますか?
955 ：デフォルトの名無しさん：04/08/04 16:33
>>950
> XPを全否定する理由はすべてのプラクティスの強制
寡聞にして知らないのだけど、XPが全てのプラクティスを強制している、のソースはどこでしょうか?
> 全てを組み入れないと効果が出ないというスタンス
それぞれのプラクティスの相互作用によって効果を高めあっていて、全てのプラクティスを組み合わせると効果がMAXになる。
が、全てを組み入れないと効果が出ないなんてことはなくて、組み合わせれば組み合わせた分の効果は出ると思うよ。
> XPを全否定する理由はすべてのプラクティスの強制
寡聞にして知らないのだけど、XPが全てのプラクティスを強制している、のソースはどこでしょうか?
> 全てを組み入れないと効果が出ないというスタンス
それぞれのプラクティスの相互作用によって効果を高めあっていて、全てのプラクティスを組み合わせると効果がMAXになる。
が、全てを組み入れないと効果が出ないなんてことはなくて、組み合わせれば組み合わせた分の効果は出ると思うよ。
956 ：デフォルトの名無しさん：04/08/04 21:36
>>954
ごめんなさい、なんだか失礼な言い方でした。手遅れなれど訂正。
= 訂正前
これでもまだ
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
と言い続けますか?
= 訂正後
これでもまだ
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
と思われますか?
ごめんなさい、なんだか失礼な言い方でした。手遅れなれど訂正。
= 訂正前
これでもまだ
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
と言い続けますか?
= 訂正後
これでもまだ
> リファクタリングとテストだけで望んだ形になる？
> 馬鹿なｗ
と思われますか?
957 ：デフォルトの名無しさん：04/08/05 00:32
色々書いてくれてありがとう
書くことは沢山がるが、今日は酒が多量に入ってしまっているのでまともに返せそうにない
すまないが後日と言うことにしてくれ
あと、あまり畏まらなくて良いよ
主張としての強い論調なら別に構わないから
それすらこちらの希望に過ぎない
お任せする
# 関係ないが今日はいろいろなベンチャー企業の面白い話が聞けた
# 開発プロセスと資金繰りの問題はかなりの面でぶつかるようだ
書くことは沢山がるが、今日は酒が多量に入ってしまっているのでまともに返せそうにない
すまないが後日と言うことにしてくれ
あと、あまり畏まらなくて良いよ
主張としての強い論調なら別に構わないから
それすらこちらの希望に過ぎない
お任せする
# 関係ないが今日はいろいろなベンチャー企業の面白い話が聞けた
# 開発プロセスと資金繰りの問題はかなりの面でぶつかるようだ
958 ：デフォルトの名無しさん：04/08/05 10:23
950 じゃないけど。
> XPが全てのプラクティスを強制している、のソースはどこでしょうか?
例えばここにあるファウラーの昔の文章の中に
http://www.objectclub.jp/community/XP-jp/xp_relate/xpvariations-j
>>XPには従うべきプラクティスが12個あるし、また、みんなが12個のプラクティ
>>スの全てを行うようにとXPの主導者が腐心していることは、関連するディスカッ
>>ショングループをずっと追いかけていればすぐに明らかになるからだ。
という表現が出てくる。しかしながら、そのすぐ後で、
>>しかしXPの魅力は、XPの具体的なプラクティスに惹かれたのではなく、XPの
>>底部を流れる「哲学」に共鳴した人々から産み出されているのだ。
と続く。
初期の XP では、各プラクティスは有機的なつながりがあって、ひとつだけを
取り出しても十分に機能しない、という主張がなされていたが、これは個々の
プラクティスを取り上げ各個撃破しようとする批判に対する反論として行われ
たものっぽい。
最近ではむしろ、プラクティスはそれぞれの現場にあわせて適切にリファクタ
リングして導入されるべきだ、ぐらいの方向に変わりつつあって、Kent Beck
ですら、TDD を独立したテクニックとして語るようになっている。
> XPが全てのプラクティスを強制している、のソースはどこでしょうか?
例えばここにあるファウラーの昔の文章の中に
http://www.objectclub.jp/community/XP-jp/xp_relate/xpvariations-j
>>XPには従うべきプラクティスが12個あるし、また、みんなが12個のプラクティ
>>スの全てを行うようにとXPの主導者が腐心していることは、関連するディスカッ
>>ショングループをずっと追いかけていればすぐに明らかになるからだ。
という表現が出てくる。しかしながら、そのすぐ後で、
>>しかしXPの魅力は、XPの具体的なプラクティスに惹かれたのではなく、XPの
>>底部を流れる「哲学」に共鳴した人々から産み出されているのだ。
と続く。
初期の XP では、各プラクティスは有機的なつながりがあって、ひとつだけを
取り出しても十分に機能しない、という主張がなされていたが、これは個々の
プラクティスを取り上げ各個撃破しようとする批判に対する反論として行われ
たものっぽい。
最近ではむしろ、プラクティスはそれぞれの現場にあわせて適切にリファクタ
リングして導入されるべきだ、ぐらいの方向に変わりつつあって、Kent Beck
ですら、TDD を独立したテクニックとして語るようになっている。
959 ：デフォルトの名無しさん：04/08/05 10:45
>>954
>あと、ファウラーも Is Design Dead?(http://www.martinfowler.com/articles/designDead.html)で以下のように言っている。
これ、以下の日本語訳には反映されていないね。
http://www.objectclub.jp/community/XP-jp/xp_relate/isdesigndead
Is Design Dead? は何度か改訂されていて、翻訳の内容がちょっと古くなっているみたい。
>あと、ファウラーも Is Design Dead?(http://www.martinfowler.com/articles/designDead.html)で以下のように言っている。
これ、以下の日本語訳には反映されていないね。
http://www.objectclub.jp/community/XP-jp/xp_relate/isdesigndead
Is Design Dead? は何度か改訂されていて、翻訳の内容がちょっと古くなっているみたい。
960 ：デフォルトの名無しさん：04/08/05 23:41
今日もまた酒が入っているが、手の甲を定規でしこたま叩かれそうなのでここらで返しておこう:-)
>>952
> 繰り返すけど、ケント・ベックだってラフスケッチはやっていると思うよ。UMLみたいな表記法を使ってないだけで。
これは平行線になりそうなので議論から外す
憶測を題材に進めるのは賢い方法ではない
>>953
> >>943はこのページで何を訴えようとしてますか?
実際にその意味を理解している人間の少なさ
ピアゾンのXPシリーズでも本当にベックが監修したのか、首をかしげたくなるものが多い
また意見のぶつかり合いなど（XPみどり本etc）、プロセスとして不安定なものがあり使用者をとまどわせる
>>952
> 繰り返すけど、ケント・ベックだってラフスケッチはやっていると思うよ。UMLみたいな表記法を使ってないだけで。
これは平行線になりそうなので議論から外す
憶測を題材に進めるのは賢い方法ではない
>>953
> >>943はこのページで何を訴えようとしてますか?
実際にその意味を理解している人間の少なさ
ピアゾンのXPシリーズでも本当にベックが監修したのか、首をかしげたくなるものが多い
また意見のぶつかり合いなど（XPみどり本etc）、プロセスとして不安定なものがあり使用者をとまどわせる
961 ：デフォルトの名無しさん：04/08/05 23:42
>>954-956
> これでもまだ
> > リファクタリングとテストだけで望んだ形になる？
> > 馬鹿なｗ
> と思われますか?
この開発手法の利点の根源は、「仕様は必ず変わる」と言う部分に帰結する
さて、呪文のようにこれらの言葉を言われ続けている事は真実なのだろうか？
答えは「Yes」だ
確かに仕様は、変わるだろう
ただ、その頻度はどうなんだろうか？
影響範囲は？
細かいテストとリファクタリングのは起こりうる変化にかかるコストを先払いすることで一定の速度を確保する
ローギアで山道を警戒しながら走るのと同じ事だ
それに対して、今までの開発手法はトップスピードで突き抜けるようなもの
単純なスピードは速いがパンクや、ガードレール直撃、JAFのお世話になって結局遅く目的地に着く可能性もある
ヘタをしたら、ガードレールを突っ切り谷底へのダイブを敢行する者もいるだろう:-P
しかし、ここで前提を確認してふと思うことがある
「はたして、常に道は山道なのであろうか？」
道には山道には山道の、ハイウェイにはハイウェイの走り方がある
同じ事が開発プロセスにも言える
企業運用プロセスも、インクリメンタルからこのような階層的プロセスに移りつつあり
この波がソフトウェア開発にも流れてくる可能性は非常に高いのではと最近強く感じる
そう、最適なスピードは階層化された進化型開発によってもたらされるのではと
まず、もう一度頭を空にして感じる事を進める
あと、こうなると既にXPの話ではなくなり、XPにこだわる価値は低くなる
やはり、XPのXPたる所以はその12のプラクティスにあるのだろう
> これでもまだ
> > リファクタリングとテストだけで望んだ形になる？
> > 馬鹿なｗ
> と思われますか?
この開発手法の利点の根源は、「仕様は必ず変わる」と言う部分に帰結する
さて、呪文のようにこれらの言葉を言われ続けている事は真実なのだろうか？
答えは「Yes」だ
確かに仕様は、変わるだろう
ただ、その頻度はどうなんだろうか？
影響範囲は？
細かいテストとリファクタリングのは起こりうる変化にかかるコストを先払いすることで一定の速度を確保する
ローギアで山道を警戒しながら走るのと同じ事だ
それに対して、今までの開発手法はトップスピードで突き抜けるようなもの
単純なスピードは速いがパンクや、ガードレール直撃、JAFのお世話になって結局遅く目的地に着く可能性もある
ヘタをしたら、ガードレールを突っ切り谷底へのダイブを敢行する者もいるだろう:-P
しかし、ここで前提を確認してふと思うことがある
「はたして、常に道は山道なのであろうか？」
道には山道には山道の、ハイウェイにはハイウェイの走り方がある
同じ事が開発プロセスにも言える
企業運用プロセスも、インクリメンタルからこのような階層的プロセスに移りつつあり
この波がソフトウェア開発にも流れてくる可能性は非常に高いのではと最近強く感じる
そう、最適なスピードは階層化された進化型開発によってもたらされるのではと
まず、もう一度頭を空にして感じる事を進める
あと、こうなると既にXPの話ではなくなり、XPにこだわる価値は低くなる
やはり、XPのXPたる所以はその12のプラクティスにあるのだろう
962 ：デフォルトの名無しさん：04/08/05 23:43
>>958
> 初期の XP では、各プラクティスは有機的なつながりがあって、ひとつだけを
> 取り出しても十分に機能しない、という主張がなされていたが、これは個々の
> プラクティスを取り上げ各個撃破しようとする批判に対する反論として行われ
> たものっぽい。
これは穿ちすぎだな
憶測の域を出ない
> 最近ではむしろ、プラクティスはそれぞれの現場にあわせて適切にリファクタ
> リングして導入されるべきだ、ぐらいの方向に変わりつつあって、Kent Beck
> ですら、TDD を独立したテクニックとして語るようになっている。
これは、切り売りしたわけではなく具体的な手法としての補完だろう
しかし、ここでもある程度問題を見ることが出来る
例えば有名なMoneyオブジェクトについてだが、明らかに指針に基づいた修正を行っているように見える
それは、ベック（もしくはカミンガム）の今まで培ってきた経験によるものに他ならない
テストとリファクタリングをしたら最適な形になったのではなく、最適な形へ向かってテストとリファクタリング
をしているわけだ
> 初期の XP では、各プラクティスは有機的なつながりがあって、ひとつだけを
> 取り出しても十分に機能しない、という主張がなされていたが、これは個々の
> プラクティスを取り上げ各個撃破しようとする批判に対する反論として行われ
> たものっぽい。
これは穿ちすぎだな
憶測の域を出ない
> 最近ではむしろ、プラクティスはそれぞれの現場にあわせて適切にリファクタ
> リングして導入されるべきだ、ぐらいの方向に変わりつつあって、Kent Beck
> ですら、TDD を独立したテクニックとして語るようになっている。
これは、切り売りしたわけではなく具体的な手法としての補完だろう
しかし、ここでもある程度問題を見ることが出来る
例えば有名なMoneyオブジェクトについてだが、明らかに指針に基づいた修正を行っているように見える
それは、ベック（もしくはカミンガム）の今まで培ってきた経験によるものに他ならない
テストとリファクタリングをしたら最適な形になったのではなく、最適な形へ向かってテストとリファクタリング
をしているわけだ
963 ：デフォルトの名無しさん：04/08/05 23:47
>>962
ごめん。何が言いたいのかよくわからないよ。
>例えば有名なMoneyオブジェクトについてだが、明らかに指針に基づいた修正を行っているように見える
これは穿ちすぎだな
憶測の域を出ない
とか言ってみたり。
ごめん。何が言いたいのかよくわからないよ。
>例えば有名なMoneyオブジェクトについてだが、明らかに指針に基づいた修正を行っているように見える
これは穿ちすぎだな
憶測の域を出ない
とか言ってみたり。
964 ：デフォルトの名無しさん：04/08/05 23:49
まぁ、お互いの重箱の隅を突くのではなく、考え・向き合いもう一度疑問を投げかけ
さらに理解を深めるという課程は何かと為になるだろう
で、質問なんだが
実際にXPを実践していると思われるが、12のプラクティスのうち幾つ使っているか
また、XP支持者としてXPの抱える問題とは何か？をお聞きしたい
さらに理解を深めるという課程は何かと為になるだろう
で、質問なんだが
実際にXPを実践していると思われるが、12のプラクティスのうち幾つ使っているか
また、XP支持者としてXPの抱える問題とは何か？をお聞きしたい
965 ：デフォルトの名無しさん：04/08/05 23:56
966 ：デフォルトの名無しさん：04/08/06 00:07
別に XPer ではないので、さらに重箱の隅をつついてみるテスト。
白本には確かに１２のプラクティスが載ってるんだけど、最新のプラクティスはいったいいくつあるの？
以下のリンクには、いずれも12個以上のプラクティスが出てくる。
http://c2.com/cgi/wiki?ExtremeProgrammingPractices
http://www.extremeprogramming.org/rules.html
どの情報が最新なのかさっぱりわからん。教えてエライ人
白本には確かに１２のプラクティスが載ってるんだけど、最新のプラクティスはいったいいくつあるの？
以下のリンクには、いずれも12個以上のプラクティスが出てくる。
http://c2.com/cgi/wiki?ExtremeProgrammingPractices
http://www.extremeprogramming.org/rules.html
どの情報が最新なのかさっぱりわからん。教えてエライ人
967 ：デフォルトの名無しさん：04/08/06 00:37
凄いことになっているｗ
しかしXPはカスタムしないと実際は使えないよね
しかしXPはカスタムしないと実際は使えないよね
968 ：デフォルトの名無しさん：04/08/06 02:27
>>967
それをがんばってやるのがXP
いくらXPを知っていて、現実的にXPやろうとしていても、カスタムXPをやるのはXPとは言えない
XPが偉いのは、こういう非難轟々が予想されたことだろうとなんだろうと、
これをやらなきゃソフトウェアは作れないという現実を示しているところだと思うよ
非難されるからっていって安全なことを言うのは単なるAgileな人 この人は結局何もできない
それをがんばってやるのがXP
いくらXPを知っていて、現実的にXPやろうとしていても、カスタムXPをやるのはXPとは言えない
XPが偉いのは、こういう非難轟々が予想されたことだろうとなんだろうと、
これをやらなきゃソフトウェアは作れないという現実を示しているところだと思うよ
非難されるからっていって安全なことを言うのは単なるAgileな人 この人は結局何もできない
969 ：デフォルトの名無しさん：04/08/06 02:29
> これをやらなきゃソフトウェアは作れないという現実を示しているところだと思うよ
狂信者登場
狂信者登場
970 ：デフォルトの名無しさん：04/08/06 02:32
971 ：デフォルトの名無しさん：04/08/06 02:35
ちゃんと12全部実践してるのかよ
972 ：デフォルトの名無しさん：04/08/06 02:41
>>971
ちゃんと実践できる組織を探して今はプログラミングとは無縁の仕事やってるぜ
でもねぇ、楽なほうへ楽なほうへ流れてくのが人間だと思う。そして結局後で苦しむ。
腹を決めてXPやるしかないんだってことになぜ皆気づかないのか、どうにもわからない
ソフトウェア開発のことが分かってない人だらけなのが日本なのだとしか思えない
ちゃんと実践できる組織を探して今はプログラミングとは無縁の仕事やってるぜ
でもねぇ、楽なほうへ楽なほうへ流れてくのが人間だと思う。そして結局後で苦しむ。
腹を決めてXPやるしかないんだってことになぜ皆気づかないのか、どうにもわからない
ソフトウェア開発のことが分かってない人だらけなのが日本なのだとしか思えない
973 ：デフォルトの名無しさん：04/08/06 02:47
アーキテクチャか？
それよりXPをそこまで盲信するのはどうかと思うけど
何故の説明が一切無くてそれだけ言ってるとキモい
同じ事がASDにもスクラムにもクリスタルにも言えるんじゃん
それよりXPをそこまで盲信するのはどうかと思うけど
何故の説明が一切無くてそれだけ言ってるとキモい
同じ事がASDにもスクラムにもクリスタルにも言えるんじゃん
974 ：デフォルトの名無しさん：04/08/06 02:50
XP、ASD、スクラム、クリスタル、それぞれキッチリとしたコンセプトを持っていていいんだけど、
その精神をちゃんと持ってソフトウェア開発やってる組織ってどのくらいあるかね
その精神をちゃんと持ってソフトウェア開発やってる組織ってどのくらいあるかね
975 ：デフォルトの名無しさん：04/08/06 03:24
UP にしたって、組織毎のカスタマイズが必要だってことは、さんざん強調さ
れてるんだし、 XP を始めとする適応型の開発手法で、状況に応じた修正が必
須なのはごくあたりまえのことだよね。
まず改めるべきは、この世のどこかに自分達を救ってくれる素敵なアイデアが
すでに用意されているという幻想であって、そんなものはこの世のどこにも存
在していないということを認めて、初めて最初の一歩が踏み出せるのだと思う。
なので、「12のプラクティスのうち幾つ使っているか」なんて疑問はそもそも
ピントがあやしくて、質問すべきは「「あなたの組織はどんな仕事をしていて、
XPの、プラクティスをどうやってカスタマイズしていますか？」ということな
んじゃないか、と。
あ。地震だ。
れてるんだし、 XP を始めとする適応型の開発手法で、状況に応じた修正が必
須なのはごくあたりまえのことだよね。
まず改めるべきは、この世のどこかに自分達を救ってくれる素敵なアイデアが
すでに用意されているという幻想であって、そんなものはこの世のどこにも存
在していないということを認めて、初めて最初の一歩が踏み出せるのだと思う。
なので、「12のプラクティスのうち幾つ使っているか」なんて疑問はそもそも
ピントがあやしくて、質問すべきは「「あなたの組織はどんな仕事をしていて、
XPの、プラクティスをどうやってカスタマイズしていますか？」ということな
んじゃないか、と。
あ。地震だ。
976 ：デフォルトの名無しさん：04/08/06 04:31
968みたいなﾊﾞｶがいるからXPって色眼鏡で見られるんだろうな。
XPの本家も見てきたけど、論調がほとんど968と同じ('A`)
961が一番まっとうに見える。
XPの本家も見てきたけど、論調がほとんど968と同じ('A`)
961が一番まっとうに見える。
977 ：デフォルトの名無しさん：04/08/06 10:47
>>976
961 のような形に流れがちだけど、それで何か解決するのかと。
XPのプラクティスの実践の不足を補うのは、そう簡単なことじゃない。
XPをやるのは難しいが、XPのプラクティス実践の不足を補うほうがさらに難しい。
結局、ソフトウェアつくりが分かってないんだよ
961 のような形に流れがちだけど、それで何か解決するのかと。
XPのプラクティスの実践の不足を補うのは、そう簡単なことじゃない。
XPをやるのは難しいが、XPのプラクティス実践の不足を補うほうがさらに難しい。
結局、ソフトウェアつくりが分かってないんだよ
978 ：名無しさん＠Linuxザウルス：04/08/06 15:19
ダレカ 新スレ タノム
979 ：デフォルトの名無しさん：04/08/06 15:30
980 ：デフォルトの名無しさん：04/08/07 00:30
981 ：デフォルトの名無しさん：04/08/07 13:21
>>977
インクリメンタル開発は他分野では既に通過点だよ
建築とか企業のプロジェクトとか既に次の段階に進んでいるっぽい
部分毎に分けてそれをインクリメンタルにするヤツ
Genesisだったっけ？
全部がXPみたいな開発はやっぱ無理があるってことらしい
インクリメンタル開発は他分野では既に通過点だよ
建築とか企業のプロジェクトとか既に次の段階に進んでいるっぽい
部分毎に分けてそれをインクリメンタルにするヤツ
Genesisだったっけ？
全部がXPみたいな開発はやっぱ無理があるってことらしい
982 ：デフォルトの名無しさん：04/08/07 17:18
4 ：デフォルトの名無しさん ：04/08/07 12:43
0.1㌧さん♀とペアプログラミング。
けっこうたのしぃ。
8 ：デフォルトの名無しさん ：04/08/07 15:10
よわよわなウチの会社ではTDD止まりでつ。
ペアプロしてみてー(異性)
0.1㌧さん♀とペアプログラミング。
けっこうたのしぃ。
8 ：デフォルトの名無しさん ：04/08/07 15:10
よわよわなウチの会社ではTDD止まりでつ。
ペアプロしてみてー(異性)
983 ：デフォルトの名無しさん：04/08/07 23:55
984 ：デフォルトの名無しさん：04/08/08 00:08
だからXPは宗教臭いと言われる
XPは絶対であり、それには間違いがないと言うことを前提とし、それをしないのが問題だという
961の指摘はまさしく981の流れになった時に、言われた指摘であり実際にその流れになりつつある
XPは絶対であり、それには間違いがないと言うことを前提とし、それをしないのが問題だという
961の指摘はまさしく981の流れになった時に、言われた指摘であり実際にその流れになりつつある
985 ：デフォルトの名無しさん：04/08/08 00:10
あと、983を見て思ったんだがXP=インクリメンタル開発になってしまっているな
981が言っているのはインクリメンタル開発全般の事だろうに
981が言っているのはインクリメンタル開発全般の事だろうに
986 ：デフォルトの名無しさん：04/08/08 02:02
>>985
藻前のような「インクリメンタルって言っておけば間違いない」というような香具師は
話が曖昧すぎて何もやってない、何も言ってないのと同じ。分かってるようで何も分かってない。
XPのような明確なメッセージを持った方法論を言うことがどれだけ難しくて、生産性が高いかを
考えたほうがいいと思うよ。
藻前のような「インクリメンタルって言っておけば間違いない」というような香具師は
話が曖昧すぎて何もやってない、何も言ってないのと同じ。分かってるようで何も分かってない。
XPのような明確なメッセージを持った方法論を言うことがどれだけ難しくて、生産性が高いかを
考えたほうがいいと思うよ。
987 ：デフォルトの名無しさん：04/08/08 02:33
>>986
だから、お前の発言は具体性がないんだよ
ただXPは生産性が高いを連呼するだけ
そんな話で誰が納得すると思う
実際に問題点を付き、それを考える人間が多数いる
常に疑問を感じ、それこそテスト＆リファクタリングしない様なヤツはただの無能だ
だから、お前の発言は具体性がないんだよ
ただXPは生産性が高いを連呼するだけ
そんな話で誰が納得すると思う
実際に問題点を付き、それを考える人間が多数いる
常に疑問を感じ、それこそテスト＆リファクタリングしない様なヤツはただの無能だ
988 ：デフォルトの名無しさん：04/08/08 02:54
XP良いと思うｊけど986はイタい
989 ：デフォルトの名無しさん：04/08/08 14:12
>>987
問題点に気づいても、XPをプラクティスを守るにはどうすればいいかっていう方法に
思考が回らなければダメ。
方法論を構築する、とか言って、結局悪い方向に構築するだけの香具師ばかりだと漏れは思う。
問題点に気づいても、XPをプラクティスを守るにはどうすればいいかっていう方法に
思考が回らなければダメ。
方法論を構築する、とか言って、結局悪い方向に構築するだけの香具師ばかりだと漏れは思う。
990 ：デフォルトの名無しさん：04/08/08 14:24
> 問題点に気づいても、XPをプラクティスを守るにはどうすればいいかっていう方法に
> 思考が回らなければダメ。
守ると言うことが前提、XPが全て正しいと言うことが前提。
ダメだなこりゃ
> 思考が回らなければダメ。
守ると言うことが前提、XPが全て正しいと言うことが前提。
ダメだなこりゃ
991 ：デフォルトの名無しさん：04/08/08 18:43
信者も気持ち悪いとは思うんだが、叩く方も必死になりすぎだと思う。
なんか嫌なことでもあったのか？
なんか嫌なことでもあったのか？
992 ：デフォルトの名無しさん：04/08/08 22:34
いつまで経っても、XPのプラクティスを守るのが至上であるを連呼すればねぇ
あたしゃ生暖かく見守るが、正直気持ち悪いなぁ
あたしゃ生暖かく見守るが、正直気持ち悪いなぁ
993 ：デフォルトの名無しさん：04/08/09 02:08
ふつー呆れて見なくなりそうなもんだけどな。
その使命感みたいなものは、何事に対しても抱いているの？
その使命感みたいなものは、何事に対しても抱いているの？
994 ：デフォルトの名無しさん：04/08/09 02:20
XP側の方が粘着に見えてきたｗ
995 ：デフォルトの名無しさん：04/08/09 21:47
XPやらなくてよかったケースがあれば教えてほしいよ
996 ：デフォルトの名無しさん：04/08/09 22:32
XP懐疑編を読んでも、要約するに結局は「適切な方法論は自分で作れ考えれ」という、
まぁ、答えになってない答えなんだよね。
メッセージ性なし。意味なし。
まぁ、答えになってない答えなんだよね。
メッセージ性なし。意味なし。
997 ：デフォルトの名無しさん：04/08/09 23:42
埋めとくか。
998 ：デフォルトの名無しさん：04/08/09 23:42
998!
999 ：デフォルトの名無しさん：04/08/09 23:43
999!
1000 ：デフォルトの名無しさん：04/08/09 23:44
1000
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。