博士

ロボ子、今日はソフトウェア技術のスケーラビリティについて話すのじゃ。

ロボ子

スケーラビリティ、ですか。博士、詳しく教えてください。

博士

例えば、小規模ではすごく便利なのに、規模が大きくなると途端に使い物にならなくなる技術があるのじゃ。最初は良くても、後で負債になるパターンじゃな。

ロボ子

なるほど。具体的にはどんなものがあるんですか？

博士

まず、シェルスクリプトじゃな。ちょっとした自動化には便利だけど、`if`文が増えてきたら、Pythonとかに書き換えるべきなのじゃ。

ロボ子

確かに、複雑なロジックをシェルスクリプトで書くと、メンテナンスが大変になりますね。

博士

そうじゃろ？大規模なシェルスクリプトの例としてDevStackが挙げられるのじゃ。

ロボ子

DevStackですか。大規模なプロジェクトでシェルスクリプトが使われているんですね。

博士

次に、Makefileじゃ。単純なタスクランナーとしては便利だけど、大規模になると悪夢なのじゃ。Maven、Gradle、Bazelが出てきた理由もそこにあるのじゃ。

ロボ子

Makefileも規模が大きくなると管理が難しくなりますね。Recursive Make Considered Harmfulという論文があるくらいですし。

博士

よく知ってるの。ロボ子、賢いのじゃ！

ロボ子

ありがとうございます、博士。

博士

YAMLもそうじゃな。30行以下の構成ファイルとしては便利だけど、大規模なYAMLファイルの編集は地獄じゃ。

ロボ子

YAMLはコメントが書けないのがつらいですよね。大規模になると可読性が落ちてしまいます。

博士

スプレッドシートも要注意じゃ。ビジネスの現場でよく使われるけど、データベースとして進化し始めると問題なのじゃ。移行も大変だし。

ロボ子

スプレッドシートは手軽に使えますが、データの整合性を保つのが難しいですよね。

博士

最後に、Markdownじゃ。小規模なドキュメントには良いけど、書籍全体を記述するには向いてないのじゃ。Hillel Wayneの記事にも書いてあるぞ。

ロボ子

Markdownはシンプルで書きやすいですが、複雑な構造を表現するのは難しいですね。

博士

そういうことじゃ。技術を選ぶときは、将来的な規模も考慮に入れるのが大事なのじゃ。

ロボ子

勉強になります、博士！ところで、博士の部屋のコードも大規模化してきていませんか？

博士

うっ…それは言わない約束じゃ！まあ、私の場合は、大規模なカオスを楽しむのが目的なのじゃ！