プログラマの思索

「はじめてのGit」「key-value ストア」が読みたくて、WEB+DB PRESS Vol.50を初めて買った。
すごくイイ！

【WEB+DB PRESS Vol.50の気になる章】
特集2
ブランチもマージも簡単な分散型バージョン管理システム
はじめてのGit

特集3
Webアプリのパフォーマンス向上の一策
［旬のライブラリ大集合］key-valueストア入門

Java＋RDBの技術だけで、IT業界で一生飯は食っていけると思っていた。
でも、Webの世界では、特にGoogleの技術が世界中を席巻しているといっていい。
自分の技術が時代から少しずつ遅れてきている気がしてきた。

オブジェクト指向はもう古い。
MapReduce、レコメンドエンジン、Cookie Session Storeなどのように、リストやハッシュでデータを保持して比較計算する処理技術の方が重要になりつつある。
これは関数型言語の発想だと思う。

例えば、Rails2.0の機能の一つであるCookie Session Storeは、セッションを暗号化してクッキーに保持する。
このアーキテクチャがあれば、各クライアントの画面の状態はローカルPCのクッキーで保持するから、Webアプリをデスクトップアプリのように操作できる。
Webアプリの古くからの難問である「戻るボタン」「注文ボタンの2度押し」などにも、アプリ側で簡単に対応できるようになるだろう。

アジャイル開発では、分散バージョン管理のように、ブランチによる並行開発、そしてブランチ間の自動マージは必須の技術だ。
CVS→Subversion→Gitというバージョン管理の歴史を辿れば、仕様変更に強い特徴を持つアジャイル開発の発展と歩調を合わせて進化している。
この関係は多分偶然ではない。

特にGitは、ブランチ間のマージ機能が優れていると言われる。
だからこそ、分散バージョン管理で、複数のブランチがメインライン(trunk)とは別にたくさん作られても、精度の良いマージのおかげでブランチにもすぐに最新機能を反映できるし、ブランチで試したパッチがリリース可能な品質になったら、メインラインへマージして反映することもできる。

ソフトウェアプロダクトラインが提唱する手法では、製品ラインを中核機能やフレームワークを持つコア資産と、カスタマイズした製品ごとに複数のコードラインでブランチとして別々に管理する。
この手法の弱点は、メインラインとブランチでマージ機能が貧弱なため、ブランチがメインラインから独自発展しやすい危険性があること。
だが、分散バージョン管理の優れたマージ機能を使いこなせれば、ブランチによる並行開発は怖くなくなる。

そうなれば、突然の仕様変更や障害修正が降って来たとしても、ブランチを積極的に使って、新規開発中のメインラインと突然の対応を行うブランチの並行開発が可能になる。
この手法は、現代のアジャイル開発のプロジェクト管理では必須の技術だと思う。

XPが提唱したアジャイル開発の構成管理も、上記の技術によって、難易度が急激に下がりつつある。

最近の技術のトレンドに注意していきたい。