Comment combattez-vous la complexité de la conception? [fermé]

Question

Je me trouve souvent aux prises avec une ingénierie excessive - la personne en charge de la conception du logiciel propose une architecture extrêmement compliquée.

C’est bien beau d'avoir toutes les fonctionnalités ésotériques que les utilisateurs ne connaîtront jamais et d'avoir ce sentiment d'accomplissement lorsque vous faites quelque chose que tous les articles de magazines vous disent est la dernière chose cool à faire, mais nous sommes consacrerons la moitié de notre temps d’ingénierie à ce monument à notre intelligence, et non, vous savez, au produit dont nos utilisateurs ont réellement besoin et que la haute direction s'attend à obtenir dans un délai raisonnable ou au moins limité.

Et vous devrez probablement revenir à la solution plus simple de toute façon lorsque vous commencerez à manquer de temps, c'est-à-dire si vous en avez l'occasion.

Nous avons tous entendu le refrain: Keep It Simple, Stupid & # 8482;.

Comment vous battez-vous avec la surcomplexité dans votre équipe?

Un exemple sur lequel j'ai dû travailler à plusieurs reprises récemment est le moment où la décision a été prise de passer à une conception de base de données entièrement dénormalisée plutôt qu’à un SGBDR. "car c'est plus rapide!" Les bases de données entièrement dénormalisées sont très difficiles à obtenir et ne conviennent que pour des problèmes de données vraiment spécialisés tels que Flickr ou eBay, et peuvent être extrêmement coûteux en temps de développeur par rapport au reste de votre développement.

Answer 1

Dents et ongles, et parfois tu perds. Le problème est qu’il est toujours facile d’être tenté de construire quelque chose de cool .

  

Pourquoi construire quelque chose de simple et d’efficace quand cela peut être compliqué et merveilleux?

Essayez de rappeler aux gens la règle de XP qui consiste à construire la chose la plus simple qui puisse fonctionner.

Answer 2

Assurez-vous de partager toutes les idées que vous avez avec quelqu'un d'autre. Souvent, nous sommes tellement entraînés à faire les choses d’une certaine manière qu’il faut un autre regard pour vous définir. Il m'est souvent arrivé de résoudre des problèmes épineux en demandant à quelqu'un d'autre de dire: "En avons-nous vraiment besoin?" Cela contribue à simplifier mon code.

En ce qui concerne les relations avec les personnes avec lesquelles vous n'êtes pas d'accord, Ward Cunningham a un bon point:

  

Ce fut un tournant dans ma carrière de programmeur lorsque je réalisai que je n'avais pas à gagner tous les arguments. Je parlerais de code avec quelqu'un, et je dirais: "Je pense que la meilleure façon de le faire est A." Et ils disaient: "Je pense que la meilleure façon de le faire est B. Je dirais:" Eh bien non, c'est vraiment A. " Et ils diraient: "Eh bien, nous voulons faire B." Ce fut un tournant pour moi quand je pouvais dire: "Bien. Do B. Cela ne nous fera pas autant de mal si je me trompe. Cela ne nous fera pas trop de mal si j'ai raison et si vous faites B, car nous pouvons corriger les erreurs. Voyons donc si c'est une erreur. ... Habituellement, cela devient C. C'est une expérience d'apprentissage pour nous deux. Si nous décidons sans expérience, aucun de nous n'apprend vraiment. Ward a gagné, et quelqu'un d'autre n'a pas. Ou vice versa. C'est trop d'une bataille. Pourquoi ne pas dire: «Eh bien, codons-le et voyons ce qui se passe. Si cela ne fonctionne pas, nous le changerons. ""

Mon conseil? Si vous voulez faire quelque chose de mieux, proposez un prototype simple qui démontre que c'est mieux. Les avis sont excellents, mais le code parle.

Answer 3

J'ai vu cette formule quelque part:

skill = complexité du problème / complexité de la solution http://img39.imageshack.us /img39/1586/whatisskill.png

En d’autres termes, il est nécessaire de disposer des compétences nécessaires pour créer une solution simple à un problème complexe. Si quelqu'un conçoit délibérément des solutions complexes trop sophistiquées et en est fier, il est inconsciemment incompétent.

Personnellement, ce qui me permet de garder mes conceptions simples, c’est le cycle TDD. Commencez par rédiger un test spécifiant ce que vous souhaitez atteindre, puis créez " la chose la plus simple: pourrait éventuellement fonctionner & ; Et de temps en temps, réfléchissez à ce que vous avez produit et réfléchissez à la façon de le rendre plus simple.

Ne créez jamais de couches supplémentaires de flexibilité et d'abstraction dans le système, jusqu'à ce que vous ayez besoin de quelque chose que vous avez maintenant. Il est facile de modifier le code lorsque vous disposez d’une bonne suite de tests unitaires. Vous pouvez donc ajouter ces couches d’abstraction ultérieurement, le cas échéant, si le cas échéant. Sinon, "vous n'en aurez pas besoin & ;

. .

Certains symptômes d’une conception trop complexe sont lorsque la rédaction de tests est compliquée. Si les tests nécessitent un code d'installation long, vous avez peut-être trop de dépendances ou, d'une autre manière, une trop grande complexité. Si vous rencontrez des bogues d'accès simultané, vous devriez peut-être réfléchir à la façon de concevoir le système de manière à limiter l'accès simultané au nombre minimum absolu de classes. Utilisez peut-être une architecture de transmission de messages, telle que le modèle Actor, et créez pratiquement chaque composant mono-thread, même si le système dans son ensemble est multi-thread.

Answer 4

Au moins pour moi, le plus gros problème est qu’il est souvent difficile de dire quelle est la fonctionnalité qui y est proposée en raison de sa bonté magaziney conviviale et conviviale, et parce qu’elle offre un niveau de flexibilité qui sera utile pour l'avenir.

Il a été démontré que les gens sont généralement terribles dans l'anticipation de la complexité future et des effets secondaires des décisions actuelles. Malheureusement, cela ne signifie pas toujours que le plus simple est ce qu'il y a de mieux - dans mon cas, il y a eu beaucoup de choses que je trouvais trop compliquées au début et que je ne voyais l'utilité que bien plus tard (euh… printemps). De plus, des choses qui, à mon avis, avaient du sens se sont révélées excessivement compliquées (EJB1). Je sais donc que mon intuition à propos de ces choses est erronée.

Meilleur pari - tout type de couche indirectionnelle devrait être pris en charge avec un argument prenant en charge la valeur de la flexibilité ajoutée par rapport à la complexité de développement ajoutée.

Cependant, les personnes qui maintiennent une configuration de base de données dogmatique de manière abstraite sur des bases abstraites sont probablement dans la zone "en train de la construire parce que j'ai lu que c'était la bonne chose". camp. Cela peut paraître irréaliste, mais certaines personnes pourraient être convaincues si vous construisez une version de test et un test de performance, en particulier si les résultats montrent plus d’efforts conduisant à une augmentation non négligeable des performances.

Answer 5

  

Tout va bien et dandy d'avoir tout   les caractéristiques ésotériques que les utilisateurs vont   ne jamais savoir sur et ...

Ce serait la modification de fonctionnalité , pas une conception inutilement compliquée. C'est différent de votre exemple sur les bases de données.

  

Un exemple avec lequel j'ai dû travailler   à plusieurs reprises est dernièrement lorsque la décision   a été fait pour aller à un pleinement   conception de base de données dénormalisée plutôt   qu'un SGBDR. "parce que c'est plus rapide!"

Dans ce cas, plusieurs choses peuvent se passer. L'un d'entre eux est que vous pouvez avoir tort et que ces personnes pourraient vraiment savoir ce qu'elles disent parce qu'elles ont travaillé avec des exemples très similaires. Une autre est qu'ils peuvent se tromper, c'est-à-dire que leur conception n'offre pas les avantages de vitesse revendiqués. Dans ce cas, il pourrait y avoir deux situations différentes: (1) ils donnent trop de poids à la vitesse dans leur conception, ou (2) la vitesse est vraiment critique. Si la rapidité est vraiment si pertinente, l’équipe ne devrait pas se fier uniquement à des hypothèses, mais plutôt essayer différents prototypes et évaluer leur vitesse sur les chemins critiques. Vous ne construisez pas une voiture de Formule 1 d'une manière juste "parce que c'est plus rapide", vous essayez toujours plusieurs solutions de conception alternatives et choisissez la plus rapide qui n'augmente toujours pas les coûts de maintenance.

Parfois, vous pouvez argumenter et parvenir à un accord, parfois non. C'est la vie.

Un dernier mot, cependant. Vous ne combattez pas la complexité. Vous le traitez. Vous identifiez les choses vraiment importantes et agissez en conséquence.

Answer 6

Je suppose que vous voulez dire par "conception de base de données entièrement dénormalisée plutôt que par un modèle normalisé (par exemple, troisième ou quatrième forme normale)", car un modèle relationnel est géré par un SGBDR, quel que soit son degré de normalisation.

Vous ne pouvez pas juger sans en savoir plus sur vos exigences, vos capacités et celles de vos coéquipiers.

Je crains que votre recommandation de KISS ne fonctionne pas dans ce cas, car une grande table dénormalisée pourrait être défendue comme la chose la plus simple possible.

Comment quelqu'un résout-il ce genre de problèmes? Communication, persuasion, meilleures données, prototypes de technologies et techniques alternatives. C'est ce qui rend le développement logiciel si difficile. S'il n'y avait qu'une seule façon de faire ces choses et que tout le monde était d'accord, nous pourrions vraiment le scripter ou demander à n'importe qui de développer des systèmes et en finir avec.

Obtenir des données. Vos mots pourraient ne pas suffire. Si un prototype rapide peut illustrer votre propos, créez-le.

"Opinions fortes, à la légère" devrait être votre devise.

Parfois, un point technique ne mérite pas d'aliéner toute votre équipe. Des fois ça l'est. Votre appel.

Answer 7

Vous vous opposez à quelqu'un d'autre au-delà de la conception / des fonctionnalités de plusieurs manières:

1. Demander la priorité des fonctionnalités, en fonction des besoins réels des utilisateurs. Imaginez des fonctions pour les testeurs alpha et bêta et demandez-leur s’ils échangeraient N mois de retard.

2. Réfléchissez agressivement pour éviter les cas spéciaux. Divisez le code en couches ou en composants modulaires, le cas échéant. Trouvez un équilibre entre " fonctionne très bien maintenant " et "facile à étendre plus tard".

3. Avertissez votre direction lorsque vous êtes en désaccord avec les décisions de conception, préparez-vous à être annulé et acceptez la décision. Ne passez pas au-dessus de la tête ou du code de sabotage.

Answer 8

Le meilleur moyen que j'ai trouvé est de demander sans cesse, encore et encore: "Quel est le problème commercial que nous essayons de résoudre" et "Comment cette décision aide-t-elle à résoudre ce problème".

Je trouve que trop souvent les gens sautent aux solutions au lieu d’être parfaitement au courant du problème.

Ainsi, dans votre exemple d'organisation d'une base de données, ma question est la suivante: "Quelles sont, à notre avis, les exigences en matière de transaction pour ce projet aujourd'hui, le mois prochain, l'année prochaine, dans cinq ans". Il est peut-être judicieux de consacrer beaucoup de temps à l’établissement du modèle de données, ce qui pourrait être une perte de temps. Vous ne savez pas quels sont les paramètres tant que la définition du problème n'est pas claire.

Answer 9

Vous pourriez souffrir de "trop ??d'architectes dans l'équipe". syndrome. Une ou deux personnes au plus devraient concevoir / architecturer un système qui sera codé par une équipe de 5 à 10 personnes. Tout le monde souhaite la bienvenue, mais les décideurs en architecture doivent être peu nombreux et expérimentés.

(les nombres sont semi-aléatoires et pourraient être différents en fonction d'autres facteurs)

Answer 10

J'essaie d'être ouvert lors des discussions. Mais quand je discute avec quelqu'un d'autre entre quelque chose qui semble simple et un autre compliqué, je suis aussi têtu que possible. Cela aide beaucoup tant que vous êtes très cohérent d’une décision à l’autre.

Answer 11

Votre exemple n'est pas vraiment un dessin compliqué, c'est un choix de design avec lequel vous n'êtes pas d'accord. Puisque vous travaillez sur le code, vous pourriez facilement avoir raison, car bon nombre de ces décisions sont prises par des personnes qui lisent un article dans un article et qui pensent que cela semble être un bon objectif, ou que la décision aurait pu être prise par quelqu'un qui a couru. problèmes avant et essayait de l'empêcher de se reproduire.

Personnellement, j’ai fait beaucoup de choses de manière facile et beaucoup de manière difficile, et je ne suis jamais heureux de choisir quelque chose de plus facile que de difficile. Maintenant, j'ai appris des astuces telles que "ne jamais faire circuler une collection nue, toujours l'envelopper dans une classe affaires".

Si je devais expliquer le raisonnement derrière cela à quelqu'un qui n'avait pas vécu les mêmes expériences, ils ne le comprendraient pas tant qu'ils n'auraient pas essayé de comparer le "moyen facile". à la "dure manière" quelques fois.

Answer 12

La solution ne devrait pas être plus complexe que le problème.

La question se mêle à la pensée de complexité essentielle. Une sorte doit toucher chaque élément, par son essence. Combien plus complexe faut-il alors obtenir pour résoudre le problème, compte tenu des contraintes techniques qui y règnent?

Answer 13

Les personnes impliquées disposent-elles de suffisamment de temps et d’incitations pour trouver une solution simple? Sans soins, la complexité augmentera. Si vous passez le plus clair de votre temps à essayer d’apporter la correction de bogue ou l’ajout de fonctionnalité le plus rapide possible, dites ensuite: "Faites simple." ne suffira pas.

Assurez-vous que certains membres de l'équipe sont blessés par la guerre en raison de la maintenance de programmes volumineux et de personnes expérimentées dans le refactoring, puis laissez-leur le temps de régler le logiciel. Si vous pouvez faire en sorte que certaines fonctionnalités et opportunités soient hors de portée, cela aidera les utilisateurs à supprimer le code inutile. Si vous voulez une métrique, essayez de réduire les lignes de code; mais essayez de ne pas être obsédé par cela. Améliorer la couverture du test; Pensez à éliminer les morceaux de code difficiles à tester.

Answer 14

N'essayez pas de tout faire en même temps. Casser chaque problème / tâche en morceaux gérables. Puis priorisez en gardant KISS et YAGNI à l'esprit. Cela vous aidera à vous concentrer sur la création de ce dont vous avez besoin . Si vous avez bien fait les choses, vous aurez un bon noyau que vous pourrez ajouter plus tard, avec du temps, de l'argent, des ressources et de l'inspiration.