🦇
バッチ処理を作るときに気をつけるようになったこと
素敵な夜ですね。
俺はWebエンジニアです。バッチについて、自分の考え方をまとめました。
考え方
1.ちゃんと作るときに作り込む
当たり前だが、リトライが面倒くさいなら面倒くさいほど、作る時に作り込みを徹底したほうが楽になる。
例えば速度が必要なものなら高速化の手札全部使ってきっちり作り込む。
2.何かあったらわかるようにする
必ずバッチにログを仕込む。エンジニアなら当然プライベートの開発では当然各所にログを仕込むはず。それをそのまま業務でもやる。
必要なアラートも出す。
3.可能な限り本番環境と近い環境を用意する
開発環境ではわからない事がたくさんある。
用意にコストがかかるとしても、相談すべき相手と相談する。
4.可能な限り全件比較チェックを行う
もちろんできるものとできないものがあるのは理解している。
例えば、機能を壊さずパフォーマンスチューニングするタスクでは全件比較調査する。リリース前後で２回実行して、差分がない事を確認すれば完了。
比較ツール
win使っていた際はWinMergeを使っていたが、最近知った限り大容量ファイルにはあんまり強くないようだ。
macなら、diffコマンドがベターか。
5.可能な限り冪等性的なものややり直し性を確保できるよう頑張る
下記を満たせるよう頑張る。
- 対象の操作や領域において、（関数型プログラミングでいう）副作用を起こさない事
- これがHTTP関連で使われている「冪等性」に近い定義だと認識しています。
- 正確に定義を理解しているわけではないのと、この言葉をそのままバッチ関連に使っていいのかわからなかったので、そのままの使用を避けています。いい言葉が思いつかなかったので頭の中で勝手にやり直し性と呼んでいます。
- 何度成功させても問題なく当初の想定を満たす事
- 導入に失敗したら最初からやり直せる事（たとえば、元のデータを破壊しない事）
- 途中で止まっても、再実行させれば当初の想定を満たす事（たとえば、失敗時すべてが完全にロールバックされないが、再実行すれば大丈夫な事）
- 途中で止まったままそのまま放置しても、全く困らない事（失敗時、全てが完全にロールバックされる等）
おわり
どんな問にも、たとえ完璧でなくても答えがあると信じており、バッチ作りも同じだと信じます。「バッチ作りに決まったノウハウがあるならそれでメシを食えるぜｗ」ってんなら皆でうまいメシを食いたいところです。
なにかご指摘等あれば
twitter:@kisihara_c
なお、以上は一般論であり機密情報とは一切関係がありません。
参考文献
Discussion