テストはすべきか、どのように行うべきか [アーキテクト]
Developers [Test] Summit 2008のパネル討論の内容がITProに掲載されていました。
内容は読んでいただいたほうが正確ですのでそちらにお任せして・・・・。
私の立場としては[大規模/開発寄り]としておきましょう。でも太田氏の意見に近いかな・・・。割と品質重視の考えを持っています。
現状ではTDDを行うのが一番よい方法だと考えています。またドキュメントもある程度までは書かないといけないが、(プログラムを見ればわかる範囲ならば)詳細な部分までは書かなくてもいいだろうと思っています。あまり詳細なドキュメントを書いてしまうとリファクタリングする際の負荷が高くなり、リファクタリングしなくなってしまう可能性があるなと感じています。
また和田氏の、バージョン管理ソフトのコミット・ログにWhyを書くというルールを徹底している、という意見には賛成です。
ただWhyを直接書くかどうかはまだ考えが微妙な部分があって、バグトラッキングのIDだけ書けばいいのではないかという考えもあります(両方にWhyを書いたら2度手間になるので)。
ひが氏の意見は最近極端すぎてついていけない・・・。それが理由でSeasar2プロジェクトから距離を置いているのですけど。
Seasar2が悪いわけではないんですけどね・・・。なんとなく、目指す方針が違うかなと思って・・・。
(Seasar2派の方、ごめんなさい。いいフレームワークだとは思っています。部分的に趣味が合わないというか、そんな感じです。)
内容は読んでいただいたほうが正確ですのでそちらにお任せして・・・・。
私の立場としては[大規模/開発寄り]としておきましょう。でも太田氏の意見に近いかな・・・。割と品質重視の考えを持っています。
現状ではTDDを行うのが一番よい方法だと考えています。またドキュメントもある程度までは書かないといけないが、(プログラムを見ればわかる範囲ならば)詳細な部分までは書かなくてもいいだろうと思っています。あまり詳細なドキュメントを書いてしまうとリファクタリングする際の負荷が高くなり、リファクタリングしなくなってしまう可能性があるなと感じています。
また和田氏の、バージョン管理ソフトのコミット・ログにWhyを書くというルールを徹底している、という意見には賛成です。
ただWhyを直接書くかどうかはまだ考えが微妙な部分があって、バグトラッキングのIDだけ書けばいいのではないかという考えもあります(両方にWhyを書いたら2度手間になるので)。
ひが氏の意見は最近極端すぎてついていけない・・・。それが理由でSeasar2プロジェクトから距離を置いているのですけど。
Seasar2が悪いわけではないんですけどね・・・。なんとなく、目指す方針が違うかなと思って・・・。
(Seasar2派の方、ごめんなさい。いいフレームワークだとは思っています。部分的に趣味が合わないというか、そんな感じです。)
コメント 0