パンくず
書籍 Refactoring to Patterns
Why I wrote this book
Over-Engineering
概要
Over-Engineeringについて
詳細
必要以上に汎用性を持たせ、洗練させたコードは「Over-Engineering」です。
一部のプログラマーは、未来の要求を知っていると思い込みこのような開発を行なってしまいます。
これは一見良いことであるかのように思えますが、もし予想が間違っていたら貴重な時間と予算を大きく浪費することになります。
「Over-Engineering」が蓄積するとコードベースはどんどん複雑になります。
このような問題を解決するために、システムを細かく分割することで対応することが往々にしてあります。
しかし、この場合各担当が担当範囲内での作業を最適化しようとし、担当外まで目を通すことが稀であるため
冗長なコードが発生します。
「Over-Engineering」は生産性にも影響を与えます。
コードの引き継ぎを行う場合、引き継ぎ先担当者が快適にメンテナンスや拡張を行う前に
要件にはない設計の意図を理解する必要が出てきてしまいます。
「Over-Engineering」は多くのエンジニアやアーキテクトがそのことに気づかずに行なってしまうために
ひっそりと混入されます。
そのような組織では生産性が下がって初めてこの原因に気が付きます。
エンジニアが「Over-Engineering」を行う主たる要因は悪い設計をしたくないからでしょう。
悪い設計はコード深くに埋め込まれ、改善には多大な工数を要します。
ポイント
eXtreme programmingの原則でもあるYAGNIに反する開発スタイル。
YAGNI="You ain't gonna need it"
必要ない機能は実装しない。
以下、思わず頷きたくなる方もいると思われる現実の例。
要件定義の段階ではある機能が必要になると思ったため、実装してみたが実際は使用されなかった。
それどころか、リリースまでの工数が少ないため追加してしまった機能を削除して
テストをし直す期間もなく利用されない機能が残ったままリリース。
一度リリースしてしまったために、削除することも出来ず。
このような火を吹いたプロジェクトほど人の入れ替えが激しいため、頻繁に引き継ぎが発生する。
数世代の引き継ぎを済ますともはや何故そのコードが存在するかも分からなくなり
メンテナンスが困難になる。
はじめに簡潔なコードで必要な機能だけ実装しておけば必要な機能は少ない工数で
すぐに追加出来る。また、後々の余計な工数も不要になる。
