9

この投稿を読んで、私は質問者と同じ立場にいると感じました。私はテクノロジーが大好きで、現実世界の問題を解決するための新しいアイデアを思いつくと、神経細胞が興奮しますが、方程式の他の部分である実際に物事を (速く) 成し遂げるということは、通常、達成するのに苦労します。私は自分のためにこれをやっています。

コードに飽き飽きすることもあれば、テキスト エディターでカーソルを動かしたり、コードを見つめたりして、既存のソリューションよりも優れたソリューションを考え出すことに時間を費やしていることもあります。これは完璧主義という病気だと聞きました。

私はその同じ投稿を読んだことがあります (また、SO でここでも数回)、TDD は実際には女の子のようにコーディングをやめるのに適していることを読みましたが、TDD でチャンスを与えたことはありません。それを学ぶ/設定するか、頭の中で必要なすべてのテストを実行できるので、必要ないと思うからです。

  • また、TDD が実際に GTD に役立つと思いますか?
  • TDD について知っておくべきことは何ですか?
  • TDD に代わるものは?
  • TDD Web アプリを編成/開発するための最良の方法論は何ですか?
  • 私の生活を楽にするために、どのライブラリを使用する必要がありますか?

PS: ここでは、主に (排他的ではありませんが) PHP を使用しています。

4

3 に答える 3

5

個人的には、TDD はせいぜい過剰であり、最悪の場合、プログラミングの創造的なプロセスの障害になると思います。まだ書かれていないメソッド/クラスごとにユニットテストを書くのに苦労して費やす時間は、元の問題を解決するのに費やすほうがよいでしょう。そうは言っても、私はユニットテストの大ファンであり、ユニットテストを心から信じています。特に複雑なコードや厄介なコードがある場合は、1 つのメソッドに対して 20 個の単体テストを喜んで作成しますが、通常は問題を解決した後に作成します。TDD は、他のすべてのプログラミング パラダイムと同様に、特効薬ではありません。スーツの場合は、探し続けない場合はそれを使用します。

しかし、私の意見を一粒の塩で考えてください。もっと興味深いのはKent BeckHow deep are your unit tests? です。.

于 2009-09-01T03:39:03.923 に答える
2

また、TDD が実際に GTD に役立つと思いますか? 私の最大の懸念は、単純にコードをテストできないことでした。複雑すぎました。私たちのコア ライブラリは、簡単にテストできるインターフェイスを中心に構築されていません。そのため、可能な限りのテストを作成しました。最終的に、コア ライブラリをリファクタリングして作業を楽にすることになりました。それに加えて、それは考え方の変化であり、途中で発生する可能性のある問題のいくつかを洗い流すためだけに、最初の TDD プロジェクトにより多くの時間を割り当てることを間違いなく検討します。

TDD について知っておくべきことは何ですか? TDD は方法論に代わるものではありません。それは有益な追加であるか、少なくともそうあるべきです。TDD を適切に行うと、ソフトウェア設計が大幅に改善されます。また、社内文書としても機能します。誰かにあなたの API を見てもらい、それがどのように機能するかを理解してもらいたい場合は、適切に名前が付けられた、形成されたテストを見るだけで済みます。

TDD に代わるものは? 私が言ったように、私はこれが方法論の代わりになるとは考えていません。代替手段があり、それはそれを使用しないことです:)

TDD Web アプリを編成/開発するための最良の方法論は何ですか? 私たちはスクラム/アジャイルでかなりの成功を収めています。

私の生活を楽にするために、どのライブラリを使用する必要がありますか? 私の PHP の知識は 5 年前に期限切れになりました。他の誰かに答えてもらいます。

いずれにせよ、ちょうど私の 2 セント。ここで読みたいと思うなら、良い概要です: http://www.agiledata.org/essays/tdd.html

于 2009-09-01T03:43:41.137 に答える
2

私は最近、「ファット モデル シン コントローラー」を使い始めましたhttp://www.amitshah.in/php/controller-vs-model.html : できるだけ多くのコードをモデルに (およびビュー/コントローラーから) シャベルします。 .

私は PHPUnit (およびそれに対する Zend Framework のサポート) を使用して、Web アプリでいくつかの複雑なモデルのみをテストしています。単純な SQL クエリを実行する 2 行の関数を徹底的にチェックする単体テストを作成するのは時間の無駄です。ここ数年、私はテストを書くのがますます怠惰になっており、コードが非常に単純であるため、ほとんどの Web アプリではその価値がありません。

しかし、最近のプロジェクト (複合製品を使用して複数の倉庫の在庫レベルを追跡する e コマース サイト) では、テスト ファーストの開発を始めました。すぐに。私の考えが発展したときにすべてを機能させ続ける唯一の方法は、いくつかのテストを書くことでした。テストよりもクラスを書く方が自然に思える部分もあれば、最初にテストする部分もありましたが、他の部分は些細なことでテストを必要としませんでした。TDD はツールであり、宗教ではありません。効果があれば使用し、効果がなければ停止します。

TDD の利点は、複雑さが軽減され、速度 (問題を解決できる速度) が向上することです。コードが機能していることを証明するいくつかのテストを作成すると、すべてのテストに合格するとすぐに次の問題に進むことができます。これにより、コーディングの楽しみが戻ってきました。

于 2009-09-01T07:59:12.510 に答える