文献やネットを調べれば、どこかにあるのかもしれない。
入社3年目の頃、目から鱗が落ちるというか、ちょっとした感動、感銘を受けた良い設計の話。
とあるバッチ処理で感銘を受けた良い設計
I.感銘を受けた良い設計
II.業務要件通りの設計なのだが、今一歩足りていない設計
何故感銘を受けたか？
業務要件では、「○○に合致したトランザクションレコードを削除のこと」というものでした。
そのまま写像すれば、II.の設計になると思いますが、I.の方が多少手間はかかっていますが、色々良いことがあり、それで感銘を受けました。
感銘を受けたこと(1)：テストがしやすい
①.削除対象リストを作るまでで、JOBを止めることができるので、要件通りに削除対象が抽出されているかテストしやすい。
(脱線：この「テストしやすい」については、他にも思うことがり、別記事を書きたいことです)。
上記II.の設計だとトランザクションレコードが一気に削除されるので、再度テストしようとすると、トランザクションデータの戻しが必要になってしまいます。数件のデータなら良いですが、稼働中の本番データをテスト用に持ってきていたりすると、まぁ大量データになり、戻すのも面倒です。
②．削除対象リストがあるので、顧客側含め皆が検証しやすい。
削除対象がリストになっているので、顧客側の受け入れテストの検証がしやすいです。
よく考えると、最初の業務要件にはなかったですが、結局受け入れテストで何らかの形でリスト化するなどが必要であり、結果的には、顧客の合意を得た設計なので、業務要件通りに作っていることになるのですが・・・。
感銘を受けたこと(2)：業務要件を分析(分けて明確にすること)し設計する
業務要件の「○○に合致したトランザクションレコードを削除のこと」の「○○」の部分はこんなに簡単ではなく、非常に複雑なものでした。これを設計した人は、業務要件を複雑な領域と単純な領域に明確に分け、複雑な領域は何度もテストできるようにしていました。
(あぁ、「何度もテストできる」、なんと素敵なことだろう)
当初の業務要件を一旦ちゃんと受け止めて、さらに一工夫しているところが、いかにもエンジニアっぽくて、良い設計だと感銘しました。
感銘を受けたこと(3):リリース後の初回稼働確認もしやすい
何よりよかったんは、リリース後の初回稼働の前日に「削除対象リスト」を作るJOBだけを動かして、本当にリストの内容が正しいか、顧客側含め確認できたことです。
応用編：リランしやすいバッチ処理の設計
教科書的にはバッチ処理では障害発生時の再実行(リラン)を考慮して設計しなさいなのですが、具体的にどうすればよいのかと思っていました。
この設計に出会ってから、実はリランを考慮したバッチ処理の設計にも使えると考え実践し、今では定石としてよく使っています。
また、さっきの今一歩の設計の登場ですが、
「何らかの処理」からすると、「トランザクションデータ」に不都合なデータがあって、異常終了したとします。
不都合なデータが簡単に取り除けない場合、例えば、外部システムの持ち物であったり、正しいデータであるため、「何らかの処理」の都合では削除できない等の時どうるすか？
「何らかの処理」を何とか修正して、リランするでしょう。時間的な余裕がなかったらどうする？・・・とかいろいろ面倒です。
こんな時、よい設計の方は、
「対象リスト」のファイルから不都合なデータを削除してしまえばリランができます。
※もちろん万能ではなく、最初の対象リストを作るところで異常終了してしまうとダメですが。ただ、ここは何回もテストしているところなので、かなり安定稼働しているところでもあります。