我目前正在上学，对于我的高级项目，我们不得不花费1/3的时间来为我们的项目做UML图和其他繁琐的文档。
这涉及到很多设计和规划尚未发生的未来问题。
出于某种原因，这似乎是鼓励过度设计。我花了最后一小时写这样的东西。
“连接到服务器 - 连接到服务器。前提条件：不存在服务器连接。后置条件 - 现在连接已存在”。
我宁愿做编码而不是做这个废话。我意识到这个设计工作有它的位置，但多少钱？我知道这不是防止在像Enterprise Arch这样的工具中进行设计的绝对证据，但在这里我会去。
我教授这些课程的教授设计了他的项目。应用程序中可能发生的每件事都已记录在案。他没有自己编码，而是利用这个“完美无瑕的文件”将海外工作和暑假期间的学生分开。
所有这些设计产生的应用程序都是可怕的。这是我见过的最糟糕的应用程序之一，任何人都可以告诉你它已被过度设计。
SO经验丰富的编码社区对此主题有什么看法？在项目之前设计很多事情是因为“设计文档这么说”而通过强制做出决策来制作糟糕的程序吗？
非常感谢你们提供的任何见解。如果我知道这一切都是有充分理由的话，我会感觉更好“浪费”我的时间。我非常愿意事先做一些设计工作，但我觉得我的教授期望在编写任何代码之前做出很多工程决策。
编辑： 关于这个主题的有趣的slashdot文章。 http://books.slashdot.org/story/09/11/16/1448204/Becoming-Agile
答案 0 :(得分：43)
我不想以破纪录的形式出现（我最近一直在使用这句话），但John Gall的引用与软件构建的许多方面非常相关。 （即使他在谈论生物系统）
“一个有效的复杂系统总是被发现从一个有效的简单系统发展而来。反向命题似乎也是如此：从头开始设计的复杂系统永远不会起作用，也无法工作。你必须开始从一个简单的工作系统开始。“
也就是说，如果你正在设计，那么首先要设计一些小而且可以实现的东西。一个巨大复杂的前端设计注定要失败。
你可以通过将它们分解成更小的部分来解决巨大的任务。构建您能想到的最小可能的工作。不要马上解决整个问题。
大型复杂设计可能注定要失败的原因之一是它所解决的问题可能是一个邪恶的问题，或者其他一类无法解决的问题，其中问题的子组件各自互相排斥。如果没有某种工作实验作为子问题可解决性的证据，那些事先很难被发现。
我在这个问题上看到的大多数证据似乎都预测，前期设计越大，它就越有可能超出预算而且可能无法解决任何问题。简而言之，设计是必要的，但您的目标应该是尽可能保持小巧和简单，并且请记住，由于您在实际编码阶段遇到的因素，您的前20个草稿可能会失败。
答案 1 :(得分：15)
这是非常主观的，但恕我直言，只能对相应的整体系统架构应该是什么样子做出相当好的猜测，但设计不应该停止，（或者甚至可以缓慢地降低），它应该在整个过程中持续应该鼓励和发起开发和开发重构，因为持续设计可以解释领域模型分析，设计和开发模型之间的不一致。无论您是在开发之前还是在开发过程中进行所有设计，您的教授所教授的概念（和工具）在设计过程中都是非常宝贵的。
您的教授正在做的事情听起来像 瀑布 软件设计生命周期（SDLC）过程的经典案例。其主要的失败并不是建设阶段（编码）被延迟，但是在编码开始时这种设计或多或少地停止了（因为瀑布方法所产生的改变的障碍）。
可以找到一些幽默的内容here。
答案 2 :(得分：15)
天儿真好，
这在很大程度上取决于项目的性质。
我曾参与过新系统取代现有系统的项目，而且绝大部分时间用于收集现有系统的行为以建立需求。
这个阶段，然后是设计阶段，花了将近18个月。编码大约需要四个月的日历。在努力方面它更多，但最终的结果是一个客户喜欢的稳定系统。
哦，顺便说一句，这是现有空中交通管制系统，德国空中交通管制系统的替代品，所以他们只需要在三个月的一个月后就可以投入使用预定的评估期是我非常自豪的一项成就。
我认为这个项目的大型评估和设计阶段是最好的方法。
编辑：该系统位于卡尔斯鲁厄，由德国版FAA运营的航路空中交通管制中心运营。现有的雷达处理系统将被雷神公司取代，但主系统的交付延迟了。因此，DFS决定将控制器位置升级到新系统的位置，但暂时将它们附加到现有的ATC处理系统。因此，Karlsruhe AdvancedDisplay System或KADS项目的名称。当整个控制室被更换时，在现有的ATC中心后面建造了一个全新的机翼。
有一个强制性的需求收集阶段，团队在现场与构建现有系统的软件工程师一起工作。
他们记录了：
然后由DFS签署这些要求并开始设计阶段。这持续了大约一个月，而几个部分是原型，并确定了最佳解决方案。与实现并行的是一个测试设计阶段，其中所有需求都被追溯到代码并进行了相关测试。
然后编码和测试开始了几次交付，约。十，完成，每个都有一个相关的测试和验收阶段。 Scrum方法之前有一个名称，因为我们选择了在阶段开始时进入每个“发布”阶段的工作块。最终交付准时按预算进行。
DFS打算与现有系统并行运行新系统三个月，以便他们评估新系统的性能和稳定性。完全转移到新系统是一个“全有或全无”的提议。他们不得不用旧的雷达线换去旧的电话开关装置，之后就没有回头了。
因此，对于德国ATC服务部门来说，他们会对系统非常满意，这对我们来说是一个很大的帮助！
BTW在需求阶段出现的旧软件工程师的数量，并说我们没有工作，因为没有编写代码是非常有趣的。当你查看一些代码时，很明显证明了旧的“裤子座位”方法。 （ - ：
HTH
欢呼声，
答案 3 :(得分：7)
这是上个世纪，如此学术化。
通常会发生什么，至少根据我的经验，无论你如何努力设计，你都会遗漏一些技术限制，在系统的不同部分之间有某些联系。也是设计的起点 - 要求总是远远不是一成不变的。
通常，为了验证您的设计，您实际上需要进行一些编码 - 原型等。更新的开发过程 - 对于一个人来说敏捷，只要说你只需要那么多设计就可以开始编码。
这并不是说你可以在没有明确了解你的目标的情况下急于编码，但过度使用它真的很糟糕
答案 4 :(得分：6)
正式的学术培训通常（据我所知）在实际生产编码开始之前（包括原型设计）将重点放在设计和其他一些东西上。
这是有道理的，你没有把它弄好（或几乎正确），你会被搞砸。
然而在实践中，很少有时间和资源的奢侈。更糟糕的是，非技术人员（特别是那些人）希望看到事情（UI，原型）确实感到安全，并取得了进展。
对我来说，这是关于平衡的，不同的组织将不得不画出自己的路线，提出最佳实践。也根据项目/资源等的性质而有所不同。
关于UML，这里有一些关于SO的有趣帖子：
Is UML practical?
Is UML still seen as a viable way of documenting a software design?
Should I use UML when designing new code and algorithms?
If you don’t design in UML, then what do you design in?
答案 5 :(得分：3)
编码行业中有些人认为设计就是一切，而且有些人认为编码和解决设计问题会更好。这是光谱的两个相反的端点，通常情况下是两个极端情况，答案就在中间的某个位置。
基于对要求的理解而进行的一些设计是不可避免的。要求告诉您 要构建的 ;设计告诉你 如何 来构建它。在现实世界中（或者至少根据我的经验），无论您是以正式方式进行需求/设计，主要是基于您所工作的组织，即组织是否要求遵循某个软件过程。但即使组织没有强制要求正式流程，事实仍然是您作为开发人员会做一些需求/设计，即使它没有正式化。在整个过程中的每一步，您都要决定如何向用户报告错误，显示将显示哪些度量单位等。所有这些都是在正式的要求/设计过程中会产生的因素，但即使没有，他们仍然是必须作出的决定。
我曾为那些对软件过程非常重视的组织和那些没有软件过程的组织工作过，而且说实话，我认为最终产品并没有多大区别。
就个人而言，我认为没有任何替代品质的人。也就是说，流程不是银弹。如果你有边缘程序员，那么世界上最好的流程就不会保存你的项目。
答案 6 :(得分：2)
根据我的经验，这不是一个好主意。做一些规划要好得多，但随后编写一些代码并进行迭代。
答案 7 :(得分：2)
我对这个问题的许多评论并不感到惊讶。
在acamedic生活中的全部目的是学习在学校的“思想过程”，这在现实生活中是非常重要的。
我见过很多孩子只想跳起码然后不写规格。编写清晰规范的能力为您带来了漫长的道路。它清楚地说明了已处理的内容和不处理的内容。
由于所有现代的IDE / Debug过程，事情变得更加试错 - 谷歌试用 - 现在它可能会起作用！ - 完成了吗？
虽然最初在开发系统时可能会令人毛骨悚然，但您在规范帮助的地方和编码帮助的地方会更好地理解，然后在现实生活中，您知道如何使其变得更好。
毕竟你还在上学！
祝你好运。答案 8 :(得分：2)
预先设计，例如UML模型是在编码期间经过测试并且通常被证明是错误的假设。简而言之，编码不类似于“构造”;而编码是设计。
使用简短的前期架构（战略）设计流程来识别，隔离和降低风险。但是使用有纪律的refactoring和偶尔的退火来自上而下地改进系统的设计。
答案 9 :(得分：2)
询问你的教授他们是否有过非学术性的工作。然后让他们描述他们写过的最大的系统;他们曾经参与过的最大的团队是什么;他们是否已开具发票或发货或发布系统。
如果他们从未有过非学术性的工作，或者从未编写过大型系统，或者开具发票或发货或发布，那么就会意识到，为了获得成绩，你将不得不忍受一些糟糕的事情。尽可能优雅地做到这一点。也许你所学到的只是你讨厌UML以及如何通过微笑来解决痛苦的事情。
答案 10 :(得分：2)
这些天Agile iterative development processes有更多的嗡嗡声，正在“替换”旧的“waterfall model”。
我们被告知，对比是介于较旧的，计划的第一个，写入要求，编写规范，文档，然后最后到最后..代码，模型，与“更新”的一个：敏捷。在敏捷中，系统是在与用户协商的基础上逐步开发的。一个人试图总是有一个正在运行的系统和单元测试。在要求被严重误解之前可以改变方向，并且在错误的方向上浪费了精力。
我不同意这种解释。
我并不反对敏捷，只是认为它是新的。相反，我会说敏捷是新流行的
我相信许多或大多数优秀的，有效的遗留系统都是采用渐进式，渐进式技术开发的，当时它们并没有一个久负盛名的流行语。当然，团队可以完成所有规划和指定，然后以敏捷方式进行，构建一个小的“工作”核心并将其演变为最终版本。 （虽然浪费时间，但是......）许多项目都是在官僚框架之外发展起来的。
在某些时候，增量原型成为公认的设计美甲学，这是敏捷的早期化身。我想有足够的金钱和时间，你可以构建完全倒退的东西，但我必须认为成功的开发人员从第一天开始就使用类似敏捷的模式。
瀑布模型除了没有任何乐趣之外，还有一种倾向，恕我直言，更糟你应用它越完全。遵循该模型的许多项目都遭遇了惊人的失败。一个具体问题是，它允许组织花费大量资金，绝对没有迹象表明未来的成功。在完成所有工作之后运行第一次测试的想法是今天的ROTFL时间，但想想在你进行第一次真正的测试之前，一个大型瀑布项目的成本是多少。
说了这么多，尝试它并不会让你受伤，其中一些文档技术在瀑布模型之外有价值。
答案 11 :(得分：1)
我想每个人都会给你一个不同的答案，部分原因是因为个人意见，部分是因为他们有经验......我的经验就是这样......
通常情况下，计划为“T”的项目通常与原始规格相差甚远......因为有时候您会遇到技术限制，或者因为原始设计无法实现的无法预料的情况。
我为不同公司的项目工作过，从设计到现在，再到“继续对我们想要的东西的总体看法”......我认为最有效的是两者之间的某种愉快的媒介
为客户工作，或建立一个其他人将直接消费的界面，显然一个彻底的设计将是关键。
就UML图而言，还有真实的深度规划吗？
我曾为各大公司工作过，从主要的无线运营商到主要的住宅和商业房地产公司，再到规模相当大的计费公司...我可以诚实地说我没有看到人们实际上使用任何UML图表有点成功。
我认为识别你的接触点和你的工作流程是件好事，但不是一张纸和笔不能为你做的事情。
就他可能收到的可怕的外包代码而言......你会得到你付出的代价。我并不打算做出任何类型的概括等等，但我认为即使在美国，你也可能有10：1的比例用于不称职的开发人员和能干......而且我认为比率从这里变得更大。我不认为代码问题的原因是计划
答案 12 :(得分：1)
我大多同意促进敏捷方法进行软件开发的意见。我不关心设计最复杂的解决方案，包括您从一开始就可以想象的所有情况。唐纳德·克努特有一句众所周知的说法：“过早优化是万恶之源”，所以要认真考虑:) 在开始处理某些事情时，软件开发人员最重要的一件事是完全定义要构建的内容。因此，在所有设计之前，天气开始变得简单或变得复杂，如果你不知道你最初想要建造什么，那么你很可能会得到你不想要的地方。定义解决方案的约束尤为重要。
您的问题是一种哲学问题，并在开发人员头脑中提出了许多其他问题。其他一些人已经指出你要看敏捷的开发方法，它以特定的方式处理这些问题。所以，我也建议阅读敏捷话题。
干杯，
伊万
答案 13 :(得分：1)
计划什么都不是;计划就是一切。
使用UML图表和其他单调乏味可能会迫使您面对您尝试解决的整个问题，并将其分解为可管理的块。
你应该按照班级设计来写信吗？几乎肯定不是;我从未参与过一个项目，由于一些不可预见的情况，这些项目的要求没有中途改变。但至少你要了解需要做些什么。听起来像你跟你的文档过于严格，这可能会导致问题。
答案 14 :(得分：0)
这完全取决于项目的时间和重要性之间的平衡。高风险项目将有高级别的利益相关者在编码之前要求大量设计。较小的项目可以从过度设计中获得一些自由，并且取决于开发人员，它们可以在编码和设计之间进行很好的迭代。
关键问题不在于第一次进行设计，而是在设计文档中保持最新，以及编码过程中发生的每一个决策变化。
如果一个大项目可以分解成几个比整体大局更好的小部分，那么分而治之的方法可以很好地运作。编码良好的那些较小的任务可以充当构建块或完成更大任务的api。因此，基本上采用自上而下的方法，可以进行大型任务的划分，然后以自下而上的方式完成并单独测试这些小块。答案 15 :(得分：0)
根据项目的不同，我有两个选择。
对于我希望快速完成的小型项目，我喜欢遵循http://www.extremeprogramming.org/（敏捷编程）的规则，在这些规则中，您可以“飙升”您的想法，而不是完全解决它们。
对于更严肃的项目，虽然我喜欢在开始之前绘制基本模型（UML /数据库/序列）。该模型基于之前的要求。该模型主要是为了让自己了解需要构建哪些类以及它们应该如何工作。我从来没有弄清楚这些方法，那就是实施时间。
我了解到拥有坚实的基础模型可以通过各种方式加速项目。对于其中一个，您将创建较少无用的代码，必须在之后进行修改。其次，在小组工作时，更容易解释想法并确保每个人都在朝着同一个方向思考并朝着同一个方向实施。第三件事是，当你休息一段时间或者项目规模较大时，最好先了解一下什么课做了什么：p。
答案 16 :(得分：0)
通常，您会获得一系列要求，然后开始设计架构。根据一些成本估算模型，您可以报价，如果您有业务（在您的情况下，您可以获得并且可怜的付款，： - D），那么您可以继续进行详细设计。真正的编码可以通过代码猴来完成......正确地思考和设计系统是成功的关键：满足要求并在预算范围内支付成本。
设计并不是我认为定义前后条件，即细节，而是更多地定义包并分发/拆分它们的要求。除了定义系统中的大组件以及它们如何交互之外。您必须考虑松散地将它们联系起来以提高可测试性（测试设计）等等：所以重点显然不是现实生活中大型项目中的一些前后条件......
这是我在这里关注的一种自上而下的方法，如果你得到一套要求，这通常是你必须要去的方式。
一旦项目运行，它就没有完成，出现了一些问题，其中一些问题证明了重新设计的合理性。开发过程几乎从不（在简单情况下除外）线性但是迭代过程。
架构 - 如果认为足够好 - 通常会保持相当稳定，但需要通过详细设计进行多次迭代。
答案 17 :(得分：0)
答案 18 :(得分：0)
在现实生活中，你可能没有奢侈的做精心设计，完全可以描述你将要建造什么。此外，它可能适得其反，因为该设计将在编码的第一天变老（在第二天过时）。遵循Agile方法，通过迭代构建原型和不断重新分解和细化，更加安全。在这种情况下，您（或您的团队）几乎可以立即开始编码。
有一些关于Xp和敏捷方法论的好书，例如The Art of Agile Development可以提供更好的想法
说 - 没有设计不是一个好主意。你总是需要一个计划。只是随着敏捷计划的改变“随你而去”
答案 19 :(得分：0)
我一直都是这样看待自己 - 我坐在脑海中想到了一个想法，但不清楚我想如何实现它，所以我在代码本身中勾画出潜在的实现 。这比创建UML图表以演示架构更快更容易，然后在此之后必须执行。现代的OO语言（以及可用的框架）是如此的动态和富有表现力，我们大多可以跳过中间步骤。
尽管如此，学习所有那些狡猾的设计仍然很重要。经过几次漫长而缓慢的操作后，您可以更自然地自动思考头脑中的设计，所以您仍然需要经历一个真正的设计过程，尽管您可能没有做太多的书面工作。因此，即使我描述了几个月的UML图表，我仍然感到畏缩，坚持下去，并祈祷你永远不会得到一份工作仍然在做的事情。
祝你好运！答案 20 :(得分：0)
我只是在学习如何最好地实现编码项目，规划/编码迭代或不迭代。花在计划上的时间等等。
我在网上发现了一篇很棒的文章。你可以找到它here。他经历了功能性项目计划背后的推理和思考过程。功能项目计划专注于用户的体验和与代码的交互。首先降低这一点将是设计过程中最重要的部分。一旦你完成了这个，你就可以做一个技术项目计划，它将解决如何实现用户在使用代码时将面临的每个问题的具体细节。我认为OP是正确的，他说项目计划的主要好处之一不是让他们编码。但是做了一次。因此，当您返回编写代码时，您可以参考您已经完成的工作。所以你只需要专注于编码工作。
这可能听起来像是常识，但...... 底线：写下你的项目计划，其目的和想法是你已经在完成一些/大部分工作。一半的工作是知道要编码什么。
答案 21 :(得分：0)
这取决于特定项目和特定客户。有些人需要能够可视化系统，以便能够理解它以及他们想从中获得什么。其他时候，您可能正在设计一个系统，其中客户为您提供一个英寸物品需求规格，对于质量流程必须更高的系统。此外，某些客户需要正式同意一系列要求。
在客户不清楚需求的情况下，敏捷方法更适合。通过这种方式，开发人员可以快速实现新功能并从客户那里获得反馈，从而降低交付不需要的内容的可能性。这与尝试建立一系列设定要求并仅建立合同约定的内容形成对比，只是为了提供不被客户接受的东西。
我的公司最近聘请了两位新开发人员，他们都曾在软件开发行业工作多年，但从未在一家公司工作过，这家公司需要编写书面或设计文档，或者遵循任何类型的SDLC;典型的商店，开发商被给予一张纸有一些要求，并被告知“建立这个”。一旦两人都被迫坐下来迭代地完成设计文件（更多是为了他们自己的学习而不是其他任何东西）他们都来找我说前期设计在实现他们从未考虑过的东西之前有多么有益，直到申请是很好并且真正实施（严重）。不久之后，他们开始预先编写单元测试（在实施之前），而在最初几周，发现它非常奇怪，并认为这是浪费时间，每天他们来找我并支持他们学到了多少有益的单元测试是。
直接编写实际的实现（而不是测试）是我们可能已经犯下的一个新手错误。
答案 22 :(得分：0)
我想你要我们告诉你，你的教授是错的。这里有一些弹药：http://www.developerdotstar.com/mag/articles/reeves_design_main.html我还没有发现，如果里夫斯是100％正确的，但到目前为止。
答案 23 :(得分：0)
在自上而下的方法中，通常被称为“瀑布模型”，在长期的基本设计阶段，事情并不是很有趣。
如果你的原型有效，那么无论花费多少时间，设计都会更好。因此，控制好奇心并完成设计。
答案 24 :(得分：0)
可能与您的情况最相关：考虑到一些大项目难以从小开始。你应该尽可能小，但通常剃刀不会剪得足够精细;虽然可能很糟糕，但你的项目可能是为了让全班同学走完基本步骤。
在编码之前花费的设计时间总是很有可能得到充分利用 - 但前提是你知道如何花好时间！正如您所注意到的那样，过度工程化，早期制作糟糕的设计系统等等都非常容易。只需记下您当前的项目经验 - 当您进行实际项目时，您将知道要避免哪些设计缺陷！
原型制作也有很大的潜力，可以节省时间 - 但是只有你有机会抛弃原型并从头开始，从经验中学习。如果你曾经不得不与sendmail争吵，你就会知道处理软件的痛苦，这些软件从一个小项目发展成一个可怕的怪物而没有重新开始......
最后，请注意那里有各种各样的方法;无论好坏，作为一个软件人，你可能需要处理它们中的任何一个。他们中的大多数都可以以一种合理有用的方式工作，所以即使某个特定的实例功能失调，你也不应该让这种毒药再次成为方法论。
答案 25 :(得分：0)
您不需要进行任何设计工作，除非您希望生产将由您以外的人使用和享受的软件产品。
在不了解潜在用户的目标的情况下创建一个体面的软件产品是非常困难的（如果不是不可能的话）。没有研究就无法理解用户的目标，如果没有设计，就无法进行研究。
答案 26 :(得分：0)
学术教师从未做过真实世界的项目:)。他们对这种瀑布精神负有责任。此外，尽管Visual Studio 2010 Ultimate即将推出，但UML Tools并不方便。