Est-il normal de penser à un problème de conception pendant des jours sans code écrit? [fermé]

Parfois, je regarde dans l’espace, dessine des idées et écris des pseudo-codes sur du papier. Ensuite, je gratte et recommence, puis quand je pense avoir la bonne solution au problème, je commence à écrire le code.

Est-il normal de penser pendant des jours sans écrire de code? Est-ce un signe que j'aborde le problème de manière totalement fausse? Cela me rend nerveux de ne pas avoir de code tangible écrit dans mon IDE.

En fonction du problème que vous essayez de résoudre, la phase de conception peut prendre des semaines et des mois (voire des années), pas seulement des jours.

Il faut de l'expérience pour ne pas commencer à critiquer le code immédiatement. Réfléchir à l'architecture et à la conception de haut niveau devrait prendre des jours, voire plus - c'est certainement quelque chose qui devrait arriver avant de commencer à écrire votre code.

Ceci est communément appelé "analyse paralysie"

C'est commun mais faux. À un moment donné, vous devez tester différentes idées pour voir ce qui fonctionnera le mieux pour vous, puis l’améliorer progressivement.

Recommandé la lecture du programmeur pragmatique Plus précisément au chapitre 2 la section "Puces de traceur"

C'est complètement commun. Toutefois, si vous utilisez une approche "Test d'abord" ou TDD, elle est moins courante et pourrait vous aider à mieux formuler vos idées.

Les habitudes résultent généralement d’approche par essais et erreurs et de la poursuite de ce qui nous donne les résultats souhaités, tout en évitant ce qui ne l’est pas. Faire ce que nous aimons et éviter ce que nous n'aimons pas entre également en jeu. Cela fonctionne jusqu'à un certain point parce que nous ferons finalement quelque chose qui ne nous plait pas pour que le loyer soit payé.

Cela dépend de ce qui vous mène à ceci et à vos raisons. Voici quelques-uns:

• Trop souvent, vous avez dû changer de code à cause de changements de conception
• Vous ne modifiez pas une mauvaise conception car la solution la moins complexe était déjà codée
• Vous préférez dessiner et concevoir que d'écrire la procrastination de code
• avoir à vous soucier de la syntaxe et des détails du codage, vous empêche de penser à de meilleurs designs.

J'espère que vous avez découvert que si vous concevez plus longtemps, votre code est meilleur. Si vous pouvez regarder en arrière et voir que peu importe le temps que vous passez à la conception, vous voudrez peut-être changer. Une autre considération est la fréquence à laquelle vous découvrez des problèmes après avoir écrit du code par rapport au travail avec vos conceptions. Si vous ne trouvez pas de problèmes avant d’avoir écrit du code, vous devriez envisager une balance et commencer à coder quelque chose le plus tôt possible. Peut-être que cette approche pourrait s’appliquer à l’utilisation de technologies plus récentes ou à une fonctionnalité très complexe.

Je ne sais pas si j'ai la discipline nécessaire pour rester fidèle à l'une ou l'autre approche, même si je découvre que l'une fonctionne mieux que l'autre. Parfois, je ressens le besoin d'aller au tableau blanc; d'autres le clavier.

C'est très courant et je pense que c'est un meilleur moyen de gérer et de comprendre les choses. Tout en travaillant sur un projet, je suis coincé plusieurs fois et il faut un jour ou deux pour comprendre comment je peux mieux l'aborder. Même une fois le problème résolu, j’attends qu’un jour passe. Cela me rend plus rafraîchie et y aller.

C'est un phénomène naturel et bon pour un développeur d'intercepter son esprit le temps et entre.

Lorsque j'ai suivi un cours en gestion de projet, l'instructeur nous a parlé de la planification, ce qui me tenait à l'esprit, était que la règle générale qu'ils enseignaient à l'armée consistait à occuper le tiers du temps consacré à la planification. . Par conséquent, si vous avez une opération qui vous demande d’être achevée dans 3 mois, comptez un mois de planification avant de commencer l’exécution.

À mon avis, il existe trois approches, chacune adaptée à une situation de codage spécifique

1. J'ai déjà rencontré un problème similaire, alors j'ai une assez bonne idée des schémas à appliquer et de la manière dont la solution devrait se comporter et réagir.

   => Utilisez BDD / TDD en partant des solutions souhaitées et en intégrant le code. (Ok, parfois je triche et écris un peu de code puis le test - une sorte d'approche imbriquée 2. -> 1.).

2. J'ai une bonne idée des modèles à appliquer, mais je ne suis pas sûr de ce que la solution devrait ressembler.

   => Prototype pour voir quels types de choses intéressantes apparaissent. Déplacez-vous sur 1. lorsque je découvre les choses intéressantes souhaitées.

3. Je ne suis pas sûr des modèles à appliquer.

   => Pensez au problème et à la manière dont les différentes manières d’aborder le problème influencent le code. Passez à 2) ou 1) en fonction du résultat de cet exercice.

En d'autres termes, la réponse est la préférée de l'ingénieur: cela dépend.

Mieux vaut passer un mois à penser et à concevoir qu'à créer un prototype rapide basé sur un design de qualité inférieure que vous devez ensuite transformer en forme. Surtout si vous faites partie d'une équipe. une fois que d'autres commencent à dépendre de votre code, il est beaucoup plus difficile d'implémenter une meilleure conception avec une API différente.

Je conviens avec les autres réponses que, en principe, prendre le temps de réfléchir à un problème / une solution est une bonne idée. Cependant, si vous sentez que vous êtes bloqué, j'ai quelques recommandations sur la manière de rendre le processus de planification un peu plus cohérent:

• Créer des artefacts de conception. Et si vous n'écriviez pas de code? Peut-être que vous venez d'écrire un journal de vos pensées. Ou un croquis d'une solution générale. Ou même simplement un très bon résumé du problème que vous affinez avec le temps. Lorsque vous examinez des idées et que vous les acceptez / les rejetez, tenez un journal de vos raisonnements sur le sujet. Ainsi, au bout du compte, vous pourrez toujours vous référer aux produits livrables du monde réel comme preuve de votre travail.

• Parle à des gens! Il n'y a rien de tel que d'avoir un être humain vivant et en respiration avec qui discuter d'idées. Si vous pensez que vous êtes bloqué, discutez-en avec quelqu'un. Prenez quelqu'un - n'importe qui! - et expliquez-lui le problème. Esquissez vos idées sur la façon de résoudre le problème. Même si tout ce qu'ils font est d'inspirer, d'expirer et de cligner des yeux pendant dix minutes tout en babillant, il y a de fortes chances que vous découvriez de nouvelles perspectives juste au cours de l'explication du problème .

Comme le disait Satchel Paige: "Parfois, je reste assis et je réfléchis, et parfois je reste assis."

J'imagine qu'il en venait à comprendre qu'il est parfois bon de clarifier son esprit, car cela peut vous amener à penser votre problème différemment. Donc, si vous ne vous en prenez pas à du code, vous pouvez proposer une solution ou une idée qui vous aurait peut-être évité autrement. Donc, oui, il est normal et une bonne pratique de ne pas passer directement au codage.

Il y a deux façons de faire ce processus moi-même. Je crée un dossier contenant un fichier texte et tous les dessins liés au projet. J'y note mes idées et j'essaie de sauvegarder le processus de pensée de mon mieux. Je créerai également un projet de bloc-notes sur lequel je pourrai rapidement tester des idées simples allant des algorithmes aux mises en forme CSS.

Programme = Algorithme + Structure de Données

IMHO, le processus de conception (résolution de problèmes) est totalement régi. Les détails de la mise en œuvre (problème technique) suivent et résolvent naturellement.

Voici mon cas de pensée.

1. Partir de zéro Tout d'abord, une idée approximative de ce que vous voulez est nécessaire. Essayez d’obtenir une liste de certaines exigences ou créez-les. Cela devrait prendre un peu de temps pour comprendre les choses ici. Une fois que vous avez au moins un élément que vous êtes sûr de vouloir, en connaissant la plupart des interfaces de cet élément, commencez à coder.

2. Résoudre un problème avec du code existant Tout d'abord, suivez le problème. Cela peut nécessiter un certain temps sans écrire de code réel (certains codes de débogage peuvent être écrits, mais ils ne seront généralement pas conservés). Une fois le problème identifié, en fonction de sa complexité, commencez à écrire du code pour tenter de le résoudre. Peu de réflexion devrait être nécessaire une fois que le bogue est connu. Si le problème s'avère être un défaut de conception majeur, reportez-vous à la section suivante.

3. Modifications de la conception / caractéristiques principales Ceci est très probablement celui qui nécessitera le plus de réflexion. La préservation de la structure, la compatibilité en amont, etc. doivent être incluses. Réfléchir pour obtenir le meilleur changement pourrait faire gagner un temps considérable, mais pour moi cela ne prend généralement pas plus de quelques jours.

4. Ajout d'une fonctionnalité simple Si aucune modification de conception significative n'est requise, codez-la simplement dans votre fonctionnalité, en utilisant un essai / une erreur. Cela ne devrait pas nécessiter beaucoup de temps en général.

Je ne suis pas d'accord avec le consensus sur celui-ci. Je préférerais commencer à prototyper quelque chose dès que j'ai la moindre idée précise de la manière dont je veux que mon système fonctionne. Il est presque impossible pour moi de penser à tous les petits détails qui pourraient causer des problèmes à moins que je ne spécifie les choses de manière très précise. Si je ne parle que de design avec des gens, il est trop facile de simplement aborder certains des problèmes les plus complexes. Une fois que je spécifie de telles choses, il se peut tout aussi bien que ce soit directement dans le code source plutôt que d’autres moyens d’expression qui sont aussi précis et formels mais ne peuvent pas être compilés et exécutés.

Cela dépend de ce que vous entendez par "normal" . En parlant de moi, je pense que le code est un excellent outil d’apprentissage. Donc, face à un problème complexe, je fais des croquis sur papier, mais je code également à l'aide de tests. Le code me dit pense qu'un tableau blanc ne peut pas dire et vice-versa, et peut-être que le résultat est un aperçu ou la nécessité de poser quelques questions supplémentaires à l'expert du domaine.

Le véritable conseil est donc: "Utilisez tous les outils d'apprentissage nécessaires pour vous rapprocher de la définition du problème" , mais aussi "souvenez-vous qu'il s'agit d'outils d'apprentissage, alors n'en tombez pas amoureux", code et croquis sont à jeter. .

En cette ère de RAD et de programmation agile, vous devriez commencer à développer dès que vous pouvez identifier les principales parties du système, des détails vous parviendront. Étant donné que les logiciels grandissent, se concentrer prématurément sur chaque détail ne vous mènera nulle part.