Comment empêchez-vous des solutions ou des conceptions compliquées? [fermé]

https://stackoverflow.com/questions/86308

01-07-2019
|

Question

Souvent, nous travaillons sur un problème, mais seulement pour nous rendre compte que la solution créée est bien plus complexe que le problème n’exige. Existe-t-il des contrôles, des pratiques optimales, des techniques, etc. qui vous aident à contrôler les complications sur votre lieu de travail?

La solution

Demander à quelqu'un de nouveau de le regarder.

Autres conseils

S'il est trop difficile à tester, votre conception est trop compliquée. C'est la première mesure que j'utilise.

D'après mon expérience, la conception d'un cas trop général a tendance à engendrer une complexité excessive.

La culture technique encourage les conceptions qui font moins de suppositions sur l’environnement; c'est généralement une bonne chose, mais certaines personnes vont trop loin. Par exemple, pourrait être utile si la conception de votre voiture ne prend pas en compte une attraction gravitationnelle spécifique, si personne ne conduira votre voiture sur la lune, et si tel était le cas, cela ne fonctionnerait pas, parce qu'il n'y a pas d'oxygène pour brûler le carburant.

La partie difficile est que le gars qui est développé le "travaille sur n'importe quelle planète" son design est souvent considéré comme intelligent, vous devrez peut-être travailler plus fort pour affirmer que son design est trop aussi malin.

Comprendre les compromis, afin de pouvoir choisir entre de bonnes et de mauvaises hypothèses, contribuera grandement à éviter une conception inutilement compliquée.

Voici quelques idées pour simplifier la conception:

lisez des livres de programmation et des articles, puis appliquez-les à votre travail et écrivez du code
lisez beaucoup de codes (bons et mauvais) écrits par d'autres personnes (comme des projets Open Source) et apprenez à voir ce qui fonctionne et ce qui ne fonctionne pas
construire des filets de sécurité (tests unitaires) pour permettre des expérimentations avec votre code
utilisez le contrôle de version pour activer la restauration si ces expérimentations tournent mal
TDD (développement piloté par les tests) et BDD (développement fondé sur le comportement)
changez votre attitude, demandez comment vous pouvez le faire de sorte que "cela fonctionne tout simplement" (une convention sur la configuration pourrait y contribuer; ou demandez comment Apple le ferait)
entraînement (comme pour les lecteurs de jazz - associer avec du code, essayez Code Kata )
écrivez le même code plusieurs fois, dans différentes langues et après un certain temps
apprendre de nouvelles langues avec de nouveaux concepts (si vous utilisez un langage statique, apprenez un langage dynamique; si vous utilisez un langage procédural, apprenez un langage fonctionnel; ...) [une langue par an est à peu près correcte]
demandez à quelqu'un de vérifier votre code et de demander activement comment vous pouvez le rendre plus simple et plus élégant (, puis le rendre )
obtenez des années à votre actif en faisant ce qui est au dessus (le temps aide l'esprit actif)

Je crée un design, etc., puis je le regarde et j'essaie de supprimer (de manière agressive) tout ce qui semble ne pas être nécessaire. S'il s'avère que j'en ai besoin plus tard, lorsque je peaufine le dessin, je le rajoute. Je le fais en plusieurs fois, peaufinant au fur et à mesure.

Lisez & "Travaillez efficacement avec le code hérité". par Michael C. Feathers.

Le problème, c’est que si vous avez un code qui fonctionne et que vous devez modifier la conception, rien ne fonctionne mieux que de rendre votre unité de code testable et de diviser votre code en éléments plus petits.

Utiliser Test Driven Development et suivre le Trois règles de TDD de Robert C. Martin:

Vous n'êtes pas autorisé à écrire un code de production, sauf s'il s'agit de faire passer un test unitaire défaillant.
Vous n'êtes pas autorisé à écrire plus d'un test unitaire que ce qui est suffisant pour échouer; et les échecs de compilation sont des échecs.
Vous n'êtes pas autorisé à écrire plus de code de production que ce qui est suffisant pour réussir le test unitaire défaillant.

De cette manière, vous n’obtiendrez probablement pas beaucoup de code dont vous n’avez pas besoin. Vous serez toujours concentré sur la réalisation d'une chose importante et ne serez jamais trop loin devant vous en termes de complexité.

Le premier test peut être utile, mais il ne convient pas à toutes les situations. Et ce n’est pas une panacée quand même.

Commencer petit est une autre bonne idée. Avez-vous vraiment besoin d'intégrer tous les 10 modèles de conception dans cette chose? Essayez d’abord de le faire "de manière stupide". Ça ne coupe pas tout à fait? OK, faites-le "de manière un peu moins stupide". Etc.

Faites-le examiner . Comme quelqu'un d'autre l'a écrit, deux paires d'yeux sont meilleures. Encore mieux sont deux cerveaux. Votre compagnon peut simplement voir une pièce pour simplifier la tâche ou un problème qui, à votre avis, allait bien tout simplement parce que vous passez de nombreuses heures à la pirater.

Utilisez un langage simplifié. Des langages tels que Java ou parfois le C ++ semblent parfois encourager des solutions désagréables et compliquées. Les choses simples ont tendance à s'étendre sur plusieurs lignes de code et il vous suffit d'utiliser 3 bibliothèques externes et un grand framework pour tout gérer. Pensez à utiliser Python, Ruby, etc. - si ce n'est pour votre projet, alors pour un usage privé. Cela peut changer votre mentalité pour favoriser la simplicité et être assuré que la simplicité est possible.

Il est inévitable que cela se produise une fois que vous avez été programmeur. Si vous avez sérieusement désestimé vos efforts ou si vous avez rencontré un problème où votre solution ne fonctionne tout simplement pas, arrêtez de coder et parlez à votre chef de projet. J'aime toujours apporter les solutions avec moi à la réunion, le problème est A, vous pouvez faire x qui prendra 3 jours ou nous pouvons essayer y qui prendra 6 jours. Ne faites pas le choix vous-même.

Parlez à d’autres programmeurs à chaque étape. Plus le design est attentif, plus il est probable qu'un aspect trop compliqué se révèle tôt, avant qu'il ne devienne trop ossifié dans la base de code.
Demandez-vous constamment comment vous utiliserez ce que vous travaillez actuellement. Si la réponse est que vous n'êtes pas sûr, arrêtez de repenser ce que vous faites.
J'ai trouvé utile de noter comment simplifier potentiellement quelque chose sur lequel je travaille actuellement. De cette façon, une fois que tout fonctionne, il est plus facile de revenir en arrière et de refactoriser ou de refaire au besoin au lieu de jouer avec quelque chose qui n'est même pas encore fonctionnel.

C’est un exercice délicat d’équilibre: d’une part, vous ne voulez pas quelque chose qui prend trop de temps à concevoir et à mettre en œuvre, d’autre part, vous ne voulez pas d’un hack qui ne soit pas assez compliqué à traiter ensuite. Le problème de la semaine, voire pire, nécessite une réécriture pour s'adapter.

Quelques techniques que je trouve utiles:

Si quelque chose vous semble plus complexe que vous le souhaiteriez, ne vous asseyez jamais pour le mettre en œuvre dès que vous avez fini de le penser. Trouvez quelque chose à faire pour le reste de la journée. À de nombreuses reprises, je finis par penser à une solution différente d'une partie du problème qui élimine par la suite une grande partie de la complexité.

Dans le même esprit, demandez à quelqu'un d'autre de vous faire part de vos idées. Assurez-vous de pouvoir leur expliquer pourquoi la complexité est justifiée!

Si vous ajoutez de la complexité parce que vous pensez que cela sera justifié à l'avenir, essayez de déterminer quand à l'avenir, vous l'utiliserez. Si vous ne pouvez pas (de manière réaliste) imaginer avoir besoin de cette complexité pendant un an ou trois, il n’est probablement pas justifié de la payer maintenant.

Réduisez la quantité de données avec laquelle vous travaillez en sérialisant la tâche en une série de tâches plus petites. La plupart des gens ne peuvent avoir qu'une demi-douzaine de conditions (plus ou moins) dans leur tête pendant le codage, alors faites-en l'unité de mise en œuvre. Concevez pour toutes les tâches que vous devez accomplir, puis piratez-le impitoyablement afin que vous n'ayez jamais à jouer avec plus d'une demi-douzaine de chemins dans le module.

Cela découle du post de Bendazo - simplifiez jusqu'à ce que cela devienne facile.

Je demande à mes clients pourquoi ils ont besoin de certaines fonctionnalités. J'essaie d'aller au fond de leur demande et d'identifier le problème qu'ils rencontrent. Cela se prête souvent à une solution plus simple que ce à quoi je pourrais penser.

Bien sûr, si vous connaissez les habitudes de travail de vos clients et les problèmes auxquels ils doivent faire face, vous comprendrez beaucoup mieux leurs problèmes dès le départ. Et si vous les "connaissez", connaissez-les, alors vous comprendrez mieux leur discours. Alors, développez une relation de travail étroite avec vos utilisateurs. C'est l'étape zéro de l'ingénierie.

Prenez le temps de bien nommer les concepts du système et de rechercher les noms liés, ce qui rend le système plus familier. N'hésitez pas à renommer les concepts, meilleure sera la connexion avec le monde que vous connaissez, plus votre cerveau pourra travailler avec.

Demandez l’avis de personnes qui s’expriment avec des solutions simples et propres.

N'appliquez que les concepts nécessaires au projet en cours (le désir de mettre à jour des systèmes génériques ou des systèmes génériques rendra votre conception gonflée).

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow