はじめに
これは設計時の見落とし Advent Calendarの8日目の記事となります。
業務アプリケーションの設計をするときに、見落としがちなところに焦点をあてて紹介します。
下流工程からの手戻りを少なくして 双方の負担を減らしましょう。
以前、別ブログなどに書いた記事のQiita向けにリライトしてみようと思います。
今回はシステム日付にまつわる話を3つ挙げます。
システム年月＋締日
当時のプロジェクトでは、私の方でコードレビュー＋検証をしておりました。
検証した画面は、締日(1～31)と得意先コード範囲を入力し帳票出力させるものでした。
そのプログラムを私の方で検証をしてみると「対象データがありません」とエラーになります。
ソースリストを見るとシステム年月＋締日となっており、仕様書もそのように記述されておりました。
そのプログラムは9月中に製造されておりテストデータも9月のみで作成されておりました。私が検証したのがちょうど月が変わった10月1日だったため、対象データが抽出されてこなかったわけです。
しかし、締日(1～31)だけしか入力項目が無いのでは、当月しか出力できないわけです。
特別な帳票というわけでは無いので、いつでも出力できるようにするべきです。
設計者に現象を伝え、年月項目を追加して初期値をシステム年月とするように提案しました。
システム日付の統一
クライアントサーバーモデルで、関連した別テーブルの登録した日時にズレがあるということで改修したことがあります。
サーバー処理はデータベースのシステム日付、クライアント処理はPCのシステム日付を使用してデータが登録されておりました。
対象となったクライアント側PCの時刻にズレが生じていたことで発覚しましたが、そもそもそうならないように最初からシステム日付をサーバー側で統一するべきでした。
日付制限
システム日付を初期値にしカレンダーの入力日付制限として過去日または未来日を指定したらエラー扱いにする仕様がありました。
エラーにする仕様は別に問題ないのですが、これを素直にシステム日付を指定した仕様書にしてしまうと、開発中に日付が変わる度にテストデータの日付を毎回更新するなど非常にテストが面倒になります。
よって、システム日付を取得するラップ関数を別途作成し、テスト用に外部設定で日付を変更できるようにしました。