L'introduction prématurée de la complexité en mettant en œuvre des modèles de conception avant qu'ils ne soient nécessaires n'est pas une bonne pratique.
Mais si vous suivez tous (ou même la plupart) les principes SOLID et utilisez des modèles de conception communs, vous introduirez une certaine complexité à mesure que des fonctionnalités et des exigences sont ajoutées ou modifiées pour garder votre conception aussi maintenable et flexible que nécessaire.
Cependant, une fois que cette complexité est introduite et fonctionne comme un champion, quand la supprimez-vous?
Exemple. J'ai une demande écrite pour un client. Lors de sa création, il y avait plusieurs façons de donner des augmentations aux employés. J'ai utilisé le modèle de stratégie et l'usine pour garder l'ensemble du processus agréable et propre. Au fil du temps, certaines méthodes de relance ont été ajoutées ou supprimées par le propriétaire de l'application.
Le temps passe et le nouveau propriétaire prend le relais. Ce nouveau propriétaire est dur, garde tout simple et n'a qu'une seule façon de donner une augmentation.
La complexité requise par le modèle de stratégie n'est plus nécessaire. Si je devais coder cela à partir des exigences telles qu'elles sont maintenant, je n'introduirais pas cette complexité supplémentaire (mais assurez-vous que je pourrais l'introduire avec peu ou pas de travail si le besoin s'en faisait sentir).
Alors, je supprime la mise en œuvre de la stratégie maintenant? Je ne pense pas que ce nouveau propriétaire changera jamais la façon dont les augmentations sont accordées. Mais l'application elle-même a démontré que cela pouvait arriver.
Bien sûr, ce n'est qu'un exemple dans une application où un nouveau propriétaire prend le relais et a simplifié de nombreux processus. Je pourrais supprimer des dizaines de classes, interfaces et usines et rendre l'application beaucoup plus simple. Notez que l'implémentation actuelle fonctionne très bien et le propriétaire en est satisfait (et surpris et encore plus heureux que j'ai pu implémenter ses changements si rapidement en raison de la complexité discutée).
J'avoue qu'une petite partie de ce doute vient du fait qu'il est fort probable que le nouveau propriétaire ne m'utilisera plus. Je ne me soucie pas vraiment que quelqu'un d'autre prenne le relais car il n'a pas été un gros générateur de revenus.
Mais je me soucie de 2 choses (liées)
Je m'inquiète un peu que le nouveau responsable devra réfléchir un peu plus en essayant de comprendre le code. La complexité est la complexité et je ne veux pas irriter le psycho maniaque qui vient après moi.
Mais plus encore, je m'inquiète pour un concurrent de voir cette complexité et de penser que je viens d'implémenter des modèles de conception pour passer mes heures de travail. Puis répandre cette rumeur pour nuire à mes autres affaires. (J'ai entendu cela mentionné.)
Donc...
En général, la complexité précédemment nécessaire devrait-elle être supprimée même si cela fonctionne et qu'il y a eu un besoin historiquement démontré pour la complexité, mais vous n'avez aucune indication qu'elle sera nécessaire à l'avenir?
Même s'il est généralement répondu «non» à la question ci-dessus, est-il sage de supprimer cette complexité «inutile» si vous confiez le projet à un concurrent (ou à un étranger)?