Web開発あなたが避けなければならない10のコーディングアンチパターン
Webサイトやアプリケーションのアーキテクチャを設計したり、効果的なコーディングワークフローを設定したりすると、頻繁に発生する問題に対処することがよくあります。我々は必ずしもこれらのソフトウェア設計の問題を最初から解決する必要はない。 アーキテクチャレベルのソリューションは再利用可能 と同じように マイクロレベルでのコードスニペット.
デザインパターンは一般的に 再利用可能なソリューション 特定のシナリオでは、 よく発生する問題を解決するのに役立ちます, そして私達が私達のコードを最適化するのを大いに助けることができます.
デザインパターンは、よくテストされた式を使用して開発プロセスを改善するための優れた手段ですが、ときどき間違ってしまうこともあります。これらはアンチパターンと呼ばれます.
アンチパターンとは?
用語 “反パターン” 1998年にAntiPatternsという本で造られました。 最初は役に立つと思われたソリューションを再利用, しかし後で判明 善よりも害を及ぼすために.
これはさまざまな理由で起こる可能性があります。たとえば、正しいコンテキスト、設定、または時間でパターンを使用しない場合（過去に効果的だった解決策が現在では必ずしもうまくいくとは限りません）。最初からちょうど悪かった.
アンチパターンはまた頻繁に呼ばれます 失敗のパターン. 良いニュースは、それが それらを認識し、回避することが可能.
この記事では、Web開発における10の一般的なコーディングの逆パターンについて説明します。これらのコードは、最適化されたコードであると考えることを妨げる可能性があります。 （この記事に掲載されているアンチパターンは、必ずしも上記の本に掲載されているものと同じではありません。）
1.時期尚早の最適化
適切なタイミングは、コードの最適化において重要な要素です。逆パターンを簡単に再現できます “時期尚早の最適化”, 自分が何をしたいのかを正確に知る前に、小さな効率に注意を払い、開発プロセスの早すぎる段階でそれらを最適化する場合.
Donald Knuthの有名な引用によると “時期尚早の最適化はすべての悪の根源です“, これは誇張かもしれませんが、時期尚早な最適化が後に引き起こす深刻な問題を示しています.
効果的なアーキテクチャを設定する前にパフォーマンスを最適化すると、 コードの読みやすさ, 作る デバッグとメンテナンスが困難, そして 余分な部品を追加する 私たちのコードに.
時期尚早の最適化を防ぐために、YAGNI（あなたはそれを必要としない）プログラミングの原則に従うことをお勧めします。 “実際にそれらを必要とするときはいつもものを実装します。.”
2.ホイールを再発明する
の “車輪の再発明” antipatternは時々また呼ばれます “真空中で設計する”. やりたいときに起こります 一人ですべてをやりなさい そして ゼロからすべてを書く, 既存のメソッド、API、またはライブラリを探すことなく.
ホイールを再発明することは、単に時間を浪費することではありませんが、 特に基本的な機能性のためのカスタムソリューションは、標準的なものほどめったに優れていません それはすでに多くの開発者やユーザーによってテストされています.
依存地獄
の反対 “車輪の再発明” antipatternは別の一般的なantipatternと呼ばれる “依存地獄”.
ゼロからすべてを書く代わりに、 他のライブラリの特定のバージョンに依存しているサードパーティライブラリが多すぎる, これらの補助的な依存関係は多くの場合にあるため、更新したいときには管理しにくい状況に簡単に遭遇する可能性があります。 相容れない.
依存地獄は、次のことができるパッケージマネージャを使用することで解決できます。 相互依存関係を賢く更新する. 私たちがその問題に圧倒されすぎる場合は、リファクタリングもまた良い考えです。.
4.スパゲッティコード
“スパゲッティコード” おそらく最も有名なコーディングの逆パターンです。それは説明します 適切なアーキテクチャがないためにデバッグや変更が困難なアプリケーション.
不十分なソフトウェア設計の結果は、スパゲッティのボウルに構造が似ているたくさんのコードです。. 絡み合って複雑な. スパゲッティコードの可読性は非常に低いです、そしてそれが正確にどのように機能するかを理解することは通常ほとんど不可能な使命です.
スパゲッティコードは通常、 さまざまな悪いコーディング方法の組み合わせ, 適切な条件ブロックを含まないコード、他の場所に属する部分を含むgotoステートメント、例外、およびスレッドが多数ある、オブジェクト間の関係が最小限である、再利用できない関数またはメソッドがある、または正しく文書化されていないまったく.
順列によるプログラミング
“順列によるプログラミング” または “偶然のプログラミング” 小さな修正を連続して試し、それらを1つずつテストして評価し、最後に最初に機能するものを実装することによって問題の解決策を見つけようとしたときに起こります。.
順列によるプログラミングは簡単にできる 私たちのコードに新しいバグを導入する, さらに悪いことに、それらは我々が必ずしもすぐに認識できないバグです。多くの場合、解決策が考えられるすべてのシナリオで機能するかどうかを予測することも不可能です。.
6.プログラミングをコピーして貼り付ける
“コピー＆ペーストプログラミング” 自分では繰り返さない（DRY）コーディング原則に従わず、一般的な解決策を作成する代わりに、既存のコードスニペットをさまざまな場所に挿入し、後でそれらを所定のコンテキストに合うように編集します。.
この練習 非常に反復的なコードになります。, 挿入されたコード部分は、通常、わずかな相違点のみが異なります。.
コピー＆ペーストプログラミングは、初心者の開発者だけでなく、経験豊富なプログラマもコミットしています。 特定のタスクには、独自に作成され、よくテストされたコードスニペットを使用する, 簡単につながることができます 意図しない繰り返し.
7.カーゴカルトプログラミング
の名前 “カーゴカルトプログラミング” と呼ばれる特定の民族誌的現象に由来する “カーゴカルト”. 第二次世界大戦後、南太平洋に貨物カルトが出現したのは、先進的な文明との強い接触が、コカコーラ、テレビ、島への貨物船で運ばれた冷蔵庫などの製造製品が超自然的なものであると考えたためです。メソッドそして彼らが西洋人の習慣に似た魔法の儀式を実行するならば、商品でいっぱいの貨物は再び来るでしょう.
カーゴカルトプログラミングの逆パターンをコミットするとき、私たちは基本的に同じことをします。私たちはフレームワーク、ライブラリ、ソリューション、デザインパターンなどを使っています。, なぜわからないのか, あるいはその技術がどのように正確に機能するか.
多くの場合、開発者は 現実的な目的を持たずに、その時の腰を儀式的に行う. このやり方は、私たちのアプリケーションを不必要に肥大化させるだけでなく、悪いことだけでなく、新しいバグを私たちのコードに簡単に取り込むこともできます。.
8.溶岩流
私達はについて話す “溶岩流” 必要なときのアンチパターン 冗長または低品質の部分を含むコードを扱う それ 不可欠のようです それでも、それが何をしているのか、あるいはそれがアプリケーション全体にどのような影響を与えるのかを完全には理解していません。これを削除するのは危険です.
それは通常起こります レガシーコード, または コードが他の人によって書かれた （通常は適切な文書がない場合）、またはプロジェクトが開発段階から本番段階への移行が速すぎる場合.
アンチパターンの名前は、火山からの溶岩と類似していることに由来します。つまり、最初はあまり注意を払わずに素早く流動的に動きますが、後で固まり、取り除くのが難しくなります。.
理論的には、溶岩流を取り除くことができます 広範囲なテスト そして リファクタリング, しかし実際には, 実装はしばしば難しいか不可能でさえあります. 溶岩流には通常高いパフォーマンスコストがかかるため、うまく設計されたアーキテクチャと最初から健全なワークフローを設定してそれらを防ぐことをお勧めします。.
ハードコーディング
“ハードコーディング” ほとんどのWeb開発本が序文の中で私たちに警告しているのに対して、これはよく知られた対パターンです。ハードコーディングは不幸な習慣です。 設定または入力データを保存します, ファイルパスやリモートホスト名など, ソースコード内 構成ファイル、データベース、ユーザー入力、または他の外部ソースから取得するのではなく.
ハードコードの主な問題はそれです 特定の環境でのみ正常に動作します, とで 条件が変わるときはいつでも, 修正する必要があります ソースコード、通常複数の場所にある.
10.ソフトコーディング
ハードコーディングの落とし穴を避けるために非常に一生懸命に努力するならば、我々は別のアンチパターンと呼ばれることに容易に遭遇することができます “ソフトコーディング”, これは正反対です。.
ソフトコーディングで, ソースコードに含まれるべきものを外部のソースに入れます。, たとえば、データベースにビジネスロジックを格納します。これを行う最も一般的な理由は、ビジネスルールが将来変更される可能性があるため、コードを書き直す必要があることです。.
極端な場合には、ソフトコードされたプログラムは とても抽象的で複雑になるので、それを理解することはほとんど不可能です。 （特に新しいチームメンバーのために）、そして非常に 保守やデバッグが難しい.
