Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - page 4
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Et qu'advient-il de votre structure claire si au milieu, ou même vers la fin du projet, le client change soudainement :
Il s'agit d'un bon test pour déterminer dans quelle mesure votre projet est prêt et résilient au changement.
C'est le problème, et c'est pourquoi je suis dans ce fil.
Je veux trouver une réponse sur la façon de concevoir (ou de faire entrer le client dans un tel cadre), de sorte que ses désirs soient satisfaits et que le projet ne soit pas brisé.
SZY parce que la pièce a deux côtés, avec l'un vous pouvez changer le projet, avec un autre vous pouvez dire "Non en tant que partie de ce projet ne peut pas faire", la vérité est quelque part au milieu.
Le mieux est de concevoir le développement de manière à ce que la plupart des besoins essentiels du client soient réalisables.
Aucun programmeur normal ne dessine d'organigrammes de nos jours. Tout cela n'est qu'un non-sens théorique conçu pour être enseigné aux écoliers, mais pas pour être utilisé dans des projets réels.
Tout dépend de ce que l'on met sur papier.
Je ne suis pas favorable à l'écriture, mais il faut parfois établir une structure générale sur papier. C'est pratique et rapide, c'est comme un croquis pour un bijoutier, l'image globale doit être claire.
C'est peut-être la raison pour laquelle il y a beaucoup de programmeurs non normaux, car ils ne dessinent pas d'organigrammes.
De nos jours, aucun programmeur normal ne dessine de diagrammes de flux. Tout cela n'est qu'un non-sens théorique conçu pour enseigner aux écoliers, mais pas pour travailler dans des projets réels.
De nos jours, aucun programmeur normal ne dessine un organigramme.
Je suppose que c'est la raison pour laquelle il y a beaucoup de programmeurs anormaux, parce qu'ils ne dessinent pas d'organigrammes.
Je n'irais pas jusqu'à dire que c'est un "non-sens théorique". Dessiner des "carrés avec des flèches" sur du papier est largement utilisé en programmation. Prenez UML par exemple - plein de "flèches avec des carrés". :) Ainsi, les schémas fonctionnels peuvent également être utiles lors des étapes initiales...
J'ai essayé de concevoir avec UML, c'est un non-sens (IMHO).
Je peux parfaitement garder tous ces carrés et ces flèches dans ma tête, mais les abstractions ne tiennent pas dans ma tête, alors je les dessine.
HI Si vous creusez plus profondément, le cerveau humain est bien adapté pour mémoriser des images, des cartes, des modèles de comportement, mais pas pour construire des abstractions, l'abstraction est la chose la plus difficile qu'une personne puisse faire.
L'humanité a donc toujours essayé de formaliser l'abstraction en quelque chose de plus familier.
Le cerveau humain est bien adapté pour mémoriser des images, des cartes, des modèles de comportement, mais pas pour construire des abstractions ; les abstractions sont la tâche la plus difficile pour un être humain.
ZZZI C'est pourquoi l'humanité s'efforce toujours de formaliser l'abstraction en quelque chose de plus familier.
Je suis d'accord.
J'ai mes propres méthodes pour recâbler mon propre cerveau dans ce domaine, j'ai même un logiciel de développement (que je peux partager à l'occasion), mais le développement est très lent (bien que perceptible avec le recul).
--
En un sens, toute programmation est un travail d'abstraction, mais il existe une énorme variation dans le niveau et la compétence de la manipulation pratique des concepts abstraits.
Je suis d'accord.
J'ai mes propres méthodes pour aiguiser mon propre cerveau dans ce domaine, j'ai même des développements logiciels (je peux les partager à l'occasion), mais le développement a été très lent (bien que perceptible avec le recul).
--
En un sens, toute programmation est un travail avec des abstractions, mais il y a une grande différence dans le niveau et la compétence de l'utilisation pratique des abstractions.
Nous ne sommes pas intéressés par l'abstraction pour l'abstraction, n'est-ce pas ?
Je pense qu'étant donné que nous ne sommes pas évolutivement les mieux adaptés à l'abstraction... ! (discutable, en tout cas meilleur que les autres habitants de cette planète), nous devrions essayer de construire des béquilles.
Par exemple, les gens ont inventé une technique comme le brainstorming.
J'ai souvent du mal à nommer une entité, à lui donner un nom succinct qui soit à la fois suffisamment compréhensible et extrêmement court. Lorsque cela réussit, l'abstraction est facilement assimilée.
Désolé, je ne peux pas écrire beaucoup maintenant (ce n'est pas pratique de le faire depuis un téléphone portable), je n'aurai pas le temps de le faire quand je serai là-bas. Je ne peux pas écrire beaucoup maintenant (ce n'est pas pratique sur le téléphone). Je n'aurai pas le temps.
Désolé, je ne peux pas écrire beaucoup maintenant (ce n'est pas pratique depuis mon portable), je n'aurai pas le temps quand je serai là-bas. Un meilleur lendemain.