web-dev-qa-db-ja.com

貢献する意図がない場合、代替手段が利用できない場合を除いて、オープンソースフレームワークのコードを変更してはなりませんか？

プロジェクトでオープンソースフレームワークを使用していて、そのフレームワークに貢献（変更を送信）せず、現在のバージョンが安定していると仮定します。可能な場合はフレームワークを変更しないでください。

たとえば、フレームワークのクラスで関数が私の要件を満たしていないことがわかった場合：

public class Fruit{
    public float calculatePrice(){
        return weight*1.2;
    }
}

要件を追加するためにラップします。

public class MyFruit{
    Fruit fruit;
    public float calculatePrice(){
        return fruit.calculatePrice()*myConstant;
    }
}

fruitを直接変更する代わりに、別の例として、クラスで保護されたプロパティを使用する必要がある場合（例：locale）：

public class Fruit{
    protected String locale;
}

ロケールにアクセスするために拡張します

public class MyFruit{
    public void checkLocale(){
        if(locale.equals("abc")){
        }
    }
}

ロケールをパブリックに変更する代わりに。

その背後にある動機は次のとおりだと思います。

  1. フレームワークのリソース（例：チュートリアル、動作、バグ、問題）は、フレームワークの元のバージョンに基づいています。フレームワークを直接変更すると、リソースが変更されたフレームワークに適用されなくなったり、適用されなくなったりする可能性があります。リソースを直接使用できる（例：オンラインの例をコピーして貼り付ける）

  2. フレームワークが元の外観を維持している場合、フレームワークをアップグレードする方が簡単です

  3. フレームワークでコードを変更すると、フレームワークにバグが発生する可能性があり、フレームワークのデバッグはカスタムコードのデバッグよりも困難です。

  4. フレームワークを元のバージョンに維持すると、ほとんどの拡張機能が元のバージョンに基づいて機能するため、フレームワークに他の拡張機能を簡単に追加できます。

  5. カスタムの変更されたフレームワークを使用する場合、フレームワークの変更された部分を投稿して説明する必要がある場合があるため、助けを求めるのはより困難です。

  6. 問題が発生した場合、元のバージョンを使用するだけで、ボランティアがフレームワークを直接ダウンロードしてからコードを追加できるため、環境をセットアップしてから再現して問題を見つけることがより迅速かつ簡単になります。

可能であれば、フレームワークのコードを直接変更してはならないというのは本当ですか？そして、この態度は正しいですか？

open-sourcemaintainability
1
ggrr

変更を送信するつもりがない限り、フレームワークを変更しないという経験則は、ほとんどの場合実用的なものです。これを行うたびに、フレームワークを新しいバージョンに更新するたびに変更を再適用することを約束します。更新後に変更を再適用するのを忘れた場合、またはフレームワークが問題のコードを変更して変更が機能しなくなった場合、アプリケーションでエラーまたは予期しない状態が発生します。それは完全に、利益がリスクと余分な作業の価値があるかどうかの問題です。

変更されたコードが配布される場合、アップストリームコードに含めるために変更を送信しないことについての哲学的な質問がある可能性があります。それは オープンソースベータ でよりよく対処されるでしょう。

2
Todd Knarr