通过伪编码进行软件设计?


9

您知道使用基于伪代码的方法设计(即写下)软件的好方法吗?

我是软件设计的新手,并阅读了一些有关UML的信息。到目前为止,我的谦逊的类层次结构还不错,但是,当事情变得复杂之后,我注意到通过“全面了解”,我可以使用其他结构来实现更高的可扩展性。由于Python可以很好地进行原型制作,所以我刚开始写就可以了,但是还不够。

所以我尝试了UML类图,但是它们似乎并没有太大帮助。我在那里解决的问题在脑海中微不足道。但是,一旦我开始对实际方法进行伪编码,我确实注意到了其他设计要求。

因此,如果您想通过伪代码进行设计,您将如何做?我相信对我来说,一种与代码大致一对一的方法效果最好。但是大多数UML软件甚至都没有显示该方法的代码(与GoF中的图片相反)。

有人声称UML仅用于文档和演示,对设计不是那么好吗?我也有这种感觉。我一直以纯粹的UML和一些简单的白板草图为设计软件的方式,直到谷歌搜索我找到Envision APDT为止。

那么,敏捷开发是我应该关注的东西吗?还是他们会随机称其为敏捷-我认为敏捷仅与计划有关?还是我设计不正确(使用UML)-有人通过伪代码进行设计吗?我如何找到一个好的工具?


3
Steve McConnell 在他的Book Code Complete 2中描述了伪代码编程过程(PPP)。该方法专注于低级设计和实现,但是如果您要这样做的话,则可能是不错的阅读方法。
thiton

Answers:


8
 I thought agile is about schedule only?

这不仅仅是计划。敏捷软件开发更多地是一种演进式开发和具有自适应计划的定时迭代交付,该计划鼓励对产品所有者所要求的变更做出灵活的响应。

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

从我的经验来看,从客户角度看图表更容易理解。它们在视觉上很吸引人,而且很多时候都非常丰富多彩并且易于遵循。但是,由于与实际应用程序代码断开连接的性质,很难维护图表。每次在应用程序中进行更改时,开发人员都必须花时间更新所有文档,包括图表。但是,只要团队或公司中有BA,并且能够很好地了解客户业务流程并能够管理UML图,便可以轻松解决该问题。

诸如UML之类的工具可以使此过程更容易,但仅适用于面向对象的编程。对于技术团队而言,伪代码要容易得多。创建此代码的过程极大地提高了实际编程语言开发阶段的速度。

您可能还会看到其他一些选择:

  • 数据流程图
  • 状态图
  • 工艺流程图

很好的参考资料:《软件设计教程》。另外,我个人会建议您阅读有关Pseudocode或Code的好博客由Coding Horror发表- 我最喜欢的博客:

总而言之,您需要考虑一些折衷。


3
+1链接到Pseudocode或Code。只是写该死的代码。
凯文·克莱恩

@ElYusubov:谢谢您的解释。看来您还暗示UML更适合演示?对于实际设计,我不强调它吗?最后,您提出3个图表。可以将它们与代码进行一对一的扩展吗?相反,我的意思是在图中起作用的某些事情可能不适用于代码-我想避免。
Gerenuk

@Gerenuk,可以使用代码流一对一地制作数据流程图。但是,通常使用图来查看高层设计以及组件/模块/用例之间的交互。
尤苏波夫

3

用汇编语言编程时,编写伪代码很有意义。该算法可以在手动将其翻译为汇编语言然后调试翻译之前进行验证。对于第一代编译语言(如FORTRAN IV)仍然有意义,在该语言中,唯一的控制结构是GOTO,所有变量(形式参数除外)都是全局变量,并且变量名限制为六个字符。

今天,我们很少用汇编语言进行编程,而我看到编写伪代码而不是仅仅编写代码的价值很小。在一种体面的语言中,实际的代码将几乎逐字跟随伪代码,伪代码只是浪费时间。

但是,我不会从底部开始编码。我按照TDD进行测试。然后,我从顶部开始进行编码,然后根据需要逐步将其从底部开始进行工作,以使测试通过。

伪代码的替代方法是不编写1000行低级类。而是从顶部开始,为您的域调用理想的但不存在的API。然后构建API。


当我刚开始编码时,有时以后我会注意到在设计方面,我可能已经排除了一些代码。虽然重构是可以的,但是如果我首先看到所有代码的概述并运用一些创造力,它仍然可以避免它。图形化的伪代码视图可以在一个压缩图中显示所有内容。我的错误在其他地方吗?
Gerenuk

2
您的错误是相信重构代码在某种程度上比重构伪代码更有效。使用现代IDE,编写实际代码比在纯文本编辑器中在纸上写伪代码要容易和快捷得多。
凯文·克莱恩

1

我发现类图几乎不值得付出,即使您跳过列出所有方法并仅显示继承层次结构也是如此。顺序图虽然很好,但是在绘制它们时可能会感到尴尬(可能只是我自己)。

我发现数据流程图和结构图更加有用(尽管结构图通常与BDUF相关联,因此目前不受欢迎)。DFD对于功能分解特别有用。可以将DFD中的每个“气泡”分解为自己的DFD,直到获得所需的详细程度。


0

我认为图形工具比伪编码更好,但是UML过于复杂,以至于它结合了这些方法的缺点:-)

更明确一点:我认为编程主要是分析特定问题的一种方法,将其分离为较小的组件及其交互。这是“一段旅程,而不是终点”,您不断提高对问题的了解,因此组件图也在发生变化:层出现和消失,功能和数据项上下移动等。

遵循此过程的自然工具是画板,它尽可能简单,但又足够复杂以帮助快速理解(相同的颜色,形状,具有相同逻辑含义的箭头)。我还没有找到银弹,也许我会写自己的一天,但是现在我有点浮躁了。结合prezi的缩放功能,它几乎是完美的。

为什么不进行伪编码?伪编码是实现构想的第一步,是“组件图的序列化形式”。不好,限制了您的头部。根据我的经验,发现我开始编码的时间越晚,我丢弃的代码就越少...

但这也许是因为我已经写了所有那些被扔掉的代码,所以我现在不必写它们了,我从它们那里获得的经验是在设计系统时伴随着我的?好吧,我必须修改该语句。

如果您迷失了图形,并看到许多等效的解决方案,请使用伪代码,甚至使用模拟对象编写该代码-在Java中,这几乎没有什么不同。查看代码,感受这些组件的结构和可用性,它将帮助您修复图形并做出决策。但这仅在您准备丢掉该代码(如果感觉不好)时才起作用。我认为这是伪代码的优点:伪代码在工作时保持诱惑的可能性较小,但是在结构上是错误的(和往常一样,您没有足够的时间)。:-)

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.