Est-ce que quelqu'un d'autre a le sentiment que les solutions pour des projets simples sont souvent sur-élaborées?

Question

D'une manière ou d'une autre, j'ai l'impression que de nombreux projets sont fortement surdéveloppés, de sorte que toutes les demandes de changement possibles peuvent être traitées avec l'effet que les demandes de changement sont très difficiles à implémenter.

D'une manière ou d'une autre, je ressens ce sentiment dans presque tous les projets sur lesquels je travaille actuellement. C'est comme si tout le monde pensait «quelle api cool, cadre, etc. pouvons-nous ajouter au projet pour aborder tel ou tel aspect» sans évaluer si c'est pratique ou nécessaire.

Est-ce que quelqu'un d'autre ressent la même chose ou quelle est l'opinion de la communauté ici?

Answer 1

Je trouve que, bien que certaines anciennes entreprises avec la haute direction « senior » ont tendance à être extrêmement rigide avec la façon dont leur code d'entreprise est créée, les entreprises plus récentes manquent complètement une épine dorsale de ce logiciel qu'ils utilisent pour finis le travail. Le problème que vous décrivez semble être que les gens voient les problèmes à un niveau trop élevé et veulent trouver un moyen de les résoudre en une fois. Créer une boîte à outils de travail (pensez aux bibliothèques standard) les aiderait à long terme. J'apprécie particulièrement le mode de fonctionnement UNIX: Plusieurs petits utilitaires qui font une chose et qui le font vraiment bien.

Answer 2

Oui.

- MarkusQ

Answer 3

Définitivement - Je pense que les gens sont souvent trop «robustes et modulaires» et «surdimensionnés».

Answer 4

Je suis encore à travailler sur n'importe quel problème du monde réel, mais j'ai lu suffisamment de gens blogging à ce sujet pour supposer qu'il y a un problème.

Answer 5

Coupable comme accusé. Trois niveaux d'abstraction et six fichiers de configuration sont simplement plus amusants à implémenter qu'une simple branche de contrôle de flux.

Answer 6

La sur-ingénierie est un danger dans tout projet, grand ou petit. Lorsque vous écrivez pour l'extensibilité du code, il y a toujours un compromis entre l'écriture d'un code suffisamment générique et extensible pour permettre un développement futur et un code suffisamment spécifique pour rendre la tâche facile. Chaque «futur hameçon» a un coût et doit être évalué en fonction de ce coût, de la probabilité qu'il sera jamais utilisé et du coût de refactoring plus tard dans le jeu. "Plus générique" n'est pas toujours meilleur. En ce qui concerne l'utilisation d'une structure ou d'un API nouveau et chaud, je pense que les chefs de projet devraient prendre les choses en main. Le développement étant un domaine en évolution rapide, l'autoformation pratique fait partie du prix à payer pour faire des affaires (mais doit évidemment rester raisonnable.)

Answer 7

Je l'ai seulement rencontré avec des gens de Java: «Utilisons printemps!" Et hiberner! J'ai aussi trouvé ce super paquet de validation! Et celui-ci va créer XSLT pour créer des formulaires XML pour créer le javascript! "

Au moment où je trouve tous les pots et les amener à jouer sympa, il y a des dizaines de classes que je dois connaître. vouloir faire abstraction de tous ces morceaux! "Nous pourrions changer de ressort. Ou ne pas utiliser hibernate, donc nous devrions les abstraire. "Ajouter une autre douzaine de classes wrapper hacky.Au moment où tout cela est fait, 50 lignes de code de psuedo se sont transformées en plusieurs milliers de lignes pour faire fonctionner les «trucs cool» et environ 100 lignes de logique métier piégées dans son enfer poilu, hacky, bug-monté. Je suis coupable de moi-même, aussi, mais c'est seulement parce que je m'ennuie et que j'ai le temps de tuer.

Answer 8

Je pense Dave Winer captured the cyclical nature of this phenomenon bien:

L'astuce dans chaque cycle est de lutter contre complexité, de sorte que la croissance peut continuer aller. Mais vous ne pouvez pas le garder dehors, les ingénieurs comme la complexité, non seulement parce qu'il leur fournit la sécurité du travail, aussi parce qu'ils aiment vraiment juste. Mais une fois que la pile devient trop mystérieuse, la génération suivante lève la main et dit "Nous n'allons pas traiter avec ce bordel."

Answer 9

La principale chose à garder à l'esprit ici est le temps. Un projet «simple» qui est éliminé du parc dès le premier jour par une feuille de calcul Excel ou une page Web peut rapidement développer à la fois son public et sa portée pour devenir un monstre insoutenable.

La sous-ingénierie est également un danger. Le monde est plein de gens «pratiques» qui se moqueront de tout effort contraire à leur opinion. Personne ne se souvient de la personne qui n'était pas d'accord un an plus tard lorsque la solution «simple» ne peut être maintenue.

L'astuce consiste à équilibrer le bon niveau d'ingénierie et être capable de s'adapter lorsque les choses changent.

Answer 10

J'ai été mordu quelques fois trop souvent par des applications que j'ai assemblées rapidement et qui sont ensuite devenues des applications «critiques». Ensuite, je dois presque réécrire la chose reprochée. Je suppose juste maintenant que cela deviendra critique et donc je "écris bien" la première fois. Cela me fait gagner du temps et de l'énergie à long terme. Bizarrement, c'est de la paresse.

Answer 11

Absolument. Mais ce ne sont pas seulement les développeurs, ce sont aussi les utilisateurs. "Je veux ceci et cela et l'autre afin d'améliorer la communication et augmenter la productivité!". Je suis étonné de voir combien de ces types de projets nous avons résolus en plaçant simplement un dossier partagé sur un serveur de fichiers.

Answer 12

Je pense que c'est un problème, mais pas aussi grand qu'il n'y paraît et qu'il y a de bonnes raisons à cela. Le problème est que la plupart des projets qui sont sous-traités vont mourir d'une mort rapide alors que ceux qui sont surexploités peuvent survivre. Ainsi, quand on regarde un projet encore en vie, il y a un biais de survie. Et, même si vous êtes un bon architecte qui vise "juste assez bien", en cas de doute, vous utiliserez la solution la plus flexible, évolutive, ... (c'est-à-dire, sur-ingénierie). Parce que le mode de défaillance si vous ne répondez pas aux exigences (quel qu'il soit) est généralement bien pire que ce qui se passe si vous les excédez.

Answer 13

Comme d'autres l'ont dit, j'ai eu trop de «petits» projets deviennent de grands projets et les raccourcis pris deviennent de la peinture.

Il ya une place pour une solution rapide et sale et en essayant de suivre le mantra YAGNI, j'ai créé des applications simples sans ingénierie.Avec cela cependant, vous ne serez pas en mesure de sauter dans un système de millions de lignes et de développer le système «bien conçu» sans pratique sur les petits systèmes.

J'ai toujours suivi l'architecture développée de notre entreprise dans tous les projets car cela m'aide à élaborer des solutions en accord avec les principes d'ingénierie que nous essayons de suivre. Ce que vous pratiquez, vous effectuez, alors faites toujours de votre mieux.

Answer 14

xkcd Aujourd'hui est la vérité absolue:

Je trouve que overengineering est un sous-produit de l'ennui. Je crois que Jeff et Joel ont couvert cela dans un podcast, mais l'idée est que les codeurs qui sont souvent trop grands peuvent être dans une ornière et ont besoin d'un changement de rythme (Jeff et Joel suggèrent qu'ils puissent faire différents jobs comme QA).

Answer 15

Oui. Je pense que les gens pensent de plus en plus à la façon dont quelque chose doit être fait, et si "c'est la bonne façon ..." et ainsi de suite, que simplement choisir la solution simple qui fera également le travail. Si vous n'êtes pas invité à l'étendre, alors ne pensez pas à l'étendre.