私的チェックリスト

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

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

コーディング

• 可読性が高いこと
• 下記の原則を遵守していること
  • 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とか使う

テスト

• DBはできるだけ本番に近いデータ量を
• FIRST特性
  • Fast（迅速）
  • Isolated（隔離）
  • Repeatable（繰り返し）
  • Self-validating（自律的検証）
  • Timely（タイムリー）
• 下記
  • カバレッジ
  • 同値分割
  • 境界値
  • 状態遷移
  • デシジョンテーブル
  • 組み合わせ
    • pair-wise
• ペネトレ
  • ZAPかけろ
• 負荷試験
  • 負荷の内容は現実的か
  • JmeterとかちゃんとCLIモードを使用して試験しているか
• フリーキーテスト
  • 実行するたびに結果が変わる良くないテスト
    • Isolated違反
    • 時刻情報をもとに処理するやつとか

コンテナー(Docker)

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

その他

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

セキュリティ

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