Comment pense un programmeur? [fermé]

Question

Cela peut être une question désespérément vague. Mais je suis intéressé par l’enthousiasme des processus logiques que les gens utilisent pour apprendre un nouveau concept ou essayer de se familiariser avec un code qu’ils n’auraient peut-être jamais vu auparavant.

En gros, quelles sont les étapes générales à suivre pour résoudre les problèmes et que faut-il pour "l'obtenir"? Si vous deviez représenter sous forme de diagramme un organigramme du fonctionnement de votre processus mental lorsque vous examinez du code ou tentez de résoudre un problème, à quoi pourrait-il ressembler?

Quels sont les références, les conseils et les hypothèses mentales courants que vous trouvez utiles pour résoudre les problèmes?

En quoi est-ce différent entre différents domaines? Par exemple, en quoi le processus de pensée d’un programmeur Web est-il similaire ou différent de celui d’un développeur d’applications bureautiques traditionnelles?

Answer 1

Je suis convaincu que quel que soit le type d'application que vous envisagez pour la première fois, que ce soit une application Web, une application de bureau, un pilote de périphérique ou autre, il y a trois étapes: développeur suit généralement afin de comprendre comment cela fonctionne:

Obtenez une vue d'ensemble:

• De quel type d'application s'agit-il (web, bureau, ...)?
• Comment se couche-t-il (autonome, client-serveur, n-tiers, ...)?
• Quel est le but de l'application? Qu'est-ce qu'il est censé faire?
• À qui est destinée cette application?

Découvrez comment cela fonctionne:

• Quelle (s) langue (s) est (sont) utilisée (s)?
• Comment le code est-il structuré?
• Comment les données sont-elles structurées?

Comprenez (ou du moins essayez) de comprendre comment l'application a été pensée:

• A-t-il été réfléchi?
• L'application est-elle clairement optimisée? (Pour les performances? Pour la lisibilité?)
• L'application est-elle terminée? Ou y a-t-il de la place pour des évolutions?
• Existe-t-il des signes de libération multiple?
• etc ...

Les 1ère et 2ème étapes sont purement techniques, tandis que la 3ème DOIT être aussi non technique que possible ... il s’agit plus de psychologie et de comprendre comment l’application a été construite. Cela demande évidemment de l'expérience, mais si vous y réfléchissez suffisamment et ne perdez pas votre cerveau en détails techniques, vous finirez par comprendre.

L'ensemble de ce processus ne devrait pas nécessiter l'utilisation d'un clavier. Vous êtes seulement censé lire, réfléchir et prendre des notes sur un papier (je ne plaisante pas: stylo et papier!).

Answer 2

Ho ho, bonne chance avec celui-ci. C'est une excellente question et je suis sûr que vous obtiendrez une tonne de réponses. Même si je dois dire que je ne peux pas donner de réponse satisfaisante à ceci - la dernière chose que je voudrais décrire mes processus de pensée sous forme d’un organigramme - je ne pense pas qu’il existe une formule en or pour cela.

Le seul conseil que je puisse vous recommander pour résoudre un problème consiste à en discuter avec quelqu'un d'autre. En ces temps où vous heurtez un mur de briques, le traverser avec un collègue est inestimable. Bien souvent, ils n’ajouteront même pas grand-chose à la discussion: si vous envisagez de faire part de toutes vos idées, la solution peut devenir claire.

Answer 3

Les gens sont notoirement mauvais pour examiner leurs propres processus de pensée, mais je vais faire un tourbillon. Je teste très haut la capacité visuo-spatiale dans les tests de QI, moyen à élevé pour les compétences verbales et modéré pour les compétences en mathématiques (explique ma note de niveau A en mathématiques, je suppose). Quand je commence à concevoir un logiciel, je pense aux formes et aux liens qui les unissent. Pour décrire ces pensées aux autres (ou les clarifier moi-même), j'utilise des schémas fonctionnels simples ou des diagrammes d'objets tirés de la méthode Objectory de Jacobson - PAS les éléments trop complexes suggérés par UML. J'écris parfois des descriptions textuelles de choses complexes, principalement comme des rappels, mais je n'utilise jamais de chiffres ni de maths.

Bien sûr, ce n’est que moi: j’ai travaillé avec des fous de maths qui étaient tout aussi bons ou même meilleurs programmeurs que moi.

Answer 4

Je ne pense pas ... je traite.

C’est en fait moins de retournement qu’il n’apparaît. Je décompose toujours les tâches en leurs composants et les décompose ensuite davantage, et cela ne va pas seulement pour l'écriture de logiciels! Tout comme @Mark Pim U passez en revue les choses de manière séquentielle.

Ma femme est vraiment énervée quand je prépare le dîner parce que je tarde tellement à commencer.

Answer 5

Diviser & amp; Conquérir

Je commence par essayer de saisir le problème dans sa globalité, puis je commence à trouver des modèles que je peux reconnaître et à faire de même pour eux dans une sorte de processus récursif, jusqu'à ce que je dispose d'une solution décomposée que je puisse mettre en œuvre et suivre. plus facilement.

Answer 6

C’est l’une des rares fois où je répondrais avec "ça fonctionne tout simplement". J'apprends des choses en les roulant à la vapeur. Je n'ai ni gadgets ni dispositifs pour m'aider. Il m'a fallu du temps pour apprendre PHP, mais après cela, le Javascript était beaucoup plus facile. Une fois que vous avez abordé un problème, les éléments suivants deviennent plus faciles à cumuler.

Answer 7

Personnellement, je mène un dialogue interne avec moi-même. "OK, nous devons donc parcourir cette liste d'entiers." "Mais nous pouvons casser quand nous trouvons la valeur que nous voulons." "OK, la liste sera-t-elle définitivement initialisée lorsque nous commencerons?"

Je serais intéressé de voir si des recherches psychologiques ont été menées sur les techniques de résolution de problèmes.

Answer 8

Semblable à Jonathan Sampson - ça marche plutôt bien.

Lorsque je m'attaque à un problème réel, j'essaie de penser au moyen le plus logique de le résoudre. Ensuite, quand tout va mal (comme d'habitude), je dois faire des centaines de pas de côté pour faire avancer les choses. Continuez simplement à vous concentrer sur cet objectif final, ce moyen logique, et vous y arriverez.

Finalement, il décide de travailler pour moi et je me retrouve avec un produit fini qui n’a en général rien à voir avec ce que j’avais prévu. Tant que les clients sont contents, je le suis!

Answer 9

Personnellement, je vois du code dans ma tête, de manière picturale que textuelle (comme Neil Butterworth). C’est un peu difficile à décrire car (citant STIV) "il n’existe pas de cadre de référence commun".

Answer 10

Ma compétence principale consiste à identifier les similitudes entre les modèles ou les systèmes que je connais déjà et la tâche à accomplir. Les liens entre certains d’entre eux peuvent sembler assez abstraits; la clé est de repérer les connexions. Cela conduit à l'abstraction de schémas et d'approches communs qui sont largement applicables. À ce propos, la chose la plus importante que j'ai apprise au sujet des algorithmes est que le problème n’est jamais de «trouver un algorithme intelligent pour résoudre X». Il s'agit du problème de modèle X tel qu'il peut être résolu par l'algorithme intelligent Y existant.