有名なベストセラーの復活。 変更が簡単で、正しく動作し、作成者に不快な驚きを投げかけない、エレガントで柔軟で理解可能なコード。 これは本当に可能ですか？ 目標を達成するには、プログラムを作成する前にテストしてみてください。 TDD（Test-Driven-Development）方法論の根底にあるのは、このような逆説的な考え方です。 ナンセンス？ 急いで結論を出すために急がないでください。 実際のプログラムコードを開発する例としてTDDのアプリケーションを考慮して、著者はこの手法のシンプルさとパワーを実証します。 この本には、TDDを使用して完全に実装された2つのソフトウェアプロジェクトが含まれています。 例の後には、TDDスタイルの手法の広範なカタログと、TDDに関連するパターンとリファクタリングが続きます。 この本は、仕事の生産性を高め、プログラミングを楽しみたいプログラマーに役立ちます。
動作するクリーンなコード-Ron Jeffriesによって造られたこの短いが有益なフレーズでは、テスト（テスト駆動開発、TDD）による開発方法論の要点が隠されています。 動作する純粋なコードは、努力する目標です。
•これは、プログラムを開発する予測可能な方法です。 作業が完了したと見なすことができ、長い一連のミスを心配する必要がない場合は知っています。
•コードが教えるレッスンを学ぶ機会を与えます。 頭に浮かぶ最初のアイデアを使用する場合、2番目のより良いアイデアを実現する機会はありません。
•プログラムのユーザーの生活を改善します。
•同僚があなたに頼ることができます。あなたは彼らに頼ります。
•このようなコードを書く方が快適です。
しかし、動作するクリーンなコードを取得する方法は？ 多くの力がクリーンなコードを取得することを妨げており、時には機能するコードさえ取得できないこともあります。 多くの問題を取り除くために、自動テストに基づいてコードを開発します。 このプログラミングスタイルは、テストによる開発と呼ばれます。 この手法によると
•新しいコードは、自動テストが書き込まれた後にのみ書き込まれ、失敗します。
•重複が排除されます。
2つの簡単なルールですか？ ただし、それらは複雑な個人およびグループの動作を生成し、多くの技術的な結果をもたらします。
•設計プロセスでは、常にコードを実行し、その作業のアイデアを得ることができます。これにより、適切な決定を下すことができます。
•他の誰かが私たちのためにテストを書くのを待つことができないので、私たちは自分でテストを書きます。
•開発環境は、コードの小さな変更に迅速に対応する必要があります。
•プログラムの設計は、コードテストを簡素化するために、多くのスタンドアロンの疎結合コンポーネントの使用に基づいている必要があります。
上記の2つのTDDルールは、プログラミング手順の順序を決定します。
1.赤-動作せず、場合によってはコンパイルさえしない小さなテストを作成します。
2.緑-正しい設計とクリーンなコードを考えずに、テストをできるだけ速く実行します。 テストを機能させるのに十分なコードを記述します。
3.リファクタリング-記述されたコードから重複を排除します。
赤—緑—リファクタリングはTDDマントラです。
このようなプログラミングスタイルが可能であると仮定した場合、その使用により、コードに含まれる欠陥が大幅に少なくなり、さらに、作業の目的がそれに参加するすべての人に明確になると想定できます。 そうである場合、テストに合格するために必要なコードのみを開発すると、社会的な結果にもつながります。
•欠陥の密度が十分に低いため、品質保証（QA）チームはエラーへの対応からエラーの防止に移行できます。
•不愉快な驚きの数が減ると、プロジェクトマネージャーは人件費をより正確に評価し、顧客を開発プロセスに関与させることができます。
•技術的な議論のトピックが明確に定義されている場合、プログラマは1日1回または1週間に1回ではなく、絶えず相互にやり取りすることができます。
•繰り返しますが、欠陥密度が十分に低い場合、新しい機能が追加された統合作業成果物を毎日受け取ることができるため、顧客とのまったく新しいタイプのビジネス関係を結ぶことができます。
だから、アイデアはシンプルですが、私たちの興味は何ですか？ なぜプログラマーは、自動化されたテストを書くという追加の責任を負うべきなのでしょうか？ なぜ彼の脳がもっと複雑な設計構造を考え抜くことができるのに、プログラマーが小さなステップで前進する必要があるのでしょうか？ 勇気。
勇気
TDDは、プログラミングプロセスの恐怖を管理する方法です。 私は椅子から落ちるのを恐れたり、上司を恐れたりするつもりはありません。 私はタスクに対する恐怖を意味します。「とても複雑なので、どうやってそれを解決するのかわからない」。 痛みとは、自然が「やめろ」と言うとき、そして恐怖とは、自然が私たちにやるときです。「気をつけろ！」
•恐怖は、この行動またはその行動が何につながる可能性があるかを前もって慎重に考えさせます。
•恐怖はコミュニケーションを少なくします。
•恐怖は、私たちの仕事についてのレビューを怖がらせる。
•恐怖は私たちをいらいらさせます。
特に困難なタスクに取り組んでいる場合、プログラミングプロセスに役立つとは言えません。 そのため、困難な状況から抜け出す方法の問題に直面しています。
•将来を予測しようとせずに、問題の実践的な研究をすぐに開始してください。
•他の国々から外れるのではなく、コミュニケーションのレベルを高める。
•応答を避けることではなく、反対に、信頼できるフィードバックを確立し、その助けを借りて彼らの行動の結果を注意深く監視すること。
•（自分で刺激に対処する必要があります）。
プログラミングを井戸からバケットを上げることと比較してください。 バケツに水が満たされたら、レバーを回し、チェーンをカラーに巻き付けてバケツを持ち上げます。 バケットが小さい場合、通常の自由に回転するゲートが非常に適しています。 しかし、バケツが大きくて重い場合、持ち上げる前に疲れます。 レバーの回転の合間に休む機会を得るには、レバーを固定するラチェット機構が必要です。 バケツが重いほど、ラチェットギアの歯がより頻繁に追従します。
TDDのテストは、ラチェットギアの歯です。 テストが機能するようになったので、テストは現在も永久に機能することがわかりました。 私たちは、テストが機能する前よりも作業を完了するための一歩に近づいています。 その後、2番目のテスト、次に3番目、4番目などのテストを行います。プログラマーが直面する問題が複雑になるほど、各テストがカバーすべき機能が少なくなります。
エクストリームプログラミングの読者は、エクストリームプログラミング（XP）とテスト駆動開発（TDD）のトーンの違いに気付いているはずです。 XPとは異なり、TDD手法は絶対的なものではありません。 XPは次のように述べています。「先に進むには、これとこれをマスターする必要があります。」 TDDはそれほど具体的な手法ではありません。 TDDは、意思決定と結果の取得の間に間隔があると想定し、この間隔の期間を制御するツールを提供します。 「1週間以内に紙の上でアルゴリズムを設計し、「最初のテスト」アプローチを使用してコードを記述したらどうなるでしょうか。 TDDに準拠しますか？当然です。 意思決定と結果の評価の間隔のサイズを知っており、この間隔を意識的に制御します。
TDDをマスターしたほとんどの人は、プログラミングのプラクティスがより良く変わったと主張しています。 テスト感染-この定義は、この変更を説明するためにErich Gammaによって考案されました。 TDDを習得したので、以前よりもはるかに多くのテストを記述していることに気付き、以前は無意味だったように思えた小さなステップを進めます。 一方、TDDに精通したプログラマーの中には、通常のプログラミングでは目的の進捗が得られない特別な場合にTDDを予約して、以前のプラクティスを使用することに戻ることを決定する人もいます。
確かに、テストの助けだけでは（少なくとも今のところ）解決できないタスクがあります。 特に、TDDでは、データセキュリティと並列操作の信頼性に関して、開発したコードの妥当性を機械的に実証することはできません。 もちろん、セキュリティは欠陥がないはずのコードに基づいていますが、データ保護手順への人間の参加にも基づいています。 並列処理の微妙な問題は、単にコードを実行するだけでは確実に再現できません。
この本を読んだ後、次のことができます。
•TDDの適用を開始します。
•自動テストを作成します。
•リファクタリング、決定を1つずつ翻訳します。
本は3つの部分に分かれています。
パートI.お金の例について。 TDDを使用して典型的なアプリケーションコードを開発する例。 この例は、何年も前にワードカニンガムから借りたもので、それ以来、TDDのデモンストレーションに繰り返し使用しています。 複数通貨の算術演算を検証します。さまざまな通貨で表された通貨の値に対して数学演算を実行します。 この例では、テストするコードの前にテストを作成する方法と、有機的にプロジェクトを開発する方法を説明します。
パートII たとえば、xUnit。 リフレクションおよび除外メカニズムを使用して、より複雑なロジックをテストする例。 この例では、自動テストインフラストラクチャの開発について説明します。 この例では、多くのテストツールを支えるxUnitアーキテクチャも紹介します。 2番目の例では、さらに小さなステップで前進すること、およびこのシステム自体のメカニズムを使用してシステムを開発することを学習します。
パートIII。 テストによる開発パターン。 ここでは、多くの質問に対する答えを見つけるのに役立つテンプレートを検討します。特に、どのテストを作成するか、xUnitを使用してどのようにテストを作成するかを検討します。 さらに、ここでは、この本の例を作成するために使用される、選択されたデザインとリファクタリングパターンのいくつかの説明があります。
私（Kent Beck）は、あなたと私がペアプログラミングセッションに参加しているかのように例を作成しました。 散歩の前に最初に地図を見たい場合は、最初に本の第3部のテンプレートに慣れてから、例を例として考えてください。 最初に散歩をして、訪れた地図を見る場合は、最初に最初の2つの部分を例とともに読み、必要に応じて3番目の部分を参照してください。 この本のレビューアーの何人かは、開発環境を読み始め、コードを入力し、テストを実行する方が、例がよりよく学べることを指摘しました。
例については、次のことに注意してください。 マルチ通貨コンピューティングとテストインフラストラクチャの両方の例は、非常に単純に見えるかもしれません。 これらの同じ問題に対して、より複雑で欠陥のあるandい解決策があります（私は個人的に同様の解決策に繰り返し対処しなければなりませんでした）。 本をより現実に近づけるために、これらの解決策の1つを示すことができます。 ただし、私の目標は、機能するクリーンなコードを書くことです。 例の過度の単純さを非難する前に、すべてのコードがきれいで明確に見えるプログラミングの世界を数秒間想像してみてください。 複雑な問題は慎重に検討する必要があります。 TDDはこれを達成するのに役立ちます。
»本の詳細については、出版社のウェブサイトをご覧ください
» コンテンツ
» 抜粋
Bearers- Beckのクーポンが25％オフ