バッチ処理の負債化は早い。理由はよくわからない。想像するに、普段ほとんど意識しないからどんな機能があるか忘れる、外部のシステムとつながっているので手動テストすらし辛い、処理が長い、などの理由がありそうだ。
バッチ処理は簡単に動作を再現できることが重要だ。もちろん、開発環境は用意してあるだろう。そこで本番に近しい結果を得ることはできるかもしれない。しかし、今動いている本番サーバーがどんな動きをするか簡単に確認出来てほしい。
例えば、一日に一回1週間ログインしていない人にメールを送るとする。そうであれば、今バッチ処理が実行されたら誰にどんなメールが送られるか確認できるようにしてほしい。出力形式はWebの画面でもCSVでもなんでもいい。このようにテスタブルにすることで微修正を重ねやすくなりソースの腐敗が防がれる。
これが実現可能であるということこそ、これまでこのブログで支持してきた副作用を抑えるプログラミングスタイルのメリットの一つである。
例えば先述のメールのバッチ処理の場合
- DBにQueryを発行する
- 1件ずつFetchし、メール送信対象者ならメールを送る
というバッチ処理ではドライラン機能をつけるのが難しい。しかし
- DBにQueryを発行する
- 1件ずつFetchし、メール送信対象者なら「メールを送る人配列」に追加していく
- まとめてメールを送る
というように書いておけば最後の3番をIF文で切り替えて「メールを送る人配列」をCSVに出力するだけで簡単にドライランが実装できる。
追記
本当に配列に入れちゃうとパフォーマンスとかヤバそうな場合あるので、その言語のイベントストリーム機能を調べよう。例えばGoならchannelの受信先を挿げ替えるだけで同じことが実現できる。