Quand faut-il supprimer la complexité?

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)

1. 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.

2. 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)?

À certains égards, je pense que c'est en grande partie une décision commerciale et pas nécessairement basée sur le code lui-même. Quelques points à considérer:

• Êtes-vous payé pour effectuer les changements?
• Le code fonctionne-t-il actuellement comme prévu?
• Existe-t-il des problèmes de sécurité ou de performances avec le code tel quel?
• Le montant de la dette technique l'emporte-t-il sur le coût de sa réparation?
• Que se passera-t-il de manière réaliste si vous laissez le code tel quel?
• Quels sont les problèmes futurs qui pourraient surgir avec ou sans refactoring?
• Quelle est la responsabilité du code pour vous et votre entreprise?

Vous êtes le mieux placé pour répondre à ces questions. Cependant, sur la base de votre description, je ne sais pas si je prendrais la peine de refactoriser et de simplifier les choses car cela ne semble pas valoir que cela vaudra votre temps. Si cela fonctionne actuellement, le client est content et vous n'aimez pas être payé pour tout mettre à jour, alors laissez-le faire et travaillez sur une activité génératrice de revenus.

En bref, effectuez une analyse coûts-avantages et une évaluation des risques des deux voies et prenez la ligne de conduite la plus sûre, la plus efficace et la plus rentable.

N'est-ce pas supprimer ce code et le remplacer par quelque chose de simple pour faciliter la programmation future d'une fonctionnalité que le client doit considérer et payer?

Vous pourriez avoir quelque chose d'utile dont un autre développeur pourrait tirer parti, mais les chances de trouver l'application d'un autre client pour la brancher ne sont pas probables.

Les commérages sur le code du concurrent ne sont pas quelque chose que vous pouvez empêcher. Ils auront l'air stupide d'essayer de recruter négativement des clients.

Un dicton commun est: "Si ce n'est pas cassé, ne le répare pas".

Il y a plusieurs raisons derrière cette règle. Certains de ceux-ci pourraient être que la "simplification" risquerait d'introduire de nouveaux bogues différents et peut-être plus gros, pourrait prendre un temps de développement croissant loin d'autres efforts plus précieux et pourrait être complètement le mauvais changement pour une opportunité commerciale future inattendue qui se pose.

S'il y a suffisamment de valeur commerciale pour que ce code soit portable et plus facile à gérer, alors décidez si cette valeur est vraiment suffisante pour considérer le code actuel "cassé". Cela pourrait bien être le cas si une expansion commerciale majeure est prévue ou si vous soupçonnez un bug latent caché dans la complexité qui pourrait faire baisser l'entreprise.

Tout d'abord, si l'application a déjà été reprise par un nouveau propriétaire, cela peut se reproduire. Et le prochain propriétaire peut recommencer à utiliser cette complexité dont on ne profite pas pour le moment.

En dehors de cela, les modifications non triviales du code de travail entraînent toujours un risque, ainsi (comme d'autres l'ont noté), le client doit les accepter (et les payer). Si la complexité "supplémentaire" actuelle ne provoque pas d'inconvénient notable et mesurable (comme des problèmes de performances), il n'y a aucune raison valable de la supprimer.

Les clients (potentiels) qui (ne) vous embauchent pas uniquement sur la base des rumeurs de leurs concurrents ne valent pas la peine, à moins que vous ayez désespérément besoin de revenus. Vous avez de bonnes raisons logiques pour lesquelles vous avez implémenté l'application comme vous l'avez fait, et tout client sérieux est susceptible de le comprendre. Quelqu'un qui ne - ou ne prend même pas la peine de vous poser des questions - serait susceptible de vous causer plus de problèmes en cours de route que le travail ne vaut de toute façon.

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?

Non.

Même si la réponse à la question ci-dessus est généralement «non», est-il sage de supprimer cette complexité «inutile» si vous confiez le projet à un concurrent (ou à un étranger)

Non. Pourquoi perdre votre temps à réparer les travaux de faible priorité comme celui-ci? Pas de mal pour le code de rester là-bas.

Quant à votre question: quand faut-il supprimer la complexité?

Je pense que si ce n'est pas cassé, ne le répare pas .

Pour pouvoir supprimer la complexité, les conditions suivantes doivent être remplies:

1. La pièce retirée doit être indépendante du programme. S'il y a des dépendances du programme environnant au code en question, la suppression de la complexité ne fonctionnera pas
2. Malheureusement, si cela ressemble à de la complexité, il est très probable que les pièces ne soient pas indépendantes et les dépendances vont casser votre programme lorsque vous supprimez la pièce
3. La suppression de toutes les dépendances va prendre du temps, de sorte que le temps doit être pris en compte lorsque vous estimez si l'opération en vaut la peine
4. La plupart du temps, cela ne vaut pas la peine, mais vous déciderez simplement de ne pas utiliser de nouveau code avec l'ancien

Je pense qu'il y a quelque chose de plus grand au travail ici ...

Ce dont vous parlez est appelé évolutivité . Peu importe si le code est complexe, il importe que l'application puisse évoluer en fonction de nouvelles règles métier ou de règles métier modifiées. Que se passe-t-il si le prochain propriétaire veut quelque chose de totalement différent.

Donc, je dis garder le code et le documenter. C'est une caractéristique de la façon dont l'application peut être utilisée.

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?

Il y a un effort et un risque pour éliminer la complexité. Si cela est supérieur à l'effort supplémentaire et au risque de maintenir le code trop complexe, vous le conservez. Sinon, vous le supprimez. Il est cependant difficile d'estimer ces risques.

J'ajouterais que vous pouvez atténuer le risque d'une maintenance plus difficile en documentant pourquoi vous avez utilisé la stratégie de modèle de conception en premier lieu, dans le code. Personnellement, je crois que tout modèle de conception doit être lié à une exigence explicite (fonctionnelle ou non fonctionnelle).

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)?

Votre scénario d'être dissipé par la concurrence pour les heures de rembourrage est précisément la raison pour laquelle vous devez documenter la complexité. Si vous documentez et justifiez (avec une exigence spécifique du client) l'utilisation de n'importe quel modèle, alors vous êtes couvert. Si vous ne pouvez pas justifier un modèle avec les exigences d'un client, cela ressemble à une conception excessive ou à une patternite.

Si les exigences changent, vous pouvez justifier de le laisser en raison du risque que vous puissiez casser le code (ou la quantité de travail pour supprimer chirurgicalement le modèle).

Je pense qu'il est bon de faire la distinction entre la complexité accidentelle et la complexité essentielle , car les modèles impliquent souvent les deux.

Autrement dit, votre exigence de prendre en charge différents algorithmes pour décider des augmentations est une complexité essentielle (une partie du problème à résoudre). La maintenance de votre code est facilitée par le modèle de stratégie, mais l'alternative codée en dur si / alors à la stratégie fonctionnera toujours. J'ai fait des exercices dans mes cours de master où les étudiants trouvent des opportunités d'appliquer la stratégie dans des projets open source. La complexité n'est pas nécessairement meilleure / pire lors de l'application de la stratégie (car c'est une complexité essentielle ). Parfois, il peut être encore plus difficile de comprendre la stratégie, car le code est divisé en plusieurs classes avec polymorphisme, plutôt qu'en un gros bloc if / then / else.

Idéalement, un modèle fonctionne lorsque les avantages qu'il procure l'emportent sur le coût de ses inconvénients. Encore une fois, il est difficile de quantifier ces choses. Souvent, un motif rend le développeur heureux (pas seulement parce qu'il facilite l'ajout d'une nouvelle stratégie d'augmentation, mais lui donne des flous chaleureux pour le développeur de savoir qu'un motif a été appliqué). Il est difficile de montrer aux clients comment cela leur profite.

Le client s'en fiche ou ne comprend même pas les détails. Dans le cas du nouveau propriétaire appliquant KISS dans ses processus, c'est elle qui réduit la complexité essentielle , ce qui devrait également avoir un impact sur la solution logicielle.