空想犬猫記

※当日記では、犬も猫も空想も扱っておりません。(旧・エト記)

XPエクストリーム・プログラミング入門―変化を受け入れる

私の持ってる唯一のXPの本だが,どうやらこれが原点らしいことを最近知った。経験豊富なプログラマからすると,この本に書いてあるのは本当に当たり前なことばかり。ソフトウェア開発のベタープラクティスを,うまくフレームワーク化したのがXPの功績なのだろうか。

XPエクストリーム・プログラミング入門―変化を受け入れる

XPエクストリーム・プログラミング入門―変化を受け入れる

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/12
  • メディア: 単行本
  • 購入: 3人 クリック: 55回
  • この商品を含むブログ (64件) を見る

私がいつも,ライブラリの設計時に気をつけているのは「まだ無い機能を設計しない」ことである。「拡張可能性」を担保しておく必要はあるが,そのための抽象化はしない。抽象化の可能性だけを頭の中で一度考慮おけば良い。経験上,より具象的なものから抽象的なインターフェースへの変更はコンパイルエラーで検出できるような,安全な変更で実現できる。おまけにその変更は,純粋で無駄のない「機能追加」で,やってて納得度が高い仕事になる。

その一方で,始めから抽象化しすぎたフレームワークは,本当に抽象的な機能を使いたくなったときには,最初の設計が古くなっていることが多い。

で,結局,作り直すことになるんだけど,それは,抽象的なものからさらに抽象的なインターフェースを作成するか,既に抽象化されている仕組みを改良することになる。前者は,最初の無駄な抽象化に皮を被せることで,言い換えるならば単に「くさいものにフタ」する仕事。仕事を終えた後も,自分のプロダクトが無駄を内包したまま世に放たれるのを指をくわえて見ることになる。後者も後者で,過去の設計の不十分さの尻拭いに違いは無い。やってみれば分かるけど,モチベーションの上がらない仕事だ。これらは,未来の自分,あるいは後任者を悪い設計の被害者にしてしまう。

というわけで,初期実装の効率を考えても,ソフトウェアの改良の仕事を楽しくするためにも「まだ無い機能を設計しない」ことは重要なのである。

てっきりこれは私が開発の中で身に付けたものだと思っていたが,この本にも書いてあった。おそらく数年前に読んだときに頭の片隅に残っていたのだろう。