# 08ex. Coding ex
________________________________________
結局どうすればいいのか？

たった2つの最も大切なこと

1. 嘘をつくな
    - 変数名で嘘をつくな、関数名で嘘をつくな、クラス名で嘘をつくな
    - 未使用の変数を書くな、未使用の関数を書くな、未使用のクラスを書くな
    - ある関数の引数がオブジェクト型の時、特定のメンバがその関数に対して常に未使用になる型を使用するな
2. 手続きを共通化するな、仕様をDRYせよ
    - 単に似た手続きを共通化するな
    - 仕様・ドメインロジックが自明で同じだと言える場合に、DRYせよ

その他の枠組み

1. ドメイン層の独立（DDD + DIP = ヘキサゴナルの適用）
    - ValueObjectの積極的な用意
    - ただのDtoを避け、ビジネスロジックレベルのValidateメソッドをくっつける
        - そのデータとそれが保証する状態を同じクラスにする、ということ
        - 他のDtoと関連する場合は、未チェックの場合はuntrusted接頭辞または接尾辞をつけた変数に格納する
2. 設計原則による評価（SOLID, 高凝集度かつ低結合度でコードを評価の徹底）
3. Xunit testing可能（副作用のない純粋な写像算出、コンストラクタDIの徹底）
4. コーディング規則の共有（プロジェクトごとの大原則、命名規則、インデントスタイルの共有徹底）
5. if-then-throw/returnパターンを積極的な利用
6. 後述のアンチパターン8種の禁止
7. 特に特殊な性能要求や機能要件がない限り、中規模以上（1000万～）であれば以下を徹底する
    - 要件定義終了時点で押さえておくこと
        - アクセス数・データ量・レコード増加速度・5年後の状態などの概算を適切に概算する
        - 業務フロー図（開発対象と想定の業務フローの関係をサブシステム内の業務フローごとに作成したもの。縦をユースケース図のアクターやシステム、横を業務フロー内のフローとした図）
        - Mockサイト（Htmlによる画面イメージ）
        - 機能一覧表（画面一覧表+バッチ一覧表）
        - 用語表（プロジェクト上での統一業務用語（ユビキタス言語）の整理をある程度進めておく。用語統一は徹底する）
    - 基本設計終了時点で押さえておくこと
        - 方式設計書
            - UXの定義（UI部品・検索画面・検索ダイアログ・新規画面・編集画面等・ファイルアップロード・ダウンロード）
            - 楽観ロックの説明
            - ファイルアップロード・ダウンロードに関するサーバ側のファイル保存やDBへの保存に対する設計方式
            - FAX等に関する方針
            - ロギング
        - ER図（詳細設計以降訂正される前提だが、この時点で実装に問題ないレベルのテーブル設計を済ませておくこと）
        - 業務仕様共通関数一覧（あくまで業務仕様レベルで必須なもの。業務日付の扱いとか、部署組織の所属判定や権限判定とか。）
        - 機能ID設計書
    - 設計・実装に関して
        - 楽観ロック
        - 各種Webセキュリティ（下記は代表的なものだけ。実際の詳細は# 04. WEb Application Securityを参照のこと）
            - ランダムでsecureでhttponlyなセッションID
            - XSS対策（出力時エスケープ）
            - SQLインジェクション対策（フレームワークに従う）
            - CSRF対策（フレームワークに従う）
            - X-Frame-Options: SAMEORIGIN
        - ロギング
    - 単体テストの用意と実施（正常系、準正常系、異常系。それがXunit testingであるかどうかにかかわらず、実質的にC0（命令網羅）カバレッジでもあること）
    - ITaの用意と実施
    - ITbの用意と実施

アンチパターン要約

1. グローバル変数
2. ハードコード
3. 例外握りつぶし
4. メソッド間の暗黙な呼び出し順序要求
5. インスタンス間の暗黙な状態共有
6. 多態性以外の目的での継承
7. Managerクラス
8. DIロケーター