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

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

在编码期间,您是否更改了以前制定的架构决策？您是否使用新的规格/用例/样机回到客户手中？

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

更新:

好吧,所以从目前为止,似乎有两种方法:

尽早设计,然后坐下来编码以避免后期修复

最小化设计单独部分,而不是迭代开发(敏捷方法似乎更喜欢它).

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

这最大限度地减少了花费的总时间;-)

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

我读了一些关于"神话人月"中可怜的设计决策影响的定量测量,或者可能出现在一本名为"软件需求专业实践"的书中,来自微软出版社,我觉得时间浪费在后期修复中(附近)产品交付)比早期阶段大约10倍.