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

Question

当你开始一个新项目时，你如何计划它或需要多长时间？

伪代码？ 流程图？

您是否尝试提前考虑所有课程？

TBH，我从不计划任何事情。当我遇到问题时，我会直截了当地思考解决方案。主要是因为我提前几次尝试计划，我总会忘记一些重要的事情，因此规划的逻辑会有缺陷。

Answer 1

经历了大量未完成的项目后，我倾向于将业务流程的简化版本实施到我的个人开发方法中。

他们通常遵循以下结构：

1. 创建一个简介，以便我有一个目标。
2. 实施class diagram以了解我将要处理的数据。
3. 实施所有课程。
4. 制定use-case diagram概述活动。
5. 支持用例disagram（用于webapps的HTML）
6. 通过实施单元测试和构建以传递脚手架来连接脚手架。
7. 决定发布该产品以取得商业成功，然后忘掉所有相关内容。

Answer 2

比我应该少

我总是潜入，变脏，然后意识到我弄得一团糟。然后回去计划，并做好。

但这个混乱的错误阶段给了我很好的想法，我通过正式的设计过程不会有。

编辑我主要是在使用大/复杂的时候进入这些粉碎键盘混乱。有趣的是，在你意识到你的“它在我脑海中，所以它没关系”之前，事情已经走了多远，设计是100％有缺陷的。

Answer 3

可能不是最好的技术......但是...... 我计划代码。

我经常发现课程/方法/等。我只需这样做就可以了。 话虽如此，我总是认为我的计划代码不会是最终的解决方案。

此外，我将写下详细说明“主要功能”和“次要/愿望功能”的说明。

Answer 4

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

1. 与参与项目的每个人见面并致意
2. 关于感知需求的大量笔记
3. 创建高级别要求的长项目符号列表
4. 开始将高级别要求细分为明确定义的细节
5. 开始填写软件需求规范字模板：SRS
6. 在photoshop，excel或（我最喜欢的）Balsamiq
中创建线框
7. 列出必须捕获的数据并开始构建粗略架构
8. 以UML列出类结构
9. 定义项目时间表
10. blah blah blah
11. 编写代码
12. 希望所要求的是代码完成后仍然需要的东西！

在过去的几年里，我一直关注敏捷（SCRUM）并采取了完全不同的方法。

1. 与产品负责人见面，了解要建立的任务
2. 将故事分解为任务（基本规划）
3. 为任务分配时间
4. 做一些更详细的规划
5. - ＆gt;写测试，编写代码以通过测试，重构 - ＆gt;检查舞蹈
6. 演示工作产品/功能
7. 开始处理

我不得不说敏捷减少了一旦墨水干掉就会写出文件腐烂的时间。产品所有者可以更快速地查看结果。这意味着他们可以随着时间的推移使项目保持正确的方向 - 即使这个方向随着我们的发展而变化。

请记住，两种发展方式都有时间和地点。我不想用Agile构建Jet软件！

Answer 5

这一切都取决于项目的规模。有时可能需要数月才能收集所有要求并确切知道它需要做什么。

当涉及到编码部分时，一切都取决于它的复杂程度。如果它非常复杂，我将首先简单地描绘出我想要它做的事情。然后我将在评论中输入我的伪代码。然后我将围绕这些评论进行编码。

但是，如果它是简单的编码。我通常只会写出我的想法并进行测试。

我们使用非常敏捷的方法，因为我们将处理主要部分，当然，事情总是会出现在需求中。因此，我们将适应那些出现的人。你永远不会完全知道你想要在创建周期开始时创建什么。

这是我的意见。

Answer 6

这取决于。我编写的大多数内容都非常简单，一个更大的设计逐步构建，我注意到仍然缺少什么，已经完成了什么。还有一些毛茸茸的东西需要大量的草图并且想要做对，尽管我还没有遇到过许多需要这样的建筑问题（还有年轻和东西）。大多数情况下这些都是棘手的算法。

Answer 7

在我去年的实习期间，我的经理惊喜地发现我使用流程图来解决问题。他认为这些日子里与学生们失去了艺术。我感到非常惊喜，因为他们被认为过时了。

无论如何，这取决于项目的时间表对我来说，截止日期当然是最重要的。

Answer 8

大多数时候，我至少尝试了一个关于模块/系统如何工作的整体图表（甚至只是在我脑海中）。我喜欢在做之前知道自己要做什么。它使编程更容易和更快（我们通常在我工作的紧迫期限内）。每次我不这样做，我会遇到一些问题，这些问题通常会导致我删除代码并将其放在其他地方。我承认，我的过程经历了痛苦的经历，我非常擅长在代码中使用正则表达式以及全局查找和替换。

其他人提出了一个很好的观点，有时你会有一个非常庞大的系统并且变得困难。我试着把它分解成块。我将处理某些事情并将其充实，并在其他方面工作一段时间，看看它们是如何相互作用的。即使提前计划，我也会错过任何事情并且必须重构代码，但至少我没有重做所有内容，因为我至少有一些工作计划。

Answer 9

这取决于您试图解决的问题有多复杂。如果您正在进行大型编程项目，则需要在开始之前进行一定程度的规划。如果你不这样做，你将会很快失去与其他部分很难沟通的细节。

基本上，尝试对需要解决的问题进行鸟瞰。查看是否有任何问题足够小，您可以解决它们并找出与其他解决方案进行通信所需的内容。可以把它想象成一个带有外部API API的黑盒子。

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

我的经验是，规划可以帮助您预防未来的问题，如果您需要添加任何内容，可以让您更多地考虑将来如何增加代码。

在大多数情况下，您将节省在调试或扩展项目时花在计划上的时间。此外，对项目进行粗略布局意味着可以更容易地获得构建所需黑盒的帮助，因此您可以使用更多人而不仅仅是自己来处理它。

Answer 10

根据项目的复杂程度，我通常从pad和paper开始，并编写一个规范，以及一些控制流的伪代码。然后我可以在编码的时候再回头看看。它使得它更容易，并且需要更少的重构，因为你没有想到问题。

Answer 11

就个人而言，这取决于范围和项目的复杂性，我与之合作的人数，以及对交付的整体期望。

了解将使用该软件的各方的总体期望非常重要。参与该项目的每个人都应该对正在进行的工作有一个共同的理解 - 如何传达这种方式可以向多个方向发展。

参与软件开发的各方往往没有意识到，各方之间的沟通往往是项目中最关键和被低估的部分 - 也是项目失误的主要原因。

Answer 12

我煮了一些咖啡，制作了几个三明治。

真的取决于项目。在编写一行代码之前，我参与了国防工业中的一些项目，这些项目花了2年的时间进行详细规划，而且我已经坐下来从一个来自3D的电子邮件中的一些请求中生成了一些小实用工具。纹理艺术家在一个单独的坐着一袋椒盐脆饼和一杯乔。

能够事先开发流程图，UML图表，用例词典和广泛的编码标准是保持组织有序的好方法，并且当然值得在更大的项目，更大的团队和关键任务项目上做。但这些事情确实需要时间，而且对于较小的项目而言往往有些过分。

您唯一需要确保的是您对问题域有充分的​​了解。如果没有，花时间研究它直到你做到总是值得花时间。

Answer 13

国际海事组织提前5分钟计划= 1小时编码......

很多时候我们不得不重新考虑整个情况，因为我们没有计划任何事情。

最重要的部分应该是FLOWCHART。

其他细节有时可以随时处理。

Answer 14

当遇到任何规模的问题时，我总是计划至少写两次。

Answer 15

我还在大学，我还没有创建大型软件系统的经验，但是......

首先需要做的是找出想要的东西。到目前为止，对我来说，这通常是一个赋值规范，但在现实世界中，它涉及与客户交谈。很多。

然后我找出如何做所需的事情。对于我一直在研究的相对较小的程序，我通常会在脑海中形成一个粗略的概念，即我的程序将会是什么样子（程序的重要部分是什么以及它们如何相互作用）。如果我不知道程序的某些部分如何工作，这可能会涉及尖峰。我不认为这种方法（在我看来都是这样）会很好地扩展，但问题是问我们实际做了什么......

一旦我或多或少知道我想要做什么，我坐下来编写代码。我在这里发现了我在思考的任何问题。

我不认为我每次都使用伪代码来设计算法。我认为伪代码太低而无法设计大块的程序。

我有一次只使用流程图来帮助设计一个程序 - 当我学习汇编时回来并且对编程很新（这很有帮助）。 The Mythical Man-Month 说：“然而，详细的逐个流程图是一个过时的麻烦，只适合初学者进入算法思考....我从未见过一位经验丰富的程序员，他在开始编写程序之前经常制作详细的流程图。“

Answer 16

我绘制了大量的流程图并为更复杂的函数编写伪代码。我觉得绘制流程图允许我重构而不会偶然引入错误。在纸上制作可视化图表（如流程图）也可以帮助我确定我的逻辑实际是否正确。这仅适用于大多数规范已知的中小型项目。

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