5 erreurs courantes en C# qui rendent votre logiciel impossible à maintenir - Expliqué par Derek Comartin

1. Absence d'appropriation de l'État

Derek commence par identifier l'erreur qui consiste à permettre à plusieurs limites ou services de mettre à jour des données partagées sans que la propriété soit clairement établie. Il utilise un exemple où le système de facturation atteint une autre partie de l'application et en modifie l'état. La traduction doit rester professionnelle et préserver l'exactitude technique tout en expliquant les caractéristiques et les avantages de ces outils de développement.

Ce type d'approche libre crée des erreurs où les développeurs se demandent : "Pourquoi ces données sont-elles incorrectes ?" ou "Qui les a modifiées ?" Derek insiste sur la nécessité de définir la propriété. Chaque partie du système doit exposer une API ou une méthode bien définie - responsable de la gestion de l'état.

Au lieu de permettre à n'importe quelle partie de l'application de modifier les données partagées, Derek suggère de créer des commandes et des requêtes explicites. Par exemple, lorsque vous souhaitez mettre à jour une expédition, vous émettez une commande via une interface dédiée. Cela permet de structurer le texte et d'éviter les fuites de ressources dues à des modifications non traçables.

2. code implicite et flux de travail explicite

Selon Derek, de nombreux systèmes s'appuient fortement sur les opérations CRUD (Create, Read, Update, Delete), mais cela se traduit par des flux de travail implicites. Le code est techniquement fonctionnel mais manque de clarté sur ce qu'il fait. Si votre classe ne prend en charge que des opérations génériques, le flux de travail réel de l'entreprise est caché.

Prenons l'exemple suivant : un chauffeur récupère un colis et un connaissement est généré. Si le système se contente d'exécuter UpdateShipment, il est difficile de savoir si le changement de chaîne (comme le numéro de BOL) est dû à un enlèvement ou à une correction. Derek souligne que nous devrions remplacer les mises à jour vagues par des opérations explicites telles que PickupStopLoaded.

Cela permet d'obtenir un code plus lisible. Elle facilite également la gestion des exceptions, car lorsqu'une exception se produit, la trace de la pile indique clairement l'opération qui a échoué. Les méthodes explicites permettent également d'améliorer les normes de codage, car chaque fonction a une responsabilité unique.

3. l'ajout d'une indirection inutile

Derek passe ensuite à l'indirection, c'est-à-dire à l'insertion de couches inutiles entre l'appelant et la méthode cible. Il illustre son propos par des connexions de bases de données. Un contrôleur peut appeler un service, qui appelle un assistant, qui appelle un autre service, qui exécute finalement la requête via Entity Framework.

Cette pyramide d'abstractions rend plus difficile la détection des problèmes et l'amélioration des performances. Si la création d'abstractions peut s'avérer utile, par exemple en enveloppant les interfaces IDisposable pour une meilleure gestion des ressources, Derek met en garde contre les excès. Demandez-vous si votre abstraction simplifie l'API ou si elle ne fait que cacher une dépendance tierce qui n'existe qu'à un seul endroit.

Au lieu de superposer des couches pour le plaisir de superposer des couches, Derek suggère de gérer directement le couplage. Une indirection excessive n'encombre pas seulement votre code, mais elle augmente également le potentiel de fuites de mémoire et affaiblit les avantages du garbage collection.

4. jouer le jeu de l'hypothèse

L'erreur suivante identifiée par Derek est de se préparer à des cas d'utilisation hypothétiques qui ne se produiront peut-être jamais - ce qu'il appelle le "What-If Game" De nombreux développeurs C# écrivent des classes et des fonctions flexibles pour tenir compte des besoins futurs. En voici un exemple : "Et si nous devions prendre en charge deux langues ?" ou "Et si nous devions changer de technologie ?"

Derek prévient que cet état d'esprit conduit à des frameworks surchargés et à un code trop générique. Il mentionne des cas de logique de concaténation de chaînes et d'enveloppes de types de référence que personne ne comprend parce qu'ils ne servent qu'un seul cas d'utilisation réel.

Au lieu de se préparer à l'inconnu, Derek conseille de se concentrer sur les besoins réels. Chaque méthode et variable doit avoir une utilité actuelle et justifiée. Les fonctionnalités inutilisées ne font qu'augmenter les coûts de maintenance. Comme le dit Derek, il ne s'agit pas seulement du temps de développement, mais aussi du coût de possession. Si votre implémentation de bool Equals, par exemple, couvre tous les cas de figure que vous pouvez imaginer, mais qu'aucun ne se produit réellement, vous avez perdu un temps précieux.

5. Ne pas gérer correctement les flux de travail

Enfin, Derek évoque l'erreur consistant à traiter les flux de travail comme des blocs procéduraux plutôt que comme des étapes modulaires. Il utilise un exemple concret : passer une commande en ligne. Une fois que l'utilisateur a terminé sa commande, le système débite la carte de crédit, puis envoie un courriel de confirmation.

Si une étape échoue - par exemple, le processus de paiement - comment votre code réagit-il ? Faut-il annuler la commande ? Une erreur s'est produite ? Vous avez envoyé un courriel d'échec ? Derek explique que le fait de regrouper tout cela en un seul bloc crée une complexité ingérable.

Il recommande de concevoir les flux de travail comme de petites unités isolées qui communiquent par le biais de la messagerie. L'utilisation d'opérations de tâches asynchrones et de retours de rendement facilite la gestion de ces étapes. En outre, l'utilisation de l'instruction using et du bloc using autour des ressources externes telles que l'accès aux fichiers ou les connexions aux bases de données peut aider à prévenir les fuites de mémoire.

Par exemple, un bloc using autour d'un flux permet de s'assurer qu'il est éliminé correctement - un point essentiel lorsque l'on travaille avec des interfaces IDisposable. Lorsque les flux de travail deviennent complexes, ces meilleures pratiques garantissent que les exceptions sont détectées et traitées efficacement, ce qui préserve les performances et la maintenabilité.

Enveloppez le tout : Écrire un code propre et facile à entretenir

Comme Derek le conclut dans sa vidéo à 12:45, il réfléchit à ces erreurs non seulement comme des choses qu'il a vues, mais aussi comme des choses qu'il a personnellement commises en construisant de grands systèmes d'entreprise. Il s'agit de leçons tirées de l'expérience, et il encourage les spectateurs à partager leurs propres erreurs dans les commentaires.

Les conseils de Derek s'appliquent non seulement à C#, mais aussi à de nombreux autres langages. Que vous travailliez avec des comparaisons de chaînes, des méthodes Equals() ou que vous conceviez de nouvelles fonctionnalités, la clé est la clarté, l'intention et la maintenance de votre code.

Si vous souhaitez améliorer vos compétences en C# et éviter ces pièges courants, la chaîne de Derek propose de nombreuses ressources gratuites sur l'architecture des systèmes, les modèles de conception et des conseils concrets sur le langage de programmation. Éviter ne serait-ce qu'une seule de ces erreurs peut considérablement améliorer la qualité de votre projet.

Alors, la prochaine fois que vous commencerez à écrire du code, rappelez-vous les mots de Derek et posez-vous la question suivante : "Est-ce que je rends les choses plus complexes qu'elles ne le devraient ?"

Pour plus de contenu de ce type, consultez la chaîne YouTube de Derek Martin CodeOpinion.