ホームに戻る
出典 :
関連 :
目次 :
アンチパターンとは
必ず否定的な結果に到達する、それでいて一般的によく見られる手法(不適切な解決策)のこと。
デザインパターンを構築する上での反面教師となる。
アンチパターンの類型
ここに挙げたもの以外は出典元を参照。
肥満児
肥大化したオブジェクト。 一つのモジュール(オブジェクト指向ではクラス)に複数の機能を詰め込んだ結果発生する 。
⇒ 一つのモジュール(またはクラス)が複数の機能を担う場合は、機能ごとにサブモジュール(サブクラス)を作成することで肥大化を避ける。委譲を用いるのも効果的。
スパゲッティコード
構造がほとんど理解できないようなシステム。 GOTO(無条件分岐)を多用するなどで、論理構造が破壊されたことで発生する。
⇒ 無条件分岐を用いない論理設計を行う。一つのルーチンが長大化したことでスパゲッティコードとなることが多いので、サブルーチンに分割する。
切り貼りプログラミング
汎用的なコードを作らず、 既存のコードをコピー・ペーストして使う 。
同様の処理がプログラムの各所に分散し、修正する手間が増えたり、同期がとれなくなる。
⇒ 複数回(2回以上)現れる共通の論理はサブルーチン化する(Don't Repeat Yourselfの原則)。
打ち出の小槌 / 銀の弾丸
気に入った方法が、あらゆるところで利用できる、あるいは万能だと思い込む。
適用すべきでない局面に無理やり適用する、そもそも「気に入った」だけで合理的でない、などで他者の理解を妨げるとともに整備性を低下させる。
⇒ その手法自体の合理性、および適用すべき場面を吟味し、不適切な場面には用いない。
組織硬直
多くの人間が設計に関与しているが、統一された考え方が存在しない。
⇒ 組織におけるデザインルールを明確化するとともに、各人が意識的にルールを順守する。設計書・ソースコード共に、設計思想が他者に伝わることを重視して記述する。
車輪の再発明
既に知られている適切な(一般的な)解決方法を採用しない。
⇒ 同様の課題に関する一般的な解法が存在しないかを確かめるとともに、自らが考案した手法が真に合理的かを自問する(疑ってかかる)。
溶岩流
除去することが非常に困難で、(除去した際の)結果が予測できないために品質の低い(多くの場合冗長で複雑長大な)コードを維持せざるを得なくなる。
モジュール同士が複雑に絡み合って(相互依存して)いる、またはそもそもモジュール分割がなされていないなど、一部を修正した際の影響範囲が予測できないコード。
⇒ プログラム全体の把握が可能となるよう、モジュール化を重視して構成する(入念に構造設計を行う)。一度溶岩流となった場合、再構築は非常に困難で、フルスクラッチを余儀なくされる。
ビジーウェイト
何らかの事象(イベント)が発生するのを待つ際にメッセージングを使わず、繰り返し確認(ポーリング)することでCPU資源を浪費する。
⇒ イベント駆動型のプログラムとし、イベントの発生はスレッド間通信(メッセージ、イベントフラグなど)を用いて検知する。
イベント駆動型プログラミングを参照。
カーゴ・カルト・プログラミング
パターンや方法論を、理由(必然性・必要性・原理)を理解せずに用いる。
⇒ 自らが用いる手法について理解する。「周囲がそうしているから」「今までそうだったから」「なんとなく」は理由とならない。
マジックナンバー
説明の無い数値(即値)をアルゴリズムで使用する。
その値が意味するものが伝わらず、また同じ値が同じものを示しているとは限らないため、修正時の該当箇所の特定が困難となる。
⇒ プログラム中で用いる定数は(自明の場合を除き)必ずシンボルを定義する 。リテラルを用いる場合はローカルスコープに留め、確実に設計書およびコメントで補足する。
ボートの碇
もはや使用されていない部分をそのままにしておくこと。無効なコードが有効であるという誤解を招き、可読性・検索性が低下する。
⇒ 必要のなくなったコードは削除する(コメントとしても残さない)。
砂上の楼閣 / ベンダーロックイン
特定のベンダー(メーカ)の独自技術に大きく依存したプログラム。他ベンダーの提供する同種の製品やサービスへの乗り換えが困難となるため、成長が阻害されたり、価格面で不利となる。
そもそものマナー違反
自分で書いたコードの推敲(セルフチェック)を行わない
コードレビューを依頼する前に、 自分の書いたコードを読まないというのは論外 。
何を書いているのかが自分でもわからないというのはそれ以前の問題 。
インデントを揃えない
最低限、 ネストレベルとインデントの深さは揃える 。
条件分岐が多い、ネストが深い
考慮すべき条件が多くなるほどチェックが行き渡りにくくなり、考慮漏れやバグの元となる。
そもそもネストが深いのは、一つの関数(メソッド)が担う責務(機能)が多すぎるため。機能単位でサブルーチン化を行うべき。
場合によっては条件分岐ではなくジャンプテーブルを用いることで、コードサイズも縮小でき、処理速度も向上する。
適切なコーディング技法(一般的な手法)を習得していない
本来 switch - case を用いるべき箇所で if - else if ... のラダーを組むなど。プロのコードとしてあり得ない。
特にソフトウェアの技術は陳腐化しやすいため、学び続ける姿勢を失わないこと。
コードとコメントの同期をとらない
コードを修正した際にコメントを直さない、そもそもコメントを書いていないなど。
コードとコメントのどちらが正しいのかが判別できず、プログラム全体の信憑性が低下する。
スペルミス
英単語のスペルくらい辞書で調べましょう。
誤ったスペルが残っていると検索できず、また正しいスペルと誤ったスペルが混在していると、影響範囲を正しく特定できなくなる。