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

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

設計、実装確認ポイント(Kotlin)

kotlin Java

実装

思想

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

クラス構成

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

基本コーディングルール

  • mutableな変数、オブジェクト可能な限り使う
    • valで定義できるものはvarを使わない
    • mutableListより、LIstを使う
  • 参照範囲を狭めているか
    • privateにできるメソッドはないか。無用な結合を減らす
  • 意味のわかる記述になっているか
    • 固定値は、enumで定義する
    • 設定値と変数名は一致させる
    • EntityはRepositoryのoutput変数名、それ以外のobjectはDtoなどの名称を利用
  • 明示的な実装か
    • 暗黙型変換をしない(明示的な変換なしで別の型に代入しない)
    • アンラップ!! は、nullチェックや定義時点でnullなしにできないか検討
      • 不用意なアンラップは、nullポを発生させる
  • 対応可能なTODOコメントが残っていないか

リクエストParamクラス

  • 個人情報やパスワードなどの秘匿情報は、ログに出力しないようにパラメータを伏せ字化する
  • パラメータの必須 or nullableを最適な指定とする
    • DB登録必須ならリクエスト時点から必須パラメータで指定するなど
    • リクエストから、レスポンスまで一貫した設定値にする。流れですべて矛盾がないか確認
    • null項目がnon nullで定義しているとnullポが発生して重大なインシデントになる可能性がある

Entity

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

Dto

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

メソッド

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

外部API呼び出し

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

永続化(DB, Redis)

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

仕様漏れはないか

  • 実装後に再度、設計書の仕様が漏れていないか
    • nullable, 型, 変数名

エラーハンドリング

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

セキュリティ

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

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

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

テスト

単体テスト

ローカル、STG動作確認

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