16

Code Complete 2をまだ読んでいない人にとって、擬似コードプログラミングプロセスは、基本的に、最初に平易な英語でルーチンを記述し、次にそれをより詳細な擬似コードに、そして最後にコードに改訂することによってルーチンを設計する方法です。これの主な利点は、システムをボトムアップではなくトップダウンで構築し、それによって別個のレイヤーでクリーンなAPIを進化させることにより、適切なレベルの抽象化を維持できるようにすることです。TDDは、テストに合格するために最低限のことを行うことに重点を置きすぎており、事前の設計をほとんど奨励していないため、これでは効果が低いことがわかります。また、不安定なコード（常にリファクタリングされているコード）の一連の単体テストを維持することは非常に難しいこともわかりました。これは、通常、1回または2回だけ必要なルーチンの単体テストが12個ある場合だからです。リファクタリングを行う場合（たとえば、メソッドのシグネチャを変更する場合）、行う作業のほとんどは、製品コードではなくテストの更新です。コンポーネントのコードが少し安定した後で、単体テストを追加することを好みます。

私の質問は、両方のアプローチを試した人のうち、どちらが好きですか？

4

6 に答える 6

6

私のチームは両方のアプローチを組み合わせており、それは（少なくとも私たちにとっては）開発するための素晴らしい方法です。大規模で複雑なソフトウェアシステムがあるため、単体テストが必要です。しかし、擬似コードプログラミングプロセスは、私が出会ったソフトウェア設計への実践的な最良のアプローチです。それらを一緒に機能させるには：

  • クラスを作成することから始め、入力と出力を含む完全にコメント化されたメソッドスタブを入力します。
  • ペアコーディングとピアレビューをダイアログとして使用して、デザインを改良および検証しますが、それでもメソッドスタブのみを使用します。
  • この時点で、システムを設計し、テスト可能なコードをいくつか用意しました。そこで、先に進んで単体テストを作成します。
  • 戻って、作成する必要のあるロジックのコメントをメソッドに入力し始めます。
  • コードを書きます。テストに合格します。

それの美しさは、私たちが実際にコードを書くときまでに、実装のほとんどの作業がすでに完了していることです。なぜなら、実装として私たちが考えるものの多くは実際にはコード設計だからです。また、初期のプロセスはUMLの必要性を置き換えます-クラスとメソッドのスタブは同じように記述的であり、さらに実際に使用されます。そして、私たちは常に適切な抽象化レベルにとどまります。

明らかに、プロセスは私が説明したほど直線的ではありません-実装のいくつかの癖は、高レベルの設計を再検討する必要があることを意味する場合があります。しかし、一般的に、単体テストを作成するときには、設計は（メソッドレベルで）非常に安定しているため、テストを何度も書き直す必要はありません。

于 2010-04-02T10:04:11.667 に答える
4

テスト駆動開発では、最初から計画を立てる必要があります。最初は、あなたがやろうとしていることを大まかに見る必要があります。すべての詳細を思い付くのではなく、問題を解決する方法について平易な英語でアイデアを得る。

次に、問題のテストを開始します。テストを実施したら、合格し始めます。簡単にできない場合は、当初の計画を修正する必要があるかもしれません。問題がある場合は、修正してください。テストはソリューションを定義するためのものではなく、変更を加えることができるため、安定性を確保しながらより良いソリューションを得ることができます。

最善の策はTDDを使用することだと思います。重要なのは、TDDが「計画をスキップする」ことを意味するのではないことを理解することです。TDDとは、開始するために少し計画を立て、必要に応じて調整することを意味します。調整する必要さえないかもしれません。

于 2008-10-03T21:51:15.873 に答える
3

一般に、問題を解決するために必要なコードが、解決策をテストするために必要なコードよりもはるかに複雑な場合にのみ、擬似コードが実際に関連するようになります。そうでない場合、私はあなたが説明する困難に遭遇しません。おそらくうまくいく可能性のある最も単純なものは、通常、問題に費やす価値のある時間の許容可能な解決策です。

一方、問題が複雑な場合は、最初の素朴な解決策を書く前に、どのようにアプローチするかを考える必要があります。コーディングする前に計画を立てる必要があります。したがって、私は両方のアプローチを組み合わせて使用​​します。最初に作成する内容の英語による説明、次にテストハーネス、次に単純なソリューションコード、次に改良です。

于 2008-10-03T21:55:17.860 に答える
1

私は Big Upfront Development と一緒に両方を使用しましたが、言語、チームのダイナミクス、プログラムのサイズ/複雑さなどの問題に応じて、3 つすべてにそれぞれの場所があります。

動的言語 (特に Ruby) では、TDD を強くお勧めします。TDD は、他の言語がコンパイル時にキャッチするエラーをキャッチするのに役立ちます。

大規模で複雑なシステムでは、事前に多くの設計を行うほど、成果が上がります。大規模なプロジェクトを設計したとき、手を振って「これはかなり簡単なはずだ」と言ったすべての領域が、プロジェクトの後半でつまずきポイントになったようです。

静的に型付けされた言語で何か小さなことを一人で作業している場合、リスト アプローチは合理的であり、TDD よりもかなりの時間を節約できます (テストのメンテナンスは無料ではありませんが、最初にテストを書くことはそれほど簡単ではありません)。悪い) -- 作業中のシステムにテストがない場合、テストを追加することは常に賞賛されるとは限らず、不要な注意を引くことさえあるかもしれません。

于 2008-10-03T22:22:40.550 に答える
1

テストに合格したからといって、すべてが完了したわけではありません。

TDD は、Red-Green-Refactorによって最もよく特徴付けられます。

テストを行うと、(2 つのうちの) 1 つのゴール ラインが提供されます。これは最初の最小限の要件セットです。真の目標は、「疑似コード プログラミング プロセス」または任意の設計分野と同じ目標です。

また、TDD はテストによって駆動されますが、それはテストによってやみくもに駆動されるという意味ではありません。コードを反復するのと同じ方法で、テストを反復できます。ここには、ばかげた計画に独断的に固執する場所はありません。これはアジャイル手法です。つまり、チームと状況に合わせて適応させるということです。

テスト可能なインターフェースを持つのに十分なコードを設計します。インターフェイスが確実に機能するように、十分なテストを設計します。リファクタリングの必要性がわかるまで、さらにいくつかのテストと実装を設計します。

本当の目標は良いソフトウェアです。TDD は「良さ」を排除することはできません。

技術は制限的な義務ではありません。テクニックは、優れたコードを生成するための松葉杖と見なす必要があります。私がもっと賢く、裕福で、見栄えがよければ、TDD は必要ありません。しかし、私は私と同じくらい頭が悪いので、リファクタリングを支援する松葉杖が必要です。

于 2008-10-03T23:18:45.773 に答える
0

私にとって、TDD には競合できないエースの疑似コーディングがあります。どちらも開発の抽象化と計画に役立ちますが、TDD ランドでの開発が終了しても、単体テストは残っています。

CC2 が説明した疑似コーディングのような有用なアプローチは、それに匹敵するものではありません。TDD は設計の半分にすぎません。プロジェクトを進化させるための厳密な足場も提供します。ただし、TDD セットの問題を解決するために疑似コードを作成できない理由はわかりません。

私は有機的に発展してはいけません。
疑似コードはマインドキラーです。
プロジェクトの記憶の忘却をもたらすのは小さな死です。
私は90年代の方法論に直面します。
私はそれが私の上を通過するのを許します。
そしてそれが過ぎ去ったとき、私は内なる目を向けてその道を見よう。
疑似コードがなくなったところに TDD があります。
単体テストのみが残ります。

（そのことで私を怒らせないでください、私は半分真剣です：P）

于 2009-01-05T09:22:08.293 に答える