日報 as 読書の記録

Clean Coder

第4章 コーディング 「遅れ」 〜 第7章 受け入れテスト
6章の「練習」は特にメモは取っていないが軽んじているわけではない。
むしろ私は練習が足りなさすぎるのでその時間を設けなければならないなあと痛感した。
ところどころ「これはエンジニアではなくマネージャにも読んでもらった方がいいのではないか?」と思うような記述があるけど、
これはエンジニアが理解して、それをマネージャやQAなどチームメンバに伝えられるようにするのがプロなのだ、ということを暗に示しているのだろうか。

## 4
- 体調を整えること
- 集中しても没入 (フローゾーン)しない
- 遅れ: 最早終了日、通常の終了日、最遅終了日を求める、毎日更新する
    - "見積もりに願望を含めてはいけない"
- 「完了」を定義する
## 5
- TDD
    - 全てのコードが正常に動いていることを把握するため
- 勇気: テストによって修正後も正常に動いているか即座に把握できるので修正に踏み込みやすくなる
- ドキュメントとしてのテスト
- 設計: テストを先に書く -> テストできるように疎結合な設計になっていく
- 利点より害が大きくなるなら原則に背く
## 6
## 7
- 早すぎる詳細化
    - 開発中のシステムを見せるなどして新たな情報を得るたびにシステムの見方に影響がある
    - 最初に詳細化すると開発中のものと乖離していく
- 後期の曖昧性
    - 早すぎる詳細化を解決しようとすると浮上してくる課題
- 受入テスト: 要求の「完了」を定義する
- 要求定義と自動受入テストを繋げる
- "コミュニケーション・明確性・正確性" p.114
- 誰がいつ受入テストを書くのか
    - 理想: ステークホルダとQAが協力して書いて、開発者がレビューする
    - 現実: ステークホルダはビジネスアナリスト・QA・開発者に責任を委譲する
        - 開発者が書く場合は実装担当以外が書く
    - なるべく遅く書く方が良い (スプリント、イテレーションに上がった時)
    - 実装が始まるまでに準備をする、準備ができてから実装を始める
- ユニットテストも受入テストもテストではない
    - "第一にドキュメントであり、第二にテストなのだ" p.119
    -  システムの構造や振る舞いを定式的に文書化する

知的創造企業

485 〜 664
そういえばこれスクラムの原点となってる論文書いた方々が著者なのだね (The New New Product Development Game)