問題の記述からコードへの移行をどのように学んだかについて、この質問を拡張する 2 人が TDD について言及しました。
スターターが TDD に取り掛かる (そして将来の悪い習慣を避ける) ことは良いことでしょうか? それとも、プログラミング言語が何であるかを理解する段階には複雑すぎるでしょうか?
問題の記述からコードへの移行をどのように学んだかについて、この質問を拡張する 2 人が TDD について言及しました。
スターターが TDD に取り掛かる (そして将来の悪い習慣を避ける) ことは良いことでしょうか? それとも、プログラミング言語が何であるかを理解する段階には複雑すぎるでしょうか?
TDD は、「従来の」方法 (最後までテストしない) よりも単純であることを意図しています。これは、テストによって問題の理解が明確になるためです。問題が何であるかを実際に明確に把握していない場合、テストを作成するのは非常に困難です。
したがって、初心者にとっては、テストを書くことで思考力が正しい方向に進みます。これは、実装の動作ではなく、契約上の動作です。
また、TDD が学習の初期段階で非常に役立つことが理想的だと思います。後から考えると、それがまったく別の観点から問題に取り組むのに役立ったことはわかっています。
私が当惑しているのは、学習しているとき、非常に多くの新しい概念が吸収され、混乱が非常に早い段階で始まる可能性があるということです. したがって、TDD は非常に役立つと思いますが、独学でうまく学べるものではないと思います。
人生の他のことと同じように、私たちは誰かが物理的に教えてくれるときに最もよく学ぶ傾向があります. 彼らが TDD の方法で問題にどのようにアプローチしているかを示すことは、本や Web でそれについて読むよりもはるかに多くのことを行うことができます。つまり、これは害になることはありませんが、真にロープを示すことができるメンターの代わりにはなりません.
TDDを体験することがすべてなので、その初期段階で誰かにTDDのやり方を教えてもらうことができれば、全体の学習は予想以上に加速すると思います。
私が最初にプログラミングを学んだときに TDD があればいいのにと思います。また、TDD を学ぶのが非常に難しいほど「古いやり方」に固執する前に、TDD を手に入れていればよかったのにと思います...
def self.learn_tdd_and_programming_together?
if you_have_tdd_mentor_sitting_next_to_you?
"go for it"
else
if language.ruby?
"it's possible, there is quite a bit of good stuff out
there that could give you a chance of learning programming
with TDD from the start. It's sort of in the ruby culture"
elsif language.dot_net?
"learn TDD after you learn the basics of .NET"
end
end
end
私はイエスと思う。研究によると、初心者にとってメリットが最も大きいことがわかっています。それはあなたにコードを書くためのより多くのガイダンスを与えます。結果と動作がどうあるべきかを知っており、テストを作成します。次に、コードを記述します。テストに合格します。完了です。そして、あなたはあなたが終わったことを知っています。
私のプログラミングのモットーは次のとおりです。
テスト駆動開発は最初の 2 つを処理します。
プログラムの実行方法を理解できるように、初心者には TDD を教えるべきだと思います。私見、そうして初めて、優れた設計テクニックを教えることができます。
確かに理解することはたくさんありますが、単体テストを書き始めればよかったと思っています。職場にメンターがいて、私の TDD の進歩を導いてくれたら、本当に良かったのにと思います。私は約 1 年間、TDD をオンとオフで独学してきましたが、カバーすることがたくさんあり、やればやるほど複雑になりますが、今では本当に報われ始めています。
このコメントは、初心者がまっすぐに学ぶことが非常に良いことであることを示していると思います.
TDD の重要な利点は、完成度を定義できることです。単純なアルゴリズム プログラミングでは、正当性が簡単に主張できるいくつかのシナリオを思いついた場合、単体テストでそれらを列挙し、すべてが機能するまでコーディングを続けるのは簡単です。
多くの依存関係があり、オブジェクトのモックが必要なシナリオに遭遇し始めた場合、初心者にとって単体テストが難しい場合があります。
ただし、正確性について簡単に説明でき、簡単に入力できる場合は、必ずコードに書き留めてください。
また、正しいことを簡単に説明できない場合は、問題を完全に理解していない可能性があることに注意してください。
幸運を...
それは本当に「スターター」の定義に依存します。「スターター」とは、プログラミングのバックグラウンドがまったくない人を意味する場合、いいえ、TDD は始めるのにあまり良い方法ではないと思います。プログラマは、リファクタリングやテスト駆動開発について心配する前に、基本 (無限ループの回避、メモリ割り当てなど) を学ぶ必要があります。
コードは、スパイクしようとしているものであろうと、テストであろうと、コードです。
最初に TDD を学ぶことには、多くの価値があります。是非とも身につけておきたいスキルの一つです。tdd の価値を理解し、気に入っている人はたくさんいますが、何年にもわたるプログラミングにより、後で破るのが難しいいくつかの習慣が植え付けられています。
TDD がコントラクトの設計/コードの実装/テストに関するものである限り、それはすべてのものです。TDD は完璧なコードをもたらしますか? いいえ、経験と技術の研究は、コーディング アプローチを成熟させるのに役立ちます。しかし、TDD はすべての開発者にとって非常に重要なツールです。
TDD を使用することで、テスト可能な設計を実現できることを願っています。そして、テスト可能な設計は、理論的には十分にカプセル化されており、オープン クローズド プリンシパルに準拠する必要があります。
私の意見では、人々がTDDをニッチなツールであるか、コードを書く際に何らかの形でオプションであると見なしている限り、それらの人々は明らかにTDDの価値を理解していません.
はい!絶対。
プログラミングを学んでいるだけの人には不向きだと思います。その人は何を主張すべきかをどうやって知るのでしょうか? :P TDD は設計用であり、テスト用ではありません。プログラミングの方法を理解したら、TDD アプローチの学習を開始することをお勧めします。
まず、適切にコーディングする方法を理解する必要があります。あなたがそれをうまく扱えるようになるまで、それを読んで、勉強して、実践してください。それができたら、テスト駆動設計を調べてください。これは非常に強力です。