Refactoring to Patterns 1
https://learning.oreilly.com/library/view/refactoring-to-patterns/0321213351/
日本語訳本「パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法」
Chapter 1. Why I Wrote This Book
コードを必要以上に柔軟にしたり、洗練させたりすると、オーバーエンジニアリングになる。
プログラマーの中には、システムの将来的な要求がわかっていると信じて、このようなことをする人がいる。
明日のニーズに対応できるように、今日の設計をより柔軟で洗練されたものにするのがベストだと考える。
それは理にかなっているように聞こえる。
予測が外れた場合、貴重な時間とコストを浪費することになる。
多くのアーキテクトやプログラマーは、自分がオーバーエンジニアリングを行っていることに気づいていない。
パターンを学び始めたとき、パターンは柔軟で洗練された、エレガントでさえあるオブジェクト指向設計の方法であり、マスターしたいと強く思った。
数多くのパターンとパターン・ランゲージを徹底的に学んだ後、すでに構築したシステムを改善したり、これから構築するシステムの設計を練ったりした。
これらの努力の結果は有望だったので、私は自分が正しい道を歩んでいると確信した。
時が経つにつれて、パターンの力が、よりシンプルなコードの書き方を見失わせるようになった。
パターンについて考えるのをやめ、小さくてシンプルで理解しやすいコードを書くことに集中する必要があると気づいた。
アンダーエンジニアリングは、オーバーエンジニアリングよりもはるかに一般的です。
アンダーエンジニアリングとは、設計が不十分なソフトウェアを作成することです。
・時間がない、時間が作れない、リファクタリングする時間が与えられない。
・優れたソフトウェア設計について知識がない。
・既存のシステムに新しい機能を素早く追加することが求められている。
・一度に多くのプロジェクトに取り組まされる。
Big Ball of Mud（大きな泥団子）
継続的なエンジニアリング不足は、ソフトウェア開発の「速い、遅い、遅い」というリズムになる。
1.クズみたいなコードでシステムのリリース1.0を素早く提供する。
2.あなたはシステムのリリース2.0を提供し、ジャンキーなコードはあなたの速度を低下させる。
3.将来のリリースを提供しようとすると、ジャンキーなコードが増え、システム、プログラマー、そして皆がこの立場になったプロセスさえも信頼されなくなるまで、どんどん遅くなっていく。
4.リリース4.0の途中か後のどこかで、勝てないことに気づく。全面的な書き直しという選択肢を模索し始める。