バッチ設計ガイドライン | フューチャー株式会社

本ガイドラインは、世の中のシステム開発プロジェクトのために無償で提供する。 ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社（以下、フューチャー）は一切の責務を負わないものとする。 また、掲載している情報は予告なく変更する場合があるため、あらかじめご了承いただきたい。 免責事項: 有志で作成したドキュメントである フューチャーには多様なプロジェクトが存在し、それぞれの状況に合わせて工夫された開発プロセスや高度な開発支援環境が存在する。本ガイドラインはフューチャーの全ての部署／プロジェクトで適用されているわけではなく、有志が観点を持ち寄って新たに整理したものである相容れない部分があればその領域を書き換えて利用することを想定している プロジェクト固有の背景や要件への配慮は、ガイドライン利用者が最終的に判断すること本ガイドラインに必ず従うことは求めて

[prograti]

内容はとても参考になるけどオンラインバッチとオフラインバッチが混ざり合っている感じがして構成はもう少し工夫の余地ありかも

[kent4989]

有益なまとめだが業務設計の要素は薄め。「バッチ処理とは、大量のデータを一括で処理するための手法」という定義には違和感もある。『データ処理を決まった時間やデータ量ごとにまとめて実行すること』ではないか。

[tmatsuu]

とてもよい。わいわい

[pmint]

バッチ処理であっても一般的なコーディングと何ら変わりない。なのに別物扱いされるのは、世の中コピペプログラマーが多いってこと。べき等性にはテーブルの使い回しを避ける。フラグは悪。JavaScript使いのconstと同じ。

[diabah_blue]

冪等性にも言及されていてよさそう。

[yohamta]

ガイドラインにある要件を満たす Airflow より手軽なワークフローエンジンを探しているなら、Go 言語製の Dagu もおすすめです。

[chikurou]

ガイドラインに沿わない設計をした場合にどんな悪影響があったのか、過去の事例とともに読みたいドキュメント。このガイドラインの確からしさはどうやって確認すれば良いか、とも

[FreeCatWork]

バッチ処理…？ボクは寝てたいにゃ。でも、ちゃんと動くように祈ってるにゃ！

[miguchi]

“Web API設計ガイドライン”

[shodai]

カレンダーは要らないのかな