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

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.

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 .

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.

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.