设计应用程序和编写应用程序之间的平衡时间是多少？

Question

这个问题可能看似微不足道，但这是一个实际问题：当你正在开展一个项目时，你是否在实际开始编码之前做了任何架构设计？您是否花了很多时间与客户一起获取详细的规格/用例/样机？

在编码期间，您是否更改过之前做出的架构决策？您是否使用新的规格/用例/样机回到客户手中？

我想知道，根据您的经验，所有非编码操作和编码本身之间的平衡是什么？

更新

好的，所以从目前为止，似乎有两种方法：

• 尽早设计，然后坐下来编码以避免后期修复
• 最小化设计单独部分，而不是迭代开发（敏捷方法似乎更喜欢这种方式）。

我想要走哪条路取决于项目，团队和客户......我是对的吗？

Answer 1

最大限度地减少花费的总时间; - ）

这在很大程度上取决于项目的类型，但一般来说，最好“浪费”时间过度设计和指定必需品，而不是稍后发现出现问题并全部回来修复它。

我读过一些关于“神话人月”中可怜的设计决策影响的量化测量，或者可能是在一本名为“软件需求专业实践”的书中，来自微软出版社，我认为浪费的时间已经很晚了修复（产品交付附近）约为早期阶段的10倍。

Answer 2

如果你做敏捷，设计和编码是一回事。根据我的经验，在项目的第一阶段配对计划是很好的......

Answer 3

看看scrum，敏捷和瀑布。这与项目管理本身没有编程有关。

一旦在域或平台中构建了足够的应用程序，架构也变得更加容易。在PHP中，如果您使用Joomla，Symphony或codeigniter，那么您的脚手架和架构已经到位。 ASP.NET MVC也是如此。

Answer 4

我个人的经验告诉我，你应该考虑不同的因素。没有银弹。我的个人名单如下，主要是根据经验增长。

1. 如果你正在开发一些众所周知的细节，那么开发团队很少并且很难高效地进行有效沟通，团队对其他团队的工作具有强烈或巨大的依赖性，而你正在开发的团队有一个未来很难改变的基本长期重要性（例如文件格式），需要很长的设计阶段，类似于瀑布模型。此外，如果您计划开发相当复杂的应用程序，则应该花费大量的设计，并且在编码之前必须深入考虑功能之间的所有可能的交互。与设计相比，编码只需要很少的时间。此外，如果从高层次的角度保持应用程序行为的有效记录，并且如果您的团队往往非常不稳定，那么您应该考虑这一点，以便您的知识保持在纸上而不是人们的脑。
2. 如果你必须实施一些全新的东西并进行研究，你想尽快获得功能，从快速反馈中增加应用程序，你就拥有一群在同一个房间工作的极客，非常致力于你因为喜欢编程，他们热衷于分享和共同构建，采用敏捷方法。
3. 如果您介绍前两种情况，请采用迭代方法。我通常选择3个月的时间表。当我单独编码时，我的工作类似敏捷，主要是因为我必须应对频繁的中断，所以我按功能添加功能。但是，我发布迭代，即我不打算在第三次迭代之前做一个官方的，稳定的发布。在承诺保持一些愚蠢的选择之前，我想要空间来学习这个领域，做错误并纠正它们。
4. 如果你在学术界编写代码，那你就搞砸了，因为你有一些问题在1而没有人力来容纳它们，而且有些问题在2中没有灵活方法所需的简单沟通。

Answer 5

大约50/50。每当我分析我的项目进度表时，大约有50％的时间用于设计，项目管理，质量控制和辅助任务。剩下的50％是编码。如果我没有看到50/50的比例，我担心。

请注意，这是使用传统的瀑布模型（更适合自定义应用程序开发）。在我看来，敏捷方法对于收缩包装软件更好。

Answer 6

我会说它大约是50/50，无论是“方法论”还是项目类型。它仅在50％设计的分布方式上有所不同。并且可能依赖于项目，但最重要的是它取决于执行工作的人，以及它们是如何“连线”的。这不仅仅是心理学而非方法论​​。

有些人（我会说更谨慎的人物）在开始编码之前需要更详细的心智图。如果他们没有先前经验的地图，他们将需要更多的“调查”时间。

其他人还喜欢只用一张粗略的心智地图“跳入”编码，并在他们去的时候弄清楚细节。

介于两者之间的是通过尖峰和原型进行详细说明，并在运行代码之上开发“大图”。对我个人来说，这往往会产生最好的结果，而且浪费最少。 （毕竟，在某种程度上，原型设计是一种应用于解决方案创意的测试优先方法。你会得到一个想法，在尖峰或原型中测试它，然后用主代码库实现/集成它。）

我的建议是：找出最适合自己的风格，并坚持下去。这将非常肯定你最有效的风格。

Answer 7

这两件事紧密相连。那么在第一阶段，你肯定会花一些时间做出设计决定。然后你将不得不开始编码，几乎在所有情况下你都会为你以前的设计做出一些改进决定。 毕竟，这将取决于交货日期和您有多少时间，然后相应地决定如何平衡它。通常，您进行启动设计，然后在编码期间更新和更改它。同样是一个很好的做法，让您的客户在开发阶段深入参与设计决策，迫使他了解它以及您将花费多少时间用于每次更改。

Answer 8

您编写规范与开始编码的时间之间的时间越长，这将增加需求变化的可能性。所以，尽快回答你的问题......

如果你的需求过多，那么我会建议实施较小的版本迭代（如果可能的话），然后为每个阶段创建新的需求/规范文档。

如果你不能这样做......确保你有一个良好的变革管理过程。

Answer 9

我的google-fu大幅失败，但最近我读到了以下内容：

“花6个月的编码，6个月的设计和6个月的测试。好消息是，它们在6个月内都是一样的。”

Answer 10

设计足够的地图以确定您要编写的代码的映射以及它与系统其他部分的关系非常重要。您不能只编写大多数大型项目 - 它们太大，通常涉及多个组件。我年轻的时候就已经这么做了，你最后得到了一个大泥球，或者整夜熬夜一整天重构它。

我现在倾向于设计包级别，并为组件分配角色。在大型系统上进入组件选择阶段可能需要几个月的时间，并涉及一些跟踪和原型编码。

然后，根据功能需要的消息以及包的客户端如何演变以引起进一步的需求或约束的出现，演变每个包的API和实现。我通常通过为每个已知用例设计纯接口（通过编写代码）和单元测试来演化API，然后实现它。因此，设计中涉及一些代码编写 - API的最佳表示通常是代码和内联文档，并且最容易确认客户端可以执行满足用例所需的操作（以及执行此操作的代码）通过编写以这种方式运行API的代码，并且该代码在到达时通常会成为API实现的单元测试，并不过分复杂。但是在“设计”期间编写的代码不是提供API实现的代码。对于低耦合的API（因此可以在不破坏太多客户端的情况下进行更改），我将在设计和实现模式之间快速切换;对于具有更高耦合的那些，我通常会在提交它们之前发布API和用例示例以进行同行评审。

Answer 11

正如aleemb所说，这确实是一个项目管理问题。我建议您阅读几种方法，找到每种方法中有用且不那么有用的部分，并评估您自己的情况（团队规模/经验，客户参与度和承诺水平，您的组织中做了什么，计划/预算等） 。）并提出最好的时间表。这真的完全取决于你的具体情况。

Answer 12

想想有多少人参与编写软件。

如果它只是一个开发人员的工作，可能需要较小的设计百分比。如果你有30个人正在研究它，你可能想要更大的设计分数。

让开发人员团队编写软件就像在多个CPU上划分软件一样 - 当你可以最大限度地减少他们之间的必要通信时，你将获得额外CPU（读“开发人员”）的最佳回报。在开发人员开始讨论架构问题之前，您肯定不希望将10-k-loc放入项目中。

现在你可能也可以说，当你在设计阶段做得更好时，编码实际上会花费更少的时间并减少痛苦。测量两次并切割一次，然后完成所有操作。

另外，您可能应该考虑项目被“搁置”的可能性;设计工件比不成熟的代码具有更好的保质期。

Answer 13

取决于您选择的方法 传统上使用Big Design Up Front或Waterfall，您可以将90％的时间用于设计，10％的时间用于编码。然后，您将花费90％的时间来处理初始设计错过的所有更改。还有90％的时间追逐错误。

通过现代敏捷开发，您可以将10％的时间用于设计，90％的时间用于编码。然后另外90％处理客户代表忘记提及的所有更改，另外90％的时间处理错误。