Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

第17章 多国通貨の全体ふりかえり #21

Merged
merged 1 commit into from
Nov 12, 2017
Merged

Conversation

at-grandpa
Copy link
Owner

@at-grandpa at-grandpa commented Nov 11, 2017

下記を振り返る。

  • ここから先はどうなるか
  • メタファー:設計の構造に与える劇的な効果について
  • JUnitの使用状況:いつ、どのように使っていたか
  • コードメトリクス:出来上がったコードをさまざまな角度から計測してみる
  • プロセス:レッド・グリーン・リファクタリングと言ったが、それぞれどれくらい作業しているか
  • テスト品質:TDDののテストは従来の指標から見てどうなるか

@at-grandpa
Copy link
Owner Author

ここからは、メモや写経というよりは、自分の思ったことや考えたことのを書く。

@at-grandpa
Copy link
Owner Author

at-grandpa commented Nov 11, 2017

ここから先はどうなるのか

  • あまり触らない箇所でも、TDDを用いれば自信を持って取り組める
    • 確かにそうかもしれないけど、なぜやろうとしないのか
    • リポジトリがテスト環境にあまりふさわしくない
    • ぐるぐるまわる環境じゃない
    • だけど、そう思ってるだけかもしれない
    • テストで保護する、というのはやってよいかも
  • コードを批判的に見る
    • 「これって大丈夫なんだっけ?」的なアプローチかな
  • テストは足りているか?
    • 「こう動いてはならない」というテストを足してみる、など
    • レッドにしてみる話かな
    • やばかったらTODOリストに足そう
  • そもそも、TODOリストはなぜ今使っていない?
    • 使ったほうが良さそうな気がする
    • 煮詰まったときとかは良いかも?
  • 設計の見直し時期
    • 長く残っている重複がある
    • TODOリストが空になる

具体例を思い浮かべないと仕事とリンクしないけど、とりあえず今はこんな感じ。

@at-grandpa
Copy link
Owner Author

メタファー

  • 設計が途中でガラッと変わったことに驚き
  • 本書の執筆途中で「式(Expression)」のメタファーを思いついたらしい
  • メタファー強力
  • 「これまでよりずっときれいなコードが出来上がった」、ほほー、まだこれが綺麗だとわからん
    • なんでこれが綺麗なんだっけ?

なんできれいなコードになったのか。きれいなコードとはなんなのか。その二つの言語化をしたい。

@at-grandpa
Copy link
Owner Author

JUnitの使用状況

  • 「実は多国通貨のサンプルを通して JUnit の実行ログを記録していた。」
    • なんと!おもしろい!
  • 予想しないレッドは、リファクタリングを急いでいた時らしい
    • 急ぐのが悪ではない
    • それをレッドで気づけたのは良いこと

まぁ、これは粒度にもよるし、本人のコーディングスタイルにもよる。

@at-grandpa
Copy link
Owner Author

at-grandpa commented Nov 11, 2017

コードメトリクス

  • テストコードとプロダクトコードのメソッド数や行数は近い
  • 条件分岐のためにポリモーフィズムを使っているので、複雑度が1に近い

まぁ、データとして。

ポリオーフィズムなどのテクニックは、言語化しておきたいなぁ。なんとなくでしかわかってないし。

@at-grandpa
Copy link
Owner Author

プロセス

  • TDDのサイクルは以下
    • 小さいテストを追加する
    • 全てのテストを動かし、失敗があることを確認する
    • 変更を行う
    • 再び全てのテストを動かし、全て成功することを確認する
    • リファクタリングを行い、重複を排除する
  • リファクタリングの変更量は、ファットテール型

サイクルの復習。

@at-grandpa
Copy link
Owner Author

テスト品質

  • TDDのテストは、開発をする際には有用
  • しかし、以下のテストを代替するものではない
    • パフォーマンステスト
    • 負荷テスト
    • ユーザービリティテスト
  • テスト評価方法
    • ステートメントカバレッジ
      • 十分な指標にはならないが、スタート地点にはなる
      • TDDに厳格に従うなら、カバレッジは100%になる
    • 欠陥挿入
      • 「プロダクトコードの意味合いを変えたら、テストは失敗しなければならない」という考え方
      • ミューテーションテストのことだな
  • カバレッジを上げる方法
    • テストを増やす
    • プロダクトコードのロジックを減らす
      • この発想はなかった

この辺は新しい視点を得られた。

@at-grandpa
Copy link
Owner Author

最後の振り返り

  • TDDを教えていて驚く3つのこと
    • テストを綺麗に機能させる3つのアプローチ。仮実装、三角測量、明白な実装。
    • テストとコードの間の重複除去が、設計を駆動する
    • テストの間のギャップを制御する能力。路面が滑りやすいならグリップを増し、路面が良いなら寄り速く

「重複除去によって設計が駆動する」というイメージは、まだ掴めていないので考える必要がある。歩幅の話はわかってきたが、ちゃんと言語化したい。

@at-grandpa at-grandpa merged commit c06e34f into master Nov 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants