Un de mes amis travaille pour une petite entreprise sur un projet que chaque développeur détesterait: il est poussé à publier le plus rapidement possible, il est le seul qui semble se soucier de la dette technique, le client n'a pas de formation technique, etc.
Il m'a raconté une histoire qui m'a fait réfléchir à la pertinence des modèles de conception dans des projets comme celui-ci. Voici l'histoire.
Nous devions afficher les produits à différents endroits sur le site. Par exemple, les gestionnaires de contenu peuvent afficher les produits, mais également les utilisateurs finaux ou les partenaires via l'API.
Parfois, des informations manquaient dans les produits: par exemple, un groupe d’entre eux n’avait aucun prix lors de la création du produit, mais le prix n’était pas encore précisé. Certains n'avaient pas de description (la description étant un objet complexe avec des historiques de modifications, un contenu localisé, etc.). Certains manquaient d'informations sur l'envoi.
Inspiré par mes lectures récentes sur les modèles de conception, j'ai pensé qu'il s'agissait d'une excellente occasion d'utiliser le modèle d'objet magique . Alors je l'ai fait et tout était lisse et propre. Il suffisait d'appeler
product.Price.ToString("c")
pour afficher le prix ouproduct.Description.Current
pour afficher la description; aucun truc conditionnel requis. Jusqu'au jour où l'intervenant a demandé à l'afficher différemment dans l'API, en disposant d'unnull
fichier JSON. Et aussi différemment pour les gestionnaires de contenu en affichant "Prix non spécifié [changement]". Et j'ai dû assassiner mon motif Null Object bien-aimé, car il n'était plus nécessaire.De la même manière, j'ai dû supprimer quelques usines abstraites et quelques constructeurs. J'ai fini par remplacer mon magnifique motif Facade par des appels directs et laids, car les interfaces sous-jacentes changeaient deux fois par jour pendant trois mois, et même le Singleton me quittait. lorsque les exigences indiquent que l'objet concerné doit être différent en fonction du contexte.
Plus de trois semaines de travail ont consisté à ajouter des motifs, puis à les déchirer un mois plus tard. Mon code est finalement devenu suffisamment spaghetti pour que personne, y compris moi, ne puisse le conserver. Ne vaudrait-il pas mieux ne jamais utiliser ces schémas?
En effet, je devais travailler moi-même sur ce type de projets où les exigences changent constamment et sont dictées par des personnes qui ne tiennent pas vraiment compte de la cohésion ou de la cohérence du produit. Dans ce contexte, votre agilité importe peu, vous apportez une solution élégante à un problème, et lorsque vous le mettez finalement en œuvre, vous découvrez que les exigences ont changé si radicalement que votre solution élégante ne convient pas. plus longtemps.
Quelle serait la solution dans ce cas?
Ne pas utiliser de modèles de conception, arrêter de penser et écrire du code directement?
Il serait intéressant de réaliser une expérience dans laquelle une équipe écrit du code directement, tandis qu'une autre réfléchit à deux fois avant de taper, prenant le risque de jeter le design original quelques jours plus tard: qui sait, peut-être que les deux équipes auraient le même dette technique. En l'absence de telles données, j'affirmerais simplement qu'il ne semble pas correct de taper du code sans réfléchir au préalable lorsque l'on travaille sur un projet de 20 hommes-mois.
Conservez le modèle de conception qui n’a plus de sens et essayez d’ajouter plus de modèles à la situation nouvellement créée?
Cela ne semble pas juste non plus. Les modèles sont utilisés pour simplifier la compréhension du code; mettre trop de motifs, et le code deviendra un gâchis.
Commencez à penser à un nouveau design qui englobe les nouvelles exigences, puis modifiez lentement l'ancien design pour le transformer en nouveau?
En tant que théoricien et celui qui favorise Agile, je suis totalement dedans. En pratique, lorsque vous savez que vous devez revenir au tableau blanc toutes les semaines pour refaire la majeure partie du modèle précédent et que le client n'a tout simplement pas les moyens de le payer, ni le temps d'attendre. , cela ne fonctionnera probablement pas.
Alors, des suggestions?