敏捷思维-_架构设计中的方法学..doc

敏捷思维－ 架构设计中的方法学目录 1．从方法论看架构设计 2 2．架构设计的敏捷视图 7 3．源自需求 13 4．团队设计 18 5．简单设计 24 6．迭代设计 29 7．组合使用模式 36 8．架构愿景 41 9．分层 (上) 45 10．分层 (下) 53 11．精化和合并 60 12．Refactoring 66 13．稳定化 71 14．代码验证 75 15．进一步阅读 80  1．从方法论看架构设计方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。 在第一篇文章中，我们来了解标题中的一些词的含义。 方法学是什么？ 敏捷是什么？ 为什么讨论架构？ 方法论方法论的英文为Methodology，词典中的解释为A series of related methods or techniques我们可以把它定义为软件开发（针对软件开发）的一整套方法、过程、规则、实践、技术。关于方法论的出现的问题，我很赞同Alistair Cockburn的一句话，方法论源于恐惧。出于对项目的超期、成本失控等等因素的恐惧，项目经理们从以前的经验出发，制定出了一些控制、监测项目的方法、技巧。这就是方法论产生的原因。 在Agile Software Development一书中，作者提到了方法论的十三个要素，基本能够函盖方法论的各个方面： 角色（Roles） 个性（Personality） 技能（Skills） 团队（Teams） 技术（Techniques） 活动（Activities） 过程（Process） 工件（Work products） 里程碑（Milestones） 标准（Standards） 质量（Quality） 工具（Tools） 团队价值（Team Values） 它们之间的关系可以用一幅图来表示： 图 1. 方法论的十三个要素 很多的方法论，都涉及了上面列举的十三要素中的部分要素，因此，我们可以把方法论看作是一个抽象的、无穷的超集，而现实中的方法论都是指超集的一个有限的子集而已。它们之间的关系就好像有理数和1到100之间的整数的关系一样。不论是XP，还是UI设计经验之类，都属于方法论的一个子集，只是这两个子集之间有大小的差别而已。我们还应该看到，讨论一个完备的方法论是没有意义的，因此这种方法论铁定不存在，就好像你视图穷举出所有的有理数一样荒唐。因此，我们关于一个通用的方法论的说法也是无意义的。好的方法论，比如说XP、水晶系列，它们都有一个适合的范围，因为它们了解一点，自己并不是一个无所不能的方法论。 在现实中，我们其实不断的在接触方法论。比如说，为了控制项目的进度，项目经理要求所有的开发人员每周递交一份详细的进度报告，这就是一种方法、一种技巧。如果把开发过程中的这些技巧系统的组织起来，就能够成为一种方法论。你可能会说，那一种方法论的产生也太容易了吧。不，这样产生的方法论并没有太大的实用价值，没有实用价值的方法论根本就没有存在的必要。因此，一个成功的方法论是要能够为多个的项目所接受，并且能够成功实现软件的交付的方法论。 我和我的同事在实践中做了一些试验，希望能够把一些好的方法论应用于开发团队。试验的结果很无奈，方法论实施的效果并不理想，一开始我们认为是方法本身的原因，到后来，我们发现事情并不是这么简单。在试验的过程中，开发人员一致认同方法论的优势所在，但是在实施过程中，鲜有坚持的下来的。在Agile Software Development中，我发现作者遇到了和我们一样的问题。 Alistair Cockburn在和大量的项目团队的访谈之后，写成了Agile Software Development一书。在访谈之前，他笃定自己将会发现高度精确的过程控制是成功的关键所在，结果他发现事实并非如此，他把他的发现归结为7条定律。而我在实际中的发现也包含在这七条定律中，总结起来就只有两点：沟通和反馈。 只要能够保证良好的沟通和即时的反馈，那么开发团队即使并没有采用先进的方法论，一样可以成功。相反，那些高质量的团队却往往由于缺乏这两个因素而导致失败（我们这里指的失败是用户拒绝使用最终的软件）。最有效，而成本也最低的沟通方法就是面对面（face to face）的沟通，而随着项目团队的变大，或是另外一些影响因素的加入（比如地理位置的隔绝），面对面的沟通越来越难实现，这导致沟通的的成本逐渐加大，质量也慢慢下降。但这并不是说非面对面的沟通不可，重要的是我们需要知道不同的沟通方式的成本和质量并不相同。XP方法尤为强调面对面的沟通，通过现场客户、站立会议、结对编程等方式来保证沟通的有效。在我的经验中，一个开发团队