私的チェックリスト

作成日時：2024-08-01以前
更新日時：2025-07-22

基本的に下記の内容を遵守/確認する。
但し、理由を説明できるならば守らなくてよい。
詳細は暇な時に書く。

チェックリスト

• あっていいが依存してはいけない
• 使わなければ意味が無い
• 明確であること
• 最小であること
• 常に改善すること
• 「なぜ」を意識すること
• 上を巻き込んで文化を作る
• 無知と無能
  • 知らなければミスは防げない
  • 知っていてもやらなければミスをする
  • チェックリスト使え

複雑性はミスを生む。
ならばシンプルを維持すべき。
シンプルならばチェックリストは不要。
チェックリストが必要ならば、対象は複雑。

大抵の悲劇はコミュニケーションの失敗が原因
-アナタはなぜチェックリストを使わないのか P.82

コーディング

• 可読性が高いこと
• 下記の原則を遵守していること
  • KISS
  • DRY/OAOO
  • YAGNI
  • SOLID
  • SLAP
  • PIE
  • 名前重要
  • 小は美なり
• 命名が適切であること
  • 業務用語を適切に表しているか(ユビキタス言語とか)
  • シノニム/ホモニム/表記ゆれは無いか
  • スペルミスは無いか
  • プロジェクトの命名規則に反していない(スネーク/キャメルなど)
  • 命名は適切であり名前だけで内容を完全に理解できる
  • スコープは短い
  • 不変である
• 過剰にネストしていないこと
  • 極論を言えばif文は書くな
  • 多態性/デザパタ駆使しろ
• マジックナンバーは許さん
• なんでもかんでも”定数クラス”にまとめんな
  • その定数があるべきクラスに書け
• 列挙型を使え
• 段落は適切に付与している
• 横に長いソースを書かない
  • メソッドチェインとか適切に改行している
• 最小/最短/最速である
  • APIやDBへのアクセス回数が最小である
  • クラスやメソッドが小さい
  • 処理速度が速い
    • なお可読性を確保するためであるならば多少パフォーマンスは犠牲にしてもよい
    • 案件によるけど
• サニタイジングを適切に行っている
  • OSコマンドインジェクション
  • SQLインジェクション
  • XSS
• 「あとで直す」は永久に直すことは無いから今直せ
  • 直せないならTODOとかFIX MEとかコメント残せ
• メソッド中のコメントは”何をしているか”を書くな。“何故そうしたか”を書け
  • “何をしているか”を書かなければ読みにくいコードはその時点でク◯コードである可能性が高い
  • ただし可読性を上げるためならば書いてもよい
• 高凝集/疎結合
• 現場のコーディング規約に従う
  • タブインデントとスペースインデント
  • 改行コード
• 副作用が発生するコードを書くな
  • 引数は弄るな。処理結果を引数に格納するな。
  • 純粋関数(入力値から決まる出力値を返すだけの関数)であれ

メール

• 開発/テスト時、開発中のメールを関係ないドメインに飛ばすな
  • モックのメールサーバーを立てて使え
  • もしくはドメインを自身や会社が管理しているものを指定しろ
  • モック+example.comドメインを使う
    • 外部に飛ばないから
• SPF/DKIM/DMARCの設定を確認する
  • gmailにちゃんと届くかどうかを確認する

ログ

• ログレベルは適切か
• CRITICAL/ERROR発生時に適切に管理者へ通知が飛ぶか
• 追跡可能である
• 解析が容易なフォーマットである
  • JSONで良くない？
• 過剰でない
• 個人情報を含まない、もしくはマスキングしている
• 保存期間

DB

設計編

• 正規化が適切である
  • 結合速度などを鑑みて
• 別カラムから算出できる値をカラムに保持しない
• カラム名は適切か
  • 業務用語を適切に表しているか(ユビキタス言語とか)
  • シノニム/ホモニム/表記ゆれは無いか
  • スペルミスは無いか
  • プロジェクトの命名規則に反していない(スネーク/キャメルなど)
• 凡化/特化
• バージョン管理するか
• ビュー/マテビューの必要性
• パーティショニングの必要性
• インデックス
  • インデックスを無駄に貼っていないか
  • カバリングインデックス
  • 複合インデックスの順序
  • B-tree/Hash/Bitmapなどの種別
• NoSQLはRDBでは実現できない場合の最終手段と考える
• 制約
• 特定のRDB固有の機能を使ったりしていないか
• 多対多の関連が存在しない事

アクセス編

• SQLインジェクション対策をしているか
  • プリペアドステートメントなど使用せず文字列の連結でSQLを組み立てていないこと
• DBへのアクセス回数/取得するデータ量は最小である
  • データを大量投入する場合、1回のSQLでまとめて投入している
  • N + 1のアクセスをしない
  • 使用しないデータを取得したりしていない
• 実行計画の内容に問題がない
  • 意味なくフルスキャンをしていない
  • インデックスを使った検索/結合をしている
  • コストが極端に高くない
  • 検索時にORDER句を指定している(場合による)
• アスタを使わない(必要のないデータ取得/結合時のカラム名衝突に繋がる)
• ロックは問題ないか
  • そもそも必要か
  • パフォーマンスへの影響は考慮したか
  • 楽観的ロック/悲観的ロックどちらが適しているか
  • デッドロックは発生しないか
  • ロックの取得順序は適切か
  • ギャップロック、ネクストキーロックが発生しても問題ないか
• スロークエリ
• NULLに注意する
  • 集計関数や計算時
  • COALESCEとか使う

コンテナー(Docker)

• セキュリティチェックしろ
• マルチステージビルドしろ

その他

• “何故”をドキュメントに残せ
  • ADRとか
• SPAの404
• CSP
• ユーザの入力値は全て疑え

セキュリティ

• localStorageよりsessionStorage
• サニタイジング/エスケープ
• CORS
• キャッシュ
• パスワードのマスク
• アカウントのロックアウト
• セッション短く
• ジャッキング
• 安全なウェブサイトの作り方

確認する

• レスポンスヘッダーの確認
  • レスポンスは圧縮してるか
  • キャッシュ系
• セキュリティ
  • CSRF
  • CSP
  • XSS
  • iframe
• js検索したらtoken入ってないか
• 検索
  • ページング遅くないか
  • 最後のページを表示する場合など
  • インデックスは使ってそうか
• 絵文字、特殊文字(文字数カウントとか)、外字
• ダウンロードファイル内容

Cookie

• httponly
• secure
• samesite
• domain

法律チェックリスト

• 個人情報保護法
• 電子帳簿保存法
• 改正民法632-656
  • 善管注意義務
  • プロジェクト管理義務
• クレジットの3Dセキュア