博士

やあ、ロボ子。今日は「苦痛指向プログラミング」について話すのじゃ。

ロボ子

苦痛指向プログラミング、ですか？なんだか物騒な名前ですね。

博士

ふむ、これは「技術は、それがないことの苦痛を感じるまで構築しない」という考え方に基づくものなのじゃ。つまり、本当に必要になるまで、複雑なものは作らないということ。

ロボ子

なるほど。大規模プロジェクトのリスクを減らすための開発スタイルなのですね。

博士

そう、「重要なことに常に取り組み、大規模な投資を行う前に問題領域を熟知する」のが大事なのじゃ。

ロボ子

記事には「まず可能に、次に美しく、そして速く」という原則が書かれていますね。

博士

その通り！フェーズ1は「まず可能に」。問題領域に不慣れなときは、最初から「一般的」な解決策を作ろうとしないのじゃ。目の前の問題を直接解決する。

ロボ子

例えば、キューとワーカーを使ってストリーム処理システムを構築する、という例が挙げられていますね。

博士

そうじゃ。それで、データ処理の保証や、クラスタによるリアルタイム計算のスケーリング、メッセージストリームの分割について学ぶのじゃ。

ロボ子

フェーズ2は「次に美しく」ですね。問題領域の「マップ」を作成し、既存のシステムを置き換える。

博士

そう、「既存のユースケースを解決する最も単純な抽象化を見つける」のじゃ。パフォーマンスとリソース特性も理解する必要があるぞ。

ロボ子

リアルタイム計算の問題領域を、ストリーム、スパウト、ボルト、トポロジーという抽象化に集約する、というのは具体的にどういうことですか？

博士

ふむ、例えば、Twitterのリアルタイム分析を考えてみるのじゃ。ストリームはツイートの連続、スパウトはツイートを収集する部分、ボルトはツイートを分析してトレンドを抽出する部分、トポロジーはそれら全体の構成、という感じじゃな。

ロボ子

なるほど、少し分かってきました。

博士

フェーズ3は「そして速く」。プロファイリングと最適化に時間を投資するのじゃ。マイクロ最適化でコードを締め付ける！

ロボ子

最後に反復ですね。新しい機能で、問題領域の新しい領域を「可能にする」。抽象化を調整したり追加したりして、より多くのユースケースを処理する。

博士

そう、リファクタリングに重点を置くのじゃ！

ロボ子

ユースケースが重要で、経験を通じてユースケースを獲得し、現実のユースケースによって設計を推進する、と。

博士

その通り！苦痛を感じる前に無駄なものを作るな、ということじゃな。

ロボ子

よくわかりました。ところで博士、この「苦痛指向」って、なんだかお腹が痛くなりそうな名前ですよね。

博士

ふふ、ロボ子もそう思うか？でも、安心してくれ。このプログラミングを実践すれば、お腹の痛みを感じる前に、問題を解決できるはずじゃ！