システム開発において、コーディングがある程度できるようになれば、次のステップは設計です。
その中でも、詳細設計に入ることになると思います。
システムを設計できるようになれば、より上流工程からシステムに参画できるようになります。その分、単価も上がり、あなたのチーム内での価値も高まります。
しかし、設計をするといっても、何をどこから始めたら良いのかが分からないかもしれません。
- 画面はどのように分けたら良いのか
- 処理の順番はどうしたら良いのか
- そもそも、何を決めたら良いのか
この辺りが不明だと、しっかりとした設計はできません。できたと思っても、他の人と違う設計になってしまったり、以前につくった画面と違う動きになってしまったりして、設計のやり直しが発生します。
このような誤りを減らし、設計のパフォーマンスを安定させて、より複雑な設計を任せてもらえるようになるには、型を身につける必要があります。
今回は、ユーザーからのリクエストに応答する処理をどのように設計するのか。
その4つのステップを説明したいと思います。
1番目の処理：入力値の検証
最初に必要になるのは、入力値の検証です。
- ユーザーから入力された値に誤りがないか
例）必須の値が入力されていない - 正しいリクエストになっているか
例）あり得ない画面遷移からの更新処理呼び出し - ユーザーが操作しても良いデータか
例）他者の管理するデータを対象にした更新処理呼び出し
このような点を細かくチェックします。厳密な要件があるシステムの場合は、1項目単位でのチェックを行います。
ここのチェックが漏れてしまうと、情報漏洩や不正データの投入に直結します。
単純な処理のように見えて、非常に重要な最後の砦となるのが、このチェック処理です。
どのような入力であれば次の処理に進んでも良いのかを、ここで徹底的に洗い出しましょう。
また、チェックでエラーとなった場合に、どのようなメッセージをユーザーに返すのかを決めるのも、この段階です。
- 必須入力です。○○を入力してください。
- 入力に誤りがあります。
- 対象のデータが存在しません。
どのようなメッセージを返すかは、プロジェクトごとにある程度決まっています。そこと合わせた方が、UXが向上しますね。
2番目の処理：入力値の加工
問題のない入力がなされたリクエストは、次に値の加工に進みます。
- ユーザーにとって入力しやすい単位で入力された値を、システムでの単位に変換する
例）kg単位で入力された値を、g単位に変換する - ユーザーに応じた固定値を設定する
例）ユーザーの年齢に応じて、未成年フラグを立てる
そもそも、ユーザーに入力されても良い値なのか、ビジネスロジック側で決定するべき値なのかも検討が必要です。
上記の例で言うと、生年月日を聞いているにもかかわらず未成年かどうかをユーザーに尋ねるのはナンセンスです。どちらか一方で十分でしょう。
また、入力値の加工を次の更新処理の中で行う場合もありますが、あまりお勧めしません。入力値に対してごちゃごちゃと処理をする箇所は、一か所にしないと保守性が下がるからです。
どうしても更新処理の途中で値を編集する必要がある場合を除いて、更新処理に入る前に値を確定させましょう。
3番目の処理：メイン処理
ここでやっとメイン処理です。
データの更新や検索、他のサービスAPIの呼び出し等、一番やりたかった処理を行うのがこの部分です。
メイン処理の設計は、だれもが一番集中して取り組む点です。そのため、誤りも起きにくいです。
- トランザクションの管理
- アクセスするデータの順番
ただし、ここで大事になる点があります。それは、エラー時のハンドリングです。バグを修正すれば、99%は正常に処理ができると思います。しかし、その1%の扱い方が厄介です。
- サーバーが意図せず止まったときはどうするのか
- DBのコネクション数が上限に達していた場合はどうするのか
- 他のサービスAPIが停止していたとしたらどうするのか
何が起きるのかが分からないのがシステムです。何が起きてもデータに不整合が生じないように、また何かが起きたことが分かるようにしておくことが重要です。
4番目の処理：メイン処理の後処理
メイン処理が無事に正常終了した際に実行される最後の仕上げになる処理です。
- 検索結果を表示用に加工する
- 更新処理の結果によって遷移先を設定する
- 更新後に必要なチェック処理を実施する
特に大事になってくるのは、更新処理後のチェックです。
事前にチェックをしている場合は、特に実装することはないかもしれません。
しかし、たとえば実際のデバイスの情報をシステムに登録するといった場合は、実物とデータはどうしても不整合が発生する可能性があります。
そのようなチェックを更新処理後に行うことによって、ユーザーに都度確認を促すことが可能になります。
また、検索結果を表示用に加工するのをメイン処理の中で行うこともできますが、お勧めしません。メイン処理の中にすべての処理を埋め込むと、同じ処理をサービスAPIや他の画面で使いまわせなくなるからです。
設計をする際は、自分の処理で使うためだけに設計するのではなく、他でも使いまわせるように設計する必要があります。
そのためには、処理を細かく切り分けることです。メイン処理とWeb画面用の処理を明確に分けることで、このような処理の共通化が可能になります。
まとめ
以上の4ステップが、Web画面のリクエストに対する処理の順番です。
それぞれどこに記述するかは、処理にもよります。ただし、方針としては先ほども既述したように、「他でも使いまわすかどうか」です。
- 更新前のチェック処理は、どこからのリクエストだろうが、同じ処理を通す必要がある
- 検索前のチェック処理は、自分の設計している画面特有の処理かもしれない
このように、処理をどこに記述するかは仕様によりますが、処理順はどのような機能であってもほとんどは上記の4ステップをたどります。
この4ステップに沿って設計を進めることで、抜け漏れを減らすことが可能になります。まずは型にはめて仕様を考えるようにしましょう。
