いわゆる「ふりかえり」にKPT（Keep, Problem, Try）というフォーマットを使うことはよくあると思います。KPTって何？という方はこちらの書籍をどうぞ！ エンジニアはKPTのProblemに知識の無さを挙げがち ことエンジニアの職場だと、KPTのProblemに「◯◯がよく分かっていない」みたいな項目を挙げがちなのかなー、と思います。 例えば、 ActiveRecordがよく分かっていない（ので、作業に時間がかかった） 正規表現がよく分かっていない（ので、プルリクを差し戻されまくって時間がかかった） Rubyがよく分かっていない（ので、既存コードが上手く読めなくて時間がかかった） みたいな感じ。 これでTryが「もっと勉強する」・・・みたいな感じになるのですが、そのTryはゴールが全然見えないのでTryになっていないし、そもそもこれが「問題」だとは思えないんですよねー。 そも

リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ