IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langages de programmation Discussion :

N'appliquez pas prématurément les principes DRY à votre code, d'après Dan Maksimovich


Sujet :

Langages de programmation

  1. #1
    Communiqués de presse

    Femme Profil pro
    Traductrice Technique
    Inscrit en
    Juin 2023
    Messages
    1 144
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Traductrice Technique

    Informations forums :
    Inscription : Juin 2023
    Messages : 1 144
    Points : 80 104
    Points
    80 104
    Par défaut N'appliquez pas prématurément les principes DRY à votre code, d'après Dan Maksimovich
    N'appliquez pas prématurément les principes DRY (Ne vous répétez pas) à votre code, car l'application trop rigide des principes DRY conduit à des abstractions prématurées et des changements futurs plus complexes.

    Selon Dan Maksimovich, il ne faut pas appliquer prématurément les principes DRY (Ne vous répétez pas) aux codes. L'application trop rigide des principes DRY conduit à des abstractions prématurées qui rendent les changements futurs plus complexes que nécessaire.

    Ne vous répétez pas (don’t repeat yourself en anglais, aussi désigné par l’acronyme DRY) est une philosophie en programmation informatique consistant à éviter la redondance de code au sein d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière.

    La philosophie DRY est explicitée par la phrase suivante, formulée par Andy Hunt et Dave Thomas dans leur livre The Pragmatic Programmer : "Dans un système, toute connaissance doit avoir une représentation unique, non ambiguë, faisant autorité". Les auteurs appliquent ce principe pour inclure les bases de données, les plans de tests, le système de construction logiciel et même la documentation logicielle.

    Lorsque le principe DRY est bien appliqué, la modification d'un élément d'un système ne change pas les autres éléments non liés logiquement. De plus, tous les éléments liés logiquement changent uniformément, de manière prévisible et restent synchronisés. En utilisant les méthodes et les sous-routines dans leur code, Thomas et Hunt se reposent sur les générateurs de code source, les systèmes de construction automatique, et les langages de scripts pour respecter le principe DRY à travers les diverses étapes de construction d'un logiciel.

    Cette philosophie prévaut dans l'architecture dirigée par les modèles, dans lequel les artefacts logiciels sont dérivés d'un modèle objet central décrit dans un langage tel qu'UML. Le code DRY est créé par transformation de données et les générateurs de code qui évitent au programmeur de copier-coller du code. Le code DRY facilite la maintenance de systèmes logiciels complexes, à partir du moment où les transformations de données sont faciles à créer et maintenir. Des outils tels que les annotations, XDoclet et XSLT sont des exemples de technique de codage DRY.

    Un exemple de système requérant une duplication d'information sont les EJB 2.0 qui nécessitent une duplication d'information non seulement dans le code Java, mais aussi dans les fichiers de configuration. Des exemples de systèmes essayant de réduire la duplication d'information sont le framework web Django, Ruby on Rails et les EJB 3.0.


    N'appliquez pas prématurément les principes DRY à votre code

    Voici ce que Dan Maksimovich écrit sur la santé du code et l'application des principes DRY :

    Nous sommes nombreux à avoir entendu parler des vertus de la méthode « Don't Repeat Yourself » ou DRY (ne pas se répéter). Faites une pause et réfléchissez : La duplication est-elle vraiment redondante ou la fonctionnalité devra-t-elle évoluer indépendamment au fil du temps ? Une application trop rigide des principes DRY conduit à des abstractions prématurées qui rendent les changements futurs plus complexes que nécessaire.

    Examinez attentivement si le code est réellement redondant ou s'il n'est que superficiellement similaire. Même si les fonctions ou les classes se ressemblent, elles peuvent servir des contextes différents et répondre à des exigences commerciales qui évoluent différemment au fil du temps. Réfléchissez à la manière dont l'objectif des fonctions se maintient dans le temps, et ne vous contentez pas de raccourcir le code. Lors de la conception d'abstractions, ne couplez pas prématurément des comportements qui peuvent évoluer séparément à plus long terme.

    Quand l'introduction d'une abstraction nuit-elle à notre code ? Considérons le code suivant :

    Nom : 1.jpg
Affichages : 30753
Taille : 63,4 Ko

    L'approche de droite semble violer le principe DRY puisque les contrôles ValueError sont identiques par coïncidence. Cependant, les tâches et les paiements représentent des concepts distincts avec une logique potentiellement divergente. Si la date de paiement nécessitait ultérieurement une nouvelle validation, vous pourriez facilement l'ajouter au code de droite ; l'ajouter au code de gauche est beaucoup plus invasif.

    En cas de doute, séparez les comportements jusqu'à ce que suffisamment de modèles communs émergent au fil du temps pour justifier le couplage. À petite échelle, il peut être plus simple de gérer la duplication que de résoudre la complexité d'une abstraction prématurée. Aux premiers stades du développement, il convient de tolérer un peu de duplication et d'attendre avant de procéder à l'abstraction.

    Les exigences futures sont souvent imprévisibles. Pensez au principe « You Aren't Gonna Need It » ou YAGNI. Soit la duplication s'avérera être un non problème, soit avec le temps, elle indiquera clairement la nécessité d'une abstraction bien réfléchie.
    Source : Dan Maksimovich, Andy Hunt et Dave Thomas

    Et vous ?

    Pensez-vous que cet avis est crédible ou pertinent ?
    Quel est votre avis sur le sujet ?

    Voir aussi :

    L'utilisation de l'assistant d'IA GitHub Copilot pour la programmation entraîne une baisse de la qualité globale du code et une quantité importante de code redondant, selon une étude

    7 signes révélateurs d'un code illisible : Comment identifier et résoudre le problème

    « Un bon code est comme une lettre d'amour destinée au prochain développeur qui va le maintenir », estime Addy Osmani. L'ingénieur de Google montre les similitudes entre les deux
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre habitué
    Homme Profil pro
    Architecte réseau
    Inscrit en
    Février 2024
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Architecte réseau

    Informations forums :
    Inscription : Février 2024
    Messages : 59
    Points : 175
    Points
    175
    Par défaut
    Alors que la bonne approche dans ce cas précis est d'avoir deux méthodes publiques set_task_deadline et set_payment_deadline, et une méthode privée _set_deadline.

  3. #3
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 481
    Points : 6 137
    Points
    6 137
    Par défaut
    De mon côté, j'ai plutôt tendance à écrire du code fortement typé tel que, quand un objet a un certain type, on a la garantie qu'il a passé certaines contraintes. Rappel : En Python, on peut utiliser les annotations de type pour avoir du typage statique.
    Ici, j'aurais fait un type Deadline qui encapsule une date et heure. Si la date et heure est avant maintenant, le constructeur de Deadline lance une ValueError.
    D'ailleurs, je n'aurais pas appelé directement datetime.now(), même si cela n'empêche pas d'automatiser les tests en Python qui permet de faire du monkey patching. Je préfère passer "maintenant" en paramètre. De manière générale, dans du code testable, je préfère rendre les entrées et sorties explicites via des paramètres que de faire du monkey patching.
    Enfin, mon type Deadline n'aurait pas encapsulé directement le type datetime. Le problème du type datetime de la bibliothèque standard de Python est qu'il n'indique pas s'il inclut la timezone. En Python, il m'est déjà arrivé par erreur de comparer ou soustraire un objet de type datetime qui a une timezone et un autre objet de type datetime qui n'a pas de timezone, ce qui a lancé une exception. Pour éviter ça, j'encapsule le type datetime dans une autre classe qui ajoute un invariant selon lequel on a une timezone.
    Finalement, le code que je décris est bien du DRY, mais la classe Deadline est bien séparée du reste.
    Remarque 1 : Ce que je viens d'écrire ne s'applique pas à tous les codes Python, car il y a plein de cas où, pour des raisons de performance, on passe par des bibliothèques qui obligent d'écrire du code faiblement typé, par exemple numpy.
    Remarque 2 : Ce que je viens d'écrire serait overkill pour de simples API CRUD. Plus on a de la logique métier complexe, plus renforcer le typage est bénéfique.

Discussions similaires

  1. Réponses: 1
    Dernier message: 30/06/2022, 18h39
  2. Réponses: 6
    Dernier message: 27/01/2021, 16h32
  3. Réponses: 0
    Dernier message: 15/01/2019, 11h52
  4. Réponses: 4
    Dernier message: 28/10/2018, 22h24
  5. jointure renvois pas tous les enregistrements
    Par rayonx dans le forum Langage SQL
    Réponses: 7
    Dernier message: 29/08/2002, 12h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo