ソフトウェアの大局的構造に関する失敗パターンです。

ソフトウェア開発の設計工程に関する失敗パターンです。

ハードウェアへのアクセス関数を、多くの個所で使っている。

ファイル内の変数を公開して、他のファイルから利用可能にしている。

ハードウェアのレジスタ値が公開されていて、多くの個所で使っている。

関数分割やファイル分割における失敗パターンです。

open（入口）が一つなのに、そのclose（出口）が複数になっていること。close漏れが発生しやすくなります。

タスク分割やスレッド設計に関する失敗パターンです。

ファイル名に「メイン」や「コモン」があることで、なんでも含めてしまう。

構造化されていない一筆書きコードやクローンコード。

動作シナリオがすべて一つのモジュールに入っている。中央集権。

ひとつの処理の流れのみの仕様記述であり、複数を重ね合わせないと、横断的な仕様が見えてこない。

手続きの途中でクラスをインスタンス化すること。ライフタイムの逆転が引き起こされることがある。

様々な場所から直接データを収集している。

手続きの流れの中で、特定の条件の時にフラグを立てて、別の手続きから参照する。

ライフタイムのねじれが発生している。処理の途中でインスタンスを生成していると発生しやすい。

名称と属性を見ても責務が分からない。

コード断片を切り貼りすること。

開発チーム単位でタスク分割されていて、並行動作で必要なタスク数を上回っている。

機能構造の内部に横断的関心が混在している。異なるドメインの用語が一つのモジュールに混在している。

ファイル間の呼出関係の規則がなく、スター形状に絡み合っている。

代々伝わってきた、なぜが動くプログラム。

フラグ変数が多く、複数のフラグの組合せの条件判断が、複数個所に存在している。

処理の流れをそのままプログラムすると、構造が「ない」プログラムになってしまう。

処理の流れをそのままプログラムすると、構造が「ない」プログラムになってしまう。

インタフェース設計で粒度が混在していること。

「～マネージャ」というモジュールが横並びになると、責務分担が曖昧になってしまう。

クラスのメソッドが3単語以上の連結になっている。

クラスの責務が曖昧で「動詞のみ」のメソッドにはならず、メソッド名で処理内容を補足説明している。

ひとつの処理の流れのみの仕様記述であり、複数を重ね合わせないと、本当の仕様が見えてこない。

3層アーキテクチャで、ミドル層を飛び越えた依存性。

アプリ層⇔ミドル層⇔ドライバ層という3層構造において、下から上への逆方向依存や階層を飛び越えた依存。

循環依存が多く、分割コンパイルできないソースコード。

手続きをそのまま並べたソースコード。

レイヤー化において「下位が上位のサービスを利用する」という逆方向の依存性。

要求仕様のまま、動く関数を作ってしまう。その結果、設計構造がなく、重要なドメイン変数が肥大化してしまうこと。

意味の異なる変数を、ひとつにまとめている。バンドリング結合。

「～メイン」などの名称で、雑多なことを多く引き受けている。自分自身の責務は曖昧。

全体俯瞰の構造図が、縦横無尽の依存線になっている。

ハードウェアのタイミングチャートを、そのままプログラミング。

同じ用語を使っているクラスが点在している。

openとclose, newとdeleteという対になる操作が、構造的に対象の位置にない。

/* とりあえず */ や /* 20210305 */ など、コード内容が伝わらないコメント。

クラス名と変数の相関が薄い。変数が雑多であり、寄せ集めている。

状態の取りうる値が意味的まとまりがない。

問題ドメインとUIドメインや通信ドメインが混在すること。基本構造が見えなくなる。

正常系処理と異常系処理が混在してること。設計の基本構造が見えなくなる。

アドホックなフラグを作って、別な場所でそのフラグを判断することです。

制御スレッドの途中でイベント待ちや遅延をしてしまう。