Concevez pour des modifications futures ou résolvez le problème à résoudre [fermé]

Lorsque vous écrivez le code ou lors de la conception, essayez-vous de généraliser le problème à la première instance ou tentez-vous de résoudre ce problème très spécifique?

Je pose la question parce que tenter de généraliser le problème a tendance à compliquer les choses (ce qui peut ne pas être nécessaire) et qu’il sera en revanche très difficile d’élargir la solution spécifique en cas de modification de l’exigence.

Je suppose que la solution consiste à trouver le moyen terme, ce qui est plus facile à dire qu'à faire. Comment abordez-vous ce type de problème? Si vous commencez à généraliser à quel moment, vous savez que cette généralisation est suffisante?

Trop souvent, lorsque vous essayez de concevoir pour le futur, vos prédictions concernant les besoins futurs se révèlent fausses. Il est généralement préférable de refactoriser lorsque vous savez réellement comment les besoins ont changé plutôt que de sur-concevoir votre système dès le premier jour. En même temps, ne vous tirez pas une balle dans le pied non plus. Il y a certainement un terrain d'entente, et savoir où il en est, c'est plus que de l'art.

Pour résumer à une règle de base: moins c'est plus.

Êtes-vous familier avec Agile? YAGNI est l’un des grands principes de l’ agilité . Je trouve que c'est la meilleure façon d'aborder les choses.

"Vous n'en aurez pas besoin" ... est un principe de programmation extrême (XP) qui stipule qu'un programmeur ne doit pas ajouter de fonctionnalités avant que cela soit jugé nécessaire. Ron Jeffries écrit: "Appliquez toujours les choses lorsque vous en avez réellement besoin, jamais quand vous prévoyez en avoir besoin."

... YAGNI est l’un des principes de la pratique XP consistant à "faire le plus simple possible" (DTSTTCPW). Il est destiné à être utilisé en combinaison avec plusieurs autres pratiques, telles que la refactorisation continue, les tests unitaires automatisés en continu et l'intégration continue . Utilisé sans refactorisation continue, il pourrait conduire à un code compliqué et à un remaniement massif. La refactorisation continue s'appuie à son tour sur des tests unitaires automatisés en tant que filet de sécurité (pour détecter les anomalies imprévues) et sur une intégration continue pour éviter des problèmes d'intégration plus vastes ...

YAGNI n'est pas universellement accepté comme principe valable, même en combinaison avec les pratiques d'accompagnement. La nécessité de le combiner avec les pratiques de support, plutôt que de l'utiliser de manière autonome, fait partie de la définition originale de XP ...

C’est probablement l’un des aspects les plus difficiles du développement logiciel car il faut franchir la ligne entre "YAGNI" et "PYIAC" (peignez-vous dans un coin).

Il est assez facile de dire "n'écrivez pas une fonctionnalité si vous n'en avez pas besoin". La partie difficile consiste à concevoir votre code de sorte que vous puissiez facilement ajouter des fonctionnalités ultérieurement, lorsque vous en aurez besoin.

La clé est de pouvoir concevoir une architecture extensible dans laquelle vous n'écrivez pas plus de code que ce dont vous avez actuellement besoin. La capacité de bien faire cela vient vraiment de beaucoup d’expérience (et de douleur).

Je passe un peu de temps à réfléchir à la direction générale de la conception - pas trop, mais assez pour esquisser un aperçu de haut niveau. Je suis ensuite une méthodologie agile basée sur des histoires utilisant TDD pour développer des solutions pour des histoires individuelles. Lors de la mise en œuvre via TDD, je garde mon aperçu de haut niveau en tête et soit (a) ordonne à mes mises en œuvre particulières de suivre la vue d'ensemble de haut niveau, soit (b) reformule (et améliore) ma compréhension / orientation de haut niveau en fonction de ce que j'ai appris lors des tests / de la mise en œuvre.

Je pense que c'est une erreur de ne pas planifier d'avance, mais c'est probablement une plus grande tâche d'en faire trop. Autant que possible, j'aime bien me laisser guider par l'expérience, puis laisser la conception se développer de manière organique, selon les lignes que j'ai définies dans mon esprit quant à la façon dont l'application va se développer. En utilisant TDD, je trouve que la conception elle-même est soumise à de meilleurs principes de conception (découplage, responsabilité unique, etc.) et est plus malléable en ce qui concerne les modifications que si j'essayais de concevoir le tout et d'y intégrer l'évolution.

Un bon design tient compte des changements futurs et vaut vraiment la peine. Considérez le système d'exploitation UNIX et son "Tout est une philosophie de fichier". Cette décision de conception a été prise non pas pour répondre à un besoin immédiat, mais pour tenir compte des besoins futurs. On frémit de penser à quoi ressemblerait un système d'exploitation basé sur une conception "agile".

Ce que vous essayez de gérer concerne la réutilisation (c'est-à-dire la généralisation d'un problème que vous êtes en train de traiter afin que vous puissiez réutiliser le travail (code) à l'avenir). Je l' ai dit avant et je vais lier à nouveau.

Je pense avoir entendu d'autres personnes dire quelque chose à l'effet de:

Je résous le problème la première fois. Quand je répète ma solution la première fois, je le note. Quand je le répète encore, je refactorise.

Concevoir pour "maintenant + 1". Cela signifie que vous devez résoudre le problème immédiat et intégrer suffisamment de fonctionnalités pour que la prochaine fois que vous demandez un changement, vous l'avez déjà fait à mi-chemin (ou plus) et vous avez le choix entre a) le résoudre immédiatement et refactoring plus tard, ou b) résoudre à nouveau "maintenant + 1" (avec "maintenant" à moitié fait)

Cela dépend du projet et, en bref, l'expérience vous apprendra ce qu'est le "+1".

La philosophie de YAGNI , vous n'en aurez pas besoin, peut être résumée avec (de l'article):

Selon ceux qui préconisent l’approche YAGNI, la tentation d’écrire du code qui n’est pas nécessaire pour le moment, mais qui pourrait l’être à l’avenir, présente les inconvénients suivants:

• Le temps nécessaire est pris en ajoutant, en testant ou en améliorant les fonctionnalités nécessaires.
• Les nouvelles fonctionnalités doivent être déboguées, documentées et prises en charge.
• Toute nouvelle fonctionnalité impose des contraintes sur ce qui peut être fait dans le futur. Une fonctionnalité inutile peut dès lors empêcher la mise en œuvre ultérieure d'une fonctionnalité nécessaire.
• Tant que cette fonctionnalité n’est pas réellement utile, il est difficile de définir complètement ce qu’elle doit faire et de la tester. Si la nouvelle fonctionnalité n'est pas correctement définie et testée, elle risque de ne pas fonctionner correctement, même si cela est éventuellement nécessaire.
• Cela conduit à un gonflement du code; le logiciel devient plus grand et plus compliqué.
• À moins de spécifications et d'une sorte de contrôle de révision, il est possible que les programmeurs ne connaissent pas cette fonctionnalité.
• L'ajout de la nouvelle fonctionnalité peut suggérer d'autres nouvelles fonctionnalités. Si ces nouvelles fonctionnalités sont également implémentées, cela peut entraîner un effet de boule de neige et donner lieu à des fonctionnalités insidieuses.

Je suis un fervent partisan de la conception du problème à résoudre et de ne pas détruire votre conception en essayant de deviner tous les cas que vous devez prendre en charge, car «un jour, nous en aurons peut-être besoin».

Fondamentalement, étant donné une liste d'exigences spécifiques, concevez par rapport à cela, cependant, cela ne signifie pas que vous ne devriez pas:

• rendre les aspects de votre conception configurables plutôt que de les coder en dur dans votre solution. Soit via des paramètres passés au moment de l'exécution, soit via une configuration externe lue au démarrage (ou après HUP ').
• lacez votre code avec des nombres magiques,
• évitez de regarder pour voir s'il y a déjà quelque chose d'écrit que vous pouvez réutiliser, peut-être après avoir adapté la solution existante pour fournir une approche adaptée à la situation existante ainsi qu'aux nouvelles exigences.

Le principal problème de la conception d'un "avenir possible" est que vous ne faites que deviner. Peut-être faire des suppositions éclairées, mais «quand les choses se gâtent», ce n'est toujours qu'une série de suppositions.

En faisant cela, vous avez également la possibilité très réelle de compresser votre solution pour qu’elle corresponde au (x) cas (s) général (aux) plutôt qu’à la résolution du problème spécifique tel que défini par vos exigences connues.

Qu'est-ce que ça dit? "Quand tout ce que vous avez est un marteau, tout commence à ressembler à un clou."

J'aimerais avoir une livre pour chaque fois que j'ai entendu quelqu'un dire: "Mais c'est une solution qui est plus adaptable pour les cas généraux que nous verrons peut-être à l'avenir."