プログラムのバグに遭遇した時、とりあえず回避するためのコードを書くことがあるかと思います。
今回は、上記のようないわゆる暫定対応コードを書いた場合にやっておきたいことについて書いてみました。
例えば、FunctionA.javaのdo()メソッド内で時々発生する原因不明のエラーに対し、暫定対応のため、「this.temp()」メソッドを追加したとしましょう。
・・（これより上既存のコード）
this.temp();
・・（これより下既存のコード）
このままだと、後から見た人が何のことかわからなくなってしまうので、コメントを入れます。
タスク管理ツールを使っている場合
BacklogやRedmineなどのタスク管理ツールを使っている場合はチケットを作成し、コメントにはチケット番号とタイトルのみ記載し、詳細はそちらに書くようにしましょう。
例えば、チケット番号が「hoge-123」、タイトルが「エラーの一時回避」の場合は以下の通り。
・・（これより上既存のコード）
// hoge-123：機能Aのdoメソッドで発生するエラーへの暫定対応
this.temp();
・・（これより下既存のコード）
チケットには、
- 発生事象
- 対応内容
- 今後の課題
などをとりまとめ、後で見た人がわかるようにします。
例えば以下のような感じ。
タスク管理ツールを使っていない場合
プロジェクトによってはタスク管理ツールを使っていないケースもあるでしょう。
その場合の代替案についても考えてみました。
1. 暫定対応用のフォルダを作ってメモを残す
代替案その1。
以下のように暫定対応用のフォルダを作成し、ファイル名にタイトルを記載し、中に発生事象、対応内容、今後の課題を記載します。
2. 設計書に目立つように記載する
代替案その2。
設計書に吹き出しを入れて、そこに対応内容を記載する、もしくは対象処理の箇所の色を変えて、近くにコメントを残す、でもよいでしょう。
NGな例
1.コメントを書かない
せっかく暫定対応のコードを記述しても、コメントがないのはNGです。
後で見た人がこのコード何?となりえず、そのことで調査が発生し、思わぬ時間をとりかねないからです。
2. コメントが短すぎる or 長すぎる
コメントを書かない、よりはマシですが、、コメントが短すぎる or 長すぎるのもNG。
コメントが短すぎるパターン
・・（これより上既存のコード）
// 機能Aのdoメソッドで発生するエラーへの暫定対応
this.temp();
・・（これより下既存のコード）
上記はこれまでの例のタイトルの部分だけ記載したケース。
わからなくもないですが、もっと具体的な内容がほしいところです。
コメントが長すぎるパターン
・・（これより上既存のコード）
/* 機能Aのdoメソッドで発生するエラーへの暫定対応
* 発生事象:機能Aで5%程度の確率でエラー画面に遷移する事象が発生
* 対応内容:回避用のtemp()メソッドを作成＆使用
* 今後の課題:直接の原因を突き止め、対処する
*/
this.temp();
・・（これより下既存のコード）
これは何かのドキュメントか?というレベル長さ。
コードの可読性もさまたげてしまいそうですね。
やはり、コメントを書いて詳細は別所に記載するのがよいでしょう。
一番大切なこと
ここまでで、暫定対応コードを書いた場合はコード内にコメントを入れ、詳細は別所に記載するのがベターとお伝えしてきました。
が、一番大切なことはこういった対応を行った際にどう記録を残しておくかチーム内でルールを統一しておくことです。
ある人は詳細をチケットに記載し、ある人はどこかにメモを残し、、では後から対応する人が困ってしまいますよね。
バグ発生⇒暫定対応コードを書くことになったら、まずチーム内のルールを確認し、ない場合はどうするか話し合って決めておきましょう！
終わりに
バグ対応は急を要することも多く、かなりエネルギーを消耗しますが、後日のことも考えて対応したいところ。