Month: January 2021

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

12.9 実践しよう 12.9.1 創発設計をマスターする７つの戦略 内容 創発設計のための効果的な戦略を７つ紹介。 戦略 説明 オブジェクト指向を理解する オブジェクト指向言語を使っているからと言って、オブジェクト指向を理解していると思うな。うまくカプセル化したエンティティを作り、解決する問題を正確にモデル化すべし。 デザインパターンを理解する デザインパターンはふるまいを分離するのに有効。創発設計の中でパターンが明らかになってくる。 テスト駆動開発を理解する テスト駆動開発は、修正した際のセーフティネットであり、創発設計をサポートする。 リファクタリングを理解する リファクタリングは創発設計に大きく関係している。コードを整理していく中でパターンが見つけられるためだ。 コードの品質にフォーカスする コードは「CLEAN」（高凝集、疎結合、カプセル化、断定的、非冗長）に保たなければ、すぐに保守不可能になる。 情けはかけない 必要に応じて設計を変える勇気を持て。思い入れた設計を捨てる勇気を持て。 良い開発プラクティスを習慣にする スクラム、XPのようなアジャイルプラクティスは、創発設計をサポートする有効なツールだ。が、アジャイルプラクティスが設計してくれるわけではない。良い設計は、プラクティスの背景にある原則を理解した上でプラクティスのサポートを受けるべきだ。 学び 12章の総集編 学びを活かすアイディア・行動 テストコードの目的の事前知識整理 コーディング規約づくり

12.7 生成と利用を分離する 内容 生成と利用を分離することで、利用する側のコンポーネントが独立し、テストをしやすくなる。 オブジェクト指向言語では、オブジェクトを生成してからオブジェクトを利用する。生成のみ行うオブジェクト群と利用のみ行うオブジェクト群に分け、生成と利用のフェーズを分けることには意味がある。 ファクトリーオブジェクト生成するオブジェクトをファクトリーと呼び、newをカプセル化する。 ポリモーフィズム利用するオブジェクトは、ポリモーフィズムというテクニックを使って、実装の中身を意識せず、目的の得たい結果だけを意識して利用する。インターフェースだけに依存しインターフェースを実装した具体的なサブクラスとの依存を切り離すテクニック。これにより、インターフェースを実装したサブクラスに依存しない独立したコンポーネントにすることができる。サブクラスとの依存がなくなると、インターフェースのモックを用意すればよいだけになりテストがしやすくなる。（さまざまなサブクラスを考慮したテストにならなくて済む。） 学び 生成と利用を分離することで、利用する側のコンポーネントが独立し、テストをしやすくなる。 このあたりってモジュールのあり方を考えるための設計原則が関係していて、デザインパターンの理解のために必要な知識だと思う。完全に理解した状態からチョットワカル状態になっていくための必要な考え方だなぁとフと思った。 学びを活かすアイディア・行動 現場のコーディング規約づくり。どのクラス群が生成を担い、どのクラス群が利用を担うのか。