Question

pseudocode nous aide à comprendre les tâches d'une manière linguistique agnostique. Est-ce la meilleure pratique ou approche suggérée pour avoir la création de pseudocode dans le cadre du cycle de vie de développement? Par exemple:

  • Identifier et diviser les tâches de codage
  • Ecrire pseudocode
  • Obtenir a approuvé [par PL ou TL]
  • Démarrer codage basée sur pseudocode

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

Était-ce utile?

La solution

L'écriture pseudocode avant le codage est certainement mieux que le codage juste sans planification, mais il est loin d'être une meilleure pratique. le développement piloté par les tests est une amélioration.

Mieux encore est d'analyser le domaine des problèmes et des solutions de conception en utilisant des techniques comme des témoignages d'utilisateurs, des cas d'utilisation, les cartes CRC, schématisation, telle qu'elle est soutenue par des méthodologies telles que Cleanroom, RUP, Lean, Kanban, Agile, etc.

comprendre à fond la nature du problème et les composants que vous utilisez pour mettre en œuvre la solution est le principe des meilleures pratiques.

Autres conseils

J'utilise des commentaires comme une sorte de code très pseudo de haut niveau dans la mesure où j'écris les commentaires avant d'écrire le code. Je trouve que la pensée à travers l'ensemble du problème, même à un niveau élevé, améliore considérablement mon code.

Non, ne pas pseudo-code premier

Ceci est trop frais généraux. Vous faites le travail d'écriture de la logique avec aucun des avantages. Je vous suggère une des options suivantes au lieu:

  1. Prototype dans la langue que vous allez livré avec (AKA Ecrire un à jeter )
  2. diagrammes d'architecture w / extraits de code à des hypothèses de test / modèles clés
  3. Test Driven Development où vous écrivez vos interfaces / structure de code en premier, suivi par des tests, suivi par la mise en œuvre du code.

Les trois ces mouvements vous directement vers votre solution, contrairement pseudo-code. Personnellement, je tendance à utiliser des techniques 1 ou 2 en fonction de la taille de l'équipe. Pour les petits (par exemple 5 personnes ou moins) équipes, le prototypage fonctionne très bien. Pour les grandes équipes qui ont plusieurs groupes de développeurs travaillant en parallèle, j'ai trouvé que les documents produits par la technique au début 2 fonctionne bien parce qu'il 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 dois encore travailler sur une équipe qui avait engagé à ce processus.

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

(1) Pour la programmation des étudiants qui ont besoin d'apprendre les concepts de modularité et d'algorithmes, mais ne sont pas encore couramment un langage de programmation.

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

est un pseudo-code approche proposée? Pour les programmeurs débutants, je dis oui. Il aide le nouveau programmeur apprendre comment traduire un problème dans le code sans se soucier de la syntaxe exacte de la langue. Cette forme le processus de pensée et peut aider à Ingrain habitudes utiles (et je suppose que les mauvaises habitudes aussi). Voilà pourquoi il est utilisé tant dans les écoles.

est-il pratiqué dans l'industrie? Dans mon expérience, non. Personne n'a le temps de dégrossir le projet entre la documentation (exigences, spécifications, story-boards, des cas d'utilisation ou tout ce qu'ils utilisent) et le code réel. Il est généralement admis que la pensée suffisante a déjà été mis sur le problème avant le feu vert au code. À ce moment-là, le codage du projet est plus important que l'ajout d'une couche supplémentaire de préparation de la conception.

Je recommande vivement pseudocode. Il vous aide à clarifier ce que vous allez faire et d'identifier les éléments que vous avez peut-être oubliées ou des problèmes potentiels. Son beaucoup plus facile / plus rapide pour corriger votre code quand il est encore au stade de la planification plutôt que d'attendre jusqu'à ce que vous avez déjà une grande partie avons écrit de celui-ci.

pseudocode peut être utile si vous n'êtes pas familier avec la langue, ou si vous avez besoin de changer de contexte mental. A l'occasion rare que j'écris pseudocode, il est sur le papier. Parfois, il suffit de prendre vos mains sur le clavier et griffonner sur le papier peut aider à se déplacer un bloc mental.

Mais comme une partie formalisés du processus de développement? En aucune façon. Il est un outil utile pour les personnes de façon sporadique. Il y a de meilleures façons de « savoir ce que vous écrivez avant de l'écrire », comme:

  1. la définition du contrat (pre / post / conditions invariantes) de la méthode avant de commencer
  2. TDD
  3. 1 et 2 combinés (écriture de tests pour exécuter le contrat)

Je vous suggère aussi que l'obtention d'une sorte d'approbation avant de commencer à écrire du code est susceptible de causer beaucoup plus de tracas que cela vaut la peine. Les revues de conception (pré-mise en œuvre) peuvent être utiles, mais ils 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 pouvez vous débarrasser de psuedocode seulement si vous êtes fébrilement consacré à refactorisation votre code pour traiter des questions qui surgissent. Psuedocode est, à son essence, une façon de définir votre code avant de définir votre code; il est une abstraction inutile dans de nombreuses circonstances, et que votre code ne sera jamais parfait la première fois (et probablement, ne pas suivre la conception à la réalisation du psuedocode), il me semble étrangère à.

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

En langues modernes, pseudocode ne fait pas comme beaucoup de sens. Qu'est-ce qui fonctionne mieux est en train d'écrire raccords de méthode, et en remplissant la logique de niveau supérieur, et autant de détails que nécessaire pour vérifier l'algorithme et exigences, tout cela dans le code réel. Vous pouvez alors montrer que le code à la chef d'équipe pour approbation, et que votre véritable code déjà commencé.

Les seules fois où je l'ai utilisé dans les pseudocode 10 dernières années sont sur entretien lorsque nous travaillons sur un tableau blanc et la langue particulière n'a pas d'importance.

Il est certainement utile de parler à travers un processus / algorithme en termes lâches sans s'enliser avec la syntaxe. Par exemple. écriture d'une classe C ++ qui a des propriétés C #, juste pour illustrer ce point.

Il a sa place, mais ne doit être utilisé en cas de besoin (c'est le travail que vous jetterai) et certainement pas partie d'un processus formel, sauf si vous avez des normes ISO de type qui insistent là-dessus.

Pour moi-même et les gens que j'ai travaillé depuis quelques années a pseudocode à peu près transformé en pas tout à fait vrai code perfectionner. à moins que vous travaillez avec plusieurs langues en même temps, la plupart des gens semblent commencer à penser dans le schéma général de leur langue principale. Je travaille dans les magasins .net pendant un certain temps si gribouillis tableau blanc autour du bureau de la plupart des gens 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 la langue peu agnostique a tendance à dériver loin que vous passez plus de temps avec quelques langues.

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

un outil en ligne pour la création et la publication de diagrammes UML simples. Il est vraiment facile pour vous fait à:

  • diagrammes UML Intégrer dans les blogs, les courriels et les wikis.
  • diagrammes UML Poster dans les forums et les commentaires de blog.
  • Utilisez directement dans votre outil de suivi des bogues basé sur le Web.
  • Copier et coller 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 UML et des croquis.

Sans yUML, la création d'un diagramme UML peut impliquer le chargement d'un outil UML, la création d'un diagramme, en lui donnant un nom, de jongler avec la mise en page, exporter vers bitmap, puis télécharger en ligne quelque part. yUML ne fait pas vous faire de tout ça ...

Excellent travail. Vous avez commencé une bonne discussion. Comme moi, je l'habitude d'écrire des codes pseudo quand je programmation apprendre à comprendre les différentes boucles et des algorithmes. Ce fut plus d'un et demi il y a quelques décennies. Ce jours, même ne sont pas beaucoup plus puissante programmation ... et évènementielle les langages de programmation était l'avenir. Maintenant, avec L4G et 5GLs, nous pensons que dans la langue elle-même plutôt que dans un anglais simple. Quand on pense à un problème, nous pensons en termes d'objets et des opérations. Et jusqu'à ce qu'il soit un algo complexe, l'écriture des codes pseudo (ou P-S-E-U-DO-codes, juste une blague) ne fait pas de sens. Mieux, représentent la solution d'une manière graphique.

dépend de la langue utilisée, et votre familiarité avec elle.

De nombreuses langues modernes tels que Python ou Java sont déjà si près de pseudocode que la rédaction d'une ad hoc est inutile pseudocode d'abord, à mon humble avis. Mieux faire juste immédiatement en utilisant le traceur approche bullet .

Il est une affaire différente si vous faites un peu de bas niveau, à proximité des objets métalliques, ou ne sont pas encore à l'aise avec la langue que vous utilisez. Alors peut certainement être pseudocode utile.

Il a tendance à être un cas couple où pseudocode a tendance à se casser dans mon travail, ce qui est dans le milieu universitaire où la programmation a tendance à se servir d'outil ou « et maintenant nous le résoudre » remplir au milieu d'un projet :

  1. Lorsque le code va être plus contre-productif à une compréhension réelle de ce qui va se passer que pseudo-code sera. SAS par exemple, prendra la moitié du tableau blanc faisant quelques tâches de programmation assez de base. Voir aussi C, qui d'autres affiches ont discuté.
  2. Avec beaucoup d'analyse des données et des statistiques de codage, il a tendance à être beaucoup de bricoler avec le code que les résultats sont générés. Pseudocode est un peu plus facile à utiliser pour « se trouve ici un processus back-et-vient, si la parcelle de diagnostic ne semble pas correcte, essayez X ».
  3. Les élèves apprennent beaucoup de différents langages de programmation. Par exemple, parmi les gens que je connais, un problème statistique peut être analysé dans SAS, R ou Stata. Quelque chose qui exige quelque chose de plus proche de la programmation traditionnelle pourrait se faire en R, Matlab, C, C ++, Java, Python ... cela dépend vraiment de ce que l'élève particulier met en œuvre le programme, et dans quel but. Mais il est toujours utile pour les personnes Java et le peuple Python et le peuple Matlab d'avoir une idée commune de ce que les autres font, et comment les approche , plutôt que le code lui-même, fonctionne.

Ce n'est pas un oui / non genre de question. Au contraire, on doit se demander quand utiliser 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 code de pseudo-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 gentils, mais ils ne décrivent que la partie « statique », à savoir les données. Pour la partie dynamique, dès que vous avez besoin pour faire face à une boucle et les données non triviales, je trouve pseudo-code pour être la meilleure méthode. alternatives graphiques comprennent des machines d'état (bon pour le flux de contrôle complexe avec peu de données) et des diagrammes flux de données (bon pour les flux simples avec des données complexes).
  3. Lors de la mise en œuvre de la solution (ou juste avant). Certaines langages de programmation sont difficiles à lire (penser, montage). Une autre représentation peut être utile dans ce cas. Si vous n'êtes pas familier avec les langues, il est également intéressant de faire.

Pseudo-code est un code réellement approprié dans un langage de haut niveau est également utilisé, il est généralement appelé prototypage.

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

Si vous vous demandez si vous devez utiliser un pseudo-code sur une base régulière, je suis personnellement contre toutes sortes de règles rigides. Cela peut facilement se transformer en une perte de temps ennuyeux de s'il est utilisé pour des problèmes triviaux tout le monde dans l'équipe comprend. En utilisant un pseudo-code pour les spécifications que vous conserviez tout au long de la vie peut aussi être coûteux et offrent peu de valeur du projet.

Licencié sous: CC-BY-SA avec attribution
scroll top