レガシーコードからの脱却 まとめ – 12.1 -12.2

12.1 変更しやすさへの障害

内容

変更しにくくする要因としてアンチコーディングパターンを紹介。
これを知ることは、変更しやすくする原則を実践することと同じくらい重要。

障害説明
カプセル化の欠如知るべきでない内容を知ると、そこに依存性が生まれ、影響範囲が増える。
そして後に、意図しない改修しにくさにつながる。
継承の過度な利用間違った継承は無関係な機能の依存を作り、影響範囲を広げる。
具体的すぎる凝り固まった実装意味が限定的すぎると、修正箇所が特定しづらくなる。
インラインコードコードをコピペすると冗長になるので、メソッド化してメソッドに良い名前をつけなさい。
依存性カプセル化の問題と同じ。
依存の方向に気をつけること。
作ったオブジェクトを使うか、使うオブジェクトを作るかサブタイプのインスタンス化を行ってしまうと、具体的な依存関係が発生しカプセル化が壊れる。
一番やっていはいけない。

12.2 持続可能な開発

12.1と比べて、持続可能にするためのコードの保守性を高くするプラクティスを紹介。

プラクティス説明
死んだコードを消すコメントアウト化されたコード、未使用なコードは不要に開発者の注意を奪う。
消すべし。コメントアウトはバージョン管理システムで行うこと。
名前を更新する開発が進むにつれてコードに変更が入り、当初の意味から変わる可能性がある。
そういうときは名前のリファクタリングも忘れずに。
判断を集約する
抽象化すべての外部依存性には抽象によって行う。
そうすれば限定的な依存関係でなくなるため、テストが簡単になる。
クラスを整頓するモデルからエンティティが抜け漏れることがあり、辻褄があわないときがある。
どこに追加するべきか整理して進めよう。

学び

  • ソフトウェアは、リリースされてからも比較的簡単に修正ができる。
    そのため、ハードウェア業界と比べると間違うことが許されている。
    しかし、小さなほころびは、積もり積もると大きなコストになり、改修が難しかくなる。
    修正ができるからと言って、間違って良いということではない。
    良いものを作るための緊張感は忘れてはいけない。
  • カプセル化、抽象化はかなり重要で、名前変更やクラス整頓はリファクタリングしながら進める。

学びを活かすアイディア・行動

  • 現場のコーディング規約づくり

kiyoshi.saito@tttsunagari.jp

アプリ開発をメインにWebアプリ開発をやってるフリーランスエンジニアです。

Leave a Reply

Your email address will not be published. Required fields are marked *