作られてから増改築を繰り返し、老朽化した情報システムを刷新するための心得集。具体的なノウハウが多く、気付きが多かったです。ただ、この本が想定しているのはJavaで書かれた築10～20年の情報システムのようなのですが、僕が相手しているのは築40年のCOBOLなんだよなぁ。。
↑気になったらここからポチっと（買ってくれるとお小遣いが入ります）↑
↓気になったらここからポチっと（買ってくれるとお小遣いが入ります）↓
↑気になったらここからポチっと（買ってくれるとお小遣いが入ります）↑
この本を読むとわかること
何かが間違っている
- 過去に作られたドキュメントもなく変数名も適当なプログラムを読み解かなければならない「ソフトウェア考古学」
- 改修によるコメントとコードの乖離という二次被害
- 過去に作られ、自動テストなどによって挙動が保証されていないプログラムが「レガシーコード（過去の遺産のプログラム）」
- 統合フェーズで多く見つかるソフトウェアのバグ
- 「開発とテストの分離」という現状の開発プロセスの問題点
- 「未知を見積もる」というソフトウェア開発固有の難しさ
CHAOSレポート再考
- プロジェクトの成功率・失敗率が記載された米国スタンディッシュグループのCHAOSレポート
- ソフトウェア開発プロジェクトの成功率はわずか1/3
- CHAOSレポートの誤り
- プロジェクトの成功を阻害するコードの変更・バグの習性・複雑さ
- 開発コストの80％が投下される「バグの特定と修正」
- 失敗したソフトウェア開発プロジェクトの被害額は年間500億から800億ドル
- ソフトウェア開発の4倍かかるソフトウェアの保守コスト
賢人による新しいアイデア
- 余計なプロセスを取り除いた「アジャイルソフトウェア開発プロセス」の登場
- 顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供するという思想
- 品質を保証するためのテストに比重を置くのではなく、開発者が品質の高いプログラムを書けるようにするという発想の転換
- スコープ（開発範囲）を小さなタイムボックス（開発期間）に収めるかがアジャイルのポイント
9つのプラクティス
- 「一度作ったらそれでおしまい」の結果生まれたレガシーコード
- その後の変更も見越したコード自体の品質が重要
- プログラマーがコードを書く速さとコードのきれいさは比例
- 「クラス（処理単位）を変更する理由は1つでなければならない」というソフトウェア開発における第一原理
- ソフトウェアの品質は外部指標ではなくコード自体の内部品質で評価
プラクティス1：やり方より先に目的、理由、誰のためかを伝える
- プログラマーには伝えるのは作るプログラムの目的
- 開発を円滑に進めるのはコミュニケーションと会話
- 開発を取り仕切るプロダクトオーナーの7つの心得
プラクティス2：小さなバッチで作る
- 分析・設計・コーディング・テスト・デプロイを長い期間でバラバラに行わず、機能単位に短期間で実施
- タスクを小さくて扱いやすいものにする「スコープボックス」
- 人を増やしても生産性は上がらないソフトウェア開発
- 開発期間が長くなるほど全体の効率は低下
- 小さなバッチにすべき4つの理由
- バックログ（要件）は優先順位をつけるのではなく並べ替え
- レガシーコードになる「なんちゃってオブジェクト指向」
- トヨタ生産方式を取り入れたアジャイル開発における「カンバン」
プラクティス3：継続的に統合する
- プログラムができ次第順次統合する「継続的インテグレーション」
- 新たなコードが追加されたら全体を自動でリビルド（統合）
- 自動テスト可能なコードを記述
プラクティス4：協力しあう
- 部屋を仕切らずコミュニケートしやすい大部屋にするのがベスト
- ソフトウェア開発は技術的かつ社会的な活動
- 生産性とコードの品質を向上させるペアプログラミング
プラクティス5：「CLEAN」なコードを作る
- Cohesive（凝集性）・Loosely coupled（疎結合）・Encapsulated（カプセル化）・Assertive（断定的）・Nonredundant（非冗長）なコードがベスト
- CLEANではないコードの見抜き方
プラクティス6：まずテストを書く
- コードのふるまいを検証するのではなく、ふるまいを定義する「テスト駆動開発」
- 品質の高いユニットテスト（プログラム単体のテスト）をくぐり抜けたプログラムを結合することで全体の品質も向上
- コードの仕様・ふるまいを表すものとしてテストケースを先に記述
- ソフトウェアの機能（外部仕様）を保ったまま内部構造を改善する「リファクタリング」
プラクティス7：テストでふるまいを明示する
- 特定のパラメーターでコードを実行するテストは具体的な要件そのもの
- テスト自動化ツールJUnitを使ったテスト駆動型開発の実例
- その後の改修で誤ったコードを書くと自動テストがエラーとなり検知可能
- プログラムの仕様・品質を自動テストによって担保可能
- プログラムが複雑化するほどテストケースの数が増加
- CLEANでないプログラムをテストケース数から検知可能
- テストケースを減らすためにコードもきれいになる副次効果
- コードを網羅するテストが書かれることでバグも抑制
プラクティス8：設計は最後に行う
- コーディングとコードのクリーニングを分けて実施
- 書かれる回数の10倍読まれるプログラムコード
- コード自体の品質（理解しやすさ・改修しやすさ）が重要
- コードを複雑化させる条件分岐・繰り返しをどれだけシンプルにわかりやすく表現できるかがプログラマーの腕
- オブジェクト志向言語における「ポリモーフィズム」を活用したコード品質の向上
- オブジェクトの生成と利用の分離
- コードをきれいにする7つの戦略
プラクティス9：レガシーコードをリファクタリングする
- 作られた直後から陳腐化・劣化が進むプログラムコード
- ブラックボックス化し、怖くて誰も触れないシステムという「技術的負債」
- レガシーコードという地雷
- プログラムのふるまいを変えずに設計を変えるのが「リファクタリング」
- いつリファクタリングするのかの7つの戦略
レガシーコードからの学び
- 機能しているウォーターフォール開発に無理矢理アジャイルを入れる必要はない
- ウォーターフォールとアジャイルを同居させる方法
- テスト駆動型開発は生産性・品質を大きく上げる
↓気になったらここからポチっと（買ってくれるとお小遣いが入ります）↓
