コーディング規約

5 プラクティス１ やり方より先に目的、理由、誰のためかを伝える 5.1 やり方は言わない 5.2 やり方を目的に転換させる 内容 ソフトウェア開発では半分を要求収集に使っていると言われている。そして、顧客から開発者までに情報が流れるなかで情報は欠落したり歪んでいったりしていく。 開発に精通していない顧客やマネージャーが要求の「やり方」まで伝えることがあるが、これは良くない。情報が専門知識が無い前提のもので、開発者は専門知識を前提に見るので混乱を招く。 なので「やり方」は専門家である開発者に任せるべき。 また、「やり方」も開発者によって千差万別で、似たようなものもあれど完全に同じやり方をするということは無いが、これはこれで良さがある。新しいアイディアが生まれるから。 細かいやり方を統一することは難しいので、原則・パターン、プラクティスを共通認識として持ち、その域を越えて標準化しなくてもよい。 学び やり方は細かすぎるものは標準化しなくてよい。 学びを活かすアイディア・行動 現場のコーディング標準

1.5 「プロセス」が「忙しい仕事」になるとき 1.6 ガチガチのマネジメント 内容 人は成果を出せないとやる気を失う。初めはやる気があったとしても。 IBMのプログラミングのコメントポリシーは何をやっているかをすべて書くことだったが、これは良くなかった。自明なコメントはコードが読みづらくなったり、シンプルすぎるメソッド名にコメントで注釈を入れて実際のふるまいとメソッド名にギャップがあったり、コメントへの反映し忘れでコメントが嘘になってしまったり。 このような良くないプロセスは忙しさを産み、やる気を無くさせる。 マネージャーは開発者が正しいことをしていると保証したい。 正しいこととは何か？答えられる人はほとんどいない。 ソフトウェア開発でやっていることは、考えること、モデル化、コーディングで、これらは創造的でそれぞれが違うことがほとんど。実質、定量的に図ることは難しい。 正しいことをしたいあまり、プロセスを追加することがあるが、追加すればするほど悪くなる傾向がある。創造性にプロセスは影響しないから、単純に作業が複雑になり創造性を阻害し忙しくなるだけ。 学び コメントはプログラムで表現できないことを書く。 結局の所どうやって計測する？という疑問が出た 学びを活かすアイディア・行動 現場のコーディング規約づくり

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

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

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

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

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

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

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