犬も猫も空想も扱っておりません。(旧・エト記)この広告は、90日以上更新していないブログに表示しています。2008-07-28XPエクストリーム・プログラミング入門―変化を受け入れるBook私の持ってる唯一のXPの本だが,どうやらこれが原点らしいことを最近知った。経験豊富なプログラマからすると,この本に書いてあるのは本当に当たり前なことばかり。ソフトウェア開発のベタープラクティスを,うまくフレームワーク化したのがXPの功績なのだろうか。見る私がいつも,ライブラリの設計時に気をつけているのは「まだ無い機能を設計しない」ことである。「拡張可能性」を担保しておく必要はあるが,そのための抽象化はしない。抽象化の可能性だけを頭の中で一度考慮おけば良い。経験上,より具象的なものから抽象的なインターフェースへの変更はコンパイルエラーで検出できるような,安全な変更で実現できる。おまけにその変更は,純粋で無駄のない「機能追加」で,やってて納得度が高い仕事になる。その一方で,始めから抽象化しすぎたフレームワークは,本当に抽象的な機能を使いたくなったときには,最初の設計が古くなっていることが多い。結局,作り直すことになるんだけど,それは,抽象的なものからさらに抽象的なインターフェースを作成するか,既に抽象化されている仕組みを改良することになる。前者は,最初の無駄な抽象化に皮を被せることで,言い換えるならば単に「くさいものにフタ」する仕事。仕事を終えた後も,自分のプロダクトが無駄を内包したまま世に放たれるのを指をくわえて見ることになる。後者も後者で,過去の設計の不十分さの尻拭いに違いは無い。やってみれば分かるけど,モチベーションの上がらない仕事だ。これらは,未来の自分,あるいは後任者を悪い設計の被害者にしてしまう。いうわけで,初期実装の効率を考えても,ソフトウェアの改良の仕事を楽しくするためにも「まだ無い機能を設計しない」ことは重要なのである。これは私が開発の中で身に付けたものだと思っていたが,この本にも書いてあった。数年前に読んだときに頭の片隅に残っていたのだろう。問題Archiveはてなブログをはじめよう!xoinuさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。