Je viens de lire le lien de l'article que vous avez publié, je dois dire que Fowler a fait de très bons points et beaucoup de choses qu'il a dit, je plaide avec notre équipe depuis des années.
OMI, si vous faites une conception décente, vous ne devriez pas entrer dans ce qui serait considéré comme une situation sans issue. J'ai toujours considéré les logiciels comme des éléments constitutifs . Je crois toujours en une conception initiale, mais l'objectif principal n'est pas de concevoir le produit dans son ensemble, mais de fournir une architecture / direction globale afin que votre équipe puisse visualiser une image commune vers laquelle nous travaillons tous. Si vous avez un tas de morceaux de cube et de triangle, il est utile d'esquisser la façon dont un château serait assemblé avant de commencer à gifler les morceaux ensemble.
Puisque je viens de la terre OO, pour moi chaque bloc est une classe et la surface de ce bloc est l'interface publique (ce qui est visible par les classes externes ou dérivantes). Si vous suivez les bons principes SOLID, vous vous assurerez que chaque bloc est extrêmement simple et dispose d'une interface publique intuitive. Pour en revenir à mon analogie, vous voulez vous assurer que le code ne crée que des formes simples. Chaque fois que vous créez des classes trop complexes (beaucoup de fonctions, beaucoup de variables), vous créez des formes qui sont difficiles à réutiliser quand les exigences changent.
Je suis d'accord avec Fowler en ce que le plus grand risque / défi pour la conception évolutive est que vous laissez les décisions de conception au temps de codage, et vous vous attendez à ce que chaque développeur individuel prenne ces décisions. C'est là que le système peut tomber en panne si vous n'avez pas de mécanismes de rétroaction appropriés en place. Chaque fois qu'une nouvelle fonctionnalité est demandée, il est extrêmement tentant de simplement trouver la fonction qui doit être étendue, de mettre une sorte de condition à l'intérieur et d'ajouter simplement un tas de code à l'intérieur de cette fonction. Et parfois, c'est peut-être tout ce dont vous avez besoin, mais c'est aussi (IMO) la pratique la plus courante qui conduit à des composants sans issue. Cela n'a rien à voir avec la conception évolutive. C'est ce qu'on appelle "pas de conception".
Tant que vous prenez le temps de prendre du recul et de dire, attendez une minute, cette classe a déjà 15 variables membres, laissez-moi en extraire 6 et les mettre dans leur propre classe autonome, votre logiciel sera composé de très léger -blocs de construction légers, flexibles et réutilisables. Bien sûr, si les PM arrivent et modifient la moitié des exigences de produits pour vous, vous devrez peut-être retirer certains de vos blocs, les remettre sur l'étagère et en dessiner de nouveaux (tout comme lors de la construction d'un château, vous ne pouvez pas utiliser tous vos cylindres). Mais à ce stade, cela ne fait que faire partie des affaires. Les exigences ont changé et en gardant votre code flexible et modulaire, vous devriez pouvoir changer votre produit pour l'aligner avec votre nouvelle direction commerciale.
Je crois que cette approche évolutive de la conception fonctionne avec tous les niveaux de compétence de l'ingénieur. Personnellement, je fais du logiciel depuis très longtemps et avant que notre équipe ne passe à une méthodologie agile, j'étais responsable de l'expédition de plusieurs composants majeurs de mon PC de développement presque directement au client avec pratiquement aucun contrôle qualité. En même temps, ces composants sont toujours restés flexibles et maintenables.
J'essaie seulement de dire que je me considérerais relativement décent dans la conception de logiciels. En même temps, si vous me demandiez de rédiger un document de conception de 100 pages, de le donner à un codeur et de s'attendre à ce qu'il fonctionne, je ne pourrais probablement pas me concevoir à partir d'un sac en papier. Au début du travail, je dessinais parfois quelques diagrammes de type UML (très simplifié, pas en langage complet), mais lorsque je commence à coder, je refactoriserais selon les besoins et mon code final ne ressemblerait jamais à ce que j'avais dessiné à l'origine. Même si je passe un mois ou deux à penser à chaque petit détail, je ne peux pas imaginer que quelqu'un d'autre puisse prendre mes diagrammes et proposer un logiciel solide sans modifier la conception pendant le codage.
À l'autre bout du spectre, actuellement dans mon équipe (maintenant agile et je soutiens pleinement cela), nous avons quelques gars qui nous ont rejoints depuis un terrain intégré où ils n'ont fait que du C pendant les 15 dernières années. J'ai évidemment aidé à la planification initiale et à l'organisation des cours, mais je me suis également assuré de faire un suivi avec des révisions de code régulières et des séances de remue-méninges où nous discutons des applications de SOLID et des principes de conception. Ils ont produit du code de spaghetti qui m'a fait un peu grincer des dents, mais avec juste un petit coup de pouce de ma part, ils ont commencé à refactoriser ce qui était déjà produit et la partie drôle est que l'un d'eux est revenu quelques jours plus tard et dit, je déteste pour le dire, mais après avoir déplacé ce code, cela semble beaucoup plus lisible et compréhensible. Impasse évitée. Point I ' Ce que j'essaie de faire, c'est que même quelqu'un qui est complètement nouveau à OO peut produire du code quelque peu décent, tant qu'il a un mentor avec plus d'expérience, pour lui rappeler que «conception évolutive» n'est pas la même chose que «pas de conception». Et même certaines de ses classes "plus complexes" ne sont pas si effrayantes parce que chaque classe n'a pas beaucoup de responsabilité (c'est-à-dire pas beaucoup de code), donc le pire devient pire, si cette classe "cul-de-sac", nous jetez-le et écrivez une classe de remplacement qui a la même interface publique (jusqu'à présent, je n'ai jamais vu un besoin de cette contingence dans tout ce que nous avons écrit et j'ai fait des révisions de code deux fois par semaine).
Pour terminer, je suis également un fervent partisan des documents de conception (au moins pour les conditions commerciales de mon équipe actuelle), mais l'objectif principal de nos documents de conception est la mémoire organisationnelle , de sorte que les documents réels sont écrits après la production du code et refactorisé. Avant le codage, nous avons généralement une phase de conception rapide (parfois moins rapide) où nous esquissons des cours sur des serviettes / mspaint / visio et je rappelle toujours aux gens que cette phase produit un chemin à suivre, pas un plan directeur et lorsqu'ils commencent à coder, tout ce qui n'a pas de sens devrait être changé. Même avec ces rappels, les nouveaux gars ont tendance à essayer de remettre le code en forme dans le design original, même si cela ne leur semble pas naturel. Cela apparaît généralement dans les revues de code.
Dang, j'ai beaucoup écrit. Désolé pour ça.