くそーコンピューターとエクセルは私の人生を台無しにしました！ 私は私の人生が嫌いです。
ミス・アラウレン （彼女の人生のある時点で他の人と同じように）
このような経験が、人々がマイクロソフトについて大きな言葉を発し、予期せずに（必然的に）期待に応えられなかった匿名プログラマを呪うよう促す理由です。 私たちは皆それを知っています。 それは私たちが家族や友人に提供した無限の時間の技術サポートで私たちの魂に焼き付けられています。 時折、私たちは、自分の仕事を迅速かつ不注意に行うプログラマーが他の人々を苦しめる方法を見ています。 そして、私たちはそのようにならないように努力しています。 私たちは、すべての戻り値をチェックし、すべての例外を処理する優れたプログラマーになるよう努めています。
エラー処理と厳密なテストに限定した場合、すべてがうまくいきます。 しかし、実際には、私たちは通常、はるかに先に進み、悲しいかな-私はそれを認めなければなりません-間違った方向に。
動作中のソフトウェアの大部分はひどく再設計されています。 私は、コントロールと設定であふれているインターフェースについても話していません 。 これらは本当に恐ろしい罪ですが、氷山の目に見える部分にすぎません。 コード自体で、表面下でリエンジニアリングがさらに悪化します。
あなたは間違っています
誰かがシンプルな5行のスイッチ構成を非常にうまく使用できる「 デザイン 」 デザインパターンを適用するのを見たことがありますか。
このような単純な構造を変換する方法は数百通りあります。
switch (operation)<br>
{<br>
case OP_ADD: return a + b;<br>
case OP_SUBTRACT: return a - b;<br>
case OP_MULTIPLY: return a * b;<br>
default: throw new UnknownOperationException(operation, a, b);<br>
}
このような、嫌な、間違ったミュータントモンスターになります。これは長すぎるため、記事に埋め込みませんでした。
リエンジニアリングの最も陰湿な原因は、過剰な一般化です。 一滴でも一般化に役立つすべてのものを再一般化します。 生徒のリストを操作するコードを作成しますか？ まあ、私たちは教師と、そして実際に一般大衆と協力することができました。 いつか 。 基本クラスManとそのサブクラスStudentを追加することをお勧めします。 または、クラスManを作成して、彼からLearning Manクラスを、彼からStudentを継承できます。 はい、それははるかに良いですよね？
そのように、今では3つのクラスをサポートする必要があります。各クラスは独自の仮想メソッドとインターフェイスを持ち、場合によっては3つの異なるファイルに分割されますが、 1行の辞書（マップ、マップ）で十分です。
おそらく、これはリラックスするからです-停止して考える必要なしに、コードでいっぱいの3つのクラスをドラミングします。 それは生産性の感覚を与えます。 このソリューションは、堅牢で防弾、プロフェッショナルに見えます。 振り返ってみると、自己満足の火花に温められています。私は優れたプログラマーであり、コードに汚いハッキングはありません！
すべてがうまくいきますが、それは私たちに良いプログラマを作りません。 このようなリエンジニアリングは、だれの生活も向上させません。 コードが長くなり、理解および変更が難しくなり、コードのエラーの可能性が高くなります。 世界を少し悪化させただけです。 通りの真ん中にボトルを投げて車を盗むことの間のどこかにあります。
リエンジニアリングによってもたらされる余分な労力には、多額の費用もかかります。
- ユーザーインターフェースを磨く時間は少なくなります。
- 作業中の機能の重要な結果について考える時間はほとんどありません。
- エラーの検索にかかる時間が短くなり、（コードの量が増えたとしても）エラーを修正するのにより多くの時間が必要になります。
はい、 Studentクラスをリエンジニアリングすることで、 ミスラウレンの日を間接的に台無しにしました。
リエンジニアリングのすべてのばかげたトリックの防御を停止し、適切な名前で呼び出す必要があります。 将来を予測することはできないため、これは「将来のための準備」ではありません。 このコードは信頼できません- 読みにくいです。 特定のケースに一般化されたソリューションを適用することは良いプログラミングではありません。それは犯罪者のリエンジニアリングです。あなたはそれが好きかどうかは別ですが、誰かがそれをどこかで支払わなければなりません。
幸せになることを心配しないでください
私は最高のプログラマー全員がこれを長い間理解していたと思うが、彼らは他の誰もが聞くことができるほど十分に大声で叫ばなかった。 ポール・グラハムは、簡潔さを認めるべきだと示唆するとき、絶対に正しいです。
プログラムの長さは、プログラムの作成に必要な作業量のおおよその推定値として使用します。 文字の長さではなく、さまざまな構文要素の長さ-実際には、解析ツリーの高さ。 短いプログラムで書くのに必要な時間が短くなるということは完全に真実ではありませんが、真実に近いです。 プログラムを見て、自問してください。もっと短く書く方法はありますか？
-ポール・グラハム、 百年言語
実際、彼は言語設計について話していました。 実際、「 簡潔さは強さ 」という記事で、彼はプログラムを短すぎて書くことが可能であることを明確に示しています。 これは、現時点では、Paul Grahamが既存のプログラマーというよりは言語デザイナーだからです。 そうでなければ、彼は言うだろう：
10行で解決できる問題を解決するために100行のコードを記述する場合は、停止して、次のことを自問してください。
-マーク、 犯罪リエンジニアリング
コードを過度に一般化または再設計したいと思うと、それはしばしば恐怖によって引き起こされます。 誰かが単純な解決策を選択すべきではないという本当に正当な理由を見つけることを恐れる。 このコードを書き直す必要があることを恐れる。 訪問者テンプレートのメリットをめぐる論争で間違った側にいることへの恐怖。 しかし、恐れはもちろん、私たちを最もエレガントな決定に導くことは決してありません。
次回、単純なタスクの適切な一般的なソリューションを作成する衝動を感じたら、停止して、単純で具体的で短いソリューションを作成するのを妨げているものを自問します。
- 私はそれを書き直さなければならないのが心配ですか？
- 誰かが彼を批判したり、私が愚かに見えることを心配していますか？
- 私はこれが十分にプロフェッショナルではないのではないかと心配していますか？
これらのオプションのいずれかが該当する場合は、リラックスしてください。 心配しないで。 あなたは心配して、私を呼んで、私はあなたを幸せにします（ ボビー・マクフェリンの歌 「 心配しないで、幸せになってください 」からのライン：「あなたは心配して、私を電話して、私はあなたを幸せにします。」）。
そして、シンプルで具体的な短いソリューションを作成し、次のように短いコメントを追加します 。 このコードが成長し始めたら、Visitorテンプレートに置き換えます 。
これは完璧なソリューションです。 次回このコードにアクセスしたとき、このコメントはあなたがやりたいことを思い出させてくれます。 他のプログラマーに、より「正しい」（複雑な）ソリューションを検討していることを示し、その時点では、今のところそれを開始しない正当な理由があります 。 このようなコメントについて議論することは困難です。何が優れているかについては議論していません。戦略テンプレートまたはスイッチではなく、3〜4件の単純なタスクに戦略テンプレートを使用するかどうかを議論しただけです。 いずれにせよ、これは間違いなくあなたに悪い面を示すことができるような議論ではありません。
数か月後、あなたは戻ってあなたのコメントのどれだけが最終的により複雑なコードに変わるかを見ることができます。 私はかなり賭けます。 それはあなたがどれだけ時間と労力を節約したかです。 これにより、 手を解放して元の問題を解決し続けることができ、世界が少し良くなります。
関連リンク：
1. オーバーエンジニアリングを停止します！ （2002年4月）; Software Developmentマガジンのソフトウェア中心の議論。
2. リエンジニアリング ; ウィキペディアの記事
3. 簡潔-パワー （ オリジナル ）