第Ⅰ部 個人的感想

[at-grandpa]

第Ⅰ部を終えた時点で、今までの疑問だった部分の整理をしておく。

[at-grandpa]

始めに思っていた疑問に対して、解決したこと

• その違いを明らかにして、TDDでは何がガイドされるのか知りたい
  • 「開発駆動」と「設計矯正」がガイドされる
• やり方がおかしいから導かれていないのでは？
  • 一部ある。意識の問題
• 自分勝手なメソッドやクラスを作って、そのテストを書いているだけっぽい
  • その通りです。意識できていないサイクルがあった。
• 本当のTDDの回転を体験したい
  • 今回サイクルは学んだ。実践しましょう。
• 遠回りなコードを書いていそうで、結局遅くないか？
  • 遠回りのコードが正しいわけではない。歩幅の調整は自分のプログラミングスタイルだ。
• やってることをあたりまえにやろう
  • はい。（ちょっと疑問の意味がわからないぞ）
• 実際に「TDDしてる！」を実感したい
  • 「開発駆動」ではかなり感じる。「設計矯正」はまだ感じていない。
  • 下記の疑問解決で達成されるので、そちらを参照。
• やりたい関数を作って、その関数の各パターンを思い描いて、それをテストに書いて回していた
  • 設計という言葉はどこにも出てきていないが、それで良いのか
  • この流れは違うね。
  • 実現したいことがあって、それから先にテストを書くのがサイクル。
• どのようなテストが通れば、自信をもってコードが完成したと言えるか
  • 要求仕様を見たした時。
• 実務で使える技術を言語化したい
  • 今回の最大のテーマ。
  • 再現性が欲しい。

この時点でのハッキリさせておきたい疑問

参考： #1 (comment)

• TDDでの恩恵を言語化したい
  • 「開発駆動」はわかる。「設計矯正」を言語化したい。感じたい。
• どういう時にTDDを使うべきか
• 今までの知識とどこが違うのかを明らかにしたい
  • before/afterを言語化しよう
• とりあえずテスト書いて回せばokっぽい、に取り憑かれて、設計を担保していないのでは？
  • やり方の部分で設計は矯正される
  • それがどこかハッキリさせておきたい
• おそらく、重複を外す、がおかしい
  • そのあたりがうまく意識できていなかったので整理しましょう
• 答の見えない納期を明らかにしてくれるの？
  • まだこの実感がないが、実際に仕事で使ってみると実感するのかも？
  • なぜまだ実感がないのか。
• 「動作するきれいなコード」はどういったものなのか言語化したい
  • 言語化しましょう

[at-grandpa]

以下、疑問についてまとめていく。

[at-grandpa]

TDDでの恩恵を言語化したい

TDDの恩恵は「開発駆動」と「設計矯正」の二つだと思っている。

開発駆動

• 迷いなく、不安なく、開発が進むこと
• テストを頻繁に実行し、今どこがおかしいかを常に把握できるのは、迷いなく、不安なく開発が進むことを意味する
• 歩幅を調整し、自分の把握できていない部分が０の状態で開発を続けることができる
• これはTDDの大きな恩恵の一つだと思う
• 特に意識せずともこの部分の恩恵は得られるはず
• 強いていうなら、開発環境の構築が一つのハードルかもしれない

設計矯正

• 「まえがき」にもあったように、TDDは「凝集度が高く、結合度が低い」プログラムを生み出せる
• 凝集度と結合度
  • 凝集度
    • http://www.itmedia.co.jp/im/articles/0510/07/news106.html
    • ある一つの機能がひとつのモジュール内に収まっていること
    • ある機能がさまざまなクラスに分散されているのは、凝集度が低く、保守性が低くなる
    • 単一責任の原則を表しているのかな
  • 結合度
    • クラス間の結びつき
    • 結合度は低いほうが良い
• 具体的にどういったTDDの場面で、凝集度・結合度を良い方向に持っていっているのか
  • クラスの責任範囲なんて、TDDやってる最中にわかるの？
  • 凝集度という「関連性」的な定性的な部分を、明確に扱うことができるの？
  • 「凝集度が高く、結合度が低い」というコードが「きれいなコード」なんだろう
  • そして、テストが動くから「動作するコード」となる
  • よって、「動作するきれいなコード」がTDDのゴールとなる
  • まえがきにあった。「凝集度が高く、結合度が低い」というコードは「テストが書きやすい」ので、テストから入るTDDは、自然とそうなるらしい。
  • なんで、テストが書きやすいと「凝集度が高く、結合度が低い」コードになるのか
  • そもそも、おかしなコードでもテストを書くことはできるだろう
  • でも、どっかで引っかかるんだろうな
  • どういう引っかかりがあるんだろう
  • 「TDD はプログラミング中の設計判断とフィードバックの間にあるギャップ を認識することであり」
  • なるほど？
  • ギャップをコントロールするのがTDD
  • 「一方 で、TDD を学んだ後に以前のプログラミングスタイルに戻り、そのやり方でうま くいかないときだけ TDD を行うプログラマもいる」
    • これかな？
    • そもそも、自分のプログラミングスタイルってなんだ
    • 今回は、それをつかむのも一つかもしれない
  • 本書を終えた時に準備できていること
    • シンプルに始める
    • 自動テストを書く
    • リファクタリングで設計判断を一つずつ行う
  • ここなのかなぁ
    • リファクタリングフェーズで設計判断をしているのかも
    • 本書ではどうやっているんだろう
    • 第一部では、設計を有機的に成長させる方法を学ぶらしい
      • 学んだか？
    • 第二部では、小さい歩幅を学ぶらしい
      • 本質というよりは、発展系かな
    • 第三部はどのようなテストを書くかの判断に関するパターンらしい
      • 第一部の知識をより強力にするものかな
  • 第一部の「有機的に設計を成長させる方法」を言語化するのが良さそう

[at-grandpa]

第一部の「有機的に設計を成長させる」を言語化する

• 複雑なテストはあとまわし
• 簡単なテストから始めよう
• 用途に合った完璧なインターフェースを想像しよう
  • 外部から見た振る舞いはどういうものか想像しよう
  • ここをやるから、凝集度が高く、結合度が低いコードになるんだろうか
  • 設計の方針を変えるところで、どうやって判断しているか見もの
• まず書いてみて、そこから問題点をTODOリストに書く
• 限りなく早くグリーンバーにしたい
• 不安のスコープを小さくする（開発駆動側の視点）
• 重複は依存性。つまり結合度に関係している。それは、プロダクトコードに関してだけでなく、テストコードとプロダクトコードの重複に対しても言える。
  • プロダクトコードの重複の排除 => 凝集度が上がる
  • プロダクトコードとテストコードの重複の排除 => 保守性が高まる。一般化されていく
• テストに導かれながら、プロダクトのコードの重複を除去していく。これはテストがないとなかなかできないものだ
• かつ、わかりやすいテストコード＝インターフェースを書くことで、意味のあるクラスが自然とできあがっていく。凝集度が高まる。
  • このあたりかな
  • 使う側の視点（テストコード）を先に書くことで、自然と凝集度が高くなっていくっぽい。
  • テストを書く時に「実装は考えちゃだめ！実装を考えた時点で、間違った実装になっていた場合、凝集度が低くなる可能性がある！」ということか。だから、「どんな実装をしようか...いや、テストから考えよう」という取り組みってことだ。
  • 自分は昔は、実装を先に思う浮かべて、そこからテストを思い浮かべていたが、逆だった。
  • 「テストから書く」ではなく「テストから考える」だと思う。微妙に違うけど、この違いは大事。
• サイクルの詳細な意味
  • テストを書く。インターフェースを書く。必要なものを使用者側の視点で書く。
    • 設計が既に入っている。凝集度が上がる。シンプルなテストにすることで、疎結合になる。
  • 速やかにグリーンバーにする
    • 開発を駆動させるためにグリーンにする。グリーン化が難しいならTODOリストに追記する。罪は許される。
  • 正しくする。リファクタリングする。重複を除去する。
    • 綺麗な設計になる。凝集度が上がる。
• 「最初に『動作する』に取り組み、次に『きれいな』に取り組む」
  • なるほどね。
  • 動作する、をテストで担保してしまう。
• TDDを行う時は、一歩一歩か明白な実装で飛ばすか、揺れ動く
• 設計が思いつかなければ、三角測量をつかう
• サイクルを思い出す
  1. テストを書く。
  2. コンパイラを通す。
  3. テストを走らせ、失敗を確認する。
  4. テストを通す。
  5. 重複を排除する。
  • 最初の 4 つ のステップは、5 つ目がなければ無意味だ。正しい設計を、正しいタイミングで行う。動かしてから、正しくする。
• ６章：コードをきれいにするときがきた
  • どんなときなのか
  • やっぱ、案出しか
  • 導かれるわけではなさそう
  • そのために第３部にパターン集があるのかも？
  • メソッドの引き上げもひとつのパターン
    • 凝集度が高くなる
  • その後の章では、Factoryなどを使って実装を隠したり、歩幅調整だったり、とりあえず変更してみてテストに聞いてみたりしている。設計のテクニックではない。
• 不要になったら消すのも大事
• 12章「設計とメタファー」
  • ここは設計に関するところだろう
  • 設計はひらめき
  • そのひらめきは経験からくるし、テストをしっかり駆動させておくのは、ひらめきの手助けになる。ひらめきを具体化するときの手助けになる。
  • 凝集度を高めるにはどうしたらよいか
  • クラスを太らせないようにするにはどうしたらよいか
  • これらの視点を「テストを書くときに考える」のがTDD。どうしたらよいかは実装寄りの考え方になりがちだが、使用者側の視点から考えることで、テストが書きやすく自然と凝集度が高いコードになる。

[at-grandpa]

ガイドや治具と言われる所以。

使用者側から設計がスタートするから

重複排除で凝集度が上がるから

ガイドや治具が必要ないなら使わなくていい。不安な時や進まない時に使う。