気軽に楽しくプログラムと遊ぶ

自分が興味があってためになるかもって思う情報を提供しています。

設計、実装確認ポイント

実装

思想

  • 改修の場合、既存仕様や全体統一感に囚われ過ぎない。シンプル化、保守性向上を意識する
    • 不要項目を含んだオブジェクトパラメータの是正
    • 変数名が設定値と異なる名称であれば是正(影響範囲が広くなりすぎないかは判断)

クラス構成

  • 継承よりも移譲を優先。クラス構成の複雑化や密結合を防ぐ

基本コーディングルール

  • パラメータの必須 or nullableを最適な指定とする
    • DB登録必須ならリクエスト時点から必須パラメータで指定するなど
    • リクエストから、レスポンスまで一貫した設定値にする。流れですべて矛盾がないか確認
  • 固定値は、enumで定義する
  • 設定値と変数名は一致させる
  • 暗黙型変換をしない
  • アンラップ!! は、nullチェックを事前にしてなるたけ排除する
  • 対応可能なTODOコメントが残っていないか

Entity

  • 型、nullableはDBの型、nullableに合わせる
  • 数値型は、int(9〜10桁)、long(32桁)を意識して使う

Dto

  • 重複dataクラスを内部クラスとして定義していないか
  • nonNull項目は!!で矯正設定せずに、バリデーションチェックで例外などにしているか
    • 不用意に!!を用いるとnullで落ちる可能性がある
  • いくつものクラス間において同じDtoを受け渡していないか、Dtoの修正影響が大きくなってしまうっっっっっl

メソッド

  • 引数は名前付き引数にしているか
    • 同じ型で違う項目に値を設定してしまう可能性を排除する

外部API呼び出し

  • URL、IF(nullable, 設定値フォーマット)

永続化(DB, Redis)

  • 1件取得前提の場合、SQL側で1件に絞るようにする
  • Redis項目名変更もDB項目名変更と同じで、データ移行を意識する
  • トランザクションを意識した実装
    • 高負荷に処理した場合、トランザクションが張られていないと、予期せぬ値で更新してしまったりしないか

仕様漏れはないか

  • 実装後に再度、設計書の仕様が漏れていないか

エラーハンドリング

  • 処理継続の判断
    • 後続処理に影響のない処理の例外握りつぶし、ログ出力

セキュリティ

  • 認証情報のパラメータ受け渡し時はマスクする

バージョン管理(git, ブランチ運用)

  • git
    • コミット、プッシュまでの確認
    • git status, git diffで追加ファイルと修正内容を確認
  • ブランチ運用
    • ブランチ運用
      • 派生ブランチの場合、親ブランチの更新が取り込まれているかを確認

テスト

単体テスト

ローカル、STG動作確認

  • データのDB登録値の確認(画面からは確認できない観点はローカル確認を漏らさない)
  • 修正における影響を意識してテストを実施する
    • 修正後、なんとなく動くという確認ではなく明確に影響を考えて、抜けもれなく確認。結合テスト時の修正を減らす
  • 複雑なデータ仕様がある場合、パターン整理を行って網羅的にテストを行う