在开始编码之前你做了多少计划?

在经历了许多未完成的项目之后 我倾向于将业务流程的简化版本实现到我的个人开发方法中。

它们通常遵循以下结构:

1. 写一个简短的话,这样我就有了一个目标。
2. 实施一 class diagram 为了理解我将要处理的数据。
3. 实现所有类。
4. 起草一份 use-case diagram 概述活动。
5. 搭建用例分解图(用于webapps的HTML)
6. 用铁丝将脚手架挂好,并进行单元测试和搭设合格。
7. 决定发布该产品以获得商业成功,然后将其全部忘记。

比我应该的少很多

我总是潜入水中,变得很脏,然后意识到我把事情搞得一团糟。那就回去计划一下,做对了。

但是 凌乱的错误阶段给了我一些很好的想法,但是通过一个正式的设计过程我是不会有这些想法的。

编辑 我主要参加这种活动 击碎键盘 玩大/复杂游戏时会出现混乱。有趣的是,在你意识到你的“它在我的头脑中,所以它是好的”设计是100%有缺陷之前,看看事情进展到什么程度。

可能不是最好的技巧…但是… 我在代码中计划 .

我经常通过这样做发现我需要的类/方法等。 尽管如此,我总是假设我的计划代码不是最终的解决方案。

此外,我将写下详细说明“主要特征”和“次要/希望特征”的注释。

当我进入“瀑布式”的做事方式时,我会写几百页的文档,展示在研究过程中可能发现的所有细节。为了得到这本庞大的文件,我通常会

1. 会见并问候参与该项目的每个人
2. 对感知到的需求做大量的记录
3. 创建高级别需求的长项目符号列表
4. 开始将高层次的需求分解为明确的细节
5. 开始填写软件需求规格说明文字模板: SRS
6. 在Photoshop、Excel或(我的最爱)中创建线框 Balsamiq
7. 列出必须捕获的数据并开始构建粗略的架构
8. 在UML中列出类结构
9. 定义项目时间线
10. 胡说八道
11. 写代码
12. 希望代码完成后,所请求的仍然是需要的!

在过去的几年里,我一直跟随敏捷(Scrum)的脚步,并采取了完全不同的方法。

1. 与产品所有者会面,了解要构建的任务
2. 将故事分解为任务(基本规划)
3. 为任务分配时间
4. 做一些更详细的计划
5. -->编写测试、编写代码以通过测试、重构-->签入Dance
6. 演示工作产品/功能
7. 重新启动进程

我不得不说,敏捷可以减少编写文档所花费的时间,而这些文档一旦墨水变干就会腐烂。产品所有者可以更快地看到结果。这意味着他们可以随着时间的推移保持项目朝着正确的方向发展,即使这个方向随着我们的发展而改变。

记住,有一个时间和地方可以同时发展两种方式。我不想用敏捷来构建Jet软件!

这完全取决于项目的规模。有时可能需要几个月的时间来收集所有的需求,并确切地知道它需要做什么。

当涉及到编码部分时,这完全取决于它有多复杂。如果它非常复杂,我将从简单地画出我想要它做什么开始。然后我将在注释中键入伪代码。然后我将围绕这些评论进行编码。

但是,如果是简单的编码。我通常只写下我的想法并测试它。

我们使用一种非常敏捷的方法,因为我们将在主要部分上工作,当然,需求中总会出现一些东西。所以我们会在他们出现的时候为他们提供住宿。在创建周期的开始,你永远不会完全知道你想要创建什么。

这是我的意见。

这要看情况而定。我写的大多数东西都相当简单,一个更大的设计一步一步地被构建,我注意到什么仍然缺失,什么已经完成。还有一些更毛茸茸的东西需要大量的素描和思考,虽然我还没有遇到许多建筑问题需要这样做(仍然年轻和东西)。大部分都是复杂的算术问题。

在去年的实习中,我的经理惊喜地发现我用流程图解决了一个问题。他认为这是学生们丢失的一门艺术。他们被认为是约会对象,我并不感到意外。

不管怎样,这取决于我的项目时间表,最后期限当然是最重要的。

在大多数情况下,我至少试着用一个整体的图表(甚至只是在我的头脑中)来描述模块/系统将如何工作。我喜欢在做之前知道我要做什么。它使编程变得越来越简单和快速(在我工作的地方,我们通常都处于严格的最后期限之下)。每次我不这样做,我都会遇到一些问题,这些问题通常会导致我提取代码并将其放到其他地方。我承认,我的过程经历了痛苦的经历,我非常擅长在代码中使用regex以及全局查找和替换。

其他人提出了一个很好的观点,有时你有一个非常大的系统,这变得很困难。我试着把它分成小块。我会做一些事情,把它充实起来,再做一些其他的事情,看看它们是如何相互作用的。即使提前计划,我也会错过一些事情,不得不重构代码,但至少我不会重做任何事情,因为我至少有了某种工作计划。

这取决于你想解决的问题有多复杂。如果你正在进行一个大型的编程项目,在开始之前你需要有一定程度的计划。如果你不这样做,你会对那些在短时间内无法与其他部分进行沟通的东西的细节大吃一惊。

基本上,试着对你需要解决的问题进行鸟瞰。看看这些问题是否足够小,您可以解决它们,并找出与解决方案的其余部分通信可能需要什么。把它想象成一个黑盒子,外面有一个API。

在计算出所有的块之后,看看是否需要将问题拆分为更小的子问题,或者是否有足够详细的整个项目视图,可以从代码开始。

我的经验是,计划可以帮助您防止将来出现问题,使您更多地思考如果需要添加任何东西等,将来代码应该如何增长。

在大多数情况下,您将节省在调试或扩展项目时花在计划上的时间。此外,拥有一个项目的大致布局意味着它将更容易得到帮助建立你需要的黑盒子,所以你可以与更多的人一起工作,而不仅仅是你自己。

根据项目的复杂性,我通常从pad和paper开始,编写控制流的规范和一些伪代码。然后在编码的时候我总是可以引用它。因为您没有仔细考虑问题,所以这样做更容易,而且需要的重构也更少。

就个人而言,这取决于项目的范围和复杂性、我与多少人合作以及对交付的总体期望。

了解使用该软件的各方的总体期望是非常重要的。参与项目的每个人都应该对正在进行的工作有一个共同的理解——这是如何在多个方向上进行沟通的。

通常,参与软件开发的各方没有意识到,各方之间的交流常常是项目中最关键和被低估的部分——也是项目事故的主要原因。

我煮了些咖啡,做了几个三明治。

这真的取决于项目。我曾在国防工业的一些项目中工作过,在写一行代码之前,我花了两年的详细计划,坐下来,在一个3D或纹理艺术家的电子邮件中,我用一袋椒盐卷饼和一杯乔酒,从几个请求中大量生产出一些小实用程序。

能够在手边开发流程图、UML图、用例字典和广泛的编码标准是一种很好的方法来保持事情的有序性,并且在更大的项目、更大的团队和关键任务的项目上肯定值得做。但这些事情确实需要时间,而且对于较小的项目来说往往是杀伤力过大。

唯一需要确保的是您对问题域有足够的了解。如果没有,那么花时间提前研究它,直到你做了为止,这总是值得的。

IMO提前5分钟计划=1小时编码……

很多时候,我们不得不回去重新考虑整个情况,因为我们什么都没有计划。

最重要的部分应该是流程图。

其他的细节有时可以在飞行中处理。

在处理任何大小的问题时,我总是计划至少写两次。

我还在上大学,还没有创建大型软件系统的经验,但是……

首先要做的是找出想要什么。到目前为止,对于我来说,这通常是一个分配规范,但在现实世界中,它涉及到与客户的对话。很多。

然后我就知道如何做需要做的事情。对于我正在研究的相对较小的程序,我通常会在脑海中形成一个大致的概念,即程序的外观(程序的重要部分是什么,以及它们如何相互作用)。如果我不知道程序的某个部分将如何工作,这可能涉及峰值。我不认为这种方法(在我的头脑中做这一切)能很好地扩展,但问题是问我们实际上做了什么…

一旦我或多或少地知道我要做什么,我就会坐下来写代码。正是在这里,我发现了我所思考的问题。

我想我没用过 伪码 设计一个算法。我认为伪代码的级别太低,无法设计大的程序块。

我只使用了 流程图 有一次我在学习汇编的时候帮助设计了一个程序,并且对编程还很陌生(这很有帮助)。 神秘人月 下面说:“详细的井喷流程图,然而,是一个过时的麻烦,只适合初学者进入算法思维。……我从来没有见过一个有经验的程序员,他在开始编写程序之前,经常制作详细的流程图。”

我绘制了大量的流程图,并为更复杂的函数编写了伪代码。我觉得绘制流程图可以让我重构而不意外引入错误。在纸上做一个可视的图表,如流程图,也可以帮助我找出我的逻辑是否是 事实上 对的。这只适用于大多数规范已知的中小型项目。

有了更多的经验,绘制大量流程图和写出整个函数伪代码的需求将变得更加多余,但是在您达到这一点之前,我强烈建议您在编码之前进行计划。