谁害怕紧急设计?

轻量级软件开发方法的一个标志是概念紧急设计．其思想是，当我们以小的增量构建代码时，解决方案的设计将逐渐出现，通常使用测试驱动的开发和非常短的红绿重构周期。

当一切顺利时，我们避免了许多问题。我们不会创建一个全面的设计，也不会编写一大堆只会让我们陷入难以爬出来的兔子洞的代码。我们不会因为我们天生的创造力而忘乎所以，也不会过度设计超出客户想要支付的价格。我们不会因为在最初的设计理念上投入太多太快而最终得到一个次优的架构。

原则上这是一个非常简单的想法。这在实践中也并不难;我可以保证，与旧的构建应用程序的方式相比，它大大减少了工作的压力，使工作更加愉快。

然而...

你试过把两块磁铁的北极推到一起吗?磁铁靠得很近，然后就分开了。每次它们分开，都是在不同的方向上。

当与开发商谁是不习惯紧急设计工作，我有时会得到同样的感觉。他们似乎理解这个概念，而且他们似乎非常接近这样做获得，然后从他们溜走。

为什么有这么多困难?俗话说，细节决定成败。

哪来的安全网？

如果你一直从全面，详细设计说明书的工作，然后开始与任何代码小于是会感到非常不舒服。如果你忘记一些重要的事情是什么？你怎么能肯定出现会有什么好的设计？由于缺乏详细的设计规范，你怎么会知道一个推荐码变化是否会影响解决方案的其他部分？

感觉就像你从一块浮冰跳到另一块浮冰，穿越一条半结冰的河。设计文档是你修改代码的安全网。现在,你应该怎么做?

事实上,你do有一个安全网，它比任何设计文档更值得信赖。请记住，我们使用一个被称为用于紧急设计测试驱动开发的技术。这些可执行测试用例准确和完整地描述在溶液中的码的每个单元的低级别的行为。他们总是最新的关于生产代码，但还是很少但是很大一部分有在任何一天。驾驶所有新功能，每次修改，并从测试每错误修复让你从错误中高程度的保护。

当然，没有什么是万无一失的，就像我们在工作中做的其他事情一样，测试驱动开发是一种需要实践的学习技能。但这对你来说并不新鲜。毕竟，你不是出生知道所有你知道如何做的事情。你必须学习他们。所有它们。这只是最后一件事。而且，它比您多年来学到的关于软件开发的大多数其他事情都要简单。(看到了吗?我告诉你的压力更小!)

刚开始的设计就足够了

刚开始学习紧急设计的开发人员一开始往往会有某种误解。他们认为“紧急设计”意味着“根本没有设计”。您只需打开您最喜欢的编辑器并开始输入即可。这并不完全正确。

有一个古老的咒语(我认为)来自功能驱动开发社区多年前:刚刚足够的设计最初(JEDI)。采取紧急方法进行解决方案设计，绝地是我们的起点。两者之间有很大的差距全面、详细的前期设计和完全没有设计．这是义不容辞的责任我们作为专业人士能够做出什么地方，在所有该领土，我们应该开始任何项目的判断。它并不总是在同一地点。

好吧，如果绝地武士在不同的情况下意味着不同的东西，那么我们要如何学会对它做出判断呢?坏消息是没有硬性规定。好消息是没有硬性规定。我们可以运用我们的智慧、创造力、训练和经验，我们可以和其他聪明、有创造力的人合作，而不仅仅是按照别人的规格编码。我告诉你会更愉快!)

建筑设计还是应用设计?

我发现区分架构设计和应用程序设计是很有用的。大多数时候，当我们编写一个新的应用程序时，我们并没有同时发明支持它的体系结构。该体系结构就像可以挂起应用程序的脚手架。然而，许多人认为必须从设计解决方案的体系结构开始每个项目。

只要我们的应用是已存在事物类型的新实例，我们不需要从建筑设计开始工作。与我们的新应用程序相关的体系结构(如果不是几个的话)已经有了。“刚刚好”的预先设计可能并不多。

有时候，如果幸运的话，我们可以建造一个这是一种全新的东西．有上把它挂任何现有的架构。我n this case, “just enough” up-front design amounts to more than in the first case…but you still might not do a comprehensive design up front, as there’s value in emerging the architectural design, as well, once you get to a good starting point.

当我们构建一个应用程序时，我们不必完全从头开始。可以使用参考体系结构、设计模式、库、代码生成器和其他资源来节省我们的时间和精力。亚傅体育app你不需要设计一个架构来支持一个新的web应用程序。你可以从模型2或MVC、层次结构和单页架构模式中选择。你不需要从头开始设计响应式web应用;你可以选择一个已经内置响应式设计的web应用框架。您不需要为大型机批处理过程设计一个体系结构，该过程通宵处理顺序文件。您已经知道它必须包含提取、排序/合并、编辑、更新和报告步骤的子集。这些是众所周知的类型一旦你看过一两个例子，你就再也不需要从头开始重新设计了。

这里的基本建议是:不要白费力气。

你过去的经验作为计数的前期设计，为您的下一个项目

我不记得在那里我第一次读到或听到他说。我没有做它，但我喜欢它。新应用程序并不等同于任何现有的应用程序。毕竟，如果它是，那么你就根本不需要写了。但与此同时，新的应用程序可能与您过去做过的其他工作没有太大不同。

你真的需要重新绘制所有你过去的那些项目，提请设计图？我会打赌你没有。你只是在检查任务清单中的框：“画设计图。”我敢打赌，如果你画这些图，你从来不看他们一次。毕竟，你没有你拉他们过去的25倍，现在是吗？来吧，“干完了！

不要做任何故意的愚蠢

这是我最喜欢的俗语中的另一个。它已经普遍工程师们数十年。标牌挂实验室承载那些鼓舞人心的话语的墙壁上。所有这些软件设计原则的人喜欢我们总是喋喋不休大约可以从单一衍生你原则:不要故意做傻事。

有时，当开发人员首先尝试应用紧急设计的想法，他们很严格遵循（故意）-incomplete和-lightweight规格的信。也就是说，他们不做任何没有明确指定的事情。

这违反了你原则。你知道您的应用程序必须优雅地处理异常。你知道它必须支持日志记录。你知道它（可能）有支持国际化，普及，以及大多数或所有应用程序必须做其他事情的主机。你真的需要有人为你写的东西下来，每一次？你知道该怎么做。

那么，谁会害怕紧急设计呢?不是你。