Pourquoi notre société abandonne-t-elle Lombok? Parce que cela met le code dans un état "sous-sain"

Si vous lisez cet article, vous devez connaître Project Lombok depuis un certain temps. Êtes-vous prêt à adopter Lombok ou êtes-vous prêt à recommander un projet aussi cool à votre équipe? Si vous êtes prêt à le faire, vous pourriez aussi bien écouter certains de mes sentiments après avoir utilisé Lombok pendant un an.

J'avoue que Lombok est une très bonne bibliothèque Java, qui vous permet d'être cool tout en écrivant moins de code. Quelques simples annotations peuvent tuer un gros morceau de code de modèle. Cependant, la plupart du code source est utilisé pour la lecture et très peu de temps pour l'exécution (vous pouvez lire cette phrase en détail).

 

Il y a un an, la plupart des gens et moi pensions que l'avènement de Lombok améliorerait l'expérience de codage Java, et j'ai fortement recommandé Lombok dans mon équipe. Un an plus tard, j'ai commencé à m'inquiéter à ce sujet, surtout lorsque je me préparais à mettre à niveau la version Java du système de blog open source Una-Boot, j'ai réalisé que Lombok était tombé dans un piège. Après avoir analysé plus en détail le code source et compris le principe de fonctionnement de la solution pertinente, j'ai constaté que je n'avais pas besoin d'utiliser une bibliothèque tierce non standard pour convertir Java en un langage sophistiqué et cool. L'introduction de Lombok a donné à mon projet un soulagement temporaire, mais le prix de l'allègement temporaire était qu'au fur et à mesure que le projet avançait, la dette technique commençait à s'accumuler.

Ensuite, j'utiliserai quelques scènes familières pour répéter comment je suis tombé dans le piège de Lombok.

Le début de l'amour, l'origine de la haine

 

Face aux nombreuses "positions divines" fournies par Lombok, cela ne vous dérange pas d'ajouter un plug-in à l'IDE. Pour les joueurs IntelliJ IDEA, recherchez simplement "Lombok Plugin" pour trouver cet artefact et l'installer. Tomber amoureux de Lombok a commencé par installer le plug-in Lombok, et la haine a germé depuis.

Avant que Lombok ne soit utilisé, notre code source ressemblait à ceci:

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+
            "}";
    }}

 

 

Chaque JavaBean sera rempli de code de modèle tel que le getter, le setter, l'égal, le hashCode et le toString ci-dessus, qui ressemble à une grosse personne (il faut admettre que Java est un langage de programmation défectueux). Après avoir installé le plug-in Lombok, l'EDI peut reconnaître ses annotations intéressantes. Après avoir utilisé les annotations @Getter et @Setter de Lombok, le code aura l'air mince comme suit:

@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+
            "}";
    }}

Le code actuel a-t-il l'air beaucoup plus cool? Mais ce n'est pas le meilleur moment. Les autres méthodes ayant été remplacées, supprimez également la méthode toString. Comme vous le souhaitez, vous pouvez utiliser l'annotation @ToString pour supprimer la méthode correspondante:

@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+
            "}";
    }}

Après l'astuce de Lombok, par rapport au code initial, est-ce que ça a l'air cool, mince et sexy? Pensez-vous que ce soit la fin? C'est bien plus que ça. Vous constaterez qu'une annotation volumineuse sur le nom de la classe semble gênante. Lombok fournit une annotation combinée @Data, qui peut remplacer l'élément de type Xiang en tête du nom de classe:

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

Maintenant, est-ce que Lombok fait de votre objet le look parfait dans votre esprit? Le «corps» du diable est cool et raffiné. Lombok a également d'autres annotations, telles que @ Slf4j, @NoArgsConstructor, @AllArgsConstructor, etc. L'introduction de l'utilisation de Lombok n'est pas l'objet de cet article.

 

Le changement du nombre de lignes de code ci-dessus peut être la principale raison pour laquelle d'innombrables programmeurs tombent amoureux de Lombok, c'est comme une personne obèse devenant progressivement une personne mince. Voyons aussi un phénomène: pensez-vous que les programmeurs sont paresseux? Parfois, ils sont plus paresseux que vous ne le pensez. Bien que cool, il a également planté le fléau du code.

Esthétique déformée, dangers cachés de l'amour

L'esthétique déformée entraîne un état sous-sain de l'objet examiné. Après avoir utilisé le plugin Lombok, notre code est également dans un état "sous-sain". Revenir à la phrase du début: Tout le code source est utilisé pour la lecture la plupart du temps, et seul un peu de temps est utilisé pour l'exécution.

 

Essentiellement, nous cherchons tous à réduire le code standard dans le programme pour rendre le code plus concis et concis, améliorant ainsi la lisibilité et la maintenabilité du code. Mais Lombok n'a pas atteint la vision que nous poursuivons: il utilise simplement le vide du langage Java au moment de la compilation et utilise une manière intelligente d'injecter (écrire) les méthodes dont nous avons besoin dans la classe actuelle. Dans ce processus, ce genre de processus est un peu comme le piratage de notre code, juste une astuce cool. Ce type d'astuce n'est ni intelligent ni sûr, mais détruira les fonctionnalités existantes du code Java et la lisibilité du code. Ci-dessous, combiné avec mes propres sentiments après avoir utilisé Lombok, parlez des principaux points de douleur causés par Lombok.

1. Problèmes de version JDK

Lorsque j'ai voulu mettre à niveau le JDK d'un projet existant de Java 8 à Java 11, j'ai trouvé que Lombok ne fonctionnait pas correctement. J'ai donc dû supprimer toutes les annotations Lombok du code source du projet et utiliser les fonctions intégrées de l'EDI pour générer des méthodes getter / setter, equals, hashCode, toString et constructeur. Vous pouvez également utiliser l'outil Delombok pour terminer ce processus. Mais cela finira par consommer beaucoup de votre temps.

2. Usage coercitif

Lorsque vous utilisez Lombok dans votre code source et qu'il arrive que votre code soit utilisé par d'autres personnes, les personnes qui comptent sur votre code doivent également installer le plugin Lombok (qu'elles le veuillent ou non), et passent du temps à comprendre Lombok L'utilisation d'annotations, si vous ne le faites pas, le code ne fonctionnera pas correctement. Après avoir utilisé Lombok, j'ai trouvé que c'était un comportement très voyou.

3. Mauvaise lisibilité

Lombok masque les détails de l'encapsulation JavaBean. Si vous utilisez l'annotation @AllArgsConstructor, il fournira un constructeur géant qui donnera au monde extérieur la possibilité de modifier toutes les propriétés de la classe lors de l'initialisation de l'objet. Tout d'abord, c'est extrêmement dangereux, car nous ne voulons pas modifier un certain attribut dans une classe; de ​​plus, s'il y a des dizaines d'attributs dans une certaine classe, il y aura un constructeur contenant des dizaines de paramètres. Lombok est injecté dans la classe, ce qui est irrationnel; deuxièmement, l'ordre des paramètres du constructeur est complètement contrôlé par Lombok, et nous ne pouvons pas le contrôler. Ce n'est que lorsque vous avez besoin de déboguer que vous trouvez un étrange "Xiaoqiang" qui vous attend ; Enfin, avant d'exécuter le code, vous ne pouvez imaginer à quoi ils ressemblent que dans toutes les méthodes JavaBean, vous ne pouvez pas les voir.

4. Couplage de code accru

Lorsque vous utilisez Lombok pour écrire le code d'un certain module, d'autres codes qui dépendent de ce module doivent introduire des dépendances Lombok, et en même temps, vous devez installer les plug-ins Lombok dans l'EDI. Bien que le package de dépendances de Lombok ne soit pas volumineux, juste parce que Lombok est utilisé à un seul endroit, toutes les autres parties de confiance doivent être forcées de rejoindre le package Jar de Lombok. Il s'agit d'un couplage intrusif. Si vous rencontrez à nouveau des problèmes de version de JDK Ce sera un désastre.

5. Le gain ne vaut pas la perte

En utilisant Lombok, cela fait du bien pendant un certain temps, mais cela pollue votre code, détruit l'intégrité, la lisibilité et la sécurité du code Java, et augmente également la dette technique de l'équipe. C'est une sorte de préjudice qui l'emporte sur les avantages. Opération. Si vous voulez vraiment affiner votre code, tout en tenant compte de la lisibilité et de l'efficacité du codage, vous pouvez aussi bien utiliser Scala ou Kotlin, un langage basé sur JVM.

 

Pour résumer

Lombok lui-même est une excellente base de code Java. Il utilise un sucre syntaxique intelligent pour simplifier le codage de Java et fournir un moyen de rationaliser le code Java. Cependant, lorsque vous utilisez cette base de code, vous devez comprendre que Lombok n'est pas Une bibliothèque Java standard. L'utilisation de Lombok augmentera la dette technique de l'équipe, réduira la lisibilité du code et augmentera la difficulté de couplage et de débogage du code. Bien que Lombok réduise dans une certaine mesure l'écriture de code standard, il comporte également des risques inconnus. Si vous participez à un projet d'équipe (ou à un projet à grande échelle), compte tenu de la mise à niveau et de l'expansion ultérieures, si vous souhaitez utiliser Lombok, veuillez communiquer avec votre équipe et réfléchir à deux fois.