Moi aussi j'ai été victime de l'over-engineering : soit de librairies que j'utilise pour développer, soit parce-que je tombe moi même dedans.
Dans la communauté zope3 par exemple on le rencontrait surtout dans la volonté d'être absolument (trop) générique, soit dans la prise en compte des use-cases soit dans l'interchangeabilité des composants (qui est une des philosophies de zope3).
Chez moi la tentation la plus forte qui porte à ce défaut est le fait de vouloir un code trop élégant (qui pousse au bout la logique formelle), ou la prise en compte de trop de use-cases (vouloir être futur proof, ce qui en pratique ne marche pas si souvent...).
Je pense aussi que la multiplicité de styles et de caractères dans une équipe de programmation, ainsi que l'ouverture d'esprit et humilité des développeurs peut beaucoup aider.
# Moi aussi !
Posté par Alex G. . En réponse au journal Lutter contre l'overengineering. Évalué à 5.
Hello,
Moi aussi j'ai été victime de l'over-engineering : soit de librairies que j'utilise pour développer, soit parce-que je tombe moi même dedans.
Dans la communauté zope3 par exemple on le rencontrait surtout dans la volonté d'être absolument (trop) générique, soit dans la prise en compte des use-cases soit dans l'interchangeabilité des composants (qui est une des philosophies de zope3).
Chez moi la tentation la plus forte qui porte à ce défaut est le fait de vouloir un code trop élégant (qui pousse au bout la logique formelle), ou la prise en compte de trop de use-cases (vouloir être futur proof, ce qui en pratique ne marche pas si souvent...).
Je pense aussi que la multiplicité de styles et de caractères dans une équipe de programmation, ainsi que l'ouverture d'esprit et humilité des développeurs peut beaucoup aider.