どこまで設計をするかってのも、規模によって変わってくるよね。
っていうか、困るのが、要件仕様がハッキリしない場合。How(どうやって実装するか)は事前に決まって無くても問題ないと思います。だけど、What(何を書くのか)を事前に決めないでプロジェクトが始まることが多い。あと、マネージャもリーダーも How と What を区別できてなかったり。
XP で言うところの、Planning Game とか User Story から生まれる Task Card が無いと、話にならない。XP やるとしても、コードだけで考えると煮詰まるのでスケッチモードの UML [amazon.co.jp] はお勧めです。
テスト専任 (スコア:2, 興味深い)
あと、設計がキッチリ決まってない場合は、開発者以外がテストコードを書くのは難しいんじゃないかな。コードに手を入れる権限がある程度必要になってくるから。ユニットテストの話をすると、全てのコードがテストできるってわけじゃないと思うんですよ。メソッドに何十行もずらーーっと書いてあるような酷いコードはテストのしようがない。ユニットテストを書くことで自然とリファクタリングが進むんだけど、ここで年上のオジサンプログラマが「俺のコードは動いてるんだから手入れるなよ」みたいな場合は困る。 しかも、ずらーーっと長い分、メソッドに期待されている振る舞いってのも理解しずらくて、テストを書くのにすごく時間がかかってしまう。
テスト書くよりも、コードの振る舞いを理解するのに時間がかかってしまうぐらいなら、開発者本人がテスト書いた方がよっぽど早いわけ。
あと、チーム全体がユニットテストの存在を認識して、更新していかないと、振る舞いの変更が行われて、テストが壊れまくってもそのままチェックインみたいな事が起こる。テストが壊れるってのは、再設計の必要がどこかであるわけで、場当たり的にクラスを拡張していくオジサンプログラマを説得して、新しいクラスを作ったり、継承を使ったりということが必要になる。OO のセンスのないオジサンプログラマが上司ってことは多いです。
ここで、腕が立つと認めてもらえれば、コードを書き換えたり再設計する権限が与えられるわけだけど、それは腕次第。
要するに、テスト以前に開発プロセスそのものが確立してない所が多いわけです。何をテストするかが明確じゃないとテストのしようがない。
適当にコード書いて、事後に UML を作って大量の Word を作るとか、そういう現場があるわけで。当然の事だけど、cvsなどのヴァージョン管理ソフト、バグ追跡ソフト、コード規定がまず必要だし。
最近、大学生のインターンを指導してるけど、ホワイトボードで UML 使って論議して、テストファーストって方法を導入してみた。 僕は、他人の書いたコードって信用できない性格なんだけど、テストがあることで少しは信用できるようになったと思う。
あと、ソフトの生涯ってのは大半を保守で過ごすわけで、ちゃんとした要件収集、設計、テストをやることで、長期的な生産性は上がります。バグだらけで、しかも誰も保守できないコードってゴミだから。 あと、データの状態によって出てくるバグってのも少なくなる。
Re:テスト専任 (スコア:1)
> 開発者本人がテスト書いた方がよっぽど早いわけ。
そりゃそうだ。でも、コードの振る舞いを理解して、それに従って試験を記述する場合、何を試験しているのかよくわからないですね。だって、コードの振る舞いに合う、つまり、必ず合格する試験を記述するんでしょ?設計が決まってないって言うんじゃ、どうしようもありませんが...
仕様が事前に決まってなくて、開発者本人が試験を書くのなら、それはtest firstに近いですね。そして、試験をインターフェース仕様と考えれば、だんだんXPに近づいて...
Re:テスト専任 (スコア:2, 参考になる)
どこまで設計をするかってのも、規模によって変わってくるよね。
っていうか、困るのが、要件仕様がハッキリしない場合。How(どうやって実装するか)は事前に決まって無くても問題ないと思います。だけど、What(何を書くのか)を事前に決めないでプロジェクトが始まることが多い。あと、マネージャもリーダーも How と What を区別できてなかったり。
XP で言うところの、Planning Game とか User Story から生まれる Task Card が無いと、話にならない。XP やるとしても、コードだけで考えると煮詰まるのでスケッチモードの UML [amazon.co.jp] はお勧めです。
> 必ず合格する試験を記述するんでしょ?
これは、挙動がある程度複雑だと、いつでも合格というわけにはいかないと思います。凡ミスを拾うことも多い。
だけど、自動化されたテストの一番の強みは、将来コードに色々拡張が入ったり、ネットワークの設定を変えたりみたいな外部環境の変化があった時に実装したコードがちゃんと動いてるかを手軽にチェックできることにあると思います。極端な話、値をチェックしてなくても、ある部分を呼び出してるだけでも、テストとしての役割はあると思います。
>> データの状態によって出てくるバグってのも少なくなる。
って書いたのはその事で、例えば、名前が「j」で始まる記録をデータベースから削除した時のみに行われる一連の振る舞いがあったとして、運用中にそういう記録が稀にしかない場合とか。運用に入って、しばらくしてからキャスティングミスで突発バグ。
Re:テスト専任 (スコア:1)
あれ? ちゃんと書いたはずなのになぁ……
(いいからその脳内コードを現実に落としなさい。)
Re:テスト専任 (スコア:1)
Q:その場合間違っているのは、試験の方なのか、コードの方なのか?
A:仕様が決まっていないので、どちらが間違いとも言えません。
設計は重要ですよ。 (スコア:1)
開発者本人が書くテストコードと、本人以外の人が行うテストとでは、意味合いが俄然違ってきます。
私は後者は必要、しかし前者は不要などということは全然無くて、絶対にあった方が良い (必ずしも必要とは書きませんが。。。) ものであると思っています。
開発者本人にテスト (コードもしくは仕様) を書かせるということは、開発者本人が (テストでは無くて製品の) 仕様を正しく理解しているかどうかを確認できる方法の 1 つと言えるんではないかと思うのです。その仕様を満足するには、どういう動作を保証しなければならないのか、そしてその動作を保証するためには、どういったテストが必要になるのか。
だから、仕様があやふやな状態では、むしろ開発者本人にテストを書かせるのは不毛であると思います。仕様がきっちり確立していること、あやふやな部分があれば設計者に事前確認し、必要ならば十分に議論すること。これはテスト以前に、本来最低限行われているべきことであるはずです。
製品を設計する段階で、テストも設計する、という考え方もあると思うんですけどね。
むらちより/あい/をこめて。
Re:テスト専任 (スコア:1)
> Microsoft みたいな所(Software Design Engineer in Test、エス
> デットとか言ってた) は限られてるんじゃないでしょうか。
私の会社にいる、元WinodowsCE開発者からMicrosoftの開発体制について話を聞いたときに、このテスト体制について話をききました。
テスターは必ずプログラマ(としての能力がある人)で、バグを指摘するときは必ず現象とともに再現させるためのテストコードが付属してくるとか。だから、開発担当のプログラマとしても軽くあしらうことができないそうです。それから、一人のプログラマに対して最低一人の専任テスターがいたと聞いた気がします。
# 余談だけどID