登壇者
- 吉羽 龍太郎 氏
- アトラクタ
- 取締役CTO
レガシーコードからの脱却
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者:David Scott Bernstein
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/09/19
- メディア: 単行本（ソフトカバー）
- ITエンジニア本大賞2020（技術書部門）で受賞！
- 「レガシーコード」というワードをタイトルにつけると書籍は売れるらしいw
レガシーコードとは
- レガシーコードとは？
- 綺麗なコードは有用だが、テストがなければレガシーだ
- 保守または拡張が困難なコード
- 定義は様々
- 議論の時はまず共通認識をとるのが大事
- 理由は問わず、修正・拡張が難しいコード
- 使われるソフトウェアには変更が必要になる
- ほぼ80%の開発コストを障害の特定や修正のために使われている
- 原因は急ぎすぎている、たくさん作ろうとしている、読みやすさより書きやすさを優先している
- つまり品質を犠牲にしている
- 品質は検査ではよくならない、最後にテストしても仕方ない
- やるべきことは問題を作り込まないこと、つまりレガシーコードを作らない
- ではどうしたらいいか -> 開発プロセスに着目する
- ソフトウェアを生み出す成果を決める要素
- 問題設定力
- 開発力
- チーム力（組織力）
- コードだけ綺麗に書いたり、開発プロセスだけちゃんとやっていればよいわけではない
- レガシーコードを最初から作らないようにするには、具体的にはどうすれば？
- レガシーコードを作らない9つのプラクティス
- やり方より先に目的・理由・誰のためかを伝える
- 小さなバッチ（単位）で作る
- 継続的に統合する
- お互い協力し合う
- CLEANコードを作る
- まずテストを書く
- テストでふるまいを例示する
- 設計は最後に行う
- レガシーコードをリファクタリングする
ScrumとXPからプラクティスが抽出されている。
やり方より先に目的・理由・誰のためかを伝える
- 役割の違い
- プロダクトオーナーの責任
- 開発チームの責任
- WhatとHowを分断する
- 何を欲しいか、なぜ欲しいか（What）は顧客やPOの領域
- やり方（How）は開発チームの役割
- 物事のやり方は1つではなく、やり方ごとにトレードオフがある
- やり方を命じされると代替案が出せなくなる
- 結果として手続き的なコードになりがち（結果的にオブジェクト指向にならない）
- 双方が創造的に協調することで無駄が減る
- 作る上で重要なのはコンテキストを共有すること
- ユーザーストーリー
- 何が・何のために・誰のために存在するかを1文で示したもの
- 機能について会話できるくらいの辛うじて十分なドキュメント（仕様書じゃない
- 知識はドキィメントではなく、コード（テストも含）にまとめるべき
- ストーリーが限定的でテスト可能になる（受け入れ基準と自動化）
- シンプルにまとめて追加はあとで行う
- ちょっとずつ進めることで良い設計が浮かび上がってくる
小さなバッチで作る
- 鉄の三角形（Quality, Cost, Deliverly, Scope）
- 同時に守れるのは2つまでと言われる
- Qは落とすべきではない
- QCDSの何を調整するか
- Q（品質）を下げると、あとで何倍もの時間を使うことがある
- C（コスト）を調整するとは、すなわち人を増やすことにつながる
- ただし人を増やしても、オーバーヘッドがあるのでリニアにスケールしない
- D（時間）を調整してもよいが、多くのビジネスは時間が重要
- つまり一番調整すべきなのは「スコープ」
- およそ半分の機能はほとんど使われていない
- スコープを調整して価値（大事）のあるものが順に進める
- タイムボックスによるアプローチ
- 固定の期間の中でタスクに取り組む
- ex.) 1 week
- タスクの分割になれるまでは機能しやすい
- ScrumやXPのやり方
- 固定の期間の中でタスクに取り組む
- 長い期間で大きなウソをつくのではなく、短いイテレーションで小さなウソをつく
- 同じリズムを刻むことで負担を少なくして、異常に気づく
- 日々の仕事も同じ
- リソース効率とプロセス効率
- 1サイクルのリズムが長くなると、リソース効率化を目指しやすい
- 並行タスク・役割分担・フェーズが増える
- 1サイクルのリズムを短くすると、プロセス効率が上がる
- モブプロ＝究極の1個流し
- いくら人を働かせても、完成しているものが0なら、ビジネス価値はない
- 難しそうなバックログはモブで、など結構モブを使っている現場は増えている
- 1サイクルのリズムが長くなると、リソース効率化を目指しやすい
- ソフトウェアの評価
- ソフトウェアの評価は顧客にとっての価値
- 価値は完成してはじめて価値になる
- 部分最適化を避ける
- 効率より効果を重視
- ソフトウェアの評価は顧客にとっての価値
- フィードバックサイクル
- 小さなバッチの方がフィードバックの回数は増える
- スプリントレビュー、レトロスペクティブ...
- 顧客やPOと同席することでフィードバックの回数を増やす
- そのためにビルドの高速化も大事
- フィードバックへの対応をサポートする文化が必要
- 価値やリスクに応じて取捨選択する
- 小さなバッチの方がフィードバックの回数は増える
フィードバックによって価値を高めていく
CLEANコードを作る
- 品質は検査では上がらない
- よくないコードの特徴
- 重複コード、長すぎるコード、巨大なクラス、長すぎるパラメーターリスト...
- よくない例をあげるとキリがないので、模範になるパターンを覚える
- CLEANコードとは？
- Cohesive (凝集性)
- それぞれの部品は1つのことだけ扱い、1つに集中する
- 理解もバグも見つけるのが簡単
- Loosely Coupled (疎結合)
- オブジェクト間の関係を明確な意図を持った状態に保つ
- テストや再利用、拡張が簡単
- Encapsulated (カプセル化)
- 何をやっているかに名前をつけて、どう動くかは隠す
- あとから変更するのが簡単
- Assertive (断定的)
- 好奇心旺盛を避ける
- Non redundant (非冗長)
- 同じことを繰り返さない（DRY原則）
- バグ修正・変更は1箇所で1回だけすればよい
- Cohesive (凝集性)
- よいソフトウェアの土台となる5つのこと
- これらを意識するとテストしやすくなる
- CLEANとテストでバグ発見の時期をシフトレフトする
- 設計の段階でバグを見つければ5分で修正できる
- テストの段階だと修正に1日、、、本番リリース後だと数日、、、
- そうならないようになるべく早期からテスト可能な状態にする
- 明日のベロシティのために、今日品質を上げる
- 速度は日々の積み重ねでしか早くならない
- CLEANコードは理解しやすく取り組みやすい
- 結果として総所有コストが下がる、逆の状態が技術的負債
- すばやく働くということは「きれいに働く」ということ
- これって"5S"だった
- 整理、整頓、清掃、清潔、躾
レガシーコードからの脱却まとめ
- 使われるソフトウェアは変更が必要になるので、コードは変更可能になるように書くべき
- プロダクトオーナーは、目的、必要な理由、誰のためのものかが伝わるようにする
- 要求は意味のある小さな単位にして重要なものから作る
- 開発チームは小さなバッチで作っていく、作るときはPOと協力する
- コードはTDDで書く、テストはふるまいを例示、テストも含めてCLEANを満たすように作る
- できあがったものは1つずつ統合していき、常にデプロイ可能な状態にする
- 1度作ったら終わりではなく、必要に応じて設計やコードを見直す、良い設計は創発する、子のときテストがあることが重要
今日伝えたかった最重要なこと
「他にも本には色々書いてあるので買ってね」
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者:David Scott Bernstein
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/09/19
- メディア: 単行本（ソフトカバー）
あわせて読みたい
