ライブラリ等のバージョンにおいては、古いバージョンに切り替える機会よりも、新しいものに切り替える機会（とモチベーション）の方が多いため、一般的に上位互換性の方が重要視されます。（ただ、Excel等のアプリケーションが吐き出すデータファイルは、下位互換性が求められることも多いです。つまり、Excel2000で作ったデータはExcel97でも読める、等）

互換性が重要なケース

広く一般に使われるライブラリ（API）は、なるべく上位互換性を維持しようと務める必要があります。例えば、commons-langが互換性を失ったら、バージョンアップした時に、かなり多くのクライアントが壊れるでしょう。

ちなみに、commons-httpclient は、v4系のリリースのタイミングで、互換性を捨てました。v3系を使って組んだアプリケーションはv4系にバージョンアップするのに大きなコストが掛かります。まぁ、互換性が重要とは言え、一定のタイミングで互換性を捨てる、という作戦もあるのです。これは「技術的負債の返済」とも言えるでしょう。

そして仮に、Java自体が互換性を失ったら、もっと大変なことになります。従って、Javaは「上位互換性を大事にしている」と言われています。Java1.0時代に書いたコードやコンパイルしたクラスが、Java6でも普通にコンパイルできる・実行できるのは、互換性が最大限に考慮されているからです。「バージョンを上げても壊れない」という実績の積み重ねが信用につながり、これがJavaの利用領域拡大に一役買っているのは間違いないでしょう。

互換性が重要ではないケース

しかし、互換性を維持する、というのはコストのかかる作業です。例えば、一度リリースしたライブラリについて「このクラス名、よくなかったなー。名前変更のリファクタリングを掛けよう」ということは、おいそれと出来なくなるのです。名前が変わったら、クライアントのコンパイルは通らなくなりますからね。

そんなわけで、個人的に使うようなライブラリや、特定の狭い範囲のみで使うことを想定したものであれば、互換性はそこまで重要視されません。というのも、バージョンを切り替えた結果、クライアントが正しく動かなくなったとしても、それに対応するようにクライアント側を修正すれば済むからです。また、範囲が狭ければ狭いほど、なぜ互換性を失ったのか、どのように直せばいいのか、というナレッジが共有しやすい為、という理由もあります。

このように「互換性の維持（＝信用の積み重ね）」と「リファクタリング（＝設計の改善）」はトレードオフです。そのソフトウェアの性格や、開発方針、リファクタリングの重要度等を検討して、互換性を維持するかどうかを決定しなければいけません。

Jiemamyはどっちだ？

いやー、Jiemamyでも長い間「互換性維持」を意識してきました。しかしまぁ、毎度のバージョンアップで「ごめんなさい、やっぱり互換性維持はできませんでした」ということになるのですが。最近は気持ちを切り替えています。Jiemamyの本質はバージョン互換（安定したAPI）ではなく、開発プロセスにあることを再確認しています。だから、互換性を意識しすぎて開発が進まないのは、ちょっと本末転倒だったな、と。こだわりすぎるのも良くない。

という気持ちで。現在新しいAPIを鋭意開発中です。

baseunitsはどっちだ？

逆に、baseunitsに関しては「互換性維持」は重要なことだと思っています。APIを広く使ってもらいた、と考えていますし、初期から「安心して広く使ってください」と喧伝しているプロダクトです。厳しく考えれば、「MavenのgroupIdを変更する」だけでも、見知らぬ誰かのプロダクトを壊すことができるんです。

というわけでbaseunitsでは、このようなことがないように、以下のポリシーに従います。

一度リリースしたバージョンは、その内容を一切変更（修正）や削除（公開停止）しない。
なるべく互換性を失わないバージョンアップを心がける。
互換性を失う場合は、@Deprecated等で事前に警告する。
互換性を失うタイミングはメジャーバージョンアップのタイミングに限る。

つまり、こちらは名前の変更などよりも、互換性が大事なプロダクトです。余程のことがない限り、互換性の維持に努めます。安心してご利用ください。

2010-11-21

「区間」のソートあれこれ

etc Java

註：本エントリは等幅フォントで見ないと訳の分からない部分があります。Firefoxではきちんと見えるのですが、Google Chromeではなぜかmonospaceが等幅になりません…。というわけで、本エントリはFirefox推奨。SafariでもOKでした。IEは知らん。

さて、昨日の続きです。昨日は区間とは何かということを主に書いてきたのだが、今日はこれをどのようにソートしたらいいのか。あれこれ考えた結果、むしろ多分数学的に優位（有意？）なソートロジックってのは多分存在しないので、主観的にどれが一番理に適っていると感じるのかなぁ、というところをつついてみたい。

そんなわけで、解答はないので、ブクマとか※で、どれが一番イケてると感じたか*1、教えてほしいなぁ。今日は技術とか理屈の紹介じゃなくて、読者をアンケートに付き合わせて俺が考えを整理したいだけです、すみませんがお付き合いをば…。

*1:つまり、主観だ。

2010-11-20

数学的な「区間」の話を分かりやすく書いてみる

etc Java

数学用語に「区間」ってのがある。wikipediaによる解説はこちら。

ちなみに、wikipediaって数学系の事しらべると、もう意味わかんないよね、正直ｗ自分も数学の下地がある人種ではないので、正直数学系の話第だけはwikipediaをアテにできない。まぁ、誰でも分かるように書いてみよう。

わかりやすい「区間」

まぁ、簡単に言えば「5〜8まで」とか、そういう範囲をあらわす概念。で、6はこの区間に含まれるよね。7.5とかもこの区間に含まれる。10は含まれないし、-2も含まれない。じゃあ、5は？ 8は？

となった時に出てくるのが「開区間」とか「閉区間」ってやつ。境界値を含むのが閉区間で、含まないのが開区間。半開区間ってのもあって、片側だけ開いてて、もう片側は閉じてる奴。

さて、そろそろ言葉で表しづらくなってきたら記号の出番だ。記号は（自分を含め）数学アレルギーには苦手なものだけど、今回ばかりは簡単。5〜8までの開区間（境界含まない奴）は「(5, 8)」って書く。で、5〜8までの閉区間（境界含む奴）は「[5, 8]」って書く。丸括弧より角括弧の方が、広い範囲を括り取っているように感じるだろうから、直感的でもあると思う。

んじゃ半開区間はどうやって書くのか。まぁ大方の予想通り「[5, 8)」とか「(5, 8]」とか書く。括弧が一致してなくて一般的には気持ち悪いところだけど、そういうモンだと割り切り重要。

ちなみに、開いてるとか閉じてるとか、言葉が覚えにくい。含む方はどっちだっけ？なんていつも混乱する。そんな時は図を頭に浮かべよう（下図）。数直線上にこんな感じで範囲を明示すると考える。塗りつぶしたのは境界を含むって意味。白抜きは境界を含まないって意味。塗りつぶした方は閉じてて、白抜きは開いてる。穴がね。覚えられただろうか。