在实际编码之前应该使用伪代码吗？

伪代码可帮助我们以与语言无关的方式理解任务。将伪代码创建作为开发生命周期的一部分是最佳实践还是建议的方法？例如：

• 识别并拆分编码任务
• 编写伪代码
• 得到[PL或TL]的批准
• 基于伪代码开始编码

这是建议的方法吗？它在行业中实践吗？

在编码之前编写伪代码肯定比不进行计划的编码要好，但这远非最佳实践。测试驱动的开发是一种进步。

更好的方法是使用诸如用户故事，用例，CRC卡，图表之类的技术来分析问题领域并设计解决方案，例如Cleanroom，RUP，Lean，Kanban，Agile等方法所支持。

彻底了解问题的性质以及用于实施解决方案的组件是最佳实践的原理。

我将注释用作一种非常高级的伪代码，因为在编写代码之前先编写注释。我发现，即使从较高的角度考虑整个问题，也可以极大地改善我的代码。

不，请勿先进行伪代码

这是太多的开销。您正在做编写逻辑的工作，但没有任何好处。我建议使用以下任何一种方法：

1. 使用您将要使用的语言进行原型制作（又名，写一个就扔掉）
2. 带有代码片段的体系结构图，用于测试假设/关键设计
3. 测试驱动开发，您首先要编写接口/代码结构，然后是测试，然后是代码。

与伪代码不同，所有这三种方法都将您直接带到解决方案中。就个人而言，我倾向于根据团队规模使用技术1或2。对于较小的团队（例如5人或更少），原型制作非常有效。对于有多个开发人员并行工作的大型团队，我发现技术2早期产生的文档效果很好，因为它使您可以尽早讨论并帮助您更好地定义组件边界。我敢肯定TDD也能很好地工作，但是我还没有致力于这个过程的团队工作。

我认为伪代码只有两个有效的目的：

（1）对于需要学习模块化和算法概念但还不熟练使用编程语言的编程学生。

（2）与非技术人员沟通，或者只是为了方便在白板形式的会议上交流。

伪代码是一种建议的方法吗？对于新手程序员，我说是的。它可以帮助新程序员学习如何将问题转换为代码，而不必担心语言的确切语法。这塑造了思维过程，可以帮助树立有用的习惯（我想也是坏习惯）。这就是为什么它在学校中被大量使用的原因。

它在工业中实践吗？以我的经验，不会。没有人有时间在文档（需求，规范，故事板，用例或其他用途）与实际代码之间进行粗略的设计。通常假设在批准进行编码之前，已经对该问题进行了充分的思考。那时，对项目进行编码比添加一层以上的设计准备更为重要。

我肯定会推荐伪代码。它可以帮助您弄清要做什么，并确定您可能忘记或潜在的问题。在尚处于计划阶段时，更容易/更快地修复代码，而不是等到您已经对大部分代码进行了编码。

如果您不熟悉该语言，或者需要更改思维环境，则伪代码会很有用。在极少数情况下，我会写伪代码，它在纸上。有时，只需将手从键盘上移开并在纸上涂鸦，就可以避免精神障碍。

但是作为开发过程的正式部分？没门。对于个人来说，这是一个偶尔有用的工具。有更好的方法“在编写之前先知道自己在写什么”，例如：

1. 在开始之前定义方法的合同（之前/之后/不变条件）
2. TDD
3. 1和2合并（编写测试以执行合同）

我还建议在开始编写代码之前获得任何形式的批准可能会带来麻烦，其价值不菲。设计评审（预实施）可能有用，但是它们需要比单个算法更高的级别。

我将不同意先前的答案，并说不，但有一点警告：您只有在热心致力于重构代码以处理出现的问题时，才能摆脱伪代码。本质上，伪代码是在定义代码之前定义代码的一种方法。在许多情况下，这是不必要的抽象，而且由于您的代码第一次就永远不会是完美的（而且很可能没有遵循伪代码的设计来完成），这对我来说似乎是多余的。

如果您正在编写COBOL或C，则伪代码可能会有所帮助，因为编写实际代码会花费更长的时间，并且如果您可以从伪代码中验证算法/要求，则可以节省一些时间。

在更现代的语言中，伪代码意义不大。更好的方法是编写方法存根，并填写顶层逻辑，并提供必要的详细信息以验证算法和要求，所有这些均在实际代码中进行。然后，您可以将该代码显示给团队负责人以供批准，并已经启动您的真实代码。

在过去的十年中，当我们在白板上工作时，我唯一一次使用伪代码是在接受采访时，特定的语言无关紧要。

这对于松散地讨论流程/算法而不会使语法陷入困境当然很有帮助。例如，编写一个具有C＃属性的C ++类，只是为了说明这一点。

它有它的位置，但是只应在需要的地方使用（这是您将要丢弃的工作），并且肯定不是正式过程的一部分，除非您坚持使用ISO类型的标准。

对于我自己和最近几年与我一起工作的人来说，伪代码几乎已变成不完全完美的真实代码。除非您同时使用多种语言，否则大多数人似乎开始以其主要语言的一般模式进行思考。我已经在.net商店工作了一段时间，所以大多数人在办公室周围的白板涂鸦看起来都像vb或c＃，但缺少一些标点符号。

在辩论诸如此类的选择时，该练习仍然很有价值，但是随着您花更多时间使用几种语言，与语言无关的部分会逐渐消失。

伪代码越来越多地使用诸如UML之类的工具以图形方式编写。例如，尝试yUML。

用于创建和发布简单UML图的在线工具。它使您确实非常容易：

• 将UML图嵌入到博客，电子邮件和Wiki中。
• 在论坛和博客评论中发布UML图。
• 直接在基于Web的错误跟踪工具中使用。
• 将UML图复制并粘贴到MS Word文档和Powerpoint演示文稿中...

... yUML节省您的时间。它是为那些喜欢创建小型UML图和草图的人设计的。

如果没有yUML，创建UML图可能涉及到加载UML工具，创建图，为其命名，修改布局，将其导出到位图，然后在线将其上传到某个地方。yUML不会让您做任何事情...

做得好。您开始了很好的讨论。从我开始，我在学习编程以了解各种循环和算法时就曾经编写伪代码。那是在十五年前。那时，即使编程语言也没有那么强大……事件驱动的编程是未来。现在有了4GL和5GL，我们以语言本身而不是简单的英语来思考。当我们想到一个问题时，我们会从对象和操作方面进行思考。直到这是一个复杂的算法，编写伪代码（或开玩笑的PSEU-DO-Codes）才变得毫无意义。更好的是，以图形方式表示解决方案。

取决于所使用的语言以及您对它的熟悉程度。

许多现代语言（例如Python或Java）已经非常接近伪代码，以至于首先编写一些临时的伪代码非常浪费，恕我直言。更好的方法是立即使用跟踪器项目符号方法进行操作。

如果您要制作一些底层的，接近金属的东西，或者对所使用的语言不满意，这是另一回事。那么伪代码肯定是有用的。

在某些情况下，伪代码倾向于在我的工作中被打破，在学术界，编程倾向于被用作工具或在项目中间填充“现在我们解决它”的学术研究：

1. 当代码比伪代码对实际发生的情况的实际理解要适得其反时。例如，SAS将占白板一半，完成一些相当基本的编程任务。另请参见C，其他一些发布者对此进行了讨论。
2. 在进行大量的数据分析和统计编码时，随着结果的生成，往往会对代码进行很多修改。伪代码对于“此处存在一个来回过程，如果诊断图看起来不正确，请尝试X”使用起来更容易一些。
3. 学生学习许多不同的编程语言。例如，在我认识的人中，可以使用SAS，R或Stata分析统计问题。R，Matlab，C，C ++，Java，Python可能需要一些与传统编程更接近的东西……这实际上取决于要实现该程序的特定学生和目的。但是，对于Java人士，Python人士和Matlab人士来说，对其他人正在做的事情以及方法（而不是代码本身）如何工作有共同的想法仍然有用。

这不是一个是/不是问题。相反，应该怀疑何时使用伪代码。在设计解决方案之前了解问题很重要，并且在实施解决方案之前要对解决方案有清晰的了解很重要。伪代码可用于以下任何步骤：

1. 在定义问题时，通常写下用例，有时使用动作序列。
2. 设计解决方案时。类图很好，但是它们仅描述“静态”部分，即数据。对于动态部分，一旦您需要处理循环和非平凡的数据，我发现伪代码是可用的最佳方法。图形化替代方案包括状态机（适用于数据少的复杂控制流）和数据流图（适用于具有复杂数据的简单流）。
3. 在实施解决方案时（或之前）。有些编程语言很难读（认为，汇编）。在这种情况下，替代表示可能很有价值。如果您不熟悉这些语言，那也是值得的。

伪代码实际上是高级语言中的正确代码，通常也称为原型设计。

除了获得理解之外，伪代码还可以用于通信。

如果您想知道是否应该定期使用伪代码，我个人会反对各种严格的规定。如果用于团队中每个人都能理解的琐碎问题，这很容易变成无聊的时间浪费。将伪代码用于在项目的整个生命周期内维护的规范也很昂贵，并且几乎没有价值。