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

Question

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

• 识别并拆分编码任务
• 写伪代码
• 获得[PL或TL]批准
• 根据伪代码开始编码

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

Answer 1

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

甚至更好的是使用用户故事，用例，CRC卡，图表，诸如清洁室，RUP，LEAN，LEAN，SLEN，MANBAN，AGILE等方法所拥护的技术分析问题域和设计解决方案。

彻底了解问题的性质以及您用来实施解决方案的组件是最佳实践背后的原则。

Answer 2

我将注释用作一种非常高级的伪代码，因为在编写代码之前，我会编写评论。我发现通过整个问题，即使在高水平上也可以大大改善我的代码。

Answer 3

不，请勿首先伪代码

这太多了。您正在做编写逻辑的工作，没有任何好处。我建议以下任何内容：

1. 您要运送的语言中的原型（又名 写一个扔掉)
2. 带有代码段的架构图测试假设 /关键设计
3. 测试驱动的开发首先编写接口/代码结构，然后进行测试，然后实现代码。

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

Answer 4

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

（1）对于需要学习模块化和算法概念但尚未流利的编程语言的编程学生。

（2）传达某事将如何与非技术人员一起工作，或者只是为了在白板类型的会议中为了权宜之计。

Answer 5

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

它在行业中实践吗？根据我的经验，不。没有人有时间在文档（要求，规格，故事委员会，用例或其他使用的其他内容）和实际代码之间进行研究。通常认为，在绿灯至代码之前已经将足够的思想纳入问题中。到那时，编码项目比添加一层设计准备更重要。

Answer 6

我绝对会推荐伪代码。它可以帮助您澄清要做的事情，并确定可能忘记或潜在问题的项目。当您仍处于计划阶段时，更容易/更快地修复代码，而不是等到您已经对其进行了很大一部分。

Answer 7

如果您不熟悉该语言，或者您需要更改心理环境，那么伪代码可能会很有用。在我写伪代码的极少数情况下，它在纸上。有时，只需将您的手从键盘上伸出来，并在纸上涂抹可以帮助您围绕精神障碍。

但是作为开发过程的正式部分？没门。这是对个人的零星有用的工具。有更好的方法可以“在编写之前先了解您正在写的内容”，例如：

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

我还建议在开始编写代码之前获得任何类型的批准，可能会引起比价值更大的麻烦。设计审查（实施前）可能是有用的，但是它们需要比单个算法更高。

Answer 8

我将不同意以前的答案，并说不，但是请注意：只有当您热衷于重构代码以处理出现的问题时，您才能摆脱psuedocode。从本质上讲，psuedocode是在定义代码之前定义代码的一种方式；在许多情况下，这是一个不必要的抽象，由于您的代码永远不会是第一次完美（而且很可能不会遵循psueDocode的设计完成），因此对我来说似乎是无关紧要的。

Answer 9

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

在更现代的语言中，伪代码没有多大意义。更好的方法是编写方法存根，并填写顶层逻辑，并根据需要在实际代码中验证所有这些算法和需求的详细信息。然后，您可以将该代码显示给团队铅供应批准，并已开始使用真实的代码。

Answer 10

在过去的十年中，我唯一使用伪代码的时间是在使用白板时采访，并且特定语言无关紧要。

这对于以宽松的方式通过流程/算法进行交谈肯定会有所帮助，而不会与语法陷入困境。例如编写具有C＃属性的C ++类，只是为了说明这一点。

它具有“位置”，但只能在需要的地方使用（这是您将丢弃的工作），当然不是正式过程的一部分，除非您具有坚持使用的ISO型标准。

Answer 11

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

在辩论选项等时，该练习仍然很有价值，但是随着您花更多的时间使用几种语言，语言不可知论往往会消失。

Answer 12

越来越多的伪代码用UML之类的工具以图形方式编写。例如，尝试 尤姆.

用于创建和发布简单UML图的在线工具。这使您真的很容易：

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

... YUML节省了您的时间。它是为喜欢创建小图表和草图的人而设计的。

如果没有YUML，创建UML图可能涉及加载UML工具，创建图表，给它一个名称，摆弄布局，将其导出到位图，然后将其在某处上传。 Yuml不会让您做任何事情...

Answer 13

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

Answer 14

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

诸如Python或Java之类的许多现代语言已经与伪码如此接近，以至于撰写一些临时伪代码首先是浪费的，恕我直言。最好立即使用 示踪子弹 方法。

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

Answer 15

在几种情况下，伪代码倾向于在我的工作中被淘汰，这在学术界倾向于将编程用作工具或“现在我们解决它”在项目中间填充的工具：

1. 当代码比对伪代码的实际理解更为适得其反。例如，SAS将占用一半的白板执行一些相当基本的编程任务。另请参见C，其他一些海报已经讨论过。
2. 通过大量的数据分析和统计编码，随着结果的生成，代码往往会有很多修补。伪代码在“这里是一个来回的过程中，如果诊断图看起来不正确，请尝试使用X”。
3. 学生学习很多不同的编程语言。例如，在我认识的人中，可能会在SAS，R或Stata中分析统计问题。需要在R，MATLAB，C，C ++，Java，Python中进行更接近传统编程的事情……这实际上取决于特定的学生正在实施该计划以及目的。但是，对于Java人和Python人和Matlab人民，对他人的所作所为以及如何如何，这仍然是有用的。 方法, ，而不是代码本身，而是有效。

Answer 16

这不是肯定的/没有问题。相反，应该想知道 什么时候 使用伪代码。在设计解决方案之前要了解问题很重要，并且在实施解决方案之前先对解决方案有清晰的看法。伪代码可以在以下任何步骤中使用：

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

还使用了高级语言中实际上是正确代码的伪代码，通常称为原型制作。

除了实现理解之外，伪代码也适合通信。

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