- デザインパターンを知るキッカケになりそう
- デザインパターンは知識的に理解しているつもりだが、実践できていない
- Q.実装方針を考える時にどうしたら良いか?
- A.パターンに気付くスキルがだいじ
- パターン志向リファクタリング入門
- パターンはリファクタリングの途中で出てくるもの
- ゴール、中間点がデザインパターン
- 設計 → リファクタリング → デザインパターンが見えてくる
- デザインパターン。沢山覚えるのは辛いので、まずはTDD本にあるパターンから
- よく使うものは、自分の手札になる
- デザインパターンより、リファクタリングの勉強をした方が身につく
- 「コードの匂い」があった時の解決策がデザインパターン
- 例: 同じif文がコードの中に複数ある…! → stateパターン
- この本で倒せなかった話題
- ゴールのイメージが見えなくても、TDDできるよ!
- 段々見えてきて具体的になるまで手を止めない
- メソッド名を書くだけでもよい
- そのメソッド名も途中で名前が変わる
- 実装して後からテストを書いても、方向転換できない
- TDDでは、最初にやると思っていたゴールと違う所につく
- TDDでは、細かく方向を変えていく、ゴールのイメージははっきりしていない
- Q. テストを書くのは具体例が見えているでは?
- むしろそれを知るための手段
- 達人プログラマーにかかれている「曳光弾」
- Q. 機能追加時に、方向の間違いに気がつくとつらいがどうしたらよいか?
- 今あるものを分析してリファクタリングする必要がある
- コストは高い。覚悟がいる
- 過去のテストが実装のテストでは、リファクタリングがつらい
- 不要なテストを消すのはだいじ
- ふるまい、インターフェイスをテストすべき
- POODR本にあった「振る舞い、インターフェイスのテスト」
- 実装に近づけすぎない
- 実装をたすけるテストを
- 今あるものを分析してリファクタリングする必要がある
- Q. (p.209) 本物のリソースが使える時はMock Objectではなく、本物を走らせるように…
- A. ケント・ベックがノリで書いている
- MockObject → テスト用のニセモノ
- 執筆当時はまだ、mock、stub の用語ができていない
- 設定で本物/mockをテストできるようにすべき
- googleでは、テストサイズというメタデータがある
- テストの設定によって、同じテストコードでスモール〜ラージを切り替える
- スモール: mock, stub を使う
- ミディアム: 社内ネットワーク, DBに接続する
- ラージ: 外部APIを叩く
- テストの設定によって、同じテストコードでスモール〜ラージを切り替える
- 付録.C テストダブル、スタブ、モックやBDD, TDDなど、用語の混同に気がつけた
- (p.303) モックオブジェクトの書きにくさが設計の悪さを検知するカナリアになるはずが…
- テストの準備が大変 = 何かがおかしい
- (p.290) Test Doubleの分類
- フロントエンドアプリケーションのTDDに難しさを感じる
- Viewは生きもの。TDDには向いていない
- 何でも当てはめてはいけない。技術的には可能だがコスパが悪い
- コードから見た目を想像できない
- Viewに絡まない所でやる
- レグレッションテストに集中する
- ゴールデンバージョンからおかしくなった時に気付くテスト
- storybookなどを使う
- viewに影響があったか?のテストをする
- 1章から感じる「真似できそう」感
- コード例がシンプルで分かりやすい
- PRレビューでよく指摘される部分が多く書かれていた。テストデータの境界とか…
- これ先輩とペア作業している時にやっていたやつ
- 「不安をコントロールする方法」というTDDに対する認識が改められた
- 「ふりかえり」が読み直す時便利
- コード、テストのコピペ→リファクタリングを無意識にやっていた
- 新しい言語に入門する時にお題として使える本かも
- ペアプロ感覚、作業粒度がとても参考になる
- 写経良い。Java - ruby の翻訳でいろいろ考える
- TDDは「個人スキル」というのがしっくり
- 組織に何かを啓蒙する時には「自分一人からはじめられる」のがだいじ
- 今、自分が何をすべきか明確にするためのメソッド
- TDDによって、必然的にコードがシンプルになる
- 細かくステップを踏んでいくことで、少しづつ前身している感が出て良い
- インターフェイスの境界を先に決めて内部をうめていくイメージ
- 脱線はTODOリストへ (p.202) 最近は自然にやっているかも
- TODOメモを残す方法。コード中に「TODO:」を書いてメモしていく自分のやり方に似ている部分があった?
- (TODOリストをやる前は) 気づいた所から直して、commit に困っていた
- (p.59)まとめて色々やろうとしない
- (p.210-212)仮実装よくやる
- (p.213)失敗させたままのテスト⇔きれいなチェックイン
- (p.213)失敗したまま次の日まで寝かせる
- (p.258)ここ何をやっているか名前をつけるならどんな名前になる?
- 悩みをテストとして表現することで、他社に相談する材料として使える
- デザインパターン
- リファクタリングという目標に対するツール/手段としてのデザインパターン
- デザインパターンとリファクタリング!
- デザインパターンの話、すっきりした
- リファクタリングをしていると自然にパターンになっていたりするかも
- 目的が分かったのであらためにデザインパターン勉強しようかな
- GOFのパターンがミッシング・リンクになっちゃっている
- デザインパターンは初学者の時に読んで途方に暮れたのを思い出した
- 本に乗っていない話
- 付録Cに書いていないことまだまだある
- 本に乗っていない話面白かった
- 本にかかれていないことを生で聞けてありがたかった
- 色々と聞けてよかった
- 最高の良さ
- 付録Cから読みはじめてよかった
- TDDの向き不向きはある
- テクニックの一つであって開発ツールではない
- ゴールに向けてだんだん見えてくる
- 共有することでの学び
- テストのメタデータについては考えたい