DRY est-il l'ennemi de la gestion de projets logiciels?
DRY (ne vous répétez pas). L'un des principes les plus fondamentaux et les plus largement acceptés du développement logiciel est également clair: la plupart des projets logiciels nécessitent une certaine gestion.
Maintenant, quelles sont les tâches faciles à gérer (estimation, planification, contrôle)? Bon, tâches répétitives, exactement les tâches à éviter selon DRY.
Du point de vue de la gestion de projet, il est donc formidable de résoudre une tâche en copiant 100 fois du code existant et en apportant quelques adaptations mineures à chaque copie, si nécessaire. À tout moment, vous savez exactement combien de travail vous avez fait et combien il en reste. Tous les managers vous aimeront.
Si à la place, vous appliquez le principe DRY et essayez de trouver une abstraction qui élimine plus ou moins le code en double, les choses sont différentes. Habituellement, il existe de nombreuses possibilités, vous devez prendre des décisions, faire des recherches , soyez créatif. Vous pourriez trouver une meilleure solution en moins de temps, mais vous pourriez également échouer. La plupart du temps, vous ne pouvez pas vraiment dire combien il vous reste de travail. Vous êtes le pire cauchemar d'un chef de projet.
Bien sûr, j'exagère, mais il y a évidemment un dilemme. Mes questions sont les suivantes: quels sont les critères pour décider si un développeur fait trop de DRY? Comment trouver un bon compromis? Ou existe-t-il un moyen de surmonter complètement ce dilemme, pas seulement en trouvant un compromis?
Remarque: Cette question est basée sur la même idée que la précédente, quantité de travail de routine dans le développement de logiciels et son effet sur l'estimation , mais je pense que cela rend mon point plus clair, désolé de me répéter:).
Vous semblez supposer que l'objectif principal de la gestion de projet est de produire des estimations exactes. Ce n'est pas le cas. L'objectif principal de la gestion de projet est le même que pour les développeurs: apporter de la valeur ajoutée au propriétaire du produit.
Un produit utilisant beaucoup de processus manuels lents plutôt que d'automatisation pourrait en théorie être plus facile à estimer (bien que j'en doute), mais il n'apporte pas un bon rapport qualité-prix au client, il s'agit donc simplement d'une mauvaise gestion de projet. Il n'y a pas de dilemme.
Il est bien connu que l'estimation des projets logiciels est difficile, et de nombreux livres ont été écrits et divers processus ont été développés pour le gérer.
Si l'objectif niquement du PM était de produire des estimations exactes, alors ce serait facile. Remplissez simplement les estimations à 10X et laissez les développeurs jouer à des jeux pour le reposez-vous s'ils se terminent tôt. Ce serait en fait mieux que votre suggestion d'utiliser le travail de copier-coller pour remplir le temps, car jouer à des jeux ne réduira pas la maintenabilité du produit.
Mais en réalité, le propriétaire du produit veut des estimations utiles et un produit de qualité livré le plus rapidement et le moins cher possible. Ce sont les contraintes réelles a PM devra naviguer.
Dans tous les cas, je conteste votre hypothèse selon laquelle le travail manuel répétitif est plus prévisible qu'automatisé. Toute expérience montre que le travail manuel répétitif est plus sujet aux erreurs. Et si un bogue est découvert dans le code copié-collé? Soudain, le coût de la correction d'un bug est multiplié par le nombre de répétitions, ce qui fait exploser l'incertitude.
Vous avez raison - le copier-coller fonctionne très bien, et DRY ne sert à rien lorsque votre tâche consiste à produire un programme pour lequel le modèle copié ou la copie n'aura pas à être maintenu ou développé dans Lorsque ces deux composants logiciels ont un cycle de vie complètement différent, puis les coupler ensemble en refactorisant le code commun dans une bibliothèque commune qui est elle-même en développement lourd peut en effet avoir des effets imprévisibles pour l'effort. D'autre part, lors de la copie de code sections à l'intérieur d'un programme ou d'un système de programme, toutes ces parties auront généralement le même cycle de vie. Je vais illustrer ci-dessous ce que cela signifie pour DRY et la gestion de projet.
Sérieusement, il existe de nombreux programmes de ce type: par exemple, l'industrie du jeu vidéo produit de nombreux programmes qui doivent être maintenus sur une courte période de quelques mois ou d'un an au maximum, et lorsque ce temps est écoulé, le copier-coller l'ancien code d'un jeu précédent où la période de maintenance est dépassée, dans la base de code d'un nouveau jeu est parfaitement correct et pourrait accélérer les choses.
Malheureusement, le cycle de vie de la plupart des programmes auxquels j'ai dû faire face au cours des dernières années est très différent de cela. 98% des exigences ou des demandes de correction de bogues qui m'ont été transmises étaient demandes de changement pour les programmes existants. Et chaque fois que vous devez changer quelque chose dans un logiciel existant, la "gestion de projet" ou la planification fonctionne mieux lorsque vos efforts de test et de débogage sont assez faibles - ce qui ne sera pas le cas si vous changez quelque chose au même endroit, mais en raison de la copie -la logique métier passée vous oubliez facilement que vous devez également changer une douzaine d'autres endroits dans la base de code. Et même si vous parvenez à trouver tous ces endroits, le temps de les changer tous (et de tester les changements) est probablement beaucoup plus long que si vous n'avez qu'un seul endroit à changer. Ainsi, même vous pourriez faire une estimation précise du changement, avoir des coûts une douzaine de fois plus élevés que nécessaire peut facilement entrer en collision avec le budget du projet.
TLDR - chaque fois que vous développez un programme où il n'y a aucune nécessité ou responsabilité pour la correction de bogues et la maintenance de l'original ou de la copie, n'hésitez pas à copier. Mais si vous, votre équipe ou votre entreprise êtes ou pourriez devenir responsable, appliquez DRY chaque fois que vous le pouvez.
Exemple
En guise d'addendum, permettez-moi d'expliquer ce que "correction de bogues et maintenance" signifie, et comment cela conduit à une imprévisibilité dans la planification, en particulier à l'intérieur d'un produit, par un exemple concret. J'ai en effet vu ce genre de choses se produire en réalité, probablement pas avec 100 instances, mais les problèmes peuvent même commencer lorsque vous n'avez qu'une seule instance en double.
La tâche: créer 100 rapports différents pour une application, chaque rapport étant très similaire, certaines différences d'exigence entre les rapports, une logique différente, mais dans l'ensemble, pas beaucoup de différences.
Le développeur qui obtient cette tâche crée la première (disons que cela prend 3 jours), après quelques changements ou corrections de bugs mineurs dus à l'assurance qualité et à l'inspection du client, elle semble fonctionner correctement. Puis il a commencé à créer le prochain rapport en copiant-collant et en modifiant le tout, puis le suivant, et pour chaque nouveau rapport dont il a besoin ~ 1 jour en moyenne. Très prévisible, à première vue ...
Maintenant, une fois que les 100 rapports sont "prêts", le programme passe à la production réelle, et certains problèmes surviennent qui ont été ignorés lors de l'AQ. Peut-être qu'il y a des problèmes de performances, peut-être que les rapports plantent régulièrement, peut-être que d'autres choses ne fonctionnent pas comme prévu. Maintenant, lorsque le principe DRY a été appliqué, 90% de ces problèmes pourraient être résolus en changeant la base de code en un seul endroit. Mais en raison de l'approche copier-coller, le problème doit être résolu 100 fois au lieu d'une seule. Et en raison des changements déjà appliqués d'un rapport à un autre, le développeur ne peut pas copier-coller rapidement le correctif du premier rapport dans l'autre 99. Il doit examiner tous les 100 rapports, les lire , traduire le changement dans le rapport modifié, le tester et peut-être déboguer chacun individuellement. Pour le PM, cela commence à devenir très difficile - il peut bien sûr prendre le temps d'une correction de bogue "régulière" (disons, 3 heures ) et multipliez cela par 100, mais en réalité, il s'agit très probablement d'une estimation erronée, certains des correctifs pourraient être plus faciles à faire que d'autres, d'autres pourraient être plus difficiles. Et même si cette estimation est correcte, le débogage coûte 100 fois plus cher élevés car ils devaient coûter cher à votre entreprise.
La même chose se produira la prochaine fois lorsque le client demandera de changer la couleur de l'emblème de son entreprise dans tous ces rapports, de rendre la taille de la page configurable ou par une autre nouvelle exigence qui affecte tous les rapports de manière similaire. Donc, si cela se produit, vous pouvez faire une estimation des coûts et facturer au client 100 fois le prix qu'il aurait à payer lorsque le code aurait été SEC. Cependant, essayez ceci plusieurs fois et le client annulera le projet car il ne sera probablement pas disposé à payer vos frais d'évolution exorbitants. Et peut-être qu'à ce moment-là, quelqu'un posera la question de savoir pourquoi cela s'est produit et indiquera du doigt la personne qui a pris la décision pour cette programmation de copier-coller.
Mon point est le suivant: lorsque vous produisez des logiciels pour d'autres, vous avez toujours au moins pendant une courte période la responsabilité de faire fonctionner la chose, de corriger les bogues, d'adapter le programme à l'évolution des exigences, etc. Même dans un projet en vert, ces les pièces peuvent rapidement s'additionner à bien plus que l'effort de développement initialement prévu. Et surtout lorsque tout votre code copié-collé se trouve dans un seul produit, la période de responsabilité est la même pour toutes les parties, ce qui est assez différent de la situation où vous copiez-copiez du code plus ancien d'un projet mort qui n'est plus en maintenance active.
Du point de vue de la gestion de projet, il est donc formidable de résoudre une tâche en copiant 100 fois du code existant et en apportant quelques adaptations mineures à chaque copie, si nécessaire. À tout moment, vous savez exactement combien de travail vous avez fait et combien il en reste. Tous les managers vous aimeront.
Votre assertion de base est incorrecte.
Ce qui rend les logiciels différents des autres professions, c'est que vous créez quelque chose de nouveau chaque jour. Après tout, aucun client ne vous paiera pour construire quelque chose que quelqu'un d'autre a déjà fait. Les chefs de projet peuvent aimer la prévisibilité, mais leurs chefs comme valeur. Si vous copiez-collez simplement du code avec de légères variations, vous n'apportez pas beaucoup de valeur à l'entreprise.
Finalement l'entreprise se rendra compte qu'elle peut faire le même travail en une fraction du temps en embauchant un bon programmeur. Et s'ils ne le font pas, leurs concurrents le feront.
La programmation par copier-coller conduit finalement à un logiciel abandonné. J'étais entrepreneur sur un système de commande de services filaires auprès d'une très grande compagnie de téléphone. Le système a été coupé et collé ad nauseum parce que tous les tests étaient manuels et qu'ils ne voulaient pas changer de code de travail. La moindre amélioration pourrait entraîner une nouvelle copie de centaines de lignes de code. À l'origine, l'application a été écrite pour gérer les comptes de jusqu'à douze lignes physiques. Bien sûr, cette limitation a été effectuée dans des centaines d'emplacements dans le code. Après environ quatre ans, l'entreprise a demandé à l'équipe ce qu'il faudrait pour gérer des comptes plus importants. Ils ont estimé environ 18 millions de dollars. À ce stade, le projet a été confié à une équipe offshore pour une maintenance minimale. L'équipe existante a été licenciée.
Les organisations qui pensent de cette façon sont écrasées par des entreprises dotées d'une meilleure technologie.
Une maxime souvent oubliée qui s'applique ici est la règle de . Cela indique qu'il est OK de copier le code une fois, mais au-delà, il doit être remplacé par du code générique.
3 pourrait ressembler à un nombre arbitraire mais un scénario courant est celui où les données et la logique sont dupliquées dans une application et une base de données. Un exemple souvent cité est celui où il y a une table de recherche dans la base de données et un côté client d'énumération. La différence de paradigmes ne permet pas de stocker facilement ces informations dans un seul endroit et les informations apparaissent donc souvent aux deux endroits.
Bien qu'il soit agréable d'avoir du code DRY, il peut y avoir des moments où la logique métier dicte une exception et vous devez donc créer deux ou plusieurs bits de code à partir de la source qui était générique auparavant.
Alors que faire? Code pour le statu quo (après tout, YAGNI ). Alors que le code doit être écrit pour faciliter la modification, l'écriture de tout un tas de cloches et de sifflets pour quelque chose qui pourrait ne pas être nécessaire est juste une torche d'argent.
Dans votre question, vous ne citez que trois fonctions de la gestion de projet: estimation, planification et contrôle. La gestion de projet consiste à atteindre des objectifs dans les limites du projet. Les méthodes utilisées pour atteindre les objectifs dans les limites d'un projet sont différentes pour les projets logiciels que pour de nombreux autres types de projets. Par exemple, vous souhaitez que les processus de fabrication soient hautement reproductibles et bien compris. Cependant, le développement de logiciels est principalement travail de connaissances - il n'est pas routinier et nécessite de réfléchir plutôt que de suivre des instructions et des procédures rigides. Les techniques utilisées pour initier, planifier, exécuter, surveiller et contrôler et fermer un projet logiciel devront tenir compte du type de travail qui doit être effectué sur un projet logiciel - en particulier, le travail non routinier qui ne peut pas être effectué aux instructions et procédures spécifiques.
Je pense que l'autre problème est que vous prenez DRY, un concept qui se rapporte à la répétition d'informations, et que vous essayez de l'appliquer à la gestion des tâches. DRY dit simplement que vous ne devriez avoir qu'une seule représentation faisant autorité. Les chefs de projet devraient adopter cela, car cela signifie que tout le monde saura où aller pour obtenir les informations, la communication des changements sera facile, et les changements peuvent être contrôlés et bien gérés. SEC, grâce à des pièces réutilisables, aide à réduire les coûts à long terme, aide à maintenir les calendriers à long terme et à améliorer la qualité - trois pièces pour le Project Management Triangle . Il faut investir du temps et de l'argent pour rendre les choses SÈCHES efficacement, mais le travail du chef de projet est de faire des compromis entre le temps, le coût, le calendrier et la qualité.
DRY est utile mais il est également surévalué. Certaines personnes peuvent aller trop loin. De nombreux développeurs ne réalisent pas que chaque fois que vous implémentez DRY pour utiliser la même méthode à deux fins (légèrement) différentes, vous introduisez une sorte de couplage très étroit entre les différentes utilisations. Maintenant, chaque chaque fois que vous modifiez le code du premier cas d'utilisation, vous devez également vérifier s'il régresse le deuxième cas d'utilisation. S'il s'agit de cas d'utilisation largement indépendants, il est très douteux qu'ils soient étroitement couplés - ils ne devraient probablement pas l'être.
La surutilisation de DRY peut également conduire à des méthodes divines qui explosent en complexité pour gérer tous les différents cas d'utilisation auxquels elles sont soumises, alors que des méthodes atomiques généralement plus petites qui répliquent du code seraient beaucoup plus plus maintenable.
Cependant, je dirais que la question n'est pas vraiment pertinente au niveau de la gestion de projet. Un chef de projet ne voudra vraiment pas se préoccuper de ce niveau de détail de mise en œuvre. S'ils le sont, c'est probablement la micro-gestion. Vraiment ... comment les choses sont implémentées est plus la responsabilité du développeur et du responsable technique. La gestion de projet est plus préoccupée par quoi se fait et quand.
EDIT: par commentaire, je conviens cependant que dans la mesure où il est plus facile de estimer le temps de développement, éviter DRY peut parfois réduire le degré d'incertitude. Mais je crois que cela est une question insignifiante par rapport aux questions les plus pressantes de (1) combien de temps jusqu'à ce que les exigences commerciales soient remplies, (2) quelle dette technique est prise en compte dans le processus, et (3) les risques pour le coût total de possession de l'architecture choix faits - si aller DRY ou non dans de nombreux cas est un choix de conception qui devrait être basé davantage sur le risque/récompense de ces facteurs, que sur le fait qu'il soit un peu plus facile de fournir un projet gestionnaires avec des informations plus précises.
L'écriture de nouveau code n'est qu'une petite partie de la tâche
Votre suggestion faciliterait l'estimation de la partie de l'écriture initiale d'un nouveau code. Cependant, pour apporter réellement quelque chose de nouveau (qu'il s'agisse d'un tout nouveau système, d'un ajout de fonctionnalité ou d'un changement de fonctionnalité), cela ne suffit pas et n'est qu'une minorité de travail - les estimations vues dans la littérature indiquent qu'en pratique, cela une partie représente quelque chose comme 20% -40% du travail total.
Ainsi, la majorité du travail (qui comprend l'adaptation de votre développement initial à ce qui était réellement nécessaire, l'intégration, les tests, la réécriture, le retestage) ne devient pas plus facile à estimer; juste l'inverse, en évitant intentionnellement DRY vient de rendre cette partie beaucoup plus grande, plus difficile et avec des estimations plus variables - ce bogue ou besoin de changement qui nécessite de changer toutes les parties clonées peut ne pas se produire , mais si c'est le cas, alors vos estimations seront totalement erronées.
Vous n'obtenez pas de meilleures estimations en améliorant la qualité de vos estimations d'une petite partie du travail mais en l'aggravant sur une grande partie du travail; ce n'est donc pas vraiment un compromis, mais une situation perdante où vous obtenez une pire productivité mais aussi des estimations moins bonnes.
Je pense que vous comprenez mal DRY.
Prenons un exemple:
public Class A
{
public int Multiply(int x, int y)
{
return x * y;
}
}
public Class B
{
public int Multiply(int x, int y)
{
return x * y;
}
public int Add(int x, int y)
{
return x + y;
}
}
vs.
public Class C : A
{
public int Add(int x, int y)
{
return x + y;
}
}
En remplaçant la classe B par C, nous avons suivi le principe DRY et la duplication de code réduite. Mais nous n'avons pas augmenté les inconnues ou les risques pour le projet (sauf si vous n'avez jamais fait d'héritage auparavant).
Je pense que ce que vous voulez dire lorsque vous parlez de DRY est quelque chose de plus comme une tâche de conception.
public Class A
{
public int Multiply(int x, int y)
{
return x * y;
}
}
!!! Nouvelle exigence! Certains clients doivent pouvoir multiplier les doubles !!
// Use class B for new clients!!
public Class B
{
public int Multiply(double x, double y)
{
return x * y;
}
}
vs.
public Class A // Version 2
{
public int Multiply(int x, int y)
{
return Multiply(x as double, y as double);
}
public int Multiply(double x, double y)
{
return x * y;
}
}
Ici (en supposant que cela fonctionne), nous avons conçu une solution qui peut répondre à la fois à l'ancienne ET à la nouvelle exigence, en essayant essentiellement de créer un modèle mathématique du problème réel ou des règles métier. Dans la vraie vie, le système que nous modélisons sera évidemment beaucoup plus compliqué, notre modèle ne s'adaptera pas exactement, et les cas Edge et les résultats inattendus prendront du temps à trouver et à corriger.
Alors, faut-il prendre B ou A version 2 dans ce cas?
B va être plus spécifique au changement réel demandé avec moins d'effets secondaires et être plus facile à estimer et plus rapide à faire.
Une version 2 se traduira par moins de code global à l'avenir et sera la solution la plus élégante
Encore une fois, je vais dire que cela dépend de la qualité des spécifications et des exigences.
Si nous avons des spécifications très claires qui couvrent les cas Edge et la compatibilité descendante, nous pouvons être sûrs que nous comprenons suffisamment le système pour refactoriser le modèle sans produire de bugs.
Si nous avons une demande d'urgence pour un seul client où la seule exigence est que le comportement change pour ce client sans tenir compte du système global; "améliorer" le modèle en refactorisant A comporte un risque substantiel. À la fois de casser d'autres clients ou de dépasser le délai en raison du temps supplémentaire inconnu nécessaire pour concevoir et tester la solution.
Par paragraphe par paragraphe
DRY (ne vous répétez pas). L'un des principes les plus fondamentaux et les plus largement acceptés du développement logiciel est également clair: la plupart des projets logiciels nécessitent une certaine gestion.
Correct.
Maintenant, quelles sont les tâches faciles à gérer (estimation, planification, contrôle)? Bon, tâches répétitives, exactement les tâches à éviter selon DRY.
Les tâches répétitives doivent être automatisées, obligatoire. Ils sont ennuyeux, sujets aux erreurs, lorsqu'ils sont fabriqués à la main.
Du point de vue de la gestion de projet, il est donc formidable de résoudre une tâche en copiant 100 fois du code existant et en apportant quelques adaptations mineures à chaque copie, si nécessaire. À tout moment, vous savez exactement combien de travail vous avez fait et combien il en reste. Tous les managers vous aimeront.
Je pense que vous pouvez changer le mot "adaptation" avec "configuration". Considérez que vous avez un bogue dans ce morceau de code qui est censé être copié. Un bogue qui apparaît dans des conditions spécifiques. S'il n'est pas corrigé dans la source d'origine et copié, il y aura beaucoup d'endroits à corriger. Cela peut être mauvais, mais quelqu'un doit alors:
- corrigez d'abord le code dans la source d'origine;
- corriger le code dans tous les autres endroits;
- assurez-vous que ce sont tous des endroits. Quand vous dites que cela devait être fait au manager, il détesterait probablement au moins quelqu'un.
Si à la place, vous appliquez le principe DRY et essayez de trouver une abstraction qui élimine plus ou moins le code en double, les choses sont différentes. Habituellement, il existe de nombreuses possibilités, vous devez prendre des décisions, faire des recherches , soyez créatif. Vous pourriez trouver une meilleure solution en moins de temps, mais vous pourriez également échouer. La plupart du temps, vous ne pouvez pas vraiment dire combien il vous reste de travail. Vous êtes le pire cauchemar d'un chef de projet.
La suppression des doublons conduit à un point de défaillance unique. Si quelque chose échoue, vous pouvez être sûr où cela se produit. SOLIDE. et les modèles de conception sont là pour aider à résoudre exactement ce problème. Des délais trop courts tendent à provoquer un "codage" de style procédural. Plus de temps investi dans un projet afin de créer quelque chose de réutilisable signifie qu'il devrait y avoir un minimum de temps passé dans le prochain projet lorsque la fonctionnalité sera réutilisée, mais elle devrait être configurable en premier lieu.
Bien sûr, j'exagère, mais il y a évidemment un dilemme. Mes questions sont les suivantes: quels sont les critères pour décider si un développeur fait trop de DRY? Comment trouver un bon compromis? Ou existe-t-il un moyen de surmonter complètement ce dilemme, pas seulement en trouvant un compromis?
Beaucoup de gens ont souligné qu'il n'y a pas de dilemme ici. Oui et non.
Si vous avez quelque chose de très expérimental qui n'a jamais été fait auparavant - il n'y a pas de dilemme. Sinon, si vous avez quelque chose à refaire, comme un nouveau système de réservation, vous avez déjà des abstractions, cela dépend juste de ce dont vous avez besoin.
Je pense que le dilemme est - devrions-nous implémenter quelque chose dans une fonctionnalité, s'il est peu probable qu'elle soit demandée. Implémentez quelque chose à la demande. Personne n'a besoin d'une énorme infrastructure qui ne sera pas utilisée.
il ne s'agit pas du tout de concevoir pour une réutilisation future ou du principe YAGNI. Il s'agit de répéter du code dans le package de travail actuel.
Il s'agit absolument de design. Peut-être pas réutilisation en soi, mais design quand même.
Quels sont les critères pour décider si un développeur fait trop de DRY?
Expérience et votre environnement/situation actuelle. Pour un problème donné, vous obtiendrez une forte compréhension du principe du Prado lorsque vous tenterez de plus grands degrés de SÉCHAGE. Puis, tout à coup, des considérations de gestion entrent en jeu. Le temps, les objectifs, le client, la gestion du code à long terme (quelqu'un a dit la dette technique ), etc. informeront votre plan d'attaque.
Comment trouver un bon compromis?
Euh ... le design? Le refactoring, c'est le design, enfin c'est censé l'être. La portée du DRYing peut facilement s'étendre comme une super nova de la boucle, à la méthode, aux classes. J'y suis allé, j'ai fait ça. Mais vous ne pouvez pas vraiment savoir jusqu'à ce que vous étudiez le problème - c'est le design.
Comment cela ne peut-il pas être un problème de conception? Vous devez considérer le problème plus largement que le code dupliqué immédiat à portée de main. Il s'agit d'une activité de conception, qu'il s'agisse d'un code existant ou d'une feuille vierge; qu'il s'agisse de "méthode d'extraction" ou de création de nouvelles classes et modules.
Épilogue
... la question posée et ses réponses ne couvrent pas l'aspect gestion de projet.
Gestion typique, ignorant le temps de conception. Nous aurions, dans l'idéal, conçu la répétitivité superflue redondante avant le codage. Au lieu de cela, la direction pense que le développement (et les corrections de bogues) est un événement olympique unique - le codage - alors qu'il s'agit en fait d'un décathlon. Et ils mesurent au 1/1000 de seconde car ils pensent que tout est analogique.
Si à la place, vous appliquez le principe DRY et essayez de trouver une abstraction qui élimine plus ou moins le code en double, les choses sont différentes.
J'ai vécu cette expérience: "J'ai passé deux jours à écrire cette ligne (d'un formulaire GUI) et deux heures à écrire le reste du formulaire." Je veux dire que j'ai pris le temps d'identifier les classes réutilisables - DRY étant un effet secondaire naturel- la ligne du formulaire GUI et w/en certains autres. Une fois débogués, ils ont été utilisés, individuellement et dans la composition , tout au long du formulaire qui est maintenant codé très rapidement et les tests ont été exceptionnellement rapides malgré la complexité de la construction. Et il a également survolé les tests formels avec un taux de bogues incroyablement bas.
La plupart du temps, vous ne pouvez pas vraiment dire combien il reste de travail. Vous êtes le pire cauchemar d'un chef de projet.
Je ne le savais pas non plus, mais j'avais confiance que l'effort de conception initial porterait ses fruits. Nous le disons tous, mais la direction en particulier n'y fait pas confiance. La direction aurait pensé que je me trompais. "Deux jours et vous n'avez même pas encore 2% de code!"
Dans un cas, nous sommes restés fidèles à nos armes lorsque la direction a déclaré: "vous passez trop de temps dans la conception, allez-y". Et des collègues qui disent "c'est trop de classes". Eh bien, un sous-projet beaucoup moins complexe était censé prendre environ 1 mois (je pensais que c'était OK deviner), mais a pris 5 mois. 3 mois de cela étaient en test/correction parce que c'était un tel point de vente. "Mais nous n'avons pas eu le temps de concevoir!". Ils ont effectivement dit cela.
Mes questions sont les suivantes: quels sont les critères pour décider si un développeur fait trop de DRY? Comment trouver un bon compromis? Ou existe-t-il un moyen de surmonter complètement ce dilemme, pas seulement en trouvant un compromis?
Montrez à la direction comment cela fonctionne. Capturez des données. Comparez-le à un autre travail, en particulier à celui de vos collègues qui font le travail de Rush slap-dash. Ce tas d'échecs semble toujours perdre la course, rester bloqué dans le test, puis après la sortie, il est revenu encore et encore pour corriger plus de bugs.