Comment trouver les parties puantes de votre code [Partie XXIX]

Les odeurs de code sont un classique.

Ça sent mauvais parce qu'il y a probablement de nombreux cas où il pourrait être modifié ou amélioré.

La plupart de ces odeurs ne sont que des indices de quelque chose qui pourrait ne pas fonctionner. Par conséquent, ils ne sont pas tenus d'être corrigés en soi… (Vous devriez cependant y jeter un coup d'œil.)

Odeurs de code précédentes

Vous pouvez trouver toutes les odeurs de code précédentes (Partie I - XXVIII) ici.

Nous allons continuer...

---

Code Odeur 141 - IEngine, AVehicle, ImplCar

Avez-vous déjà vu un IEngine dans la nature ?

TL; DR : Ne préfixez ni ne suffixez vos cours

Problèmes

• Lisibilité
• Défaut de bijection
• Noms implémentatifs

Solutions

1. Supprimer les préfixes et les suffixes
2. Nommez vos objets d'après ce qu'ils font

Le contexte

Certains langages ont des conventions culturelles liées aux types de données, aux classes abstraites ou aux interfaces. Ces noms chargent nos modèles de traductions cognitives difficiles à suivre.

Nous devons nous .

Exemple de code

Faux

 public interface IEngine { void Start(); } public class ACar { } public class ImplCar { } public class CarImpl { }

Droite

 public interface Engine { void Start(); } public class Vehicle { } public class Car { }

Détection

• [x] Automatique

Si nous avons un thésaurus, nous pouvons pointer vers des noms maladroits.

Des exceptions

En C#, il est courant de mettre "I" dans le nom d'une interface car, sans lui, vous ne pouvez pas dire s'il s'agit d'une interface ou d'une classe.

C'est une odeur de langue.

Mots clés

• Appellation

Conclusion

Utilisez de vrais noms pour vos modèles.

Rapports

Code Odeur 130 - AdresseImpl

Plus d'informations

• Qu'y a-t-il dans un nom : partie II Rehab ?

Crédits

Photo de Tim Mossholder sur Unsplash

---

Certaines personnes, lorsqu'elles sont confrontées à un problème, pensent "Je sais, je vais utiliser des expressions régulières". Maintenant, ils ont deux problèmes.

Jamie Zawinski

Excellentes citations de génie logiciel

---

Code Smell 142 - Requêtes dans les constructeurs

Accéder à une base de données dans des objets de domaine est une odeur de code. Le faire dans un constructeur est une double odeur.

TL; DR : Les constructeurs doivent construire (et probablement initialiser) des objets.

Problèmes

• Couplage
• Effets secondaires

Solutions

1. Dissociez la logique métier essentielle de la persistance accidentelle.
2. Sur les classes de persistance, exécutez des requêtes dans des fonctions autres que les constructeurs/destructeurs.

Le contexte

Sur le code hérité, la base de données n'est pas correctement séparée des objets métier.

Les constructeurs ne devraient jamais avoir d'effets secondaires.

Selon le principe de responsabilité unique, ils ne doivent construire que des objets valides

Exemple de code

Faux

 public class Person { int childrenCount; public Person(int id) { childrenCount = database.sqlCall("SELECT COUNT(CHILDREN) FROM PERSON WHERE ID = " . id); } }

Droite

 public class Person { int childrenCount; // Create a class constructor for the Main class public Person(int id, int childrenCount) { childrenCount = childrenCount; // We can assign the number in the constructor // Accidental Database is decoupled // We can test the object } }

Détection

• [x] Semi-automatique

Nos linters peuvent trouver des modèles SQL sur les constructeurs et nous avertir.

Mots clés

• Couplage

Conclusion

La séparation des préoccupations est essentielle et le couplage est notre principal ennemi lors de la conception de logiciels robustes.

Plus d'informations

• Couplage : le seul et unique problème logiciel

Crédits

<span>Photo de sur </span>

---

Ma conviction est toujours que si vous obtenez les structures de données et leurs invariants correctement, la plupart du code s'écrira en quelque sorte.

Pierre Deustch

Excellentes citations de génie logiciel

---

Code Smell 143 - Amas de données

Certains objets sont toujours ensemble. Pourquoi ne pas les diviser ?

TL; DR : faire voyager ensemble des objets primitifs cohérents

Problèmes

• Mauvaise cohésion
• Code dupliqué
• Complexité de la validation
• Lisibilité
• Maintenabilité

Solutions

1. Extraire la classe
2. Trouver de petits objets

Le contexte

Cette odeur est amie avec l'obsession primitive.

Si deux ou plusieurs objets primitifs sont collés ensemble, avec une logique métier répétée et des règles entre eux, nous devons trouver le concept existant de la bijection .

Exemple de code

Faux

 public class DinnerTable { public DinnerTable(Person guest, DateTime from, DateTime to) { Guest = guest; From = from; To = to; } private Person Guest; private DateTime From; private DateTime To; }

Droite

 public class TimeInterval { public TimeInterval(DateTime from, DateTime to) { // We should validate From < To From = from; To = to; } } public DinnerTable(Person guest, DateTime from, DateTime to) { Guest = guest; Interval = new TimeInterval(from, to); } // Even Better... public DinnerTable(Person guest, Interval reservationTime) { Guest = guest; Interval = reservationTime; }

Détection

• [x] Semi-automatique

La détection basée sur les motifs de cohésion est disponible sur quelques linters.

Mots clés

• Cohésion

Conclusion

Regroupez le comportement au bon endroit et masquez les données primitives.

Rapports

Code Smell 122 - Obsession primitive

Code Smell 01 - Modèles anémiques

Code Smell 27 - Tableaux associatifs

Plus d'informations

Crédits

Photo de Dynamic Wang sur Unsplash

---

Le cœur du logiciel est sa capacité à résoudre les problèmes liés au domaine pour son utilisateur. Toutes les autres fonctionnalités, aussi vitales soient-elles, soutiennent cet objectif fondamental.

Eric Evans

Excellentes citations de génie logiciel

---

Code Smell 144 - Objets fongibles

Nous avons beaucoup entendu parler des NFT. Maintenant, nous maîtrisons le concept Fungible.

TL;DR : Respectez le MAPPER . Rendre fongible ce qui est fongible dans le monde réel et vice-versa.

Problèmes

• Défaut de bijection
• Sur la conception

Solutions

1. Identifiez les éléments fongibles sur vos domaines
2. Modélisez-les comme interchangeables

Le contexte

Selon :

La fongibilité est la propriété d'un bien ou d'une marchandise dont les unités individuelles sont essentiellement interchangeables et dont chacune des parties est indiscernable d'une autre partie.

Dans les logiciels, on peut remplacer des objets fongibles par d'autres.

Lors de la cartographie de nos objets avec des objets réels, nous oublions parfois le modèle partiel et construisons sur la conception.

---

Exemple de code

Faux

 public class Person implements Serializable { private final String firstName; private final String lastName; public Person(String firstName, String lastName) { this.firstName = firstName; this.lastName = lastName; } } shoppingQueueSystem.queue(new Person('John', 'Doe'));

Droite

 public class Person { } shoppingQueueSystem.queue(new Person()); // The identity is irrelevant for queue simulation

Détection

• [x] Manuel

C'est une odeur sémantique.

Nous devons comprendre le modèle pour vérifier s'il est correct ou non.

Mots clés

• Sur la conception

Conclusion

Rendre fongible ce qui est fongible et vice-versa.

Cela semble facile mais nécessite des compétences en conception et évite la complexité accidentelle.

Crédits

Photo par sur

---

Les gens pensent que l'informatique est l'art des génies mais la réalité est le contraire, juste beaucoup de gens font des choses qui se construisent les unes sur les autres, comme un mur de mini pierres.

Donald Knuth

---

Code Smell 145 - Hack de court-circuit

N'utilisez pas l'évaluation booléenne comme raccourci de lisibilité.

TL; DR : N'utilisez pas la comparaison booléenne pour les fonctions d'effets secondaires.

Problèmes

• Lisibilité
• Effets secondaires

Solutions

1. Convertir les courts-circuits en IF

Le contexte

Les programmeurs intelligents aiment écrire du code hacky et obscur même lorsqu'il n'y a aucune preuve solide de cette amélioration.

Une optimisation prématurée nuit toujours à la lisibilité.

Exemple de code

Faux

 userIsValid() && logUserIn(); // this expression is short circuit // Does not value second statement // Unless the first one is true functionDefinedOrNot && functionDefinedOrNot(); // in some languages undefined works as a false // If functionDefinedOrNot is not defined does // not raise an error and neither runs

Droite

 if (userIsValid()) { logUserIn(); } if(typeof functionDefinedOrNot == 'function') { functionDefinedOrNot(); } // Checking for a type is another code smell

Détection

• [x] Semi-automatique

Nous pouvons vérifier si les fonctions sont impures et changer le court-circuit en IF.

Certains linters réels nous avertissent de ce problème

Mots clés

• Optimisation prématurée

Conclusion

N'essayez pas d'avoir l'air intelligent.

Nous ne sommes plus dans les années 50.

Soyez un développeur d'équipe.

Rapports

Code Smell 140 - Évaluation des courts-circuits

Code Smell 06 - Programmeur trop malin

Crédits

Photo de Michael Dziedzic sur Unsplash

---

Un ordinateur est une machine stupide capable de faire des choses incroyablement intelligentes, tandis que les programmeurs informatiques sont des gens intelligents capables de faire des choses incroyablement stupides. Ils sont, en bref, un match parfait.

Bill Bryson

---

Article suivant : 5 autres odeurs de code.