なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

この記事を読んでいる場合は、しばらくの間Project Lombokを知っている必要があります。ロンボクを受け入れる準備はできていますか?それとも、このようなクールなプロジェクトをチームに推奨する準備ができていますか?準備ができたら、ロンボクを1年間使用した後の私の気持ちを聞いてみてください。

Lombokは非常に優れたJavaライブラリであることを認めています。これにより、少ないコードで簡単に記述できます。いくつかの単純な注釈は、大きなテンプレートコードを殺す可能性があります。ただし、ほとんどのソースコードは読み取りに使用され、実行にはほとんど時間がかかりません(詳細にこの文を読むことができます)。

なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

 

1年前、ほとんどの人と私はLombokの登場によりJavaコーディングエクスペリエンスが改善されると考え、チームにLombokを強くお勧めしました。1年後、私はこれについて心配し始めました。特に、オープンソースのブログシステムであるUna-BootのJavaバージョンをアップグレードする準備をしているときに、Lombokがトリックトラップに陥っていることに気付きました。さらにソースコードを分析し、関連するソリューションの動作原理を理解したところ、非標準のサードパーティライブラリを使用してJavaを洗練されたクールな言語に変換する必要がないことがわかりました。ロンボクの導入により私のプロジェクトは一時的に救済されましたが、一時的な救済の代償として、プロジェクトが進むにつれて技術的負債が蓄積し始めました。

次に、おなじみのいくつかのシーンを使用して、ロンボク島のトリックトラップに陥った方法を繰り返します。

愛の始まり、憎しみの起源

なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

 

Lombokが提供する多くの「神の位置」に直面すると、IDEにプラグインを追加してもかまいません。IntelliJ IDEAプレーヤーの場合、「Lombokプラグイン」を検索して、このアーティファクトを見つけてインストールします。LombokプラグインをインストールすることからLombokに恋するようになり、それ以来憎しみが芽生えています。

Lombokが使用される前は、ソースコードは次のようになっています。

public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;
    public Long getId(){
        return id;
    }    public void setId(Long id){
        this.id = id;
    }    public String getName(){
        return name;
    }    public void setName(String name){
        this.name = name;
    }    public int getAge(){
        return age;
    }    public void setAge(int age){
        this.age = age;
    }    public int getGender(){
        return gender;
    }    public void setGender(int gender){
        this.gender = gender;
    }    @Override
    public boolean equals(Object o){
        if(this == o){
            return true;
        }        if(o == null || getClass() != o.getClass()){
            return false;
        }        MyObject obj = (MyObject) o;        return age = obj.age &&
            gender = obj.gender &&            Objects.equals(id,obj.id) &&            Objects.queals(name,obj.name);    }    @Override
    public int hashCode(){
        return Objects.hash(id,name,age,gender);
    }    @Override
    public String toString(){
        return "MyObject{"+
            "id="+id+
            "name="+name+
            "age="+age+
            "gender="+gander+
            "}";
    }}

 

なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

 

各JavaBeanは、上記のgetter、setter、equals、hashCode、およびtoStringなどのテンプレートコードで埋められます。これは太っている人のように見えます(Javaが欠陥のあるプログラミング言語であることを認める必要があります)。Lombokプラグインをインストールすると、IDEはそのクールなアノテーションを認識できます。Lombokの@Getterおよび@Setterアノテーションを使用すると、コードは次のようになります。

@Getter
@Setter
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;
    @Override
    public boolean equals(Object o){
        if(this == o){
            return true;
        }        if(o == null || getClass() != o.getClass()){
            return false;
        }        MyObject obj = (MyObject) o;        return age = obj.age &&
            gender = obj.gender &&            Objects.equals(id,obj.id) &&            Objects.queals(name,obj.name);    }    @Override
    public int hashCode(){
        return Objects.hash(id,name,age,gender);
    }    @Override
    public String toString(){
        return "MyObject{"+
            "id="+id+
            "name="+name+
            "age="+age+
            "gender="+gander+
            "}";
    }}

現在のコードはもっとクールに見えますか?しかし、これは最高の時間ではありません。他のメソッドが置き換えられたため、toStringメソッドも削除します。必要に応じて、@ ToStringアノテーションを使用して、対応するメソッドを削除できます。

@Getter
@Setter
@EqualsAndHashCode
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;
    @Override
    public String toString(){
        return "MyObject{"+
            "id="+id+
            "name="+name+
            "age="+age+
            "gender="+gander+
            "}";
    }}

ロンボクのトリックの後、最初のコードと比較して、それはクールでスリムでセクシーに見えますか?これで終わりだと思いますか?それだけではありません。クラス名の大きなアノテーションは扱いにくいように見えるLombokには、クラス名の先頭にあるXiangのようなものを置き換えることができる組み合わせアノテーション@Dataが用意されています。

@Data
public class MyObject{
    private Long id;
    private String name;
    private int age;
    private int gender;
}

さて、ロンボクはあなたのオブジェクトをあなたの心の中で完璧な見た目にしますか?悪魔の「体」はクールで洗練されています。Lombokには、@ Slf4j、@ NoArgsConstructor、@ AllArgsConstructorなどの他のいくつかのアノテーションもあります。Lombokの使用法の紹介は、この記事の焦点では​​ありません。

なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

 

上記のコードの行数の変化が、無数のプログラマーがロンボクに恋をする主な理由かもしれません。肥満の人が次第にスリムになる人のようです。また、現象を見てみましょう:プログラマーは怠惰だと思いますか?時々彼らはあなたが思うより怠惰です。クールな間、それはまたコードの悩みの種を植えました。

歪んだ美学、隠された愛の危険

美観が歪むと、検査対象の状態が正常以下になります。Lombokプラグインを使用した後も、コードは「正常以下」の状態にあります。冒頭の文章に戻ると、ほとんどすべてのソースコードがほとんどの時間読み取りに使用され、実行にはほんの少しの時間が使用されます。

なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

 

基本的に、プログラムのボイラープレートコードを減らしてコードをより簡潔にし、コードの可読性と保守性を向上させることを目指しています。しかし、Lombokは、私たちが追求しているビジョンを達成していません。コンパイル時にJava言語のギャップを使用し、賢い方法を使用して、必要なメソッドを現在のクラスに挿入(書き込み)します。このプロセスでは、この種のプロセスは、コードをハッキングするのによく似ています。この種のトリックはスマートで安全ではありませんが、Javaコードの既存の機能とコードの可読性を破壊します。以下に、ロンボクを使用した後の私自身の感情と合わせて、ロンボクによって引き起こされる主な苦痛について話してください。

1. JDKバージョンの問題

既存のプロジェクトのJDKをJava 8からJava 11にアップグレードしたいのですが、Lombokが正しく機能していないことに気付きました。したがって、プロジェクトのソースコードからすべてのLombok注釈を削除し、IDEの組み込み関数を使用して、getter / setter、equals、hashCode、toString、およびコンストラクターメソッドを生成する必要がありました。Delombokツールを使用してこのプロセスを完了することもできます。しかし、これは最終的に多くの時間を消費します。

2.強制使用

ソースコードでLombokを使用していて、コードが他のユーザーによって使用されている場合、コードに依存するユーザーは、Lombokプラグインも(それが好きかどうかに関わらず)インストールし、Lombokを理解するために時間を費やす必要があります。アノテーションを使用すると、それを行わないと、コードが正しく実行されません。Lombokを使用した後、これは非常に不正な動作であることがわかりました。

3.読みにくい

LombokはJavaBeanカプセル化の詳細を隠します。@ AllArgsConstructorアノテーションを使用すると、オブジェクトを初期化するときに、クラスのすべてのプロパティを変更する機会を外部に提供する巨大なコンストラクタが提供されます。まず、クラスの特定の属性を変更したくないため、これは非常に安全ではありません。さらに、特定のクラスに数十の属性がある場合、数十のパラメーターを含むコンストラクターが存在します。 Lombokはクラスに注入されますが、これは不合理です。2番目に、コンストラクターパラメーターの順序はLombokによって完全に制御され、制御できません。デバッグが必要な場合にのみ、奇妙な「Xiaoqiang」が待っています;最後に、コードを実行する前に、すべてのJavaBeanメソッドでそれらがどのように見えるかを想像するだけで、それらを見ることができません。

4.コード結合の増加

Lombokを使用して特定のモジュールのコードを記述する場合、このモジュールに依存する他のコードでLombokの依存関係を導入する必要があります。同時に、LombokプラグインをIDEにインストールする必要があります。Lombokの依存関係パッケージは大きくありませんが、Lombokが1つの場所で使用されているため、他のすべての証明書利用者はLombokのJarパッケージに参加する必要があります。これは侵入型の結合です。JDKバージョンの問題が再び発生した場合は、これは災害になります。

5.利益は損失の価値がない

Lombokを使用すると、しばらくは快適ですが、コードを汚染し、Javaコードの整合性、可読性、安全性を破壊し、チームの技術的負担を増やします。これは、メリットを上回る一種の害です。操作。読みやすさとコーディング効率を考慮しながら、コードをさらに洗練させたい場合は、JVMベースの言語であるメインストリームScalaまたはKotlinを使用することもできます。

なぜ私たちの会社はロンボクをあきらめるのですか?それはコードを「サブヘルシー」状態にするからです

 

総括する

Lombok自体は優れたJavaコードベースです。巧妙な構文糖を使用してJavaのコーディングを簡素化し、Javaコードを合理化する方法を提供します。ただし、このコードベースを使用する場合、Lombokは標準Javaライブラリ。Lombokを使用すると、チームの技術的負担が増え、コードの可読性が低下し、コードの結合とデバッグの難易度が上がります。Lombokはボイラープレートコードの記述をある程度減らしますが、いくつかの未知のリスクももたらします。チームプロジェクト(または大規模プロジェクト)に参加している場合は、その後のアップグレードと拡張を考慮して、Lombokを使用するかどうかをチームと連絡し、よく考えてください。

おすすめ

転載: blog.csdn.net/qq_45401061/article/details/108740773