# 10ex. Anti Design Pattern ________________________________________ 【電子合本版】Code Complete 第2版 完全なプログラミングを目指して（上巻：第5章、第6章） https://bookplus.nikkei.com/atcl/catalog/05/589000/ その他多数（どこから参照したか覚えてないもの多数あり…） ________________________________________ ## 1. 業務設計・コード実装のアンチパターン ________________________________________ ## 1.1. 設計内容や実装のアンチパターン 1. 08ex. Coding ex をまず読んで、その内容を違反しないでください 2. 説明困難な仕様を作らないでください。1年後に質問されたとき、仕様書またはソースを熟読しなければ危険な仕様はやめてください 3. 正常入力だけを想定するのはやめてください。入力の検証は、方式設計で方針を決めてください 4. 好き勝手にエラー処理を書かないでください。エラー処理は、方式設計で方針を決めてください 5. 異常な状態のまま処理を進めないでください。安全に中止してください 6. 過剰な業務仕様をやめてください。どうせ誰も細かい部分まで使いこなせません（エンジニアが理解できないなら、普通の人が使いこなせるわけがありません） 7. 過剰な設計（オーバーエンジニアリング）をやめてください。凝った設計はやめてください。単純で理解しやすい設計にしてください 8. モノシリックな設計を避けてください。サブシステムに分断し、サブシステム間のやり取りを限定してください。大きな泥だんごをやめてください 9. 難しく抽象化しないでください。わかりやすくドメインを捉えてください 10. カプセル化を勘違いしないでください。適切な概念を捉えていない場合、結局中身を読む羽目になります。抽象化・カプセル化・ドメインを捉える、は本質的に同義です 11. クラス名、関数名、変数名で嘘をつかないでください 12. 余計なコードを書かないでください。使われていないコードは消してください。苦しいので最初から追加しないでください ________________________________________ ### 1.2. 設計作業のアンチパターン 1. なんでもフルスクラッチするのは避けてください。この視点において、仕事と趣味は分けてください 2. なぜその手法が良いのか説明できないのに、特定の手法をかたくなに使うのを避けてください 3. 頭の中だけで設計するのをやめてください。紙やホワイトボードにスケッチしてみてください 4. トップダウン設計、ボトムアップ設計の片方にこだわるのをやめてください。適切に使い分けてください 5. プロトタイプを実装し始める際はYES、NOがはっきりする命題を掲げるか、得るべき知見を想定してから取り組んでください ________________________________________ ### 1.3. 会議・打合せのアンチパターン 1. むやみやたらに会議・打合せしないでください 2. 議題に関わらない人を、会議・打合せに参加させないでください。人数の最小化を目指してください 3. 前項補足。情報共有を推し進めることと、全員で会議に参加することは全く異なります。8人以上での会議・打合せはただのパフォーマンスの場です 4. 議題と質疑ポイントをあらかじめ用意せずに打合せするのをやめてください 5. 誰が何をする必要があるのかはっきりしないまま、打合せを終えないでください。誰が動く必要があり、誰が待ちなのかはっきりさせてください ________________________________________ ## 2. クラス設計レベル ________________________________________ ### 2.1. むやみやたらに汎化・継承しないでください 「is A」より「has A」を好んでください ```text ある抽象クラスに対して、派生クラスが何の具象実装のないoverrideをする場合、明らかに抽象クラスが間違っている （ただし、既にリリース済みのライブラリにメンバが追加された場合は除く） interfaceに関しても基本的には同様 ``` ________________________________________ ### 2.2. SOLIDに違反しないでください 08. Coding を参照のこと ________________________________________ ### 2.3. 誤ったinterface設計 interfaceを作り始めたのにメンバメソッド名がすぐに決まらない時、根本から間違えている。主従を逆転させないでください ```text 正しくは、まずは先に明確な操作・手続き・命令（想定される用途）があり、それに従ってinterfaceが用意される DIP・ヘキサゴナル的に言えば「interfaceのメソッド名が決まらない」とは「ドメインが何やってるのかわかっていない」と同義である 主従が逆転した抽象化・汎化は、共通化アンチパターン(※)と同じ迷路に迷い込んでいる ※ 再利用の意味を履き違えて、たまたま構造が同じだけの処理を共通化してしまうアンチパターン (単に構造が同じ手続きを)共通化するな、（意図・意味・ルール・業務仕様を抽象化して）DRYせよ ``` ________________________________________ ### 2.4. ドメイン貧血症 ________________________________________ ### 2.5. 神、Manager ________________________________________ ### 2.6. ICloneable ________________________________________ ### 2.7. Singleton ________________________________________ ### 2.8. Non controller high fan-out ```text - Mediator - アプリケーション層 - 集約ルート 上記いずれでもないのに、8以上のClassを直接メンバに持たねばならないなら何かがまずい （直接DIで受け取るインスタンスが8以上になってしまっているのは何かがまずい） ```