プログラミングの未来を予測する方法――過去に学ぶことが最強の戦略である理由

なぜRailsはあれほど速く普及したのか？

Railsがなぜこれほど短期間で爆発的な人気を獲得したのか、不思議に思ったことはありませんか？

シンプルさは大きな要因でした。特にJavaとXMLにまみれた「エンタープライズ」の世界から移ってきた開発者にとって、その簡潔さは衝撃的だったはずです。また、マーケティングも見事に行われていました。しかし、それだけが理由ではありません。

Railsがスタートアップの世界で成功した最大の理由は、実にシンプルな事実にあります。ビジネスが抱える問題は、それほど特殊なものではないということです。RailsはCRUDサイトの構築に長けていながら、柔軟性も保っていました。そして、それは多くのビジネスにとって必要なすべてであり、特に創業期においてはなおさらです。

しかしこれは、ビジネスだけに当てはまる話ではありません。私たちソフトウェア開発者が直面する問題の多くは、実はほとんど変わりません。確かにソリューションは進化し、循環し、私たちはより良いエンジニアになっていきます。それでも、前世代の開発者たちが発見した解決策は、今日の私たちにも依然として役立つのです。

では、将来直面する問題への答えを知りたいなら、どうすればよいのでしょうか？　最善の方法は、過去に目を向けることです。

過去に学ぶ

Martin Fowlerのウェブサイトには、よくある問題に対する優れた解決策が驚くほど豊富に集められています。最近開発者の間で話題のEvent Sourcing（イベントソーシング）について聞いたことがありますか？　彼は10年前に、このテーマに関する決定的な記事をすでに書いています。新しいREST APIやサービス指向アーキテクチャ（SOA）で、パフォーマンスや信頼性の問題に悩んでいませんか？　その答えは、約15年前に彼が提唱した「分散オブジェクト設計の第一法則」の中にあります。

Avdi Grimmはこう語っています。「技術の波の先端を行きたいなら、Martin Fowlerが10年前に書いていたことに目を向けろ」と。まったくその通りです。彼のサイトにあるパターンを読み込む時間は、あなたのプログラミングの未来への素晴らしい投資になるでしょう。リファクタリングのパターンについては、言うまでもありません。

さらに踏み込めば、アジャイルマニフェストの署名者たちが著した本や記事は、ほぼすべて読む価値があります。15年前、彼らは今の私たちが直面しているのと同じソフトウェアアーキテクチャの問題に取り組んでいたのです。

彼らの議論の多くは、C2 Wikiで見つけることができます。TDDが最も効果を発揮するのはどんな場面か、といった現代の議論は、すべてそこにあります。しかも、ずっと昔からずっと存在していたのです。このWikiには長い歴史がありますが、今なお第一級のリソースであり続けています。

90年代後半から2000年代前半の書籍も大いに役立ちます。私は『Smalltalkベストプラクティス・パターン』や『エンタープライズアプリケーションアーキテクチャパターン』（Railsに多大な影響を与えた一冊です）を読みながら、終始笑みがこぼれていました。自分が経験してきた問題が、あまりにも的確に描写されていたからです。

ファッションの流行と同じように、ソフトウェア開発の手法も循環します。分散型から集中型へ、クライアントサイドからサーバーサイドへ、動的型付けから静的型付けへ。

一歩先を行き、何が来るのかを理解し、ひいては次の潮流を自ら牽引したいと思いませんか？　過去に目を向けてください。現在のソリューションが将来引き起こす問題に対する、過去の解決策を研究するのです。そして、前世代のソフトウェア開発者たちの優れた実践を、次の世代へと受け継いでいきましょう。