程序员必读之软件架构
上QQ阅读APP看书,第一时间看更新

第18章 每个人都是架构师,除非他们有其他身份

很多软件团队都朝着敏捷和自组织努力,在这种对现代软件开发团队的描述中,软件架构角色如何融入并不是显而易见的。

每个人都是架构师

Extreme Programming Annealedhttp://www.vanderburg.org/Writing/xpannealed.pdf中,格伦·范德堡(Glenn Vanderburg)讨论了极限编程实践适用的层次,他强调了架构和集体所有制之间的联系。当我们谈论集体所有制http://www.extremeprogramming.org/rules/collective.html时,通常指的是集体拥有代码,以便团队中任何人都有权做出改动。这种方式奏效暗示团队中每个人至少都对“大局”有一些基本的了解。想想你目前的项目,跳转到代码库的任何一部分,你都明白发生了什么吗?

想象一下,如果你有一队经验丰富、能够在大局内外自如切换的软件开发者,一队真正会动手的架构师,这样的团队太棒了,所有通常会跟软件架构联系起来的元素(非功能需求、约束,等等)都会得到解决,不会漏掉任何一样。从技术的角度来看,这就是一个自组织的团队。

除非他们有其他身份

对自组织团队的想法,我有一个大问题,我们在行业中谈论了很多,但很少看到实践。这可能是在咨询的环境中工作的副作用,因为我的团队总是随着项目而变化,而且我不太可能跟某一个客户在一起超过几个月。或者,我怀疑,真正的自组织团队非常少。把自组织作为努力方向是值得尊敬的,但对很多软件团队而言,这就像是还没学会走就想跑了。

在“Notes to a software team leader”http://leanpub.com/teamleader中,罗伊·奥谢洛夫(Roy Osherove)描述了他的“弹性领导”概念,这种领导风格需要根据团队的成熟度有所变化。罗伊用一个简单的模型对团队成熟度做了分类,每个等级需要不同的领导风格。

(1) 生存型(混乱):需要一种直接指挥和控制的领导风格。

(2) 学习型:需要一种指导的领导风格。

(3) 自组织型:需要简易化来确保平衡不受影响。

就像我说的,团队里每个人都是经验丰富的软件开发者和架构师,那就太棒了,但我还没见过这样的团队。大多数项目的团队连一个对“大局”之类的东西有经验的人都没有,一团乱的代码库、不明确的设计、很慢的系统,类似这些都是明证。从技术角度来看,这种情况最为多见,我建议团队中由一个人来承担软件架构角色的责任。

罗伊举了流程经理角色的例子。在成熟的初始阶段,一个人承担流程经理的角色来帮助团队向正确方向前进,这将使团队受益。另一方面,自组织团队不需要别人告诉他们做什么。名字就是线索;从定义上,他们是自组织的,可以自己承担这个角色。我想说,软件架构的角色是同样的,因此技术领导的角色也是。

敏捷需要架构吗

可惜,许多团队把“大局”上的技术技能看作一种不必要的邪恶,而不是重要的补充,可能是因为他们过去深受大型预先设计之害。有些人也过于渴望“敏捷”,以至于忽略软件开发流程的其他方面。接踵而至的是混乱而非自组织,这样的团队也面临着需要更直接的领导方式的挑战。毕竟,他们在努力变得敏捷。单个点负责项目的技术层面,也跟他们对敏捷团队的想象相冲突。这种冲突使人认为敏捷和架构是对立的:你只能拥有其中一个。与敏捷对立的不是架构,而是大型预先设计。

敏捷软件项目仍然需要架构,因为那些围绕复杂非功能需求和约束的棘手问题不会消失,只是对架构角色的执行不同。

集体代码所有制,每个人都要能在架构的层次上工作,因此每个人某种程度上都是架构师。还不是自组织阶段的团队如果试图跑太快,就会陷入挣扎。尽管人们的愿望是变得敏捷,集体代码所有制和架构角色的分配都有可能阻碍混乱的团队,而不是帮助他们。混乱的团队需要更直接的领导方式,单个点负责软件项目的技术层面,将使他们受益。换句话说,他们会受益于一个人负责软件架构的角色。理想的话,这个人会指导别人,让他们也能以这个角色产生帮助。

软件架构师要一个还是多个?一个人承担责任还是团队共同分担?不论敏捷与否,软件架构的角色都是存在的。只有所处语境会告诉你正确的答案。