アンチパターンの概要
アンチパターンはパターンの正反対です。デザイン パターンは優れたプログラミング手法の例、つまり特定の問題を解決するためのパターンであることを思い出してください。しかし、アンチパターンはそれらの正反対、つまりさまざまな問題を解決するときに起こる間違いのパターンです。
適切なプログラミングの実践の一部は、まさにアンチパターンを避けることです。これがそのような理解できない理論上のゴミであるとは思わないでください。これらは、ほぼすべての開発者が遭遇する特定の問題です。誰が気づいているでしょう、彼は武装しています！
初心者によくあるアンチパターンをいくつか見てみましょう。
- マジックナンバーと文字列
- 神クラス
- 時期尚早な最適化
- 自転車の発明
- 一輪車の発明
マジックナンバーと文字列
マジック ナンバーは、何か (ほとんどの場合はデータ識別) のコードで使用される定数であり、対応するコメントがなければ番号自体は意味を持ちません。数字には意味論がまったくありません。
プロジェクトのコードに数字が表示され始め、その意味が明らかではない場合、これは非常に悪いことです。このようなコードの作成者ではないプログラマーは、そのコードがどのように機能するかを説明するのが難しいでしょう。時間が経つと、マジックナンバーを使ったコードの作成者ですら説明できなくなるでしょう。
数字があると、コードの理解やリファクタリングが難しくなります。このエラーの主な理由は、開発を急いでいることと、プログラミングの練習が不足していることです。このアンチパターンは、開発を開始する前に数値定数の使用を規定することで芽を摘み取る必要があります。
この問題を解決するには、数値定数の目的を説明する名前の変数を作成し、それに目的の値を割り当てる必要があります。
神クラス
神聖なオブジェクトは、 OOP 開発者の間で非常に一般的なアンチパターンです。このようなオブジェクトは、多すぎる機能を引き受けたり、ほぼすべてのデータを保存したりします。その結果、移植性のないコードが作成され、さらに理解が困難になります。
さらに、システム全体がほぼそのコードに依存していることを考えると、そのようなコードを保守するのは非常に困難です。このエラーの理由: 開発者の無能、1 人の開発者が作業の大部分を引き受けている (特に作業量がその開発者の経験レベルを超えている場合)。
タスクをさまざまな開発者が処理できるサブタスクに分割することで、このアプローチに対処する必要があります。
時期尚早な最適化
時期尚早な最適化とは、プログラマがどこでどのように実行するかについて情報に基づいた決定を下すために必要な情報をすべて得る前に実行される最適化です。
実際には、ボトルネックがどこで発生するかを予測することは困難です。経験的な結果を得る前に最適化を試みると、コードが複雑になり、エラーが発生しますが、何のメリットもありません。
どうやって避けるか？まず、よく知られ実績のあるアルゴリズムとツールを使用して、クリーンで読みやすく、機能するコードを作成します。必要に応じて、プロファイリング ツールを使用してボトルネックを見つけます。推測や仮定ではなく、測定値に依存してください。
事例と特徴
プロファイリング前のキャッシュ。数学的に正しいアルゴリズムの代わりに、複雑で証明されていないヒューリスティックを使用する。負荷がかかると誤動作する可能性がある、テストされていない新しいフレームワークの選択。
難しさは何ですか
最適化が時期尚早であることを判断するのは簡単ではありません。成長の余地を事前に残しておくことが重要です。簡単に最適化して成長できるソリューションとプラットフォームを選択する必要があります。また、時期尚早な最適化が、悪いコードの言い訳として使用されることもあります。たとえば、アルゴリズムが O(n) より難しいという理由だけで O(n2) アルゴリズムを採用します。
自転車の発明
このアンチパターンの意味は、解決策がすでに存在し、多くの場合、より成功する解決策が存在する問題に対して、プログラマが独自の解決策を開発することです。
開発者は自分が賢いと考えているため、前任者の経験を無視して、各タスクに対して独自の解決策を考え出そうとします。ほとんどの場合、これは時間のロスとプログラマの効率の低下につながるだけです。結局のところ、解決策が見つかったとしても、それは次善の策である可能性が高くなります。
もちろん、独立したソリューションの可能性を完全に放棄することはできません。これは、直接的な方法でプログラミングをコピーアンドペーストすることになるからです。開発者は、既製のソリューションを使用するか、独自のソリューションを発明して、目の前に現れる可能性のあるタスクを適切に解決するためにナビゲートする必要があります。
非常に多くの場合、このアンチパターンの理由は単純な時間不足です。そして、時は金なりです。
角輪自転車の発明
このアンチパターンは、単に車輪の再発明、つまり、より良いソリューションが存在するのに、独自の悪いソリューションを作成することと非常に密接に関連しています。
このアンチパターンでは 2 倍の時間がかかります。まず、独自のソリューションの発明と実装に時間がかかり、次にそのソリューションのリファクタリングや置き換えに時間がかかります。
プログラマは、特定の範囲のタスクに対してさまざまなソリューションが存在することを認識し、それらの長所と短所を考慮する必要があります。
プログラマーとして直面するすべての問題は、次の 2 つの部分に分けることができます。
- 賢い人々は30年前にこの問題を解決しました
- 賢い人々は50年前にこの問題を解決しました
プログラミングの問題のほとんどは、あなたが生まれる前にすでに解決されています。何も発明する必要はありません。他の人の経験を研究するだけです（本はそのために書かれています）。
2022 年には、次の誕生日を祝うことができます。
- プログラミング言語
- C 言語が 50 周年を迎える (1972 年)
- Java 言語は 27 周年を迎えました (1995 年)
- パイソンが 31 歳になる (1991)
- 繋がり
- インターネットは 39 歳になりました (1983 年)
- 携帯電話は49歳になった（1973年）
- 最初の SMS が送信されたのは 30 年前 (1992 年)
- パターン
- MVC パターンは 44 年目になりました (1978 年)
- SQL は 48 年前 (1974 年) に発明されました。
- Java Beans は 26 年前 (1996 年) に発明されました。
- 図書館
- Hibernate は 21 年前 (2001 年) に発明されました。
- 春は 20 年前に発明されました (2002 年)
- Tomcat は 23 年前 (1999 年) にリリースされました
- OS
- Unix は 51 年前 (1971 年) にリリースされました。
- Windows が日の目を見たのは 37 年前 (1985 年)
- 21年前（2001年）にリリースされたMac OS
そして、これらすべては単に発明されたものではなく、当時非常に一般的で関連性のある問題の解決策として開発されました。