Faut-il utiliser un pseudocode avant le codage proprement dit?

Le pseudocode nous aide à comprendre les tâches d'une manière indépendante du langage. Est-ce une meilleure pratique ou une approche suggérée que la création de pseudocodes fasse partie du cycle de vie du développement? Par exemple:

• Identifier et diviser les tâches de codage
• Écrire un pseudocode
• Faites-le approuver [par PL ou TL]
• Commencer le codage basé sur le pseudocode

Est-ce une approche suggérée? Est-il pratiqué dans l'industrie?

Écrire un pseudocode avant de coder est certainement mieux que simplement coder sans planifier, mais c'est loin d'être une meilleure pratique. Le développement piloté par les tests est une amélioration.

Encore mieux est d'analyser le domaine problématique et de concevoir des solutions en utilisant des techniques telles que les user stories, les cas d'utilisation, les cartes CRC, les diagrammes, comme le préconisent les méthodologies telles que Cleanroom, RUP, Lean, Kanban, Agile, etc.

Comprendre parfaitement la nature du problème et les composants que vous utilisez pour implémenter la solution est le principe derrière les meilleures pratiques.

J'utilise les commentaires comme une sorte de pseudo-code de très haut niveau, en ce sens que j'écris les commentaires avant d'écrire le code. Je trouve que la réflexion sur l'ensemble du problème, même à un niveau élevé, améliore considérablement mon code.

Non, ne pas pseudo-coder d'abord

C'est trop de frais généraux. Vous faites le travail d'écriture de la logique sans aucun des avantages. Je suggère plutôt l'une des options suivantes:

1. Prototype dans la langue avec laquelle vous allez expédier (AKA Écrivez-en un à jeter )
2. Diagrammes d'architecture avec extraits de code pour tester les hypothèses / conceptions clés
3. Test Driven Development où vous écrivez d'abord vos interfaces / structure de code, suivi de tests, puis d'implémentation du code.

Tous les trois vous dirigent directement vers votre solution, contrairement au pseudo-code. Personnellement, j'ai tendance à utiliser les techniques 1 ou 2 selon la taille de l'équipe. Pour les équipes plus petites (par exemple 5 personnes ou moins), le prototypage fonctionne très bien. Pour les équipes plus importantes qui ont plusieurs groupes de développeurs travaillant en parallèle, j'ai trouvé que la documentation produite tôt par la technique 2 fonctionne bien car elle vous donne quelque chose à discuter tôt et vous aide à mieux définir les limites des composants. Je suis sûr que TDD fonctionnerait très bien aussi, mais je n'ai pas encore travaillé sur une équipe qui s'était engagée dans ce processus.

À mon avis, le pseudo-code n'a que deux objectifs valides:

(1) Pour les étudiants en programmation qui ont besoin d'apprendre les concepts de modularité et d'algorithmes, mais qui ne maîtrisent pas encore un langage de programmation.

(2) Communiquer comment quelque chose fonctionnera à une personne non technique, ou simplement pour des raisons de commodité lors d'une réunion de type tableau blanc.

Le pseudo-code est-il une approche suggérée? Pour les programmeurs débutants, je dis oui. Il aide le nouveau programmeur à apprendre à traduire un problème en code sans se soucier de la syntaxe exacte du langage. Cela façonne le processus de pensée et peut aider à ancrer des habitudes utiles (et je suppose que les mauvaises habitudes aussi). C'est pourquoi il est tellement utilisé dans les écoles.

Est-il pratiqué dans l'industrie? D'après mon expérience, non. Personne n'a le temps d'ébaucher le projet entre la documentation (exigences, spécifications, story-boards, cas d'utilisation ou quoi que ce soit d'autre) et le code réel. On suppose généralement qu'une réflexion suffisante a déjà été mise sur le problème avant le feu vert pour coder. À ce stade, le codage du projet est plus important que l'ajout d'une couche supplémentaire de préparation de conception.

Je recommanderais certainement le pseudocode. Il vous aide à clarifier ce que vous allez faire et à identifier les éléments que vous avez peut-être oubliés ou les problèmes potentiels. Il est beaucoup plus facile / plus rapide de corriger votre code lorsqu'il est encore en phase de planification plutôt que d'attendre d'avoir déjà codé une grande partie de celui-ci.

Le pseudocode peut être utile si vous n'êtes pas familier avec la langue ou si vous devez changer les contextes mentaux. À de rares occasions où j'écris du pseudocode, c'est sur papier. Parfois, simplement retirer les mains du clavier et gribouiller sur du papier peut aider à contourner un blocage mental.

Mais en tant que partie formalisée du processus de développement? En aucune façon. C'est un outil sporadiquement utile pour les individus. Il existe de meilleures façons de «savoir ce que vous écrivez avant de l'écrire», comme:

1. définir le contrat (conditions pré / post / invariantes) de la méthode avant de commencer
2. TDD
3. 1 et 2 combinés (rédaction de tests pour exécuter le contrat)

Je dirais également que l'obtention d'une approbation avant de commencer à écrire du code est susceptible de causer beaucoup plus de tracas que cela ne vaut. Les revues de conception (pré-implémentation) peuvent être utiles, mais elles doivent être à un niveau plus élevé que les algorithmes individuels.

Je vais être en désaccord avec les réponses précédentes et dire non, mais avec une mise en garde: vous ne pouvez vous débarrasser du pseudo-code que si vous êtes fiévreusement dévoué à refactoriser votre code pour résoudre les problèmes qui surviennent. Le pseudo-code est, par essence, un moyen de définir votre code avant de définir votre code; c'est une abstraction inutile dans de nombreuses circonstances, et puisque votre code ne sera jamais parfait la première fois (et probablement, ne suivra pas complètement la conception du pseudo-code), il me semble étranger.

Si vous écrivez COBOL ou C, le pseudocode peut être utile car l'écriture du code réel prendra beaucoup plus de temps, et si vous pouvez vérifier votre algorithme / exigences à partir du pseudocode, vous pouvez gagner du temps.

Dans les langues plus modernes, le pseudocode n'a pas autant de sens. Ce qui fonctionnerait mieux, c'est d'écrire des stubs de méthode, de remplir la logique de niveau supérieur et autant de détails que nécessaire pour vérifier l'algorithme et les exigences, tout cela dans le code réel. Vous pouvez ensuite montrer ce code au chef d'équipe pour approbation et faire démarrer votre vrai code.

Les seules fois où j'ai utilisé le pseudocode au cours des 10 dernières années sont en interview lorsque nous travaillons sur un tableau blanc et la langue particulière n'a pas d'importance.

C'est certainement utile pour parler d'un processus / algorithme en termes lâches sans s'embourber avec la syntaxe. Par exemple, écrire une classe C ++ qui a des propriétés C #, juste pour illustrer le point.

Il a sa place, mais ne doit être utilisé qu'en cas de besoin (c'est du travail que vous jeterez) et ne fait certainement pas partie d'un processus formel, sauf si vous avez des normes de type ISO qui y insistent.

Pour moi-même et les personnes avec qui j'ai travaillé ces dernières années, le pseudocode est devenu un code réel pas tout à fait parfait. à moins que vous ne travailliez avec plusieurs langues en même temps, la plupart des gens semblent commencer à penser selon le schéma général de leur langue principale. J'ai travaillé dans des magasins .net pendant un certain temps, donc les gribouillis du tableau blanc de la plupart des gens autour du bureau ont tendance à ressembler à vb ou c # avec une partie de la ponctuation manquante.

L'exercice est toujours utile lors du débat sur les options et autres, mais le bit indépendant de la langue a tendance à s'éloigner lorsque vous passez plus de temps avec quelques langues.

De plus en plus, le pseudocode est écrit graphiquement avec des outils comme UML. Par exemple, essayez yUML .

un outil en ligne pour créer et publier des diagrammes UML simples. Cela vous permet de:

• Intégrez des diagrammes UML dans les blogs, les e-mails et les wikis.
• Publiez des diagrammes UML dans les forums et les commentaires de blog.
• Utilisez directement dans votre outil de suivi des bogues basé sur le Web.
• Copiez et collez des diagrammes UML dans des documents MS Word et des présentations Powerpoint ...

... yUML vous fait gagner du temps. Il est conçu pour ceux qui aiment créer de petits diagrammes et croquis UML.

Sans yUML, la création d'un diagramme UML peut impliquer de charger un outil UML, de créer un diagramme, de lui donner un nom, de jouer avec la mise en page, de l'exporter en bitmap, puis de le télécharger en ligne quelque part. yUML ne vous fait rien de tout cela ...

Bon travail. Vous avez commencé une bonne discussion. Quant à moi, j'écrivais des pseudo-codes lorsque j'apprenais à programmer pour comprendre les différentes boucles et algorithmes. C'était il y a plus d'un an et demi. À cette époque, même les langages de programmation n'étaient pas très puissants ... et la programmation événementielle était future. Maintenant, avec les 4GL et les 5GL, nous pensons dans la langue elle-même plutôt qu'en anglais ordinaire. Lorsque nous pensons à un problème, nous pensons en termes d'objets et d'opérations. Et tant qu'il ne s'agit pas d'un algo complexe, écrire des pseudo-codes (ou PSEU-DO-Codes, je plaisante) n'a aucun sens. Mieux, représentez la solution de manière graphique.

Cela dépend de la langue utilisée et de votre connaissance de celle-ci.

De nombreux langages modernes tels que Python ou Java sont déjà si proches du pseudocode que l'écriture d'un pseudocode ad hoc en premier est un gaspillage, à mon humble avis. Mieux vaut le faire tout de suite en utilisant l' approche par balle traçante .

C'est une affaire différente si vous faites des choses de bas niveau, proches du métal, ou si vous n'êtes pas encore à l'aise avec le langage que vous utilisez. Le pseudocode peut alors certainement être utile.

Il y a généralement quelques circonstances où le pseudocode a tendance à se décomposer dans mon travail, qui est dans le milieu universitaire où la programmation a tendance à être utilisée comme un outil ou le "et maintenant nous le résolvons" en remplissant le milieu d'un projet:

1. Quand le code va être plus contre-productif pour une compréhension réelle de ce qui va se passer que ne le sera le pseudo-code. SAS, par exemple, occupera la moitié du tableau blanc pour effectuer des tâches de programmation assez basiques. Voir aussi C, dont d'autres affiches ont discuté.
2. Avec beaucoup d'analyse de données et de codage statistique, il y a généralement beaucoup de bricolage avec le code à mesure que les résultats sont générés. Le pseudocode est un peu plus facile à utiliser car "ici réside un processus de va-et-vient, si le tracé de diagnostic ne semble pas correct, essayez X".
3. Les étudiants apprennent de nombreux langages de programmation différents. Par exemple, parmi les personnes que je connais, un problème de statistiques peut être analysé dans SAS, R ou Stata. Quelque chose qui nécessite quelque chose de plus proche de la programmation traditionnelle pourrait être fait en R, Matlab, C, C ++, Java, Python ... cela dépend vraiment de quel étudiant particulier implémente le programme, et dans quel but. Mais il est toujours utile pour les personnes Java et Python et les personnes Matlab d'avoir une idée commune de ce que font les autres, et comment l' approche , plutôt que le code lui-même, fonctionne.

Ce n'est pas une question de type oui / non. Il faut plutôt se demander quand utiliser un pseudo-code. Il est important de comprendre le problème avant de concevoir une solution, et il est important d'avoir une vision claire de la solution avant de l'implémenter. Le pseudo-code peut être utilisé dans l'une de ces étapes:

1. Lors de la définition du problème, il est courant d'écrire des cas d'utilisation, parfois en utilisant des séquences d'actions.
2. Lors de la conception d'une solution. Les diagrammes de classes sont agréables, mais ils ne décrivent que la partie "statique", c'est-à-dire les données. Pour la partie dynamique, dès que vous avez besoin de traiter une boucle et des données non triviales, je trouve que le pseudo-code est la meilleure méthode disponible. Les alternatives graphiques incluent les machines à états (adaptées aux flux de contrôle complexes avec peu de données) et les diagrammes de flux de données (adaptés aux flux simples avec des données complexes).
3. Lors de la mise en œuvre de la solution (ou juste avant). Certains langages de programmation sont difficiles à lire (pensez, assemblage). Une représentation alternative peut être utile dans ce cas. Si vous n'êtes pas familier avec les langues, cela vaut également la peine de le faire.

Un pseudo-code qui est en fait du code approprié dans un langage de haut niveau est également utilisé, il est généralement appelé prototypage.

En plus de parvenir à la compréhension, le pseudo-code est également bon pour la communication.

Si vous vous demandez si vous devez utiliser régulièrement un pseudo-code, je suis personnellement contre toutes sortes de règles rigides. Cela peut facilement se transformer en une perte de temps ennuyeuse s'il est utilisé pour des problèmes triviaux que tout le monde dans l'équipe comprend. L'utilisation de pseudo-code pour des spécifications que vous maintenez tout au long de la vie du projet peut également être coûteuse et offrir peu de valeur.