レガシーコードからの脱却
ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
David Scott Bernstein 著
吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳
オライリー・ジャパン 2019年
https://www.oreilly.co.jp/books/9784873118864/
第Ⅱ部 ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
13章 プラクティス9 レガシーコードをリファクタリングする
14章 レガシーコードからの学び
を読んだメモ
プラクティス9 レガシーコードをリファクタリングする
もしかしたらあったかもしれない会話
エンジニア「リファクタリングがしたいです。」
マネージャー「いいね！ それで、どんな機能が増えるの？」
ビジネスにとっての意味
ソフトウェアは資産であり保守が必要。
保守のコストを低減させるためのリファクタリング。
変更要求が来るのは顧客にとって価値がある証拠。
→素早く、低リスクで変更要求に応えることで顧客に価値を提供する。
技術的負債
技術的負債は変更のたびに累積していく。
できるだけ早く返済するのが正しい選択。
金銭的負債と同じ。利子が付くので返済できるならすぐする。
技術的負債とビジネスのトレードオフ
完璧なコードを作ることはできない。
コードに問題があっても出荷することもある。
技術的負債は必要悪。許容しないと仕事が成り立たないが、過剰でも成り立たない。
どこをリファクタリングするか？
レガシーコードも(変更する必要がない限り)価値を生み出せる。
レガシーコードは地雷。必要がなければそのままにしておく。
**「変更が必要なコード」**をリファクタリングする。
リファクタリングで良い習慣を身に着ける
保守可能なコードを書く訓練の場。
リファクタリングをしていると、最初から保守可能なコードを書くようになる。
リファクタリングのテクニック
1. ピンニングテスト
全体的なふるまいに対するテスト。
粒度は非常に粗いが、まずは小さく始めることが必要。
2. 依存性の注入
ソフトウェアをテスト可能にするための方法。
インターフェースクラスを使用したりなど、オブジェクト指向的な実装にする。
3. ストラングラーパターン
少しずつサービスを置き換えていくやり方。
Strangler Fig(絞め殺しの木)の比喩。
4. 抽象化によるブランチ
バージョン管理からブランチをなくすためのテクニック。
※フィーチャーブランチの統合がリスクになる。
開発中の機能はフィーチャーフラグで隠す。
オープン・クローズドの原則
新しい機能の追加は新しいコードの追加と最小限の既存コード変更で済むようにする。
拡張対象の既存コードのリファクタリング
↓
コードを追加(テストファーストで！)
↓
追加したコードのリファクタリング
※一度にいろいろやるとかえって間違えやすい。
レガシーコードからの学び
技術を大切に
開発者は多くの時間をコーディング以外に費やしている。
テストは欠かすことのできないコードであり、テスト駆動開発により開発者はコーディングに集中できる。
しかし、アジャイルとスクラムはマネジメントプラクティスに変わってしまい、技術的なプラクティスにそれほど重きを置かなくなってしまった。
間違いと付き合う
私たちは人間なので小さな間違いをたくさん犯す。
バグの検出がQAプロセスまで先送りになると、コードを思い出すのに時間がかかる。
→テストを自動化して早くバグを見つける方がムダが少ない。
品質は作り込むのが基本
品質を保証するだけでなく、良いプラクティスで品質を作り出す。
従来型開発でオーバーヘッドになっていた時間を取り戻し、コードを「CLEAN」にして品質を作り込む。
※QAが不要というわけではない。
教条主義に陥らない
ソフトウェア開発には万能のやり方はない。
オブジェクト指向、テスト駆動開発、アジャイル...これらはツールにすぎない。
私たちはソフトウェア開発者だ。現在利用可能なツールを最大限に活用して、ソフトウェアを開発している。
視野を一つ拡げる
ソフトウェアはビジネスを動かす中心にある。
一方、私たちはドメインを正確に理解しモデル化する方法をトレーニングされてこなかった。
一歩下がって自分たちが何をしているのか考えてみる。
自分たちが何を、どのように、なぜやっているかを考えるほどより良い仕事ができる。