疑問と今後

[at-grandpa]

疑問

• 教条主義的な側面に陥らないようにするにはどうしたらいいか
  • 何が一番良いんだっけ？
  • 自分なりのスタイルを持って、常に更新し続ける
  • そのプラットフォームがあるといいね
• TDDでは開放閉鎖原則が徐々に満たされるのはなぜか
  • 重複を省くことでインターフェースが整い、責任の分離が進み、ある機能追加（拡張に対しては開放）の際には抽象処理に対しての変更が不要（変更に対しては閉鎖）。
• 今の自分が思っているTDDとはなにか
  • 広い範囲の知識
    • テストの一部
    • ビジネス面でのテストではない
    • 製品批評ではない
    • 技術面のサポートである
    • チーム開発支援である
    • 開発支援、設計のカナリア、駆動の明かり
    • TODO：このあたりを自分の言語化して、開発手法にまで落とし込みたいな
• TDDが解決しようとしている課題は何か
  • 開発中の「うまく動作するのか」という不安
    • レッド・グリーン・リファクタリングのサイクルをまわし、常にグリーンバーで動作をチェックできるから
  • 良い設計になる
    • なんで良い設計になるんだっけ？
      • 良い設計とは？
        • 責務が分離されていること
          • 結合度が低く、凝集度が高い
          • 開放閉鎖原則に則っている
          • インターフェースが共通化されていて、抽象プログラミングがメインになり、重複が省かれるから
      • なぜその良い設計になるのか？
        • ここが重要なんだよなー、なんでだ？
        • あー、「良い設計ではない、ということを教えてくれる」
          • これかな
          • で、「良い設計ではないから、どうリファクタリングするか」というところで、自分の設計の知識が問われるわけか
          • 第32章 TDDを身につける #38 (comment)
          • ここやな
          • 前準備に要するコードが長い
          • 前準備のコードの重複
• それらの良いことを享受するには、どういった具体的な開発スタイルがよいか
  • TODOリストを書く
  • 自身を持って書ける、いろいろと教えてくれそうなテストから書き始める
  • まずはassert-firstで、アサーションから書く
  • そのアサーションを達成するために必要な準備を書いていく
  • いち早くグリーンにする
  • 仮実装、明白な実装、三角測量を駆使してリファクタリング
  • 何か違和感がないかをチェック
    • 前準備に要するコードが長い
      • 密結合しているので、オブジェクトを分割しよう
    • 前準備のコードの重複
      • オブジェクトを分割しよう
    • これらを解消する方法は経験だなぁ
  • リファクタリングは単純に重複排除をしていくが、排除の仕方はデザパタなどの戦略がある
    • ここは設計の知識が必要だなぁ
    • とはいえ、TDDがヒントをくれているので、最初っから何か設計を決めないとダメ、というのはない