Day: February 28, 2021

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

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

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