tabateeの日記： 最近した議論

自分も含めて以前にオープンソースのソフトウェアを書いていた人たちで自分たちの書いたソフトウェアの性質について議論する機会がありました。その場のメンツの書いたソフトウェアの特徴として(1)Computer Science系の手の込んだアルゴリズムとデータ構造を持ち、その部分は開発に参加する敷居が高い。(2)それらのソフトウェアの出力は比較的エンドユーザに見える形で利用される。このような特徴を持ったソフトウェアの開発には往々にして周辺を肥大化させてコアのメンテナンス性を悪化させる方向に圧力がかかってしまうという傾向があるんではないかという話がありました。

コアをいじる側の人間としては、自分のバックグラウンドと小難しい技術を振りかざして周辺の開発者を妨げるような最悪最低なことはしたくありませんし(そんなことするぐらいならどこか別の所へ行くべきでしょう、特にこれはオープンソースの話ですし)、周辺の開発者も悪意があってやっているわけではないはずです。
とは言っても、コアの側への理解の無い人間がフレームワークとか言ってたり、予算を取って(コアのメンテナンス性を犠牲にした上で)コアの部分以外で色々な成果っぽいものを出してたりすると、もっと適切なバランスはないものかと考えてしまいます。

コアと周辺のよくある誤解

[okky (2487)]

特にコア側によくある誤解ですが…

フレームワークはコアを守るためのもの

という視点が欠けている気がします。フレームワークは周辺の人たちのために存在するのではありません。彼らがコア側に食い込んでこないように排除するためのものです。

.

私も昔、商用システムでコア部分を書くようになるまで気がつかなかったのですが、フレームワークを作ったり、インターフェースだけ先に決めたりするのは、そうすれば周辺部がコアを侵食する気にならなくなるからなんですね。C++の private のようにプログラム言語レベルで明示的に防御壁を立てられない以上、コア内部に入り込んで勝手にインターフェースを変更されたり、勝手なフックを作ったりしないようにさせるには、周辺部の人たちより先にフレームワークを作って与えてやる必要がある。

逆にコア内部に踏み込まれると、整合性がなくなったり、酷いときにはバグの温床になったりして、本来やりたいことに集中できなくなります。これらを全部追い出して、インターフェースを切りなおすのに、当時はえらい苦労をした覚えがあります。

--
fjの教祖様