kiyoshi.saito@tttsunagari.jp

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

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

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

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

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

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

12.6 循環複雑度を減らす 内容 循環複雑度はコードの実行経路の数。 条件分岐がなければ、循環複雑度は１。条件分岐が１つの場合、異なる２つの経路があるので循環複雑度は２。２つの場合は４、３つの場合は８。。。 循環複雑度は幾何級数的に大きくなる。大きければ大きいほど条件パターンが増え、注意が行き届かなくなる場合があり、バグの発生率が高くなる。 なので少ないに越したことはない。 しかし、常に１にすることはできない。条件分岐を使わないことは実質ありえないからだ。循環複雑度を減らすテクニックとして、インスタンスの生成やメソッドの利用にポリモーフィズムを使う。そうすることで、プログラム上の条件分岐がなくなる。 学び 循環複雑度はバグの原因になるからなるべく減らそう。ポリモーフィズムを使っても減らすことができる。 循環複雑度は常に１にはできないよ。 学びを活かすアイディア・行動 現場のコーディング規約づくり。

12.5 意図によるプログラミング 内容 API、メソッド、サービスなどを外部に公開するとき、メソッドの中に実装を入れることはしない。実装は別のメソッドに移譲する。こうすれば、コードが読みやすくなる。 このテクニックを「意図によるプログラミング」と呼んでいる。（へー、そうなんだ） なぜ読みやすくなるのか？抽象レベルと具象レベルで観点が切り分けられ、観点に一貫性が出るから。抽象レベルでは「目的」を、具象レベルでは「やり方」を見ることができる。 抽象レベルを読み進めることで、プログラムの大枠の文脈を読むことができる。必要に応じて具象レベルの具体的な方法を読めば良い。 12.6 循環複雑度を減らす 循環複雑度はコードの実行経路の数。 条件分岐がなければ、循環複雑度は１。条件分岐が１つの場合、異なる２つの経路があるので循環複雑度は２。２つの場合は４、３つの場合は８。。。 循環複雑度は幾何級数的に大きくなる。大きければ大きいほど条件パターンが増え、注意が行き届かなくなる場合があり、バグの発生率が高くなる。 なので少ないに越したことはない。 しかし、常に１にすることはできない。条件分岐を使わないことは実質ありえないからだ。循環複雑度を減らすテクニックとして、インスタンスの生成やメソッドの利用にポリモーフィズムを使う。そうすることで、プログラム上の条件分岐がなくなる。 学び パブリックにするものは抽象レベルで定義すると、大きな文脈で読むことができるプログラムになりやすい。 「意図によるプログラミング」というワードでググってもわかりやすい情報は出てこない。。 循環複雑度はバグの原因になるからなるべく減らそう。ポリモーフィズムを使っても減らすことができる。 循環複雑度は常に１にはできないよ。 学びを活かすアイディア・行動 現場のコーディング規約づくり。抽象レベルの切り分けルール。 現場のコーディング規約づくり。

12.3 コーディング対クリーニング 内容 コーディング・・・特定のタスクの解決方法を探す作業。テストを通すことに集中する。 クリーニング・・・動くコードを保守可能にする作業。扱いやすくすることに集中する。 それぞれ、別のタスクとして捉えて進めたほうが効率が良い。 技術的負債は短期的にも長期的にも返済を続ること。短期的には、テストファースト開発のリファクタリングステップにて。長期的には、チームの学習をコードに取り込むための定期的なリファクタリング作業の中で。 それでも技術的負債が溜まり続けてしまう場合もある。新しい機能を実装するために設計変更が必要だったり、単にもっと良いやり方を思いついたりする場合だ。その場合、通常数か月ごとに、大規模なリファクタリングを行い、技術的負債の返済作業を行う。この場合でも、ユニットテストが助けとなる。 12.4 ソフトウェアは書かれる回数より読まれる回数のほうが多い 平均してコードは書かれる回数の１０倍読まれる。効率性、拡張性のために読みやすくなければならない。コードは自分のためではなく読み手のために書け。 コメントの注意点１わかりやすくするためにコメントを書くことがある。注意点として、コードが「そうなっている理由」を書くのは良いが、「やっていること」を書くのは良くない。「やっていること」はコードで表すべきだ。まず、冗長である。そしてコメントの運用の手間が二重になり、コメントの修正漏れによりコードとの差分が生まれる可能性が発生する。どちらが本来正しいのかがわからなくなる。 コメントの注意点２「わかりにくい理由」を書く前に、一度わかりやすく出来ないか設計を考えよう。 学び 技術的負債のタイミングは、以下３つ。 テストファースト開発のりファクタリングステップ、 チームの学習をコードに取り込む定期的なリファクタリング、 それでも溜まってしまう技術的負債を解消するための大規模なりファクタリング コードは平均して、書かれる回数の１０倍読まれる。読めるように書こう。 学びを活かすアイディア・行動 大規模なリファクタリング計画と実施 現場のコーディング規約づくり

12.1 変更しやすさへの障害 内容 変更しにくくする要因としてアンチコーディングパターンを紹介。これを知ることは、変更しやすくする原則を実践することと同じくらい重要。 障害 説明 カプセル化の欠如 知るべきでない内容を知ると、そこに依存性が生まれ、影響範囲が増える。そして後に、意図しない改修しにくさにつながる。 継承の過度な利用 間違った継承は無関係な機能の依存を作り、影響範囲を広げる。 具体的すぎる凝り固まった実装 意味が限定的すぎると、修正箇所が特定しづらくなる。 インラインコード コードをコピペすると冗長になるので、メソッド化してメソッドに良い名前をつけなさい。 依存性 カプセル化の問題と同じ。依存の方向に気をつけること。 作ったオブジェクトを使うか、使うオブジェクトを作るか サブタイプのインスタンス化を行ってしまうと、具体的な依存関係が発生しカプセル化が壊れる。一番やっていはいけない。 12.2 持続可能な開発 12.1と比べて、持続可能にするためのコードの保守性を高くするプラクティスを紹介。 プラクティス 説明 死んだコードを消す コメントアウト化されたコード、未使用なコードは不要に開発者の注意を奪う。消すべし。コメントアウトはバージョン管理システムで行うこと。 名前を更新する 開発が進むにつれてコードに変更が入り、当初の意味から変わる可能性がある。そういうときは名前のリファクタリングも忘れずに。 判断を集約する ？ 抽象化 すべての外部依存性には抽象によって行う。そうすれば限定的な依存関係でなくなるため、テストが簡単になる。 クラスを整頓する モデルからエンティティが抜け漏れることがあり、辻褄があわないときがある。どこに追加するべきか整理して進めよう。 学び ソフトウェアは、リリースされてからも比較的簡単に修正ができる。そのため、ハードウェア業界と比べると間違うことが許されている。しかし、小さなほころびは、積もり積もると大きなコストになり、改修が難しかくなる。修正ができるからと言って、間違って良いということではない。良いものを作るための緊張感は忘れてはいけない。 カプセル化、抽象化はかなり重要で、名前変更やクラス整頓はリファクタリングしながら進める。 学びを活かすアイディア・行動 現場のコーディング規約づくり