http://p0t.jp/archives/2008/07/wordpressweb.html
オープンソースをちょっとカスタマイズとか出来ると楽できていいですよね。
確かに、ソースコード見えると自分の気に食わないところとかちょいちょいと修正してしまえていいですよね。
作者はとにかく「サードパーティー開発者」と「ユーザー」に奉仕して、DRYに反していても誰にでもわかりやすいまま頑張ってスパゲッティにならないようにします。
より多くの「サードパーティー開発者」に気に入ってもらえるようにすることがひいてはプラグインの増加、ソフト自身の価値向上につながるんですね。
確かに、これもその通りだなと思います。使ってくれるユーザーとプログラム周りを協力してくれる他の開発者の存在は継続して開発する上でとても大切だと思います。
しかしここで問題なのが、バージョンアップしたらどうするの？ っていう。
- バージョンアップとのDiffを取って、マージする
- 作者に連絡して、バージョンアップ時に自分のカスタマイズを取り込んでもらう
という2つの方法があって、どちらもそれなりに現実的なんだけど、そして後者の方法でマージされたのも少なからずあってそれで機能とソースがどんどん増えていったっていうのもありなんだろうけど。
しかし、やっぱりほとんどのカスタマイズ作者は、前者の方法を涙を流しながらやるか、バージョンアップしない。 だがそれは、穴の多いWordPressにとって文字通り致命的ともいえる行為となる。
それに対する回答の一つが、XOOPSCubeのPreload+Delegateという方法。
要するに、コアコードのいたるところに、コードを修正しなくてもいいように処理を差し込めるフックポイントを作成しておく。
そこに、特定ディレクトリに処理のロード時に自動的に読み込むファイルを作っておき、そのファイルでフックポイントに作用を行う。
これはプラグインに似てるけど、あそこまでオートじゃないというか、プログラマ寄り。プログラムの挙動を根底から変えられる威力がある。
これで、基本的にバージョンアップ時にファイルが被る可能性はほぼゼロになり、Diffをとる必要はなくなる。もちろん、バージョンアップに伴い、その機能が動かなくなることはあるだろうけど、そんなのDiffをとるあの苦痛で生産性ゼロでプログラムのなんたるかを破壊された気分になる作業に比べれば「なんで動かなかったか」を考えることのなんて創造的なことよ！
http://po3a.blogspot.com/2007/12/subversion.html
ずっとまちがった問題を見てるんだ。ブランチが問題なんじゃない。マージが問題なんだ。
