CleanCoder

imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。

Clean Coder プロフェッショナルプログラマへの道

開発者にコードを「はやく」書かせる方法

1. アプリはシンプルだと開発者に伝える。
2. 機能を追加する。
3. 納期を延ばす。何度も何度も。

約束できること

• 自分の行動
• 目標に近づく行動
• 期限(変更があればすぐに伝える)

TDDの３原則

1. 失敗するユニットテストを書くまでプロダクションコードを書いてはならない
2. テストを失敗させる目的以外でユニットテストを書いてはならない
3. 失敗しているユニットテストが成功するまで他のプロダクションコードを書いてはならない

TDDの利点

• 確実性

  テストが成功すれば、出荷できる程度の確信が持てる
  

• 欠陥混入率

  大幅に低下する
  

• 勇気

  テストがあれば
  → 変更が怖くない
  → クリーンなコードにできる
  → クリーンなコードは理解しやすい
  → 変更が怖くない
  

• ドキュメント

  TDDの３原則に沿って書いたユニットテストは、システムの使い方を説明したサンプルコードになっている
  

• 設計

  他の関数を呼び出している関数をテストするのは難しい
  → その関数を他から切り離す方法を考える
  → うまく疎結合した設計になる
  

型

プログラミングの問題を解くためのキーボードやマウスの動きの練習。

脳や指に動きや反応を覚えさせるために何度も練習する。

CodeKata

受け入れテスト

• 要求の完了を定義するテスト。

  完了とは、すべてのコードを書き終え、すべてのテストが成功し、QAと関係者が受け入れたもの
  

• 完了を確認する自動テストを作成し、これらがすべて成功すれば、完了とする。

  ビジネスアナリスト(上流設計者)が正常系のテストを書く。
  QA(品質管理者)が異常系のテストを書く。
  

• 「後期の詳細化」の原則に従い、受け入れテストはできるだけ遅く書く。

  機能を実装する数日前(直前)にその機能のテストを書く。
  

• 受け入れテストは仕様の文書化が本来の目的。

  受け入れテストやユニットテストは、第一にドキュメントであり、第二にテストである。
  受け入れテストは、ビジネスの観点からシステムの動作を定式化した要求文書である。
  ユニットテストは、コードの構造や振る舞いを定式化した設計文書である。
  

テスト自動化ピラミッド

テストの種類	内容	継続的インテグレーション	自動化	頻度	網羅率
ユニットテスト	コードの網羅テスト	実行する	自動	ビルド毎	100%
コンポーネントテスト	機能の受け入れテスト	実行する	自動	ビルド毎	50%
インテグレーションテスト	機能の組合せテスト	実行しない	自動	定期的	20%
システムテスト	システム全体のテスト	実行しない	自動	定期的	10%
手動探索テスト	意図しない振る舞いの確認	実行しない	手動	必要なとき	5%

コミットメントと見積もり

コミットメントとは、達成しなければいけないものである。

コミットメントすれば、その日までに成し遂げなければならない。
自分ができるとわかるまでコミットメントしない。

見積もりは予測である。

コミットメントでも約束でもない。
見積もりが外れても恥じることはない。
どれだけ時間がかかるかわからないから見積もりをする。

暗黙的なコミットメントをしないように気をつける。

3点見積もり

• O：楽観値
• N：標準値
• P：悲観値

ソフトウェア徒弟制度

• マスター 10年程度
• ジャーニーマン 5年程度
• アプレンティス 1年以上

ツール

git
IntelliJ
Pivotal Tracker 
Jenkins 
CppUTest 
コンポーネントテストツール