たまにはデバッグでも。

最近は、本当にバグがたくさん出てます。

そんな不具合発見隊からは漏れてて、別タスク中心で済んでるので、
あんまり関わってこなかったわけですが、今日珍しく対応してみました。

始めは、
顧客にExcelでデータをもらって、DB用に変換したデータを
入れ直すっていう作業で作った情報に関するエラーだったので、
開発環境にあるデータを元に検索してみました。

データに不整合は起きてなかったので、
次は画面に映りました。
とりあえず起きてる画面で、普通の操作で起きない事を確認します。
もちろん起きませんね。

さて、ここからが問題です。
どうやって再現するか。

最初は、適当にいじってました。
担当している機能ではなかったので、操作そもそもの理解も少なかったので、なんとなく。
でも、いくらやっても出ないので、次はロジックを追うことにしました。

すると、パラメータに対するチェックが薄く、
所々で、「こういうデータ来るから大丈夫だ！」という実装がされていました。
こうなってくると、どこかロジックがおかしいんだろうと、
本腰を据えて、対応してみようかなぁと思えてきます。

オブジェクトにセットしている箇所を呼び出してみたり、
transitionログに吐き出されている通りに画面遷移してみたり・・・。

と、なんと再現できました！！
やったね☆

でも、私が思ってた箇所に修正を入れても、うんともすんとも。。。
だんだんと、ロジックじゃないんだなぁと思うようになってきました。
そこで、再現の方法自体を疑ってみます。
こうすると起きるかもしれない・・・と、いじってみるとー、
出ました！ぉぉ、なんということでしょうか。

結果

入力フォームがアクティブでなくなると、そのタイミングで、
項目に対して、カンマ編集や計算を行っているのですが、
項目に直接カンマを入れたときの考慮が漏れていたため、
計算結果が表示されなくなり、ロジックでエラーになってたというわけです。

はははー全然違うよー。

成長点
・ここを直せばいけるけど・・・に、頼らない。
・時間がなくても根本的な原因が突き止められなければ、修正したとはいえない。きちんと第三者に説明できるレベルで解析してこそ保守対応というものなり。
・transitionログを見て再現する方法は結構効果的（なんて初歩的な発見？）
・ここだ！と思ったところは対外はずれる・・・。
・今回のバグ突き止めルート：exceptionログ解析→データ分析→ロジック→transitionログ解析→再現方法の再確認→画面（JSP）