Existe-t-il un terme pour une complication excessive de la POO?

18

Il y a un an ou deux, j'ai vu un excellent article sur la POO (Java), qui montrait la progression d'un simple enregistreur concret de deux ou trois lignes de code, et une réflexion théorique excessive par le développeur inexpérimenté qui disait essentiellement oh, je devrais ajoutez ceci au cas où nous le voudrions! À la fin de l'article, ce simple enregistreur était un gâchis géant que le développeur d'origine pouvait à peine se comprendre ...

Y a-t-il un terme commun pour ce type de sur-complication? Cet article (que je souhaite vivement retrouver) montre à merveille le concept d'un cas isolé, mais j'ai rencontré des projets entiers où les développeurs s'étaient essentiellement programmés en un nœud par une utilisation excessive de modèles, de cadres, de bibliothèques et autres issues. À sa manière, c'est aussi mauvais (voire pire) que les applications de spaghetti VB6 héritées dont nous héritons pour le remplacement.

Ce que je recherche vraiment, c'est d'en parler lors des entretiens. Je veux savoir si quelqu'un est conscient et conscient de la facilité avec laquelle il est possible de tomber dans ce manque d'architecture / de pré-planification (et d'obtenir une chute pour savoir s'il semble avoir le bon équilibre en place), mais ce n'est pas vraiment quelque chose Je peux trouver beaucoup d'informations sur.

jleach
la source
25
Ouais, ça s'appelle OOP.
gardenhead

Réponses:

28

Le terme le plus fréquent que j'ai entendu pour décrire de telles conceptions est l' ingénierie excessive . Le sens original de ce mot, cependant, n'est pas lié au développement de logiciels, et en dehors du développement de logiciels, il n'a probablement pas un si mauvais ton.

À un niveau plus général, Joel Spolsky a donné aux concepteurs qui compliquent les conceptions architecturales le nom d '« astronautes d'architecture ».

Cependant, en particulier pour une interview, je pense qu'il est plus important de savoir ce que l'on appelle le contraire, de ne mettre que des éléments dans un design qui sont réellement nécessaires et d'oublier l'approche malsaine "au cas où" - c'est ce qu'on appelle le principe YAGNI .

Doc Brown
la source
Merci. Je suis un grand défenseur de YAGNI, je ne savais pas s'il y avait un opposé commun.
jleach
Je voudrais souligner que Yagni concerne "ce dont nous avons réellement besoin en ce moment". Vous devriez toujours laisser les choses de côté, même si on sait qu'elles seront nécessaires plus tard, tant qu'elles ne sont pas nécessaires pour le moment.
Bent
7
@Bent Je voudrais également souligner que cela ne signifie pas d' ignorer complètement les choses / changements que vous savez avec certitude qui vont se produire dans la fonctionnalité proche ... savoir comment le logiciel sera étendu après peut vous guider pour écrire du code qui sera plus facilement refactorisable le long de ces axes de changement.
Bakuriu
J'ai utilisé le terme «mauvaise ingénierie» par opposition à «suringénierie». J'ai travaillé avec des gens qui aiment ajouter toutes sortes de fonctionnalités et d'extensions "au cas où" qui n'ont pas de cas d'utilisation clairs. Si vous ne comprenez pas le problème que vous essayez de résoudre, c'est simplement une mauvaise ingénierie.
Josh Johnson
4

Oui, la suringénierie est le terme le plus simple pour décrire cela. J'ai vu des conceptions trop élaborées et inutilement compliquées plus de fois que je ne m'en souviens au fil des ans. Il y a de nombreuses années, en suivant un cours Microsoft GWBasic, l'instructeur a martelé à plusieurs reprises la méthode KISS (Keep it Simple Stupid). C'est aussi vrai aujourd'hui qu'il l'était alors.

Je me souviens donc toujours de KISS et je conçois toujours avec des principes SOLID en tête. Mais cela étant dit, il est toujours possible de sur-concevoir une conception avec des principes SOLIDES pleinement pris en compte. Vous devez équilibrer une approche pragmatique de bon sens avec le désir d'être pur et d'adhérer aux directives de la POO généralement acceptables. Si vous disposez de suffisamment de temps et si vous aimez créer des solutions complexes, vous pouvez vous retrouver sur la voie de la conception d'un moteur pour une planche à roulettes parce que vous pensiez qu'il serait éventuellement transformé en voiture. Heureusement, j'ai été suffisamment discipliné pour ne pas faire cela au fil des ans, mais je l'ai vu plusieurs fois.

Donc, pour résumer, pour éviter une surcompression de code:

1) KISS (Keep it Simple Stupid)

2) Suivez les principes SOLID en gardant à l'esprit l'aspect pratique.

3) N'essayez pas de concevoir pour chaque éventualité. Et parfois, de petites abstractions qui fuient ne sont pas des choses horribles, si elles sont isolées, intentionnelles et si l'effort de les prévenir l'emporte de loin sur les effets de leur conservation.

4) Envisagez la mise en œuvre de solutions lors de leur conception. Vous ne pouvez pas simplement dire "oh, c'est un détail d'implémentation" et supposer que votre conception est pratique. J'avais l'habitude de travailler avec un architecte qui faisait cela fréquemment, et hélas, ses créations n'ont jamais fonctionné, et en conséquence, je n'y travaille plus.

5) Codez comme si vous étiez celui qui allait le maintenir.

David Spenard
la source
-3

Donc, vous allez avoir cette interview et vous avez l'intention de tromper le candidat en lui montrant ce qu'il sait sur le génie logiciel et ensuite vous allez dire "Nan, vous voulez probablement appliquer tout ce que vous savez dans votre première mission, continuez maintenant , créatrice de sur-ingénierie plaquée or et non commerciale! Shoo! "

Je pense qu'il serait plus sûr de présenter un exemple concret et de discuter des avantages et des inconvénients de l'application de certains modèles. Que vous seriez en train de solliciter des réponses comme "Cela dépend, voulez-vous que ce soit rapide? Est-ce que ce sera tout? Quelle est la complexité du problème? Quels modèles sont déjà en place?" et vous pouvez apprendre quelque chose vous-même. Cela permettrait également au candidat de prouver son sens du contexte alors que ce serait une question plus ouverte. Attendre et vouloir une réponse spécifique vous permettra au mieux de trouver quelqu'un avec la même préoccupation que la vôtre. Si vous n'obtenez pas votre réponse, il se peut que le candidat considère cela comme une évidence.

Martin Maat
la source
4
Je suis désolé, mais je me demandais vraiment s'il y avait un terme pour cela. Je ne cherchais pas de conseils sur la façon de mener une entrevue (ou de faire en sorte que ma question soit perçue de quelque façon que ce soit sur la façon dont je mènerais une entrevue). Merci pour votre inquiétude ...
jleach
1
Eh bien, vous avez écrit ce dernier paragraphe de votre question, qui est difficile à ignorer et tout à fait une déclaration. Si vous n'appréciez pas les commentaires sur certaines parties de votre texte, vous voudrez peut-être être plus restrictif dans ce que vous notez.
Martin Maat