開発時に気をつけたほうが良いなと思ったことを抽象的機能単位でまとめました。
自身の経験や他の人の話が元ネタになっています・・・・・・
開発初心者の方に「こういうこと気をつけたほうが良いんだな〜」という気付きになれば幸いです！
参照系画面
- どのカラムの昇順、降順で表示させるか
- 検索結果を表示後、並び替えをするか
- 1ページに何件表示させるか（1ページあたり件数）
- ページャーを実装する場合の検索結果の持ち方（フレームワークに乗せるか、セッションか、リクエストパラメータか）
更新系画面
- Update文に更新対象カラムが指定されない場合のケースを考慮する（画面側で条件を全く入力せず更新を実行した場合など）
- チェック処理を行い上記の場合はエラーとし更新を実行しないのが無難
- 更新できたか否かを返すか更新結果をどう扱うのか
- データを一括登録する際に、既にあったデータは削除してから一括登録を実施するパターン
- データを登録しようとして、対象データがすべて空データの場合、削除だけ実行するのか処理を行わないことにするか
- 複数データをまとめて登録しようとする時、行の重複はどう対応するのか
- 重複したまま登録する
- 重複した一方を登録する
- 重複したらそのレコードは両方とも登録しない
- 重複があればエラーとし登録を実行しない
画面共通（フォーム）
- デフォルト値は空欄か、あるいは何らかの値を持つか
- プルダウンリストの場合はキーバリュー両方
- 値がありません、のようなメタな文言を表示することもある
- null、空文字、スペースだけの値を弾くのか、許容するのか
- 全角半角の違いを考慮するか
- プルダウンリストや複数項目チェックボックスはDBから値が取れないなど値がない場合はどうするか（空のものを表示、値がないことを示す文言を表示など、合わせてエラーメッセージ発出するか）
- 参照（Read）よりは更新（Update）、削除（Delete）で入力制限を厳しくする
- エラーメッセージの表示形式（画面上で表示、ポップアップで表示など。
- 画面上とポップアップを併用する場合メッセージはどちらでも利用できるようにしておく
- 日付データを用いる際の開始日と終了日の時系列矛盾のチェック処理
ログ
- フォーマット
- 出力先
- エラーレベルに応じた扱い
- 例えば、DEBUG、INFOは開発時のみ、それら以上は常に出力しログファイルに残す
- ログがDB接続失敗などで出力できない場合、業務ロジック優先のためエラーログなど出すだけして例外を握りつぶすか否かの考慮
- できれば設計段階で共通化しておく
DB接続
- SQLの記述形式（文字列生成かSQLファイルか）
- DB接続処理でのエラー、例外の扱いは明確にしておく（Class宣言、PS、コネクション、SQLExceptionのそれぞれに対して考慮）
- できれば設計段階で共通化しておく
- PreparedStatementでIN句を扱うときは、置換は使わずString文字列の状態でSQLを作る
- IN句で指定するデータがVARCHAR型で「1」など数字の場合、数値に変換されエラーになる（※うろ覚えなので間違っているかも）
ファイル操作
- ファイルのフォーマットは何か
- ヘッダーは必要か否か
- 文字コード
- csvの場合ファイルの中の項目自体にカンマが含まれたらどうするか
- 配置先はどこか
- ファイルの容量制限はするか
- 処理途中でファイルを分割したり
- webアプリでファイルをアップロードする場合、データを保持して処理を続けるか、一旦サーバー側にファイルとして書き出すか
- データの大きさによる
- 各ブラウザのアップロードサイズ上限を超えないか（ChromeとMicrosoftEdgeとFireFoxは10GB、safariは2.01GB）
- zipとして圧縮する場合、ツールによって圧縮率が違ったりするのでどのツールで圧縮するかの要件考慮
- チェック処理などのデータ操作とファイル操作は分離する
- 分離させないとチェック処理結果とファイル操作が混在して、テストケースごとにファイル操作が発生するなど手間になりテストがしにくくなる
- 取り込み処理などでのnullと空文字と半角全角スペースの扱い
- CSVなどファイルから取り込んでデータを配列やArrayListにした時は、要素数のチェック
終わりに
自身の経験や他の人の話を今後にも使えるようにと一般化して書いています。
そのためわかりにくい、あるいは一般化できていないのなどご指摘いただければと幸いです！
今後新しく気づいたことがあれば追記していきたいと思います！