敏捷思惟－架构设计中的方法学（4）
团队设计是敏捷方法论中很重要的一项实践。咱们这里说的团队，指的并非复数的人。一群人就是一群人，并无办法构成团队。要想成为团队，有不少的工做要作。
咱们之因此考虑以团队为单位来考虑架构设计，是由于软件开发自己就不是一件我的的事情，架构设计更是如此。单我的的思惟难免有考虑欠妥之处，单我的的学识也不可能覆盖全部的学科。而组织有效的团队却可以弥补这些缺憾。
Context
谁来负责架构的设计？
Problem
在咱们的印象中，总认为架构设计是那些所谓架构设计师的专属工做，他们每每拥有丰富的设计经验和相关的技能，他们不用编写代码，就可以设计出理论上尽善尽美的架构，配有精美的图例。
问题1：理论上设计近乎完美的架构缺少程序的证实，在实际应用中每每会出这样那样的问题。
问题2：设计师设计架构带有很大的主观性，每每会忽视客户的需求，致使架构没法知足需求。
问题3：实现的程序员对这种架构有抵触的情绪，或是由于不理解架构而致使架构实现的失败。
问题4：架构师设计架构主要是依据本身的大量经验，设计出的架构不能真实的反映目前的软件须要。
Solution
团队设计的理论依据是群体决策。和我的决策相比，群体决策的最大好处就是其结论要更加的完整。而群体决策虽然有其优势，但其缺点也是很明显的：须要额外付出沟通成本、决策效率低、责任不明确、等等。可是群体决策若是可以组织得当的话，是可以在架构设计中发挥很大的优点的。
避免象牙塔式的架构设计
对软件来讲，架构设计是一项相当重要的工做。这样的工做交给某我的是很是危险的。即使这我的再怎么聪明，他也可能会遗漏部分的细节。组织有效的团队的力量是大大超过我的的力量的，所以团队的成果较之我的的成果，在稳定性和思考的周密程度上，都要更胜一筹。
Scott W. Ambler在其著做中给出了象牙塔式架构（ivory tower architecture）的概念：
An ivory tower architecture is one that is often developed by an architect or architectural team in relative isolation to the day-to-day development activities of your project team(s).
中国如今的软件开发行业中也逐渐出现了象牙塔式的架构设计师。这些架构师并不参与实际的程序编写，他的工做就是为项目制做出精美的架构模型，这种架构模型在理论上是至关完美的。
例1：在XP中，咱们基本上看不到架构设计的影子。并非说采用XP技术的团队就不须要架构设计。XP不存在专门的设计时期，它提倡使用一些简单的图例、比喻的方式来表达软件的架构，而这种的架构设计是无时无刻不在进行的。其实，XP中的设计采用的就是团队设计的方式，结队编程（Pair Programming）和代码的集体全部制（Collective Ownership）是团队设计的基础，也就是基于口述的沟通方式。经过采用这样的方式，XP几乎不须要文档来表达架构的设计。
优秀的架构师可以充分的利用现有框架，减小软件的投入，加强软件的稳定性。这些都没有错，可是问题在于“过犹不及”。象牙塔式架构师每每会出现文章开始指出的那些问题。架构设计其实并非很是复杂的工做，但它要求开发人员具有相关的技能、经验以及对问题域有必定的了解。开发人员每每都具备相关的技术技能（编程、数据库设计、建模），而对问题域的理解能够从用户和行业专家那里得到帮助。所以，在理论上，咱们要实现架构设计的团队化是彻底可能的。
在上面的象牙塔式架构定义中，咱们看到架构师和平常的开发工做是隔绝的。这样的设计出的架构有很大的局限性。在现实中，咱们还会发现另一种角色，他来自于开发团队外部，为开发人员提供相关的技术或业务的培训。这种角色称为教练，在软件开发中是很是重要的角色，不可以和象牙塔式架构设计师之间画等号。
选择你的设计团队。
软件的架构在软件的生命周期的全过程当中都很重要，也就是说，软件开发团队中的全部人员都须要和架构打交道。所以，最好的团队组织方式是全部开发人员都参与架构的设计，咱们称这种方式为全员参与。全员参与的方式保证了全部开发人员都可以对架构设计提出本身的看法，综合多方面的意见，在全体开发人员中达成一致。这种方式尤为适合于一些小的团队。
仍是会有不少的团队因为种种的缘由不适合采用全员参与的方式。那么，组织优秀的开发人员组成设计组也是比较好的方式。通常，咱们选择那些在项目中比较重要的，有较多开发经验，或是理论扎实的那些人来组成设计组。固然，若是你考虑到为组织培养后续力量，你也可让一些新手加入设计组，或是你以为本身的开发力量不足，邀请外部的咨询力量介入，这彻底取决于具体的状况。
设计组不一样于咱们以前提到的象牙塔式架构设计师。设计组设计出来的架构只能称为原始架构，它是须要不断的反馈和改进的。所以，在架构实现中，设计组的成员将会分布到开发团队的各个领域，把架构的思想带给全部开发人员，编写代码来检验架构，并得到具体的反馈，而后全部的成员再集中到设计组中讨论架构的演进。
团队设计中存在的问题
在团队设计的过程，咱们会遇到各类各样的问题，首当其冲的就是沟通成本的问题。架构设计时，需求还没有被充分理解，软件的设计思路还处于萌发的状态。这样的状况下，团队的每位成员对软件都有独特的看法，这些可能有些是相同的，有些是互斥的。就比如盲人摸象同样，他们的观点都表明了软件的一部分或是一方面，可是没有办法表明软件的所有。
在敏捷方法论中，咱们的每个流程都是迅速进行、不断改进的。架构设计也是同样，咱们不可能在一次架构设计上花费更多的时间。而团队决策老是倾向于较长的讨论和权衡。
例2中的问题在架构设计中时有发生，纯技术的讨论很容易上升称为争吵。这种状况几乎没有办法彻底避免。团队型的决策必然会发生观念的冲突。控制必定程度内的观念的冲突对团队的决策是有益，可是若是超出了这个程度就意味着失控了，须要团队领导者的调节。而更重要的，咱们须要注意沟通的技巧：
团队沟通
团队进行架构设计的时候沟通是一个很是须要注意的问题，上述的情境在软件组织中是常常发生的，由于技术人员很天然认为本身的技术比别人的好，若是本身的技术受到质疑，那怕对方是抱着讨论的态度，也无异于自身的权威受到了挑战，面子是不管如何都须要捍卫的。而沟通若是带上了这样一层主观色彩，那么沟通讯息的受众就会潜意识的拒绝接受信息。相反，他会找出对方话语中的漏洞，准备进行反击。所以，咱们要注意培养一种良好的沟通氛围。
在实际的观察中，我发现团队沟通中存在两种角色，一种是建议者，他们常常可以提出建议。一种是质疑者，他们对建议提出否认性的见解。这两种角色是可能互换的，如今的建议者可能就是刚才的质疑者。质疑者的发言是很能打击建议者的积极性的，而在一个脑力激荡的会议中，最好是你们都可以扮演建议者的角色，这就要求沟通会议的主持者可以掌握好这一点，对建议给予确定的评价，并鼓励你们提出新的建议。
例2：敏捷方法很是注重的就是团队的沟通。沟通是一个颇有意思的话题，讲起来会花费大量的时间，咱们这里只是针对架构设计中可能存在的沟通问题作一个简单的讨论。咱们这里假设一个讨论情境，这个情境来源于真实的生活：
项目主管徐辉、设计师李浩、设计师罗亦明正在讨论一个新的软件架构。
"李浩你认为这个软件数据库链接部分应该如何考虑？"徐辉问。
李浩想了想，"我以为方案A不错…" "方案A确定有问题！这个软件和上一次的又不一样。"罗亦明打断了李浩的发言。
"你懂什么！你到公司才多久，方案A是通过很长时间的证实的！"发言被打断，李浩有点恼火，罗亦明进入公司没有多久，但在一些事情上总是和他唱反调。
"我进公司多久和方案A的错误有什么关系！"
在这样一种氛围中，会议的结果可想而知。
良好的沟通有助于架构设计工做的开展。一个成员的能力平平的团队，能够藉由良好的沟通，设计出优秀的架构，而一个拥有一个优秀成员的团队，若是缺少沟通，最后可能连设计都出不来。这种例子现实中能够找到不少。
标准和风格
咱们老是在不知不觉之中使用各类各样的标准和风格。在团队设计中，咱们为了提升决策的效率，能够考虑使用统一的标准和风格。统一的标准和风格并非一朝一夕造成的。由于每一个人都有本身不一样的习惯和经历，强制性的要求开发人员使用统一的标准（风格）容易引发开发人员的不满。所以在操做上须要注意技巧。对架构设计而言，比较重要的标准（风格）包括如下的这些类别：
·界面设计
·流程设计
·建模规范
·编码规范
·持久层设计
·测试数据
在个人经验中，有一些组织平时并不注意标准（风格）的积累，认为这种积累属于雕虫小技，但正是这些小技，可以很是有效的提升沟通的效率和下降开发人员的学习曲线。试想一下，若是一个团队中全部人写出的代码都是不一样标准和风格的，那么理解起来确定会困难许多。固然，咱们没有必要本身开发一套标准（风格）出来，现实中有不少能够直接借用的资料。最好的标准是UML语言，咱们能够从UML的官方网站下载到最新的规范，经常使用的编码标准更是随处可见。不过虽然有了统一的标准，若是风格不统一，一样会形成沟通的障碍。例以下图显示的类图，虽然它们表示的是同一个类，可是因为版型、可视性、详细程度的差异，看起来又很大的差异。而在其它的标准中，这种差异也是广泛存在的。所以，咱们在使用了统一的标准以后，还应该使用一样的风格。Scott W. Ambler专门成立了一个网站讨论UML的建模风格的相关问题，有兴趣的读者能够作额外的阅读。
图 4. 两种风格的类图
在统一的风格的基础上更进一步的是使用术语。使用沟通双方都了解专门的术语，能够表明大量的信息。最好的术语的范例就是设计模式的模式名。若是沟通的双方都了解设计模式，那么一方只须要说这部分的设计可使用工厂模式，另外一方就可以理解，而不用再详细的解释设计的思路。这种的沟通方式是最高效的，但它所须要的学习曲线也会比较陡。
团队设计的四明确
为了最大程度的提升团队设计的高效性，能够从4个方面来考虑：
一、明确目标
泛泛的召开架构讨论会议是没有什么意义的，一个没有鲜明主题的会议也不会有什么结果。在源自需求的模式中，咱们谈到说能够有非功能需求的架构，能够有功能需求的架构。所以，在进行团队设计以前，咱们首先也须要肯定，这次要解决什么问题，是讨论业务逻辑的架构，仍是技术架构；是全局性的架构，仍是各模块的架构。
二、明确分工
咱们之因此重视团队，很重要的额一个缘由就是不一样的成员有不一样的擅长的区域。有些成员可能擅长于业务逻辑的建模，有的擅长于原型设计，有的擅长于数据库设计，有的则擅长于Web编程。你可以想象一个软件没有界面吗？（有些软件多是这种状况）你可以想象一个软件只有数据库，而没有处理逻辑吗？所以，架构设计就须要综合的考虑各个方面，充分利用成员的优点。这就要求团队的各个成员都可以明确本身的分工。
三、明确责权
除了明确本身的分工，每位成员都须要清楚本身的责任。没有责任，分工就不会有任何的效力。每位成员都须要明确本身要作些什么。固然，和责任相对的，没有成员还须要知道本身的权力是什么。这些清楚了，进行高效的沟通的前提就具有了。每次架构的讨论下来，每一个人都清楚，本身要作些什么，本身须要要求其余人作些什么，本身该对谁负责。若是这些问题回答不了，那此次的讨论就白费了。
四、明确沟通方式
这里使用沟通方式可能有一点点不恰当，为了明确的表达意思，你们能够考虑信息流这个词。一个完整架构包括几个方面，分别都由那些人负责，如何产生，产生的整个过程应该是什么样的？这样的一个信息流程，囊括了上面提到的三个明确。若是团队的每个人都可以为架构的产生而努力，并顺利的设计出架构，那么这样的流程是完美的。若是你发现其中的一些人不知道作些什么，那么，这就是流程出问题的现象了。完美的流程还会有一个额外的副产品，架构产生以后，团队对于软件的设计已是很是的清晰了。由于咱们提倡的是尽量多的开发人员参与架构的设计。
不只仅是架构 讨论到这里，其实有不少的内容已经脱离了架构设计了。也就是说，不少的原则和技巧都是能够用于软件开发的其它活动的。至于哪一些活动可以利用这些方法呢？你们能够结合本身的实际状况，来思考这个问题。提示一点，关键的入手处在于目前效率较低之处。