どこまで正確性を担保したプログラムを書くのか
システムだって人が作ったものだからミスを犯す。
それは自身が手がけているシステムかもしれないし、連携先のシステムかもしれない。
システムにどこまでミスをカバーしてもらえばいいのか。。。
業務中に思った疑問
要件に無いところにおいて、どこまでプログラムでエラーを補えばいいの?
エラーって何？？どこまでがエラーなの？？
と混乱したことから、学んだことを初心者なりにまとめておこうと思い書きました。
状況
実装していて、システム間のやりとりが必要になりました。
その時下記のような状態であり、どこまでシステムでカバーするのか問題になりました。
登場人物
・システム[A|B]
・API_[b1|b2|b3] （システムBのAPI）
システムA はシステムB に値を格納するため、API_b1, API_b2にデータを送る。
このとき片方でもエラーが返ってくると、システムAは次の動作ができない。
-
前提１（システムB について）
- 送られたデータを整形して格納する
- バリデーションがあり、基本的には正しいデータのみ受け付ける
- システムA が送った値が不正な値でも登録できてしまうことがある
- 返すエラーからは登録されているか、いないかわからない
-
前提2（エラーの対処）
- API_b3 に問い合わせれば登録状況がわかる
- 登録されていなければシステムA はデータを再送信する
- 間違って登録されていた場合はアラートをあげる
-
前提3（エラーについて）
- エラー時、簡単なデータメンテで解消することが可能
- エラーの頻度は1か月に1回程度発生しそうである
システムとしてあるべき姿
- 基本的には正常系のみを担保
- 工数の削減
- 余分なコードを書かないことから、バグを生む原因の減少
- 気づける仕組みの用意
- エラー発生時にデータメンテができるようにする
コードを書いて網羅的なテストをする時間、エラー対応のコードを入れたことによる新たなバグ修正の時間（完璧なコードを毎回かければいいのですが...）とデータメンテにかかる時間を比べたら、（このケースの場合）簡単なデータメンテをしたほうが楽であるかと思います。
どっちにしろ、間違って登録されていた場合はデータメンテが必要なることを踏まえるとより明確です。
逆に、すべてうまくいって、失敗も起きなければ工数をかなり削減できたことになります。
まとめ
自分への戒めのためにも書きました。
自身だけでなく納品先にも上記のやり方でいいか聞く必要はもちろんありますが、丸投げされている場合には考えるべき事象だなと思いました。
完璧主義者的考えをついしてしまい、自分の手は汚したくないから、全部システムに入れてしまえ！とつい考えてしまいそうなところです。
天秤にかけることは難しいですがこれからも経験積んでいきたいと思います。