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