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

13.9.2 いつリファクタリングを行うかについての７つの戦略 内容 リファクタリングできるコードはかなり多いはずだ。基本的に触ることもないし、拡張する必要もないコードはリファクタリングしなくてもよい。ここでは何をいつリファクタリングすれば効果的なのかを判断するための７つの戦略を紹介。 戦略 説明 重要なコードがうまく保守されていないとき 明らかに主要機能で、今後も修正は見込まれるけど、複雑になりすぎている場合。まずはテストコードから追加しよう。 コードを理解している人がいなくなったとき いなくなる前に、関連コードを修正する場合は、そのキーパーソンがクリーンアップしよう。基本全員が扱える状態を目指そう。 新しい情報によって、より良い設計が見つかったとき 今の設計を改修するコストよりもメリットが大きい場合リファクタリングが選択肢となる。 バグを修正するとき テストがなかったからバグが発生したと考えることができる。テストを書いてついでにリファクタリングするとよいだろう。 新機能を追加するとき 安全に機能追加する方法は、まず機能追加できるようにリファクタリングしてから機能追加すること。 レガシーコードのドキュメントを書くとき 難解なコードを理解するためのドキュメントに起こすとき。製造中であれば設計を見直し、リファクタリングできるか検討しよう。 作り直すより安いとき 同じような開発プロセスで作り直す場合、高い確率で同じような技術的負債を産む。リファクタリングをプロセスに組み込む方が安くなるか検討しよう。 学び リファクタリングできるタイミングは意外と多い 学びを活かすアイディア・行動 何をいつリファクタリングできるか整理 リファクタリング内容と関連しているコードの整理

13.9 実践しよう 13.9.1 リファクタリングから価値を得るための７つの戦略 内容 リファクタリングから効果的に価値を得るための７つの戦略を紹介。 戦略 説明 既存のシステムを学ぶ わかりにくいところは全部反面教師。 小さく改良する メソッド、クラスの移動、名前変更はツールで安全にできる。これを先にやるとロジックの修正がしやすくなる。 レガシーコードをテストで改良する リファクタリングは後々の開発コストを減らすことができる。テストはリファクタリングを安全にサポートする。まずテストを書こう。 クリーンアップしながら進める 開発を進める中、常にリファクタリングは行おう。 詳細がわかったら実装を再設計する 既存の設計では実現が難しい場合や、明らかに既存設計より良い設計が出た場合、今後を見越して再設計実施を検討する。 進む前にクリーンアップする 動作確認したら次に進む前にかならずリファクタリングする。 やってはいけないことを学ぶリファクタリング リファクタリングには良い学びがある。間違いを認識し、良いプラクティスを積み上げよう。 学び これまでのまとめなので、特になし 学びを活かすアイディア・行動 現場メンバーへの展開

13.6 オープン・クローズドにリファクタリングする 内容 SOLID原則のOこと、オープン・クローズドの原則では、ソフトウェアは「拡張に対して開かれているが変更に対して閉じられている」べきだとしている。こうすると、新しい機能の追加は、新しいコードの追加と最小限の既存コード変更で済むようにする。 変更を加える際は常に2段階のプロセスで進める。 まず新しい機能に対応できるように、拡張したいコードをリファクタリングする。この時点ではまだ新しい機能は追加しない。リファクタリング中の間違いはテストが教えてくれる。 次に機能拡張ステップに入り、テストファーストでレッド・グリーン・リファクタリングを繰り返す。 この手順を混同して進めると混乱して間違えやすい。 13.7 リファクタリングで変更しやすさを確保する コードの変更しやすさを担保することは、正しい抽象化を見つけ、コードが適切にカプセル化されていることを意味する。 つまり、正しい抽象化とはなにかを理解し、それを見つけていき、カプセル化を理解し、カプセル化をしていくことが重要だ。 最終的に重要なのは「自分がモデル化しているものを理解してモデルへ組み込む」ことで、これが正確性と一貫性をもたらす。 プラクティスやTDDは、自分がやろうとしていることを明確にするためのサポートはしてくれるが、自分がやろうとしてくれることそのものをすべて生み出してくれるわけではない。 コードの変更しやすさが偶然生まれることはない。 13.8 2回めは適切にやる 正しい抽象化は、複数のふるまい・具体的な例を挙げることで、何が同じで何が違うかが浮かび上がり、そこから汎化することで見つけられる。 この作業は、具体例が多いほど精度が高くなり少なければ精度が低くなる可能性があることを意味する。プロジェクトが進むにつれて、具体例は見えてくる傾向にある。つまり、プロジェクト初期は精度の高い適切な設計が難しいことを意味している。 ソフトウェアの「柔らかい」特性を理解して、いつでもリファクタリングできるようにしておくことで、プロジェクトを進めながら設計の精度を上げることができる。 学び 修正する際はオープン・クローズドの原則を意識すること 修正は、拡張用のリファクタリング→機能追加の2段階プロセスを踏む。そのためには、どのように拡張するかをドラフト設計する。 プロジェクトを進めながら、リファクタリングしながら設計の精度をあげよう。 学びを活かすアイディア・行動 現場にプラクティスを展開する モデル化の学習 カプセル化の学習 正しい抽象化、カプセル化を理解することが重要 TDD実践記の展開

13.4 リファクタリングのテクニック 13.5 変化に対応するためのリファクタリング 内容 リファクタリングのテクニックを紹介するよ。 リファクタリングの手法はたくさんあるが、目的は顧客が変更したいものを変更しやすくすることだ。 それを前提に、標準的なやり方を示す規律を作り、直感的に行うのではなく、皆が共通認識を持ち安全に繰り返していくことが望ましい。 13.4.1 ピンニングテスト DIできるようになるまで（モジュールが分離できるようになるまで）、粒度の粗いテストを書いてコード変更できる準備をする。そしてコードをリファクタリングしてテストを再実行しながら少しずつ修正する。DIできるようになると、モックを使うことができるようになるので、モジュール単位で細かいユニットテストができるようになる。 13.4.2 依存性の注入 DIはモジュールを切り離すことができる。そしてモックを注入すればテストができ、モジュールの正しさは担保できる。そして切り離されていることで、そのモジュールに集中してテスト、リファクタリングができる。 13.4.3 ストラングラーパターン システムを停止せずにコンポーネントを変更する場合は、ストラングラーパターンを使う。古いサービスをラッピングする形で新しいサービスを作り、最終的に古いサービスがなくなるまでゆっくりと置き換えていくという考え方である。 リファクタリングに使える手法だ。 13.4.4 抽象化によるブランチ 「抽象化によるブランチ」は変更したいコードからインターフェイスを抽出して、新しい実装を書くというものだ。そして開発中はフラグで古い機能が動くように管理しておき、新しい実装ができたらフラグで新しい機能が動くように切り替える。 学び DIできる状態かどうかは重要な指標。まず粒度の粗いテストでそこを目指すとよい。 モジュールの種類別に役割を概ね決めておいて、リファクタリングの目標の像をある程度明確にする必要がある。 DIはリファクタリングの手助けをする。 アプリ配信の場合、どのように適用できるだろうか。 抽象化によるブランチというテクニックはフラグのスイッチングを前提に小さなリリースをしていくことに向いている。 リファクタリングの目的はソフトウェアが変更可能でありつづけることで、それを忘れてはいけない。 リファクタリングの手法は体系的で共通認識を持っていることが望ましい。 学びを活かすアイディア・行動 ピンニングテストが必要な箇所の洗い出し DIすべきポイントの洗い出し ストラングラーパターンを使ったリファクタリングの適用の検討 抽象化によるブランチを適用したら効果的にリファクタリングできる箇所がないか調査 毎日学習した内容の展開をする

13.3 コードの変更が必要なとき 13.3.1 既存コードへのテスト追加 13.3.2 良い習慣を身につけるために悪いコードをリファクタリングする 13.3.3 不可避なことを先送りする 内容 変更しづらいレガシーコードは地雷と例えることができる。そのままにしておかないと危ない。 しかし、そんな地雷コードでさえも変更する必要がない限り、そのままにしておけば価値を提供し続けられる。物理的な機械とは違ってまったく故障しないからだ。 ただし、変更、拡張、リファクタリングが必要になったとき、地雷撤去には大きなコストを生む。 ソフトウェアはリリースされれば新しいビジネスの方向性が見えてくる。どのレガシーコードがいつまでレガシーコードのままで良いかはわからない。だから、いつでも変更が簡単な状態を保つことが重要なのだ。 既存コードへのテスト追加は、既存コードをテストしやすいようにする。テストファースト開発で行うよりも難易度は高くなる場合があるが、変更コストの削減を見込める。 だから変更要求がある機能、あるいはそこに関連する機能については積極的にテストを追加した方がよい。 悪いコードのリファクタリングにはスキルアップの価値がある。 開発者全員がリファクタリングスキルを知っているわけではないが、これはソフトウェア開発において常に必要なスキルだ。 リファクタリングができるようになると、最初からクリーンなコードを書こうとするようになる（プレファクタリング）。 悪いコードをリファクタリングすることで「してはいけないこと」「代わりにすべきこと」がわかるようになる。 ソフトウェア開発者としての目標は、私たちが開発するソフトウェアが価値を創造し、未来でも価値を生み出し続けることだ。 しかし、ソフトウェアは実を結ばずに死ぬか、思った以上に長く生き残るかのどちらかだ。コードが将来どのような形になっていくのかを正確に予測することはできない。 ソフトウェアが価値を生み出し続けるためには、投資対効果をできる限り高くするのと同時に、コストを下げることも必要だ。 学び ビジネスが息が長くなるかどうはかはわからない。だから、エンジニアはいつでも変更が簡単な状態にコードを保つ必要がある。 早さのために保守性を失うのであれば、それは保守性を考慮したスキル、プラクティスが足りないからだ。本当に早い人は、きれいだからこそ早い。 変更要求がある場合、テスト追加するチャンスだし、テスト追加して今後の変更コストを削減した方がよい。 開発の学習の中にリファクタリングの工程を入れたほうがよい。TDDを教えることが、それにつながる。 ソフトウェアが価値を生み続けるために、ランニングコストは常に低くあれ。 学びを活かすアイディア・行動 テスト追加のタイミングの共有。 リファクタリング内容と関連モジュールの一覧作成 リファクタリング内容と関連モジュール一覧を作成し、メンバーに実施してもらうことで、リファクタリング力をアップさせる。

13.2 怠け者になる 内容 クレジットカード業界では全額決済し支払残を残さない人のことを「怠け者」と呼ぶ。 技術的負債と金銭的負債は似ている。たとえば17,000ドル借りていて、最低限の決済で返済した場合、93年と184,000ドルが必要になる。 技術的負債も、ときには問題を先送りにする必要があるかもしれないが、ほったらかしにしていると、思っている以上に技術的負債と付き合っていくことになる。 だれも完璧な仕事をすることはできないし、完璧など存在しないが、それでも納得しながら責任を持てるかたちでリリースしていかないと、結局どんどんきつくなる。 学び 技術的負債は気づけば大きくなる。ほったらかしにしていると、どんどんきつくなる。 学びを活かすアイディア・行動 レビューではアーキテクチャ通りになっているか、読みやすいコードになっているかをしっかり見る。

13.1 投資か負債か？ 内容 ソフトウェアを一度作ったら、もう、ほぼ作り直しは必要ないという考え方がある。ひと昔前、クラウドサービスが当たり前でない時代では、バグ修正の適用が今よりも難しかったので、確かにその要素が強かったかもしれない。 しかし、今は違う。多くのサービスはクラウド化しており、機能追加やバグ修正されたサービスはすぐに適用できる。世界の変化にソフトウェアが適用し続けることがしやすくなっているのだ。そんな中、世界が変わり続け、ソフトウェアが変わずにいると、いずれソフトウェアは価値を提供できなくなる。だから、ソフトウェアは時代に合わせて変更可能にしておくことが重要なのだ。 ソフトウェア開発にも先送りにしていい問題と悪い問題があるが、技術的負債はほとんどの場合、累積して対応が難しくなっていくため、早期に解決しながら進めていきたい。 たとえば、その観点で担当エンジニアを誰にするかを話すとき、保守フェーズに入ったからといって開発担当したエンジニアを簡単に変えることは一概に得策とは言えない。 学び ソフトウェア開発において、人は簡単に変えるべきではない。 人にとっても、その人の主観において、続けがいを感じる仕事でなければなければならない。 学びを活かすアイディア・行動 サービスにアサインしてもらう人の能力と動機のマトリクスを作り、担当割当のための設計をする。

13 プラクティス９ レガシーコードをリファクタリングする 内容 リファクタリングとは、外部へのふるまいを変更せずに、コードを再構築または再パッケージ化すること。 リファクタリングすることをマネージャーに伝えるときは、リファクタリングがビジネスにとってどう価値があるかを伝える必要がある。 リファクタリングは以下４つのコストを削減する。 あとからコードを理解する ユニットテストの追加 新しい機能の追加 さらにリファクタリングをする 納期を守るために、ときに雑な仕事をしてしまったものも出てくるだろう。そういうものはリファクタリングで修正する。 学び リファクタリングは、理解容易性、変更容易性を上げることができる。 コストを減らす観点で言うと以下のようになる。マネージャーと会話するため。 あとからコードを理解する。つまり、メンバー変更や担当変更がしやすくなる。 ユニットテストの追加。リファクタリングがさらに行いやすくなる。 新しい機能の追加。コードが整理されるので、拡張性を上げることができる。 どのリファクタリングをいつやるかという話をするときに、マネージャーと会話するための語彙が必要。 学びを活かすアイディア・行動 リファクタリングを実際にいつやるかのマネージャーとの会話

12.10 本章のふりかえり 内容 設計は最後にして意図を示すプログラミングをすることで複雑さを減らせる。 品質は作り出すものだ。保証はできない。 読みやすく理解しやすいコードが、柔軟で、変更しやすい（ゆえにコストパフォーマンスも高い） 意図を示すプログラミングは観点の凝集につながる。抽象のレベルがそろい、読みやすく、理解しやすくなる オブジェクトの生成と利用を分離することで、テスト容易性を改善し、依存性を下げよう 創発設計は初心者向きではない。品質とテスト容易性に不断の注意を払う必要がある 学び 創発設計は初心者向きではない！ペアでのフォローが必要だ。 学びを活かすアイディア・行動 現場のコーディング規約づくり

12.9.2 コードをクリーンにする７つの戦略 内容 コードをクリーンにする７つの戦略を紹介している。 戦略 説明 コードに語らせる 何をしているかわかる明確な名前をつけよう。不要なコメントも減るよ。 テストを足すために、接合部を作る ？ メソッドの凝集性を高める メソッドがやりすぎているから名前がつけづらくなる。小さく分けよう。 クラスの凝集性を高める クラスがいろいろやりすぎているから名前がつけづらくなるし、設計が理解しづらくなる。意味が明確に分かれているところは、分けよう。 判断を集約する ビジネスルールは集約させたほうが、理解しやすいよ ポリモーフィズムを導入する 条件パターンが増えそうなところはポリモーフィズムを使っておけば、そのクラスは変更しなくて済む。 生成をカプセル化する ポリモーフィズムを使っているクラスではインスタンスは生成させない。ファクトリーを使うかスタティックメソッドを使ってインスタンス化しよう。 学び メソッドもクラスも名前をわかりやすくつけて、ポリモーフィズムで条件を減らせば、コードはだいぶわかりやすい。そのためにはテストファーストで創発設計しながら適切な設計にしていこう。 学びを活かすアイディア・行動 現場のコーディング規約づくり