敏捷思维: 架构设计中的方法学

十分精辟。。敬佩之，学习之。

 

https://www.ibm.com/developerworks/cn/linux/software_engineering/Methodology/part1/

....

https://www.ibm.com/developerworks/cn/linux/software_engineering/Methodology/partn /

 

将上面的红粗体的n换成想要看的章节，比如上面的1，就是要看章节的url地址。

 

 

 

精辟语录照抄如下：

 

1：

2：

架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。架构是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解，然后我们 还要能够熟练的应用技术来实现现实世界到模型的映射。因此，我们在对业务或技术理解不够深入的情况下，就很难设计出好的架构。当然，这时候我们发现一个问 题：怎样才能算是理解足够深入呢。我认为这没有一个绝对的准则。

 

3：

软件中的各种需求：功能需求、非功能需求、变化案例 等等。

一般来说，功能需求决定业务架构、非功能需求决定技术架构，变化案例决定架构的范围。需求方面的知识告诉我们，功能需求定义了软件能够 做些什么。我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的 技术架构要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个 架构的范围。

 

其实还有一个很重要的需求，就是环境的需求 。这并不是一个很重要的需求，但是对于部署（deployment）架构设计来说就特别重要。毕竟，我们开发出的软件是要上"战场"的，充分的考虑部署问题是非常有必要的。

 

在敏捷方法论中，需求最好是迭代进行的，也就是说一点一点的作需求。这种做法在那些需求变化快的项目中尤其适用。由于我们采用的流程是一种迭代式的流程， 这里我们将会面临着如何对待上一次迭代的中间产物的问题。如果我们每一次迭代都需要修改已存在的中间产物，那么这种维护的成本未免过大。因此，敏捷方法论 的基本做法是，扔掉那些已经没有用处的中间产物。还记得在第一章的时候，我们强调说软件要比文档重要。我们生成中间产物的目的都是为了生成最终的程序，对 于这些已经完成作用的模型，没有必要付出额外的维护成本 。