|
|
あなたのプロジェクトに基づいたコードを不安なく開発するために、
そして、コードの下にある絨毯が引き抜かれたことを常に注意を払わなくてもいいように、
以下のポリシーを設けます。
この問題を、きわめて重要なプラクティスとして扱うことが目的です。
-
すべての既存のクラスとメソッドを変更する場合、
非推奨化のフェーズを実行する必要があります。
これを行った場合、一部のAPIコードが汚くなる場合があることがわかっています。
それでも実行しなければなりません。
メソッドを非推奨にした場合、.javaファイルの一番下に移動することを推奨します。
-
非推奨化からそれを取り除くまでに、少なくともリリース1回分の期間を空ける必要があります。
1つ以上のバージョンリリースを待って、非推奨化したアイテムを取り除くことができますが、
バージョンをリリースしないで取り除くことはできません。
つまり、2.1で非推奨化にしたものを2.1.1リリースで取り除くことができます。
2.1と2.1.1の間の時間は月数ではなく日数で数えられるかも知れません。
非推奨化とそれを取り除くまでの実際のバージョン番号までの間、
メーリングリストで議論されるでしょう。
あなたは懸念事項を説明する機会があるでしょうし、我々はそれを考慮することができます。
主要な機能の変更は、おそらく2.1と2.1.1の間で取り除かないでしょう。
このような場合は2.2まで待って取り除くことになります。
あるプロジェクトにとって6ヶ月は十分な期間ではないかも知れず、
別のプロジェクトには2週間でも細かすぎるかも知れないため、
時間が重要ではないと感じています。
複数のリリースに渡った非推奨化に注目することで、
プロジェクトの特定のバージョン向けのコードを選択でき、
また少なくとも1つのリリースバージョンで安心してコンパイルできます。
また、それ以前の様々なリリースでコンパイルする機会も与えられるため、
漸増的なアップグレードを行って、次のリリースで正常動作しなくなるものを見つけ出すことができます。
-
メソッドを非推奨化したときは、必ず非推奨化されたメソッドと代替手段を記した文書を開発者メーリングリストに通知しなければなりません。
これによって、アーカイブを検索し、メソッドが推奨されなくなった時期と理由、
そして最新の手法へアップグレードする手続きを見つけることができます。
-
Javaコードではない、非推奨化できないアイテム(プロパティのキーの変更や、
DTDの修正)は、メーリングリストで文書化しなければなりません。
-
修正の最後の時点で、最新のコードの状態を反映するように文書を更新しなければなりません。
-
これらのルールに従わないパッチやコミットは拒否されるかも知れません。
そして、新しいパッチを投稿する、問題を修正する、CVSからコードを戻すことは、
修正をチェックインする、あるいはパッチを送信するその人の責任になります。
publicやprotectedの可視性を持つメソッドやクラスのシグニチャを変更することは、
そのメソッドやクラスに依存する誰かのコードを動作不能にする可能性を秘めています。
開発しているのはオープンソースソフトウェアであるため、誰かが自分たちのコードを使っているかどうか知る方法は全くありません。
変更の影響を最小にするために、非推奨化の概念を使用することは可能です。
コードに作業するときは、以下のガイドラインを意識して下さい:
-
既存のpublicやprotectedの可視性を持つメソッドやクラスを修正するときは、
まず既存のメソッドを推奨しないとマークします。
その上で古いものを新しく置き換えるものを作成します。
-
アプリケーションの外部で使用される可能性があるpublicやprotected
のクラスやインターフェイスを削除してはいけません。
その代わりに推奨しないことをマークします。
-
あるパッケージのコードを別のパッケージに移す場合は、
古いパッケージを非推奨化します。
そして、古いコードは新しいコードを参照する一時的な薄いラッパーに変更します。
推奨されないことで、将来ラッパーがなくなることを示します。
-
設定ファイルの変更は、foo->bar形式の行動予定リストを持てるように、
十分に文書化する必要があります。
-
データベーススキーマを変更する場合は、既存のデータベースを簡単に変換できるように、
スキーマを修正するALTER TABLEステートメントを提供する必要があります。
|
