Day: January 3, 2021

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

12章 プラクティス8 設計は最後に行う 内容 ソフトウェア開発では、保守性の設計は最後にしたほうが良い傾向がある。プロジェクトの終盤の方が、システムの全体に対して理解が深くなっており、適用させるデザインパターンの判断もしやすくなる。実現の手段として、ユニットテストのサポートを受けながら、再設計とリファクタリングを行う。 反復開発は設計を創発する。創発とは、最初の設計よりも開発が進むに連れ、もっと良い設計が見えてくることを指す。 12.8 創発する設計 原則として、テストファースト開発を行いながら、理解容易性、テスト容易性に注意を配りながら開発していけば、修正しやすいプログラムになり、あとから生まれた設計を取り込むことも、テストがサポートしてくれる。 創発した設計を取り込むことができないということは、修正がしづらいことを意味し、それを続けているといずれ保守可能でないシステムになり、システムはビジネスの拡張についていけなくなるし、エンジニアたちも苦しむことになる。 学び 保守性を加味した設計とリファクタリングは、テストが書かれている前提であれば、プロダクトの全体像が見えるプロジェクトの後半が適している。 テストファースト開発は創発した設計を取り込むことができる。 最初に設計しきるのは現実的ではない。だから、創発した設計を取り込めるプロセスを作ることが重要だ。 学びを活かすアイディア・行動 まずは実践し、メンバーに手法として展開する テストコードの目的の事前知識整理

11.12.2 バグを修正する７つの戦略 内容 バグ修正は大きなコストとなる。そのための７つの戦略の紹介。 戦略 説明 そもそもバグを作らない そのまま。ツールを駆使してヒューマンエラーを減らそう。 できるだけ早くバグを見つける 自動回帰テスト環境を作ってフィードバックを早くし、バグ発見を早くしよう。 バグを見つけられるように設計する カプセル化されていれば、バグは特定しやすくなる 正しい質問をする まず何が正しいのかを明確にする。その次にどこにギャップが有るのかを明確にする。 バグをテストの不足とみなす バグを見つけたら修正する前に失敗するテストを書き、その後にコードを修正する。バグは誤った想定のもと起きるので、まず何が誤った想定なのかを把握し、ユニットテストで具体化する。そうすることで二度と再現しなくなる。 欠陥をもとにプロセスを修正する バグが見つかったら、なぜそのバグが発生したかを、開発プロセスの観点で確認する。開発プロセスに原因があるのであれば、ツールでヒューマンエラーを防げないか検討する。 失敗から学ぶ ↑に似ている。バグを教訓に設計、プロセスを修正する方法を探す。 学び バグが起きたら再発防止フローを徹底する。なぜ起きたのか、どんな種類のバグなのか、ツールで防ぐことができないか、開発プロセスが原因ではないか。 学びを活かすアイディア・行動 現場にレトロスペクティブの観点として展開できる。

11.12 実践しよう 11.12.1 テストを仕様として使うための７つの戦略 内容 テストを文書のようにすることで生きた仕様になる。そのための７つの戦略を紹介する。 戦略 説明 テストを文書のように扱えるようにする テストのコードも、マジックナンバーをハードコードせずに意味がわかる変数名にする 意図がはっきりわかるヘルパーメソッドを使う セットアップの処理や、そのほかの機能を独自のヘルパーメソッドでラッピングすることで、個々のテストの重複を排除しつつも、異なるセットアップオプションを用意できるようになる 何が重要なのかを明らかにする １と似ている。マジックナンバーをハードコードせずに変数で読めるようにして、意図するところをわかるようにする 実装ではなくふるまいをテストする 具体的な実装に合わせてテストするのではなく、テストメソッド名を表すことをテストする。悪い例：testConstructor 。単純すぎる。良い例：testRetrievingValueAfterConstruction 。何をテストしたいのかがわかる。 モックを使ってワークフローをテストする アサーションは値やふるまいをテストできるが、ワークフローやオブジェクト間の相互作用はテストできない。これはモックを使ってテストする。 書きすぎない 微細に記載することは簡単だが、意味が同じテストは重複である。例えば、境界値とその間の値の場合、その間の値のパターンは無尽蔵にあるが、実施するのは１つでよい。それ以外は実施した１つのテストと意味が同じだ。重複したテストは削除する。 正確な例を使う 実際の使われ方を実行することによって、コーディングを開始する前に、矛盾や設計上の問題が明らかになり、早期に対処できる 学び プログラマでない人でも読めるように書くべし 重複は省くべし 相互関係のテストはモックを使うべし ふるまいを明確にテストすべし 学びを活かすアイディア・行動 現場のユニットテストのコーディング規約づくり