Please enable JavaScript.

Coggle requires JavaScript to display documents.

テスト駆動開発 (ゴール (『動作する綺麗なコード』 (コードが伝えようとしていることを余すところなく受け取れる。最初に思いついたコードを書き殴った…

- - - - ２つのルール
        
        重複を除去する。
        
        自動化されたテストが失敗したときのみ、新しいコードを書く。
        
        良い影響
        
        有機的に設計を進められるようになる。動作するコードが設計判断にフィードバックをもたらす。
        
        自分たちでテストを書くようになる。誰かがテストを書いてくれるのを1日に20回も待っていることなどできないからだ。
        
        小さな変更に迅速に応答する開発環境を備えなくてはならなくなる。
        
        凝集度が高く結合度が低いたくさんの部品で構成された設計を行うようになる。そのほうがテストが書きやすいからだ。
        
        作業の順序でもある
        
        レッド・グリーン・リファクタリング。それがTDDのマントラだ。
        
        レッド：動作しない、おそらく最初のうちはコンパイルも通らないテストを1つ書く。
        グリーン：そのテストを迅速に動作させる。このステップでは罪を犯してもよい。
        リファクタリング：テストを通すために発生した重複をすべて除去する。
        
        テストを書く。頭の中で想像した操作がどんなコードとして現れるかを考える。いまあなたは物語を書いている。欲しいと思うインタフェースを創作しよう。物語には、正しい答えを導くために必要そうな要素をすべて盛り込もう。
        
        動かす。テストがすべて通り、バーがグリーンになる状態へと素早く到達する。きれいでシンプルな解が見えているなら、そのとおり書いてしまおう。もし実現に少し時間がかかりそうな場合は、いったんTODOリストに書いておき、目の前のバーを速やかにグリーンにする作業に戻る。なんでもいいからとにかく動かすという考え方は、優れたエンジニアリングのルールに反するように感じるし、特にベテランの開発者にとっては、審美的にも価値観的にも受け入れがたいかもしれない。それでも、素早いグリーンはすべての罪を赦す。ただし、赦されるのはほんの短い時間だけだ。
        
        周囲の人びとの関係にも影響
        
        欠陥率を十分に下げられるならば、品質保証担当者は、後手に回るのではなく、先手を打って仕事ができる。
        
        悪い知らせを十分に減らせるならば、プロジェクトマネージャは正確な見積りを行えるようになり、顧客を日々の開発に招き入れられる。
        
        技術的な議論の対象を十分明確にできるならば、ソフトウェアエンジニアは週や日ではなく分単位のコミュニケーションを行える。
        
        繰り返しになるが、もし欠陥率を十分に下げられるならば、新しい機能を伴うソフトウェアを毎日リリースすることが可能になり、顧客との新しい関係を作れる。
      - 自動化されたテストによって開発を推し進める
      - プログラミング中の不安をコントロールする手法
  - - - 不安
        
        悪い効果もある
        
        不安はためらいを生む。
        不安はコミュニケーションを減らす。
        不安はフィードバックから逃げ腰にさせる。
        不安はイライラさせる。
        
        プログラミングを妨げる要因となる
        
        難しい対象に取り組んでいるときはなおさら
        
        不安は「気をつけろ」というサイン
      - どのように難しい局面と対峙するか
        
        ためらいがちになるのではなく、可能な限り素早く着実に学び始めること。
        黙り込むのではなく、はっきりとコミュニケーションをすること。
        フィードバックを避けるのではなく、具体的で有用なフィードバックを探し出すこと。
        （自分のイライラは自分で対処しなければならない。）
        
        テストを書く
        
        テストが通ったときに、正しく動くコードが完成したと自信を持って言えるようなテストを書く。
        
        書くべきテストを思いついたときには、
        そのつどTODOリストに追加する。
        
        複雑なテストより簡単なテストから小さく始める。
        
        外部から見た振る舞いは
        どのようなものであるかを想像する
        
        物事は最初に想像したとおりになるとは限らない
        
        API（アプリケーションプログラミングインタフェース）から始めて、逆向きに作業していくほうが、複雑で見苦しい「現実的」なプログラムを最初から書くよりは良いものだ。
        
        大事なのは、小さいステップを踏むことだ。気づいた問題点を書き留めて先に進もう。目の前には失敗しているテストがある。これを可能な限り早くグリーンバーにしたい。
        
        1つずつ解決していこう
        （私はいつも進捗を「数えられる」ようにしている）
        
        失敗するテストでいいので走るテストを書く
        
        「この機能が正しく動くテスト」の作成ではなく「このテストを通す。その後で他のテストも書いて通す」となり、とてもシンプルになった。
        
        不安のスコープもだいぶ小さくなった。
        
        目の前の目標は完璧な解を出すことではなく、テストを通すことだ。代わりに犠牲になった正しさや美しさは、後から追求することにしよう。
        
        成功するようにする
        
        意味のあるものにする
        
        例
        
        2 more items...
        
        サイクル
        
        テストを書く
        
        コンパイル＆テストが失敗する
        
        テストを通す
        
        1 more item...
        
        フェーズ
        
        テストが失敗するフェーズまではサクッと済ませたい
        
        素早く先に進むためにコピペでもなんでもする
        
        1 more item...
        
        正しい設計を正しいタイミングで行う
        
        動かしてから正しくする
- - - - 間接的に
  - - - どちらも実現する処理をかく
- - - - 足される方
    - - たす方