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