最近、他人がコーディングした「.NETアプリケーション」を保守していると、登録や更新処理時にフォームのコントロールから何回も値を取得しているソースコードをよく見かける。この実装は、実は余り好ましくはない。
なぜ、よくないのか？
それは、Windowsアプリは、パソコンやOSの環境でよくフリーズしたり、イベント処理が適切に処理されないことによって、コントロールから値が取得できなかったり、おかしな値に変更される不具合がある。これは、WindowsOSの問題でもあるため、ある意味仕方がないことでもある。
顧客がシステムをがんがん使用するようになると、顧客の環境によってはイレギュラーとして発生する。
プログラムの処理としては問題ないのに、なぜか？想定通りの挙動しないなどの現象が発生する。これは、GUI系によくある。コマンドベースではあまり起きない事象である。
例としてあげると、登録処理内で画面の数量を使って、入力チェックや合計金額計算、データベースを更新するといった処理があったとする。更新処理内でなんども画面のコントロールから値を取得すると、WindowsOSやアプリケーションに不具合があったときに、この数量が取得できない、もしくは想定しない値を取得するなどのイレギュラーが発生する。
では、この場合どのようなロジックにすることが望ましいのか。まず、登録処理や更新処理をする場合は、画面内の値を内部変数（配列）やクラスプロパティ、データセットなどにすべて値をキャッシュします。これにより画面内のコントロールへのアクセスが一回で済みます。
また、必須チェックやマスタの存在チェック、値の整合性チェックも格納した変数やプロパティ、データセットに対して行います。画面のコントロールに対してアクセスしていないので、不具合の確率がかなり下がります。
このような処理は、一般的かと筆者は考えていましたが、実際のシステム開発の現場では、かなり散見されます。原因一つとしては、技術者の考慮不足です。経験不足といっても過言ではありません。保守や運用フェーズを経験した開発者では、当たり前のことかもしれませんが、新規開発しか経験がないプログラマーではよくありがちです。
本来はPGレビューで指摘しますが、レビュワーやレビュー観点においても指摘及び記載されているプロジェクトは、見たことがありません。
当然、保守や運用フェーズとなってから発見されるため、プログラミングとしては問題ないのに、意図しない挙動をします。そこでなぜだろうと担当者は悩みます。また、何万行という膨大な処理部分発生することもあり、作り直したほうが早いケースもあります。下手に構造を変えるとテスト工数が爆発的に跳ね上がり、トラブルの確率も高くなります。
当然、対処療法でしのぐことになります。
トラブルが少ないコーディングをするのであれば、開発時点のレビューでしっかり対処しておくのが吉です。
