アカウント名:
パスワード:
同じく単体テスト部分だけ部分導入しました. あいまいな仕様をもとに作業している上に, 人が少ない・納期が厳しい時にはドキュメントを いちいち残していられないので、テストがドキュメント (=仕様)代わりになっています.(提出すべき仕様は 後からまとめればいい)
ペアプログラミングも興味があります.最近考えている のは、メインプログラマのバックアップとしての役割. 最近の開発はまず締め切りありきで,締め切りを守れ なかったら大きな損害が出ます.そんなときに メインのプログラマに倒れられたりしたら…もっとも 二人いっしょに倒れたら意味無いのですが…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
テストバカになる(いい意味で) (スコア:3, 興味深い)
Re:テストバカになる(いい意味で) (スコア:0)
同じく単体テスト部分だけ部分導入しました. あいまいな仕様をもとに作業している上に, 人が少ない・納期が厳しい時にはドキュメントを いちいち残していられないので、テストがドキュメント (=仕様)代わりになっています.(提出すべき仕様は 後からまとめればいい)
ペアプログラミングも興味があります.最近考えている のは、メインプログラマのバックアップとしての役割. 最近の開発はまず締め切りありきで,締め切りを守れ なかったら大きな損害が出ます.そんなときに メインのプログラマに倒れられたりしたら…もっとも 二人いっしょに倒れたら意味無いのですが…
Re:テストバカになる(いい意味で) (スコア:1)
この頃は、そうあっていいんじゃない、という事で、どのように作られているか(設計書)は軽視してます。結局の所、テスト(検証)にパスすれば製品として出荷 OK となるので。
仕様書には、やりたい事が記述されているので、どういう検証を行えばソレが実装されているかを考えます。
仕様変更が舞い込んで来た時も、どのような検証でもって、既存部に影響の無い事、追加分が実装されている事を確認できるかを考える。
初めにテストありき。自分自身 昔は、どう作ろう?という事ばかりに囚われ過ぎていたように感じます。
プログラマのトッピング (スコア:0)
ペアプログラミングの利点で,指向の異なるプログラマーをペアにすることで,コードの偏りを防げるのではないだろうか.
たとえば,セキュリティに強いプ