Comment puis-je gérer la paralysie de l'analyse?

61

Très souvent, je suis coincé lors du choix de la meilleure décision de conception. Même pour de petits détails, tels que les définitions de fonctions, le flux de contrôle et les noms de variables, je passe des périodes anormalement longues à analyser les avantages et les compromis de mes choix.

J'ai l'impression de perdre beaucoup d'efficacité en passant mes heures à des détails insignifiants comme ceux-là. Même si, sachant au fond de moi, je peux changer ces choses si ma conception actuelle ne fonctionne pas, j'ai du mal à choisir fermement un choix.

Que dois-je faire pour lutter contre ce problème?

utilisateur8
la source
Discutez avec un collègue sur un tableau blanc. Cela aide souvent à clarifier la question et si vous êtes d'accord, cela a de bonnes chances d'être un bon choix

Réponses:

35

Deux règles simples:

  1. Faites la chose la plus simple qui puisse fonctionner.
  2. Refactor en continu.

En commençant à faire chacune de ces choses, vous aurez l’assurance que vous pourrez prendre des décisions simples maintenant sans compromettre votre capacité à réagir au changement plus tard.

Rappelez-vous que la vérification future signifie rendre le code facile à modifier, sans chercher à anticiper toutes les modifications possibles de votre code.

Rein Henrichs
la source
4
La refactorisation continue n’est raisonnable que si vous avez une bonne couverture de test. Donc, je dirais: "Écris un test unitaire. Puis fais la chose la plus simple pour réussir le test. Refactor. Répète."
Kevin Cline
Vraiment d'accord. "Red, green, refactor" est le chemin à parcourir.
Rein Henrichs
5
Jolie petite friandise du manuel XP, mais ce n'est vraiment pas un bon conseil si on la sort de son contexte.
Aaronaught
2
Hors contexte, cela équivaut littéralement au codage cowboy. Voir Fowler's Design Dead? qui met en garde contre les principes de picking cherry de XP et des méthodologies similaires. Peut-être êtes-vous un excellent concepteur et codeur et êtes intrinsèquement et implicitement capable et motivé de maintenir l’intégrité conceptuelle lors du refactoring, mais la plupart des programmeurs ne le sont pas, et leur donner ce conseil hors contexte est irresponsable (bien qu’ils aiment tous l’entendre, car cela signifie moins de travail pour eux).
Aaronaught
1
"Faire la chose la plus simple qui puisse fonctionner" ne nécessite aucun contexte supplémentaire. Le refactoring le fait, mais comment quelqu'un qui ne connaît pas le contexte pourrait-il apprendre à refactoriser mais en apprenant le contexte?
Rein Henrichs
9

Habituellement, lorsque je ressens cela, cela signifie que je dois essayer:

  1. Levez-vous, promenez-vous et assurez-vous que toute la biologie fonctionne correctement.
  2. Passez au tableau blanc et dessinez jusqu'à ce que je ressente de la confiance.
  3. Trouvez un «copain de réclamation pour la conception» avec lequel vous pouvez simplement parler du problème.

Si le problème implique une syntaxe et de petits morceaux, alors:

  1. Assurez-vous que, même si c'est moche, il est bien encapsulé quelque part et représente un genre de cruauté purement locale.
  2. Ajoutez des marqueurs TODO ou simplement des commentaires expliquant pourquoi le code vous pose problème.
  3. Passez à la tâche suivante.
Darien
la source
+1 pour le premier et le deuxième n ° 2. Dessiner des boîtes, des lignes, des étiquettes et obtenir de grandes images m'aident généralement à choisir entre les options. Si vous disposez d'un bon analyseur de code permettant de suivre les tâches (Hudson peut suivre les tâches et les afficher facilement dans vos versions), vous pouvez facilement suivre ce que vous n'aimez pas.
Randy
5

Il est très facile de penser à l'inaction. Même si vous parvenez, d'une manière ou d'une autre, à trouver la meilleure solution en ce moment, qui pourrait facilement changer avant la fin du projet, et ensuite?

Il est préférable de choisir une solution décente et de l'utiliser, plutôt que de s'asseoir et de dire la meilleure solution. La meilleure solution est insaisissable et pire, subjective. Si les exigences changent même légèrement, votre solution pourrait s'avérer pire qu'une solution que vous avez écartée car elle n'était pas la meilleure à l'époque.

Satanicpuppy
la source
J'en suis conscient, mais j'ai toujours du mal à choisir un seul choix.
Anne Nonimus
@anne: Mieux vaut faire immédiatement quelque chose de constructif que de faire ce qui s'impose trop tard. La seule chose qui est sûre d'être la mauvaise chose est de ne rien faire.
Satanicpuppy
4

J'apprends aussi à éviter la paralysie de l'analyse, donc félicitations à nous =). Cela arrive souvent parce que nous voulons faire le "meilleur design". En réalité, "le mieux" est dans l'oeil du spectateur . Ma formule pour éviter la paralysie de l'analyse consiste à appliquer le principe de conception suffisamment bon . Comment je fais ça? J'apporte des variables comme le temps, le calendrier-contraintes et je me demande quelle est la conception la plus simple qui peut faire le travail (cela ne signifie pas le plus facile) sans compromettre la qualité, mais en même temps, je vous assurer que est testable et une ouverture pour extension fermée pour modification (OCP)conception aussi bien. Qu'est-ce que je veux dire par testable et OCP? Au lieu de rechercher ce que j’ai considéré comme le meilleur, j’ai envisagé une conception qui permette de me dire quand les choses vont mal et d’essayer de faire juste assez de code pour me permettre de refactoriser et d’améliorer ultérieurement. Aussi, essayez de séparer le code qui va changer avec le code qui reste le même. La refactorisation devient plus facile, car le code qui n'est pas supposé changer est plus sûr de votre avenir, de votre part ou de la part de quelqu'un d'autre.

Armando
la source
2

Que diriez-vous de laisser votre instinct décider pour l'une des options? Cela devrait aller assez vite et bien mélanger avec Timeboxing , qui ammoQ également proposé . Vous pouvez essayer une limite de 1 minute si les options sont déjà définies ou de 2 minutes si vous devez les définir au préalable. Ou ce qui semble approprié (défini au préalable). En apprenant à écouter votre instinct, votre choix intuitif deviendra plus rapide et meilleur avec la pratique .

Au cas où vous craignez de ne pas choisir parfaitement, voici quelques idées pour y remédier:

  • S'il existait une option nettement supérieure aux autres, vous ne vous demanderiez pas laquelle choisir. Donc, par ce raisonnement, chaque fois que vous êtes indécis quant à un choix sur une question pas trop compliquée, cela indique que les options sont toutes très égales; il n'y a donc pas grand chose à perdre en optant pour l'un d'entre eux.
  • Cela étant dit, l’ intuition n’est pas aléatoire du tout, mais une très bonne conjecture instruite pour la solution optimale. Souvent mieux que ce que l’on pourrait imaginer en fouillant sans fin.
  • Au service du perfectionnisme, on pourrait attribuer à la rapidité de la décision une valeur supérieure à l’optimalité du choix lorsqu’on évalue sa performance de façon inconsciente. Ce qui est tout à fait logique avec des choix sans importance, mais n’est pas anodin à garder à l’esprit.

Bonne chance! :)

effective.altruistUtoo
la source
2

Je pense que ça part avec un peu d'expérience. La plupart de mes paralysies surviennent parce que j'essaie d'imaginer ce que la base de code aura l'air d'être beaucoup plus avancée que nécessaire, alors pour la surmonter, je fais simplement la chose la plus simple possible, qui fonctionnera puis passera à autre chose. Une fois que le projet a une forme définie, les unités de code répétitives commencent à se démarquer et il est assez facile d’abstraire les motifs répétitifs et de simplifier le code.

davidk01
la source
1

Pour surmonter votre réticence à décider, appliquez la fonction Timeboxing : définissez un réveil pour qu'il se déclenche dans quelques minutes; tourmentez votre esprit jusque-là, mais lorsque l'alarme se déclenchera, choisissez la meilleure option que vous ayez trouvée jusque-là.

utilisateur281377
la source
3
Et puis, il peut passer des heures à se tourmenter pour savoir exactement combien de temps le réveil doit être réglé! :)
Jordanie
1
Jordanie: Il existe plusieurs solutions possibles à ce problème. Malheureusement, je ne peux pas décider lequel proposer.
user281377
0

Créer un prototype. Rappelez-vous qu'un prototype est fait pour être jeté, alors peu importe les fonctions, le nom de variable ou même la grande architecture que vous utilisez. Vous venez de le construire pour prouver que cela fonctionne.

Une fois que vous l'avez créé et mis à la poubelle, je serais prêt à parier que vous auriez plus de facilité à prendre ces décisions.

Tylermac
la source
Vous ne devriez jamais jeter un prototype, car vous pourrez peut-être le développer plus tard lorsque vous ajouterez une fonctionnalité. Ou peut-être avez-vous besoin de tester un bogue avec un SSCCE. Je contrôle toujours tous mes prototypes dans un endroit séparé.
maple_shaft
2
Je pense que l'idée de "jeter" ne veut pas dire que vous perdez des données, mais que vous ne devriez pas utiliser de prototypes comme base d'un programme, car l'objectif principal des prototypes est d'expérimenter la liberté de faire des erreurs.
Darien
prototype dans une branche, effectuez les tests nécessaires et créez une version propre dans le noyau.
zzzzBov
0

Je souffre de ce problème aussi. Ce que je dirais, c'est que vous n'avez pas assez d'incitation à l'achèvement.

Par exemple, lorsque j'écrivais du code de rendu, j'avais un important incitatif à l'achèvement parce que je savais que si je m'entendais bien, je pouvais voir le système en action et penser à quel point j'étais génial pour texturer un quad, ou transformer un vert. Mais maintenant que je re-factorise (tentative 4, si vous voulez savoir), je souffre parce que c'est beaucoup de travail et même si je termine, je vais juste voir le même vieux quad. Et je ne veux vraiment plus avoir à refacturer et j'en ai marre de voir le même vieux quad encore et encore, et ce n'est plus une récompense pour moi.

Vous devez le diviser en composants et vous récompenser de les avoir terminés, même si ce n’est qu’avec une console d’entrée / sortie qui montre que cela fonctionne.

DeadMG
la source
0

J'étais en train de lire votre question et de réfléchir aux idées des autres affiches: vous ne vous adaptez pas à ce travail; donnez-vous une limite de temps; faire quelque chose d'autre pour un moment. Après réflexion, je ne suis pas sûr que les réponses soient vraiment utiles

Le problème avec les problèmes mentaux tels que celui-ci est qu’ils ne sont pas faciles à résoudre, ils font partie de vous, et évidemment vous vous souciez (trop peut-être) de votre travail, vous n’avez pas la confiance d’être d’accord avec vous-même, vous êtes trop inexpérimentés à considérer que votre premier choix était correct depuis le début, ou que le stress était trop important pour obtenir un résultat parfait. Pourquoi voudriez-vous vous inquiéter pour de telles banalités?!

Maintenant, j'ai des problèmes similaires, mais pas beaucoup avec le code .. généralement c'est quoi avoir pour le dîner .. pizza ou curry .. hmm ... pizza mais alors curry c'est bien, mais est-ce que je me sens comme un curry, la pizza est moins chère , mais alors vous obtenez plus de curry, mais ... et ainsi de suite. :)

Alors j'ai pensé - pourquoi n'ai-je pas des problèmes similaires avec le codage, et je pense que c'est simplement parce que j'ai un ensemble de motifs que j'utilise régulièrement. Si j'ai besoin d'une définition de fonction, c'est facile ... ce sera dans la même veine que toute autre définition de fonction que j'ai jamais codée. Si j'ai besoin d'un flux de contrôle, je décide d'abord si j'ai besoin d'une boucle for ou d'une boucle while, puis je crée le même ancien code que celui que j'avais utilisé la dernière fois où j'avais besoin de l'une de ces choses. La même chose vaut pour tout, est-ce que je veux une file d'attente? Bien sûr, allons couper et coller mon code de file d'attente 'standard' (archivé du dernier projet sur lequel j'ai travaillé ou de celui dont je me souviens en utilisant l'une de ces choses). Résultat final ... Je ne m'inquiète que de nouvelles choses et, pour être honnête, c'est un plaisir.

Mon conseil est donc de commencer à créer une bibliothèque d'extraits de code - j'avais l'habitude de les envoyer par courrier électronique à moi-même et de les mettre dans un dossier, mais quel que soit le type de travail avec lequel vous travaillez est préférable - et vous commencerez alors à savoir quoi faire à chaque fois. Vous irez toujours à l'ancien code que vous avez écrit et résoudrez le problème, prêt pour le problème suivant. Vous deviendrez un développeur beaucoup plus rapide (sérieusement, c’est le seul moyen d’améliorer la productivité des programmeurs) et espérons trouver du temps pour les éléments amusants, et non les tristes problèmes quotidiens que vous avez déjà résolus à maintes reprises. plus de.

Bien sûr, la dernière partie de tout ce qui est important aussi - plus vous travaillez, moins vous avez de temps à penser.

gbjbaanb
la source
La programmation d'extraits de code est le pire type de mauvaise pratique
Neil Butterworth
@ Neil: Utiliser les extraits d'autres personnes comme programmation d'extraits et ne pas savoir ce qu'ils font est une mauvaise pratique. Il est généralement bon d’utiliser vos propres extraits de code, car il est fort probable que vous compreniez ce que vous avez écrit. Si non, alors il n'y a probablement aucun espoir pour vous.
Jordanie
@ Neil, tu es de très mauvaise humeur aujourd'hui! La plupart des codeurs seniors ont de toute façon une vaste bibliothèque de snippets dans la tête, vous ne remarquez pas que vous les utilisez. Pour un junior, les écrire les aide à construire cela.
gbjbaanb
0

Voici une stratégie qui combine les suggestions de Rein Henrichs ( start simple, refactor ) et de ammoQ ( timeboxing ):

  1. Donnez-vous un délai assez strict pour une première solution qui fonctionne. Par exemple, 30 secondes pour un nom de variable. Vous pouvez d’abord proposer quelque chose comme x, puis l’affiner string, namejusqu’à ce que le temps soit écoulé.
  2. Passez ensuite à d’ autres tâches pendant une durée déterminée, par exemple 10 minutes.
  3. Alors seulement, accordez-vous un autre délai pour améliorer votre décision, par exemple pouruserHandle

Avantages possibles de cette approche:

  • la connaissance de revenir à cela plus tard peut aider à résoudre le problème pour l'instant
  • Tout en continuant d'autres tâches, vous pouvez simplement trouver une solution satisfaisante et satisfaisante sans fouiller trop de temps.
  • avoir relâché après l'étape 1 et être dans le flux de l'étape 2 , il peut s'avérer facile de garder l'étape 3 vraiment rapide, car vous souhaitez continuer avec l'étape 2, et donc choisir simplement une solution décente et l'accepter
effective.altruistUtoo
la source
Cette réponse semble plus spécifique et complète que la précédente , mais les deux semblent couvrir le même terrain. Veuillez les fusionner en un seul ou choisir celui que vous souhaitez conserver.
Adam Lear
@Anna J'ai publié deux articles distincts, car j'ai trouvé qu'ils contenaient des idées de concept différentes qui devraient être votées indépendamment: Celui-ci: laisser aller en reportant la décision finale. La précédente: sensation d'intestin. En effet, les deux techniques vont bien ensemble, mais chacune fonctionne aussi sans l'autre.
Aaron Thoma
0

Quand j'ai fait les recherches et qu'il ne me reste plus aucun choix, je me donne un délai (habituellement 5 minutes) pour en choisir un, puis je vais de l' avant. Même si vous rencontrez des obstacles, à ce stade, rien ne garantit que vous n'auriez pas rencontré le même obstacle en prenant une décision différente. Je ne peux pas penser à un moment où j'ai regretté ma décision.

John MacIntyre
la source
0

Généralement, la raison pour laquelle vous ne pouvez pas décider est que la différence est insignifiante ou que vous ne disposez pas de suffisamment d'informations.

Dans le cas a) Fixez une limite de temps pour proposer des options raisonnables à considérer. Ne décidez pas lequel. À la fin du temps, choisissez une (au hasard si aucune préférence claire) des options identifiées et une autre limite de temps. Si aucune décision claire n’est prise à la fin du temps, c’est celui qui a déjà été choisi. Commencez à coder et à refactoriser si vous vous êtes clairement trompé. Si le patron demande pourquoi, dites "J'ai lancé une pièce de monnaie, vous avez un meilleur moyen?"

Dans le cas b) - vous avez besoin de plus d’informations et vous asseyez-vous sur votre grosse graisse .... tout au long de la journée ne vous la fournira pas. Sortez du mode conception et passez en mode collecte d'informations. Prototypes, poser des questions, lire des magazines techniques. Quoi que vous fassiez, ne dormez pas trop longtemps dessus.

Mattnz
la source
0

Souvent, la meilleure solution consiste à essayer d’expliquer votre décision à un collègue. Cependant, comme vous ne voulez pas le faire très souvent, la meilleure chose à faire est de penser sur papier, avec un stylo / papier ou une fenêtre vide du bloc-notes.

Commencez par écrire absolument n'importe quoi - juste pour entrer dans le rythme de l'écriture. Dans une fenêtre du bloc-notes, vous pouvez simplement taper "Je réfléchis sur papier" et continuer avec un flot de conscience. Après quelques secondes, vous serez au rythme de l'écriture. Appuyez donc plusieurs fois sur Entrée et commencez à expliquer votre dilemme.

Énoncez le problème, puis indiquez les solutions possibles, les avantages de chacune d’elles, etc.

Bien que cela ne fonctionne pas toujours, le processus de récupération des pensées de votre tête (RAM) sur un support externe (le bloc-notes) vous donne plus de liberté pour établir de nouvelles connexions et voir la décision sous différents angles.

Saqib
la source
0

Je souffre du même problème. Pour les petits problèmes, la façon dont je tente de le gérer est d’utiliser le premier design auquel je pense qui n’est pas stupide. Il ne sert à rien d'essayer de trouver un design optimal; Il est difficile, voire impossible, de raisonner sur toutes les nuances d'un dessin auquel vous pourriez penser sans le rédiger. En codant, vous constaterez que vous pouvez apporter de petites améliorations. Bien fait, je trouve qu'il est assez facile de converger vers une solution raisonnablement bonne de cette façon.

Pour les plus gros problèmes, je pense qu’il est utile de réfléchir à vos options en premier lieu, mais à la chronologie. Les gros problèmes ont de grands espaces de solutions, vous ne pouvez pas évaluer toutes les possibilités, vous ne devriez pas non plus essayer.

TLDR; Choisissez une solution raisonnable, améliorez-la au fur et à mesure.

Ceci est également pertinent:

Le professeur de céramique a annoncé le jour de l'ouverture qu'il divisait la classe en deux groupes. Tous ceux du côté gauche du studio, a-t-il dit, seraient classés uniquement en fonction de la quantité de travail produit, tous ceux de droite uniquement en fonction de la qualité. Sa procédure était simple: le dernier jour de classe, il apportait sa balance de salle de bain et pesait le travail du groupe "quantité": cinquante livres de pots notés "A", quarante livres par "B", etc. Ceux qui sont classés sur la "qualité", cependant, n'ont besoin de produire qu'un seul pot - même s'il est parfait - pour obtenir un "A".

Et bien, le temps du classement est arrivé et un fait curieux a émergé: les œuvres de la plus haute qualité ont toutes été produites par le groupe classé pour la quantité. Il semble que pendant que le groupe "quantité" travaillait activement - et tirait des leçons de leurs erreurs - le groupe "qualité" avait théorisé la perfection et n'avait finalement guère plus à montrer de leurs efforts que des théories grandioses et un tas d'argile morte.

tiré de http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

dan_waterworth
la source
-8

Je n'ai jamais compris cela. Quand j'étais instructeur, je disais quelque chose comme:

"OK, create an integer variable and assign the return value of strlen() to it."

Pas trop compliqué, vous pourriez le penser, et 95% des gens ont écrit quelque chose comme:

int x;   // or y, or len, or whatever
x = strlen( s );

Mais il y avait parfois quelqu'un assis comme un lapin paralysé par les phares. Je demanderais avec sympathie quel était le problème et ils diraient "Je ne sais pas comment l'appeler!".

Ce sont les personnes qui devraient chercher une autre carrière. Comme peut-être devriez-vous.

Neil Butterworth
la source
2
@ Anne Je ne fais pas de suppositions - vous avez vous-même dit que vous aviez du mal à trouver des noms - "Très souvent, je suis coincé lorsque je choisis la meilleure décision de conception. Même pour les petits détails, tels que ... les noms de variables"
Neil Butterworth
3
Et pourquoi devrais-je chercher une autre carrière parce que j'ai du mal à nommer certaines choses? Tous les concepts n’ont pas une correspondance nette et brève avec le langage naturel.
Anne Nonimus
2
@Anne L'essence de votre question initiale me semble être que vous avez du mal à faire ce que les bons programmeurs ont naturellement. Il n'y a pas de honte à cela - la plupart des gens (même la plupart des programmeurs!) Sont affreux à faire ces choses. Cependant, en supposant que, comme moi, vous ne puissiez être heureux que de faire quelque chose pour lequel vous êtes vraiment bon, j'ai suggéré que la programmation ne soit peut-être pas ce pour quoi vous êtes fait. J'ai passé les 10 premières années de ma vie adulte en tant que microbiologiste. Je n'y étais pas très bon et j'étais beaucoup plus heureux quand je suis devenu programmeur.
Neil Butterworth
3
Un rappel amical à tous: si vous n'êtes pas d'accord avec la réponse, n'hésitez pas à utiliser des votes négatifs pour exprimer cela. Les attaques personnelles des deux côtés seront supprimées.
Adam Lear
3
En fin de compte, j’estime que la réponse est plutôt sévère, mais les commentaires me donnent l’impression que ce n’est pas si dur. Vous devriez peut-être modifier cela.
DeadMG