CLEAN CODE

9.8 実践しよう 9.8.1 コード品質を上げる７つの戦略 内容 品質の定義を明確にする高品質のコードを作るには、高品質のコードとは何かを明確に定義しなければならない。高品質なコードとは少なくとも、理解しやすく拡張が簡単でなければならない。 品質のためのプラクティスを共有するたとえば、機能開発を重要視することで、それぞれのメソッドの凝集性を高くするなど。 完璧主義を手放す完璧なものは作れない。完璧でなくても明確な受け入れ基準を持てば、それを叶えるための最善は尽くせる。 トレードオフを理解する状況に応じたトレードオフを理解することで、完璧でなくてもニーズに応えられるかどうかを判断することができる。 「やり方」を隠す読み手は、どうやって実装されているかを気にすることなく欲しい物がなんなのかがわかるようになる。 良い名前をつけるソフトウェア自身が一番のドキュメントであることを理解し、それが何なのか、何をしてくれるものかをわかる名前をつける。略称を使う必要はなく、長さを気にする必要もない。説明的、肯定的、能動的、呼び出し側がどのように変化するのかが分かる名前をつける。 コードをテスト可能に保つ観測可能なコードとコード品質は相関関係がある。テスト可能なようにコードを書こう。 学び 品質を高める戦略。 学びを活かすアイディア・行動 今の所特になし

9.6 コード品質が私たちを導いてくれる 9.7 明日のベロシティのために今日品質を上げる 内容 「CLEAN」コードはテストのしやすさで測ることができる。 凝集性に問題がある場合、あるクラスのテストをたくさん書くことになる。 疎結合に問題がある場合、関係ない依存関係がたくさんあることになる。 カプセル化に問題がある場合、テストが実装に依存していることになる。 断定性に問題がある場合、テスト結果がテストオブジェクト以外から得られることになる。 冗長性に問題がある場合、あちこちで同じテストを書くことになる。 また、これらの品質は１つを上げるとその他の品質も上がっていく。 ケント・ベックは著書「テスト駆動開発」でコードの重複（冗長性）にだけ気をつければ、全体の品質は上がるとしているし、著者も凝集性にフォーカスするのを好んでいる。 これらはテストで測れるわけだから、テストを書いて進めるテストファースト開発をすることがおすすめ。 学び CLEANコードかどうかはテストでわかる。 フォーカスする品質は１つか２つでも効果がある。 学びを活かすアイディア・行動 今のところ特になし

9.4 高品質なコードは断定的である 内容 自分自身のことは自分自身で管理する。これをしないと凝集性が薄くなり、依存し合うコードが生まれやすい。そうなると複雑性が増し、保守しづらくなり、壊れやすくなる。 9.5 高品質なコードは冗長でない 内容 同じことを繰り返さない。保守の難易度が上がるから。 ただし、ミッションクリティカル（人命に関わるような）な場合で、その方が安全と判断するような、「意図的な重複」は良い。 良くないのは「意図しない重複」。 学び 「断定的」に関して、まだ理解が薄いので学習が必要 学びを活かすアイディア・行動 今の所特になし

9.3 高品質なコードはカプセル化されている 内容 カプセル化とはインターフェース（やりたいこと）と実装（どうやるか）を切り離すこと。 開発者はアウトサイドインとインサイドアウトの方法でカプセル化をする。これらの呼び名は著者がそう呼んでいるもので、 アウトサイドインプログラミングドメインを全体的に捉え、ユーザーのニーズとなる体験をベースに設計していく方法。 インサイドアウトプログラミング問題を小さく分解し、それらを組み合わせて１つのソリューションを作る方法。 開発者はこの両方の観点を持って開発に臨むべきだが、先に必要なのはアウトサイドインの方。インサイドアウトから始めると、全体を俯瞰せずに実装を進めることができるため、ドメインを全体視した場合の持つべきふるまいや役割と乖離する可能性があり、そういったモジュールは結果的に壊れやすいため。だからユーザーの体験に基づいて設計し、その実現方法はインサイドアウトの観点で進めるとよい。 基本的に、モジュールを使う側の視点で設計されたインターフェースはpublicで、それ以外はprivate、必要に応じて protected 、package というようなアクセスレベルで調整すると良い。 学び カプセル化の仕方はいろいろあるが、まずユーザーに届ける体験をベースに考えて、ユーザーが何をしたいのか、何を得たいのかをインターフェースにすし、具体的な実装は別で隠すという方法を基本的な考えに持つと良い。 学びを活かすアイディア・行動 今の所特になし

9.2 高品質なコードは疎結合である 内容 疎結合とは、部品と部品の結合部につなぎ目を入れて、お互いが直接干渉しない状態のこと。その逆は密結合。 これによってそれぞれを変更したときにお互いが影響しないため変更しやすくなる。テストするときはモックを使ってテストができる。JavaやC#ではインターフェースを使って実現できる。 ただし、なんでもかんでも疎結合にすればよいというわけではない。例えば、GUIに終了ボタンとボタン押下時の終了アクションがあり、要件的にその２つは必ずセットになっていないとおかしい場合、必ずしも疎結合でなければならないとは思えない。 つまり、疎結合であってほしいところと疎結合で、密結合であってほしいところは密結合であってほしい。 これを「意図による結合と不慮の結合」という言い方を著者はしている。疎結合が良くて密結合が悪いのではなく、それぞれあるべき結合度をコントロールできているかが重要。 特に、多くのことを行うAPIが不慮の結合になってしまうケースが見受けられる。こういう場合は内部で複数のAPIを呼び出すように実装することで、複雑性をそれぞれのAPIに任せることができ、結果的に疎結合にもなり凝集性も高くなる。また、性能や別の制約によってコード品質を下げてしまう場合があまりにも多いが、これは本当にしょうがない場合だけにするべき。 学び 結合度と凝集性は少し似ている。 学びを活かすアイディア・行動 GUIとプレゼンテーションロジックの結合度を考える

9 プラクティス５ 「CLEAN」なコードを作る 9.1 高品質なコードは凝集性が高い 内容 良いソフトウェアの土台となる５つのコード品質を表す「CLEAN」を紹介。 Cohesive (凝集性) Loosely Coupled (疎結合) Encapsulated (カプセル化) Assertive (断定的) Non redundant (非冗長) Cohesive (凝集性) 高品質なコードは何よりもまず凝集性が高い。凝集性とは部品がどれだけ１つのことだけを扱うようにできているか。SOLID原則の「単一責務の原則」がどれだけ適用されているかということでもある。 凝集性を高くするための方法としてオブジェクト指向が用いられ、基本的な部品の単位をクラス（概念）となる。 ソフトウェアのコードは結局のところ言語的活動であるため、これらの部品が「何」を扱い「どんなふるまい」があるかを表すネーミングは非常に重要。表していることが明確でないと意味不明で読めないから。 「人」のように「会話」や「食べる」「歩行」「手がある」などさまざまなふるまいや性質を持っている複雑なものは、それぞれの要素を分解しそれぞれが凝集性が高い小さな部品とする。それらの部品を持つように構成させる。 また、オブジェクト指向言語のトレースの仕方の話になるが、構造化プログラミングのようにコードを上から下に読むだけでは読むことができない。オブジェクト指向のオブジェクトはhas-a関係、親子関係が階層になっており、純粋に処理を順番に読もうとすると、親クラスと子クラスをいったり来たりして読みづらい。基本的な読み方のスタンスとしては、その階層だけで処理を読み、具体的に知りたい場合は必要に応じて子クラスの詳細を読むようにする。そうすることで、文脈のレベルが保たれ、読みやすくなる。 学び 特になし 学びを活かすアイディア・行動 今の所特になし