ＸＰのxUnitは使えてる？
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGユニットテストできないクラスの方が多くないですか？
数学ライブラリとか単純なストリングクラスレベルのものであれば
可能ですが、そうでないものは難しいのではないかと思うのですが
実際に触れられているか、または、触ったことがある方教えてちょ。
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNGだけでなくテストがコードに優先する、ということだと解釈して
います。
従って、テストできないコードはテストできるように書き換えなければ
いけない、というのがXP的な姿勢ではないですかね。まあ確かに既存の
コードを書き換えるときには大変ですが。
0004デフォルトの名無しさん
NGNGテストしにくい部分を別クラスに追い出していくこと。
そういうクラスの責務をはっきりさせる習慣がつくのがいい感じ。
あとコーディング、変更に伴うケアレスミスが激減すること。
これは大きい。
0005デフォルトの名無しさん
NGNGなってしまいます。
テストが難しい理由はなぜかを考え、テストしやすくするにはどうすれば
良いのかを考えましょう。それが良い設計への第一歩です。
0007デフォルトの名無しさん
NGNGできない. そんなものです.
0008デフォルトの名無しさん
NGNG意味が良くわからないんだけど、単体テストしてないって事じゃないよね？
0009デフォルトの名無しさん
NGNG前半はともかく後半は謎だな。
どんな大きなシステムだろうと、しかるべき(大きさ)のクラスが
集まって作られているなら、それらのクラス「は」単体テストできるだろうに…。
大きさゆえにドキュな設計者がよってたかってドキュ設計をしてしまった、
というならば手のつけようが無いだろうけども。
0010デフォルトの名無しさん
NGNGここは実は結構気になっている点です。
基本的には（よい設計であれば）、
すべてのクラスの単体テストは本当に行える、
そして行わなければならない、ということですか？
00118
NGNG単体テストとか結合テストって用語自体が構造化言語までしか想定してないから
議論が噛み合わなくなることが多いけど、基本的にテストできない設計は駄目な
設計と考えるべきだと思う。
複雑すぎるクラスはテスト可能な粒度まで分割して、Compositパターンで再構築
するとかしてね。
あと、個人的にはGUIテストは単体テストじゃなくて機能テストだと思うので、
xUnitで苦労してテスト書くよりXPチームに参加してるユーザがやる方が良いと
思う。
0012デフォルトの名無しさん
NGNGほんとどうやるんだろう？
俺も今これを実装したいと思ってるところ。
0013デフォルトの名無しさん
NGNG有るけども、それが「それ以外の面に対して害になる」ってことは
あんまり無く、むしろ益になることが多いんで、
それはそれでいいと思われ。
ついでにリファクタを一種のフレームワークとして捉えるといいんじゃないかな。
つまりテストしやすく改良しやすいコードを書くという枠組み。
もちろん、枠だからといって、他のプログラミング的側面を阻害されたりはしないし。
>>12
ん？すれ違いっすか？なんか気になった。
0014馬鹿ちん
NGNG教えてください。
コマンド１と２は「作成中」とメッセージを出し、コマンド３は
終了するか否か？ってやつです。
Option Explicit
Sub Wait()
MsgBox "作成中"
End Sub
Private Sub Command1_Click()
Call Wait
End Sub
Private Sub Command2_Click()
Call Wait
End Sub
Private Sub Command3_Click()
Dim Answer As String
Answer = MsgBox("終了しますか?", vbYesNo, "Msgbox")
If Answer = ybYes Then
End
End If
End Sub
Private Sub Form_Load()
Label1.Caption = "管理人"
Command1.Caption = "初期設定"
Command2.Caption = "開始"
Command3.Caption = "終了"
Form1.Cartion = "組込み関数"
End Sub
0015デフォルトの名無しさん
NGNGXPもxUnitも知らねーなら素直に「教えてください」って言えよ。
0016デフォルトの名無しさん
01/08/29 02:27ID:5XKVyCFEのように理解しているのですがあっていますか？
あっている場合、単体テストってどういう風に考えればよいんですか？
例えば、３層でシステムを構築した場合、プレゼンテーション層は、
アプリケーション層やデータ層に依存することになりますが、
プレゼンテーション層用のクラスの単体テストをしようとすると
下層のクラスが必要になりますよね。この場合総合テストになってしまう
ように思うのですが、どういう風にやればいいんでしょう？
同じように、あるクラスがいくつかのクラスのオブジェクトを利用して
いる場合の単体テストも単体ではないですよね？
こういう悩みがあるので、 >>7 で言われていること納得できてしまうの
ですが、認識に間違いがありましたらアドバイスお願いします。
0017デフォルトの名無しさん
01/08/29 03:13ID:PK.6ELLoまた、単体テストは、そのクラスに対応するコードが直接実装している
機能に対して行う、というように考えています。
具体的にはプレゼンテーション層のクラスの単体テストでは、そのクラスが
依存しているアプリケーション層、データ層のクラスは全て正しく動いて
いるとしてテストを書きます。
たとえばデータを0個入力したときに特殊処理があるとします。
その特殊処理の処理責任がプレゼンテーション層にあれば、もちろん
プレゼンテーション層の単体テストの対象になります。しかし、処理責任が
アプリケーション層,データ層のクラスにあれば、プレゼンテーション層の
単体テストには必ずしも入れはしません。
00188
01/08/30 00:28ID:hAE3SefAなんとなくxUnitの精神から逸脱してる感じがするっす。
階層ごとに処理責任があるってとこまでは同意するけど、
>処理責任がアプリケーション層,データ層のクラスにあれば、
>プレゼンテーション層の単体テストには必ずしも入れはしません。
ってのはちょっとね。
プレゼンテーション層の単体テストにアプリケーション層のテストを
「含める」って事があり得るとしたら問題だと思うよ。
0019デフォルトの名無しさん
01/08/30 00:39ID:MxA3bdF.下層をテストするために「ダミーの中層クラス」を作るんじゃないんですか？
で、そのダミー中層自体がTestクラスになってりゃいい、と。
で、動きが確認された下層クラスに、本物の中層クラスを乗せ、
その上にダミー上層テストクラスを乗せて…
という風に順繰り(再帰的?)にやるのではないかと推察します。どう？
002017
01/08/30 01:30ID:UucBSbhIここらへんはどんなプロジェクトにも通用する指針を作りにくいところだと思います。
もしかするとうまく伝わっていないかもしれないので、少し補足します。
クラスFoo,Gooがあり、GooはFooを使用しているとします。
Fooが実現する機能は、Fooで実装した機能です。
Gooの実現する機能は、Gooで実装した機能+Fooが実現する機能です。
単体テストは「〜が実現する機能」を対象にするのではなく、「〜で実装した機能」に
対して行うのがよいのではないか、というのがオレの主張です。
17の例では「データが0個の時の特殊処理」がFooで実装した機能なのかGooで実装した
機能なのかによって、Foo,Gooのどちらかの単体テストに割り当てるのかを決めればよい
ということです。
いかがでしょうか？他にも良い指針があったら教えてください。
00218
01/08/30 01:42ID:hAE3SefA基本的には17さんの方針でおっけーだと思う。
気になってたのは、GooをテストするときにFooの実装を意識するのか
どうかってとこで、「意識しちゃマズいよね」ってのがxUnitの基本思想
だと思うと言いたかったわけです。
んじゃ今宵はこの辺で。
002291
01/08/30 10:02ID:AuuQmmaUという決まりはないと思う。has_a のクラスがあればそれを所有している状態が
そのオブジェクトのあるべき姿なのでそのままでテストするべき。
setUp() でオブジェクトを生成する時に必要な周辺のオブジェクトも一緒に作る。
委譲が単純なメッセージの転送で結果が自明だと思うならテストを省いてもいいかも
しれないけど、リファクタリングの結果メソッドの移動で委譲の形になったのなら、
その変更の影響確認の意味があるのでテストを削ることはない。
あと、setXXX(), getXXX() などの自明なメソッドや、GUIなどのテストが難しいも
のを無理してテストに含める必要もない。
「リファクタリング」の本にも、100%のカバレッジにこだわって結局テストしなく
なってしまうよりも、できるところからどんどんテストを書いていった方がいいと
書いてあった。
00233
01/08/30 13:13ID:SlMm8NNoそういったクラスの単体テストに関しては、XP導入篇にやり方が書いてあるので、
立ち読みでもいいので読んでみるといいと思います。
基本的にはそのクラスが依存している下層クラスのダミーを作ってテストする、
ということになると思います。
0024IDEなんてクソ
01/08/30 21:48ID:ZAelFQ6sとにかくコーディングしまくって、家に帰るときに全部xUnitで自動実行。
翌朝、デグレードしていないことを確認して、別の観点でテストを書きまくる。
クソみたいなテストでも、何回も書き直すと自分のスキルになる。
単体とか結合とかは、人件費よりCPU時間の方が貴重な頃のクソ概念。
屁理屈こねてるぐらいならコーディングしろ。
それがイヤならプログラマやめな。
002517
01/08/31 00:05ID:sK1P25wQ単体テストはホワイトボックステストなので、GooのテストがFooの実装を意識したものに
なっていてもかまわないのではないかと思います。いかが？
>>24
漢らしい！ある意味extremeですな。それでうまく進められるのなら、全くOKだと思います。
オレはそれほど漢気(ｵﾄｺｷﾞ)がないので、テストの効果は低下させずにテストの規模を
少なくできる方法を考えたいと思います。
24氏の方法だと、特定のクラス階層を取り出して再利用するときに、テストコードの
切り分けに手間がかかりませんか？テストを単体,結合に分けておくとそのような時には
便利ではないかと思います。
このあたりの考察,議論が屁理屈ではなくて、仕事の質を高める理屈につながることを
願います。
002616
01/08/31 00:31ID:r3.yQrDE1. 基本は、クラス単位でテストをする。
2. has-aクラスを持っているのであればそれらは生成してもよい。
3. 利用関係のクラスはダミークラスを用意する。
という方針で進めればよいという風に理解しましたがあっていますか？
あっていた場合、私自身悩んでいたのは、3.についてです。本当にダミー
クラスを用意することができるのか？ 単純なシステムであれば、
可能に思えますが、複雑なものであればダミークラスを用意し、それら
の用意したクラスがうまく連携するかどうかの補償する必要が発生し、
ダミークラスのユニットテストが必要になり、それをするのにさらに
ダミークラスが必要になる...。つまり、ダミークラスが必要がなくなるまで
それを繰り返すか、どこかで妥協する必要があるんじゃないだろうかという
こと。それにより、複雑なシステムではユニットテストは難しくなって
くるのではないかという疑問へとつながります。ここら辺は、みなさん
問題なくできていますか？ Webアプリ程度のものであれば可能に思え
ますが、マルチスレッドなシステムとか大規模なシステムは、
GUIに近づくほど難しいと感じます。
0027デフォルトの名無しさん
01/08/31 00:31ID:4nm4VJrc0028デフォルトの名無しさん
01/08/31 00:59ID:6bUtDlqkFoo(interface), FooImpl, MockFoo, FooImplTest
をつくるけど 駄目？
ちょっと面倒だけど、ほかのクラスの実装にほとんどたよらずに
テストできるのでいいかんじ。
002916
01/08/31 02:42ID:r3.yQrDE購入してみようかと思ったのですが、あまり評価がよくないようなのですが、
実際のところみなさんどう思いましたか？
http://www.amazon.co.jp/exec/obidos/ASIN/4894714914/ref=b_br_r_4_3/249-6364008-4713114
0030デフォルトの名無しさん
01/08/31 11:33ID:FX.uO0Uc評判が悪いのは、『実行計画』の方です。
内容そのものが悪いというわけではなく、訳がヒドイという理由で評判が悪いです。
『導入編』の方はそのようなことはありませんでした（精読したわけではないですけど）
00313
01/08/31 11:50ID:l23fvLAEいや、一番ひどいのは「入門」です。これは、
http://objectclub.esm.co.jp/eXtremeProgramming/ec-errata.txt
と併用しないと理解できません。
もっとも「実行計画」も基本的に同じ人間が翻訳しているので出来はよくない
ですが。「導入編」はわかりやすいし、おまけもついているのでお勧めです。
003230
01/08/31 12:50ID:FX.uO0Ucあ、そうでしたね。
あまりに酷かったので、俺の記憶から消去してました（藁
00338
01/08/31 12:52ID:pdlIkxbsあえてsageずに激しく同意。
大学受験レベルの訳が出来てないのには閉口する。
導入編があれば入門も実行計画もいらんのではないかと思うよ。
0034デフォルトの名無しさん
01/08/31 14:58ID:SVE3wbvcHttpRequestを使ってるクラスが多くて、
そういうクラスをどうやってXUNITでテストできるのでしょうか？
DB系のクラスも難しい
結局ブラウザで地道にやってます
0035sage
01/08/31 16:33ID:BPhzZYhEhttp://wiki.esm.co.jp:8080/xp/29
じゃだめ？
>34
0036デフォルトの名無しさん
01/08/31 16:41ID:SYzSjnws簡易サーバ作れば？
んでsetUp() でlocalhostとかで起動しとく
0037デフォルトの名無しさん
01/08/31 16:58ID:FX.uO0Uc>DB系のクラスも難しい
これはテストしやすいと思うけどなぁ。
テストしづらいとしたら、それは、メソッドが複雑である、ということでは？
どういう所が難しいの？
0038IDEなんてクソ
01/09/01 00:59ID:t2cxml/2コアサーブレット＆ＪＳＰかなんかのサンプルに
ＵＲＬ指定してＰＯＳＴするＡｐｐｌｅｔのコード
が出てたのでそいつを改造してJUnitしたことはあ
るけど、そういうことではないのかな？
あんまり真剣にやったわけじゃないから、細かいこ
とはわからんが、中途半端なフレームワーク使うよ
り、人のコード改造した方が生産性はあがるぞ。
0039IDEなんてクソ
01/09/01 01:03ID:t2cxml/2ちなみにサンプルのコードは以下のＵＲＬから落とせるよ。
http://books.softbank.co.jp/isbn/1431/
SendPost.javaとかいうファイル名だったとおもう。
0040デフォルトの名無しさん
01/09/01 03:56ID:lnjRwD/QRequestの使用するメソッドだけを備えたラッパーを
つくれば幸せになるかも
>>37
DB関連はUnit単位ならどうということはないけど、
実際のDBを使用するテスト(Acceptance?)となると
データを用意する -> テストする -> 後始末
となりやっぱり面倒かと
004110
01/09/01 14:39ID:EO8HRrv6なるほど、やはり仮想クラスのダミーを作って
テストするということですね。
とりあえず、導入編を買って読んでみます。
0042デフォルトの名無しさん
01/09/01 21:07ID:ln0xQxLk>データを用意する -> テストする -> 後始末
>となりやっぱり面倒かと
というか、それってxUnitの全否定に繋がるような気が・・・。
0043「人のバグ見て、わがバグなおせ」
01/09/01 22:18ID:FG67tGr.君には向いていない職業だね。
早く出世するか、転職するか選んだ方がいいよ。
プログラマが「コーディングがイヤ」とか「コーディングに自信がない」
って言ったらおしまい。
「血を見るのがイヤ」とか「盲腸切るの自信が無い」なんて言う外科医に
命預けられる？
あんたの顧客も同じ気持ちだよ。
0044デフォルトの名無しさん
01/09/01 23:47ID:npROBw1Mやっぱり、そこで苦しくなってくるのがDB絡みだな。
パフォーマンスや時間やライセンスの都合で、
DB空間を必要な数だけ構築できない場合には、
複数の開発者(＆デバッグ者)が同一のDB空間に相乗りすることになり、
うまく(素早くってのも含めて。delete * from HOGEHOGEとかをやれるかどうか)
必要なデータを用意＆抹消するのが困難になったりする。
言いかえれば、空間を好きなだけ作ることが
パフォーマンスや、ましてライセンスに、縛られるという
DBMSの構造が駄目駄目だ、ということなんだけども。
というわけで、大抵の商用DBMSベンダーは、いってよし。
そうそう。
http://www.zdnet.co.jp/enterprise/0108/30/01083006.html
今時WaterFall開発を薦めるという勇気有るドキュ記事。
言ってること、これ、変だろ。
(乱暴にいえば)渡して「から」デバッグするのがSpiralだろうに、
バグは許されないからWaterFallしろってのは、勘違い。
00458
01/09/02 00:04ID:VPRUB6jg優良スレに育ちつつあるんだから煽りモード控えめで行きましょう。
00468
01/09/02 00:08ID:VPRUB6jgDBに対するxUnitの適用方法ですが、導入編に示唆的な一節があります。
“テストをできる限り高速で走らせるためには、安全性を考えあわせた上で、
なるべく実際のデータベースにはアクセスしないことが基本的なルールだ。”
（導入編131ページより）
004740
01/09/02 02:56ID:BNPFq0lAプログラムは好きですよ、ほんと。
>>46
それは、ＤＢ周りのクラスを使うがわの話であり
ＤＢ周りのクラスそのもののテストにはＤＢやらＳＱＬやらが
関係してくると思います、多分。
現実のリソースに触るようなテストはできれば別系統にしておいて
実行速度をあげるという意味だったかと。僕もそうしてます。
004840
01/09/02 03:20ID:BNPFq0lAxUnitマンセー！否定だなんて！
ただSQLがらみだと何度もテスト実行可能なように
setUpやらtearDownやらに手間がかかって
やだなあ、とか思いません？
僕がSQL嫌いなだけかもしらないけど。
っていうかなんか楽な方法ないですか？
0049デフォルトの名無しさん
01/09/02 03:39ID:yCMII86.初期化・終了処理周りのルーチンワークが面倒なら
xUnit拡張してSQL Unitかそこまで行かなくても
SQLTestCaseでも作ってやればいいんじゃない？
本質的に複雑で面倒でライブラリ化不可能ならあきらめるしかないかもね...
005040
01/09/02 04:08ID:BNPFq0lAならやってますが、個々のテストで必要なデータが
結構ちがうためデータのそれはどうにも…。
外部にバッチをおいてテスト前に必要なＳＱＬを
実行するようにしたこともあったけど、あんまり
気持ちよくない。xUnitだけで完結しないし。
0051デフォルトの名無しさん
01/09/02 10:02ID:BlWYAHM.生DBにアクセスしないかどうかをユーザーの自由意志で決められる場合は、そうでしょうね。
OODBとかJDO(藁)みたいに、なかば暗黙化されてる場合に、ちょっと困るなぁと。
DBを切り離すわけにもいかないし、パフォーマンスやライセンスで足引っ張られるのは厳然たる事実だし。
某環境でObject1つを生成するのに1秒かかった時は本当に鬱になった。
00528
01/09/03 01:49ID:1RRG7AyI>それは、ＤＢ周りのクラスを使うがわの話であり
「DB周りのクラス」がどこまでを指すかが気になるなぁ。
この辺の認識って十人十色ですよね。
皆さんは大体どのあたりをイメージされてますか？
0053デフォルトの名無しさん
01/09/03 14:22ID:fElqx/V6>ただSQLがらみだと何度もテスト実行可能なように
>setUpやらtearDownやらに手間がかかって
>やだなあ、とか思いません？
いや、だから、何を「やだなあ」と思っているのか、読み取れないんですが・・・。
>>50
>ならやってますが、個々のテストで必要なデータが
>結構ちがうためデータのそれはどうにも…。
問題はこれだけですか？
結局「面度くさい」ということですか？
だったらしかたないですねぇ。
0054＿＿
01/09/03 23:53ID:eYogrFz2でも、テストデータを作るのも楽しくない？
テストデータを生成するロジックを考えるのも楽しいよ。
制約があるから、知恵を絞る楽しさがあるんだじゃないかな？
制約なくなったら、俺は仕事しない。納期もないだろうしね。
005540
01/09/04 02:58ID:u0uEF7woちょっと長いけどこんな感じ？(with JUnit)
public FooCreatorTest extends TestCase {
public static Test suite() {
return new TestDBSuite(FooCreatorTest.class) {
protected void doSetUpDB(Connection conn)
throws SQLException
{
conn.executeQuery("create table foo ....");
conn.executeQuery("create table baa ...");
conn.executeQuery("insert into foo...");
// だらだらと続く
}
protected void doTearDonw(Connection conn)
throws SQLException
{
conn.executeQuery("drop table foo");
conn.executeQuery("drop table baa");
}
}
//以下テストが続く
}
このやり方だと長ったらしくＳＱＬが続く上に
テストのためのＳＱＬ自体が間違いを含んでいたり,
エスケープが面倒だったりと結構いやなものです。
ＳＱＬを直に使うためＤＢに依存も起きます。
テストに要する時間が通常の三倍くらいってとこかな。
怠慢ってのは(それなりに)大切だとおもうけど、だめですかね？
で、なんかいい方法ないっすか？
005640
01/09/04 03:06ID:u0uEF7woあとexecuteQuery --> execute ですね…
>>54
それはちょっとむごいかと
つうか僕が新人ですよ！
一番きつい制約が時間なので、できるだけ安いコストで
テストしたいです。
0057通りすがりのプログラマ
01/09/04 07:26ID:172vGpu.やはり読みづらいですか。
デザインパターンとか、XPはいい方向だと思うのですが、
どうにも良書が少なくて、取り入れづらくて。
最先端で天狗になっちゃって誰も何も言えないのかな。
0058通りすがりのプログラマ
01/09/04 08:36ID:172vGpu.この手の訳書が出ないことを嘆いてますが、間違いなく足ひっぱってるとおもわれ。
分からなかったら俺のセミナーを聞け！なのかな。
導入編訳者が違うので買ってみま。
005953
01/09/04 14:27ID:xkDT0p0oこれは仕方がないですね。
>テストのためのＳＱＬ自体が間違いを含んでいたり,
これは間違わないようにするしかないです。
>エスケープが面倒だったりと結構いやなものです。
何をエスケープするんでしょう？
>ＳＱＬを直に使うためＤＢに依存も起きます。
それも仕方がないですね。
>怠慢ってのは(それなりに)大切だとおもうけど、だめですかね？
怠慢おおいに結構。
>で、なんかいい方法ないっすか？
create table - drop tableは本当に必要なんですか？それも毎回？
Singleton patternとRollbackをうまく使えば、テストに要する時間は短縮できます。
テストデータ生成も、Insert文を直接書くのではなく、CSVをInsert文に変換する
クラスなどを作って、間違いをなくすようにする。
こんなとこかな。
0060デフォルトの名無しさん
01/09/04 22:39ID:2dtERGnw新人ならやめちゃえよ。今からならやり直せるよ。
大体、そんなに自動化しちゃったら、お前ができる仕事なくなるよ。
楽する方法を考えるのが、今の仕事なんじゃないの？
ＸＰ以前に、仕事に対する姿勢が問題じゃん。
006140
01/09/05 02:05ID:nluvb.ck何度よんでも一回だけ処理をしてくれるSetUp用の
クラスは、データが重複する場合は作ります。
create - drop は趣味の問題かもしれません。
ごみは残さないって感じで。
データの量が多い場合は外に出しますが
少ない場合はテストに内臓のほうがよいような気がします。
エスケープは正規表現かなにかと勘違いしたかも、すみません…
0062デフォルトの名無しさん
01/09/05 13:16ID:42ScEOYYじゃぁ、結局何が問題なの？
つまるところ「面倒くさい」ってとこに帰着するのかな？
それって、xUnitを全否定することでは・・・(loop)
0063デフォルトの名無しさん
NGNGこんな奴が「xUnitは役立たない」って知ったかぶって言いふらすんだろうな。
役立たないのは、、、
ま、それ以上は言わないよ。大人だから。
00648
NGNG大人なら初めから黙ってるよろし。
いたづらに煽るばかりのﾚｽはｳｻﾞい事この上なし。
というわけで話題提供を試みてみる。
実DBにアクセスしないとできないテストが多岐にわたるようであれば、それこ
そリファクタリングの対象とすべきでは？
「DBにアクセスするな」というのは、テストの手間を惜しむという面もあるが
、DBへの依存度が低い設計を強制するという面も忘れてはならないと思う。
0065デフォルトの名無しさん
NGNGそれからUnitTest自体のリファクタリングも必要だよね。
0066デフォルトの名無しさん
NGNGタイトルだって、xUnitの効果に疑問があるわけでしょ？
で、よくよく聞いてみると、「めんどくさいことしたくない」でしょ？
何処が優良スレなんだよ。別のスレたてて議論しよ。
00678
NGNG別スレでも「めんどくさいことしたくない」派が書き込むのは不可避。
なぜなら彼らのほうが多数派だから。
改革派だけでオナニー議論したところでこの業界は変わらない。
66さんの同僚にも「めんどくさいことしたくない」派がたくさん居るはず。
このスレで説得する方法を磨いてみては？
P.S.懐疑派を煽るのはXPの価値を貶めるだけなので止めましょう。
00688
NGNG「XPエクストリーム・プログラミング導入編」は良書なので否定派も肯定派も
ご一読を。（税抜2400yenナリ）
0069デフォルトの名無しさん
NGNG0070デフォルトの名無しさん
NGNGというかこれって、いわゆるOOPと(R)DBのインピーダンスミスマッチの話だよね。
あっちの世界とこっちの世界を行き来するためのコードがナニかと煩雑になるというあれ。
JDOだっけ？あれにでも期待するといいんじゃないかな。最終的には。
一方、今すぐ最終段階になれるわけでもないんで、DBアクセスをライブラリ化しとく
ってのは必要になるだろうね。毎度毎度JDBCコードを素で書いていたらやってられん。
「ライブラリ化する」というリファクタリング(?)は、必要だと思われ。
>>68
導入編ですか。買ってみます。たしか薄い本ですよね。持ち運べるのが嬉しい。
0072デフォルトの名無しさん
NGNGどうせリストラするんだから、きっかけをあげればいい。
仕事しない奴10人より、やる気のある新人の方が役立つよ。
何もみんな一緒にＸＰする必要なし。少数精鋭でいきましょう。
結果を残せば経営陣は何もいえないよ。
■ このスレッドは過去ログ倉庫に格納されています