バッチ処理に共通する処理を担当するクラスがある。実行時間の計測やコマンドラインオプションのパース、結果のメール送信などを担っているものだ。バッチを書く場合はこのクラスを継承することが原則になっている。

バッチの実行時間を可視化したいという話がでてきて、このバッチ処理親クラスに手を入れ、実行ごとに処理時間を GrowthForecast に投げるという処理が追加された。バッチをグラフ化オプションをつけて起動するとデータを gf へ投げるという設計だ。

あとはバッチサーバの crontab を一括で書き換えて、上記のオプションをつけてあげれば完了。のはずだった。なぜかひとつだけ、処理を全部自前で書いた、独自路線のバッチが生き残っていたのだ。あえなくバッチは不正終了し、アラートメールが飛ぶこととなった。

ちょっとした改修でも、こうしておもわぬところから不具合がでると気が滅入る。一貫性が損なわれるとメンテナンスコストが増えるし、なにより変更がおっくうになり、スピードが落ちてしまう。こんなコードが入り込んでしまったのは実装者の不理解もそうだし、レビュー不足も要因だ。大したことない手間で一貫性が保たれるのならば、動けばいいというのは言い訳にならない。あらためて統一感の大事さを実感し、原因がわかって情けない気持ちになった出来事だった。