レガシーコードからの脱却

Info

• title: レガシーコードからの脱却
• author: DavitScottBernstein
• published date: 2019-09-17
• started reading on: 2022-04-02
• finished reading on: 2022-05-14

Notes

失敗のコスト

• ソフトウェアの障害にかかるコストは、アメリカで毎年600億ドル
• ソフトウェアにかかるコストの8割は最初のリリース後にかかる

9つのプラクティス

単一責務の法則

• クラスを変更する理由は一つでなければならない
• オープン・クローズドの法則
  • ソフトウェアのエンティティは
  • 拡張に対してオープンで
  • 変更に対して閉じていなければならない

9つのプラクティス

1. やり方より先に目的、理由、誰のためにを伝える

2. 小さなバッチで対応する

• 理想的なタスクサイズは4時間で終わるもの

7つの計測方法

• 価値実現までの時間
• コーディングにかかった時間
• 欠陥密度（コード1000行あたりのバグの数
• 欠陥検出までの時間
• 機能ごとの顧客価値
  • 価値の高い項目により多くの時間を割けるようになる
• 機能を提供しない場合のコスト
  • 「その機能がなかった場合にかかるコスト」
• フィードバックグループの効率

3. 継続的に統合する

4. 協力し合う

• ペアプログラミング
  • チームで一貫したコーディングスタイルを保つ
    • 誰が書いたか分からないくらいの統一感が理想
  • ペアプロによって失われる時間は15%程度
• スパイク
  • 使う時間を予め設定し
  • 未知の問題に対してその解決のために何をするべきかを探る
• スウォーム
  • 「先に進めないような障害」に対して
  • 複数メンバーで同一の課題に取り組む
• モブ
  • チーム全体が一緒になって
  • 単一のストーリーに取り組む

5. 「CREAN」なコードを作る

• Cohesive（凝集性）
• Loosely Coupled（疎結合）
• Encapsulated（カプセル化）
• Assertive（断定的）
• Noredundant（非冗長）

6. まずテストを書く

7. テストでふるまいを明示する

• 良いテスト基準 ＝ 既知の理由で失敗すること
• テストは一意であること
• バグを再現するようなテストを書く
• 実装ではなくふるまいをテストする

8. 設計は最後に行う

9. レガシーコードをリファクタリングする

Tags

#Software #Book