html浮现_设计不会从代码中浮现

html浮现

我知道很多人正在过渡到敏捷或已经遵循敏捷开发方法。 几乎所有人都使用了以Scrum为核心的内容 ，并结合了常见的XP实践（例如持续集成，重构和自动化单元测试）–迈克·科恩（Mike Cohn）认为应该在他的《 成功与敏捷》一书中提到。

Scrum和XP中的紧急设计

但是他们都不像Cohn所描述的那样进行紧急设计 ，或者像Kent Beck解释的那样在极限编程中完成设计 ：试图在没有任何前期设计和架构工作的情况下逃脱，立即编写功能并依赖

测试优先的开发 ， 重构和技术峰值 ，可以一次或两个星期动态地设计出一个设计。
“对于第一次迭代，请选择一组简单的基本故事，您期望这些故事会迫使您创建整个体系结构。 然后缩小视野，以可能可行的最简单方式实施故事。 在本练习的最后，您将拥有自己的体系结构。 可能不是您期望的架构，但是您将学到一些东西。”

肯特·贝克

您不需要预先的架构和设计吗？

也许是因为我认识的每个人都在大规模工作–构建大型企业系统和许多客户使用的在线系统，这些系统具有很多约束和依赖性。 他们中的许多人正在棕地项目中工作，在这些项目中 ，您需要先了解现有系统的设计和实现，然后才能提出新的设计和进行任何更改。 在高度管制的环境中对性能至关重要，对任务至关重要的系统。

紧急的增量设计不适用于这些情况。 而且它不能扩展到大型项目或必须与其他项目一起交付的，指定了集成点和依赖关系的任何项目，这几乎是我从事过的每个项目。 另一位帮助定义如何进行敏捷开发的人鲍勃·马丁（Bob Martin） 认为，这种渐进式设计方法很好 ……

“敏捷开发的一个更加隐蔽和持久的神话之一是，前端架构和设计是糟糕的； 永远不要花时间在做架构决策上。 取而代之的是，您应该从无到有地发展您的架构和设计，一次只需要一个测试用例。 请原谅，但这就是马屎。”

马丁接着说：

“存在一些架构问题需要预先解决。 有些设计决策必须尽早做出。 有可能将自己编码为一个非常讨厌的死胡同，您可以稍加深思熟虑就避免。”

纪律敏捷交付中的体系结构和设计

Scott Ambler在“有纪律的敏捷交付”中对我认识的大多数人进行敏捷开发的方式进行了更好的描述，该模型是将敏捷扩展到更大的系统，项目和组织的模型。 正如Ambler的研究表明， 几乎所有团队（86％）至少花了一些时间（平均一个月或更长时间）进行规划，范围界定和架构构想，这就是他所说的“初始阶段” （借用Rational的统一过程 ）或其他大多数人所说的“ Sprint 0”或“ Iteration 0 ”。

这段时间至少要花时间来理解系统的范围，以及项目需要在其中工作的约束和依赖关系。 是时候对系统的主要部分及其接口进行建模，并选择一个技术指导作为开始了。

前期的建筑和设计工作不需要花费很多时间 。 正如Ambler所指出的，对于许多团队（除了一些初创公司而言），已经为您做出了许多架构决策：

“实际上，您可能不需要做太多的初始体系结构建模：大多数项目团队都可以处理几年前做出的技术体系结构决策。 您的组织很可能已经选择了网络基础结构，应用程序服务器平台，数据库平台等。 在这种情况下，您的团队将需要花费时间来理解这些决定，并考虑现有基础架构的扩充是否足够（如果不能，则确定潜在的改进）。”

当您拥有一个真正的未开发项目时，没有任何东西可以利用，而您正在做一些全新的事情时，您应该花更多的时间进行前瞻性的设计思考，而不是花更少的时间。

如果没有紧急设计，您可以“敏捷”吗？

当然可以。 鲍勃·马丁（Bob Martin）指出，“敏捷开发”中没有任何内容表明您不应该进行先期设计-对于要构建的系统大小和所使用的环境，需要进行尽可能多的设计。

您可以并且应该进行迭代的渐进式设计和开发，从计划您的去向以及您认为如何到达那里开始。 在逐步验证设计并响应反馈并处理需求变更时，这才是增量设计真正发挥作用的地方-处理方向变化，填补空白，纠正误解。 设计将发生变化，并且可能变成您没有想到的东西。 但是您需要一个起点，而设计不仅仅来自代码。

参考： Building Real Software博客上的JCG合作伙伴 Jim Bird的《代码不会出现设计》 。

翻译自: https://www.javacodegeeks.com/2013/01/design-doesnt-emerge-from-code.html

html浮现