Robert Martin, Code propre. Revue du livre sur le « code kung fu » pour les développeurs

Bonjour les Javarashevites ! Cet article est une critique du livre « Clean Code » de Robert Martin. Ensemble, nous examinerons les moyens d'améliorer et d'optimiser votre code, et à la fin, une tâche petite mais intéressante vous attend. Chaque jour, lorsque nous ouvrons votre éditeur de code, nous sommes confrontés à de nombreuses classes, fonctions et variables. La meilleure option est s'il s'agit de votre code écrit à partir de zéro, écrit une seule fois, qu'il contient peu de lignes, que vous travaillez dessus seul, qu'il n'y a aucune modification ni aucune assistance supplémentaire de la part du client. MAIS! Comme le montre la pratique, oui, je pense que vous comprenez vous-même que cela n'arrive pas. Fondamentalement, nous devrons interagir d'une manière ou d'une autre avec les membres de notre équipe, maintenir le code « hindou » et analyser les produits en millions de lignes. J'ai souvent entendu des réponses comme celle-ci de la part de mes collègues formateurs : « Ce code a été écrit par moi, et je ne vais le montrer à personne », mais quand je vois des demandes d'aide sur un tel code, cela prend beaucoup de temps. du temps (parfois très long) pour approfondir et comprendre. Qu'est-ce que la personne voulait me dire, j'ai même envie de dire « effacer et réécrire » ! Appréciez le temps et l’énergie des personnes qui veulent vous aider, écrivez correctement, et si vous ne savez pas comment, il n’est jamais trop tard pour apprendre. Le livre de Robert Martin se distingue parmi les livres de ce format par le fait qu'il contient de nombreux exemples en Java. C'est peut-être une déclaration un peu fanatique de ma part, mais elle a été écrite dans le style POO, notamment dans l'écriture des parties et des sections. Facile à comprendre et à lire, le livre se lit facilement en déplacement ou le soir avant de se coucher. Clean Code est divisé en 3 parties. Dans la première partie, il nous est demandé de parcourir la théorie du livre, de nous renseigner sur les modèles de conception et les règles de bonnes manières. La deuxième partie nous invite à pratiquer le refactoring et l'écriture, et la troisième partie est le résumé final des « odeurs » de code dans les exemples. Eh bien, l'auteur a abordé de nombreux sujets pour lesquels vous aurez principalement besoin de connaissances sur Java Core, mais il existe également des sections dédiées aux tests unitaires JUnit, à la journalisation Log4j, à la connaissance des modèles les plus simples en conception (mais comme je l'ai dit plus haut, il n'y en a pas). beaucoup d'entre eux, et tout ce qui est incompréhensible peut être recherché avec succès sur Google, oui et analysé dans le cours JavaRush). Tous les chapitres du livre ne sont pas liés les uns aux autres ; vous pouvez commencer à lire avec succès à partir du chapitre que vous aimez. Un bref résumé des principales idées que j'ai retenues du livre. Je serais reconnaissant pour vos commentaires à leur sujet, dans lesquels vous pourrez partager votre propre vision de ces déclarations.

1. Commentaires == mal.

Dans la plupart des cas, les commentaires sont des béquilles avec lesquelles nous essayons de dissimuler notre mauvais code. Et dans certains cas, ils mentent également sur le but des méthodes ou des variables s'il y a une refactorisation constante du code.

2. Code commenté, code mort.

Laisser ces morceaux de code dans votre application équivaut à de la foutaise. Le code inutilisé s'accumule avec le temps et interfère avec la propreté de votre application, vérifiez le code de ces modules de temps en temps.

3. Rubriques des méthodes, classes et variables.

Cela vaut la peine d'articles séparés pour discuter de ce sujet. Ne soyez pas paresseux et écrivez des noms qui peuvent révéler leur objectif. Apprenez quelques normes d’orthographe des titres. Ce sujet est un « must have » pour une étude détaillée.

4. Chaque méthode et variable a sa place dans la hiérarchie des classes.

En règle générale, une classe peut avoir des variables et des méthodes (statiques et non statiques), un constructeur, des classes imbriquées et internes et des énumérations. Bref, il y a beaucoup d’informations, et il faut déterminer la place de chacun dans la classe. Si vous regardez les classes principales de Java, vous verrez que la structure est clairement structurée, on peut voir chaque partie à sa place, bien sûr dans vos projets cela peut changer au sein du projet, mais pas dans chaque classe. Pour ma part, j'ai défini la structure de construction suivante : Au début de la classe j'ai des variables statiques, puis des variables objets + Enums si elles existent. Après les variables, je définis les constructeurs de classe. Ensuite, j'écris des méthodes pour travailler avec la classe. Après les méthodes, j'écris des getters et des setters. Et à la toute fin, j'ai des cours intérieurs. Vous pouvez utiliser ma structure ou écrire la vôtre dans les commentaires.

5. Niveaux d'abstraction des méthodes.

Pour moi, c'était la découverte n°1. Chaque méthode contient des opérateurs à un seul niveau d'abstraction. Vous ne devez pas mélanger des opérations à plusieurs niveaux.

6. Gestion des erreurs.

Exceptions cochées ou non, qu'est-ce qu'il est préférable d'utiliser dans le projet (qu'en pensez-vous ?, écrivez des commentaires) ? Je suis partisan de la vérification, mais le livre aide à examiner les exceptions non vérifiées de l'extérieur. En effet, une Exception non cochée ne défigure pas la signature de la méthode, d'autant plus que les exceptions « transpercent » plusieurs couches à la fois. L'inconvénient du moindre changement conduit à redéfinir toute la chaîne de méthodes avant de l'attraper, ce qui est extrêmement gênant pour le développement dans de nombreux cas.

7. Formatage du code.

Un code correctement formaté est non seulement clair, mais également très lisible. Vous avez immédiatement une idée des supports et des actions à l'intérieur. En utilisant l'exemple des conditions dans les constructions if, else, vous ne devriez pas tout écrire sur une seule ligne, il est préférable de déplacer de longues chaînes.

8. Négations dans la condition.

Essayez d'éviter le déni dans des conditions, c'est plutôt un facteur psychologique, notre cerveau ne perçoit pas bien le déni, et oui ! avant que l'expression ne soit peut-être pas remarquée. Par exemple, nier if (!condition.isTrue) est préférable pour réécrire la méthode, cela rendra les choses beaucoup plus faciles comme ceci (condition.isFalse)

9. Les fonctions doivent effectuer une opération.

Si votre méthode effectue de nombreuses opérations, divisez-les en méthodes à opération unique. Ces méthodes sont très faciles à prendre en charge, faciles à tester et, si nécessaire, remplacées ou supprimées.

10. Ne vous répétez pas.

Ne répétez pas le code DRY (Ne vous répétez pas). C’est l’une des règles fondamentales qui réduira considérablement votre code, gardez-la à l’esprit. Essayez de mettre tous vos morceaux de code répétés dans une fonction distincte. Bien sûr, on peut parler beaucoup plus de DRY, KISS(Keep it simple Stupid), SOLID , YAGNI. Ces termes sont essentiels à la compréhension et à la conception. Ils méritent un article séparé, j'écrirai peut-être à nouveau sur eux, puisque cet article est consacré à une critique du livre « Clean Code ». Comme promis, une petite tâche facile pour vous. Le programme doit calculer l'indice d'obésité sur la base des données fournies. Écrivez dans les commentaires le nombre d'erreurs et de correctifs dans le code. P.S. Le code fonctionne et remplit sa fonction s'il est utilisé correctement.

//Weight in kg.
//Height in metres.
public class sample {
    public static void main (String[] args) {
        humanIMB humanIMB = new humanIMB(80,1.52);
        System.out.println(humanIMB.Result());
    }
}
class humanIMB {
    public double W; //Weight Human
    public double H; // Height Human
    private static double imb;
    public humanIMB(double w, double h) {
        W = w;
        H = h;
        imb = W / (H * H);
    }
    public double takeW() {
        return W;
    }
    public void putW(double w) {
        W = w;
        imb = W / (H * H);
    }
    public double takeH() {
        return H;
    }
    public void putH(double h) {
        H = h;
        imb = W / (H * H);
    }
    public static double takeImt() {
        return imb;
    }
    public static String Result() {
        String  string = null;
        if (imb >=18.5 & imb <25) {
            string ="Норма, ты в форме!";
        }
        if (imb >=25 & imb <30) {
            string ="Предожирение. Эй, поосторожнее с пирожными ";
        }
        if (imb >=30) {
            string ="Ожирение. SCHWEINE! Хватит жрать, иди на треню!";
        }
        if (imb <18.5) {
            string ="Дефицит массы тела. В модели решил переквалифицироваться?";
        }
        return string;
    }
}