大道至易:实践者的思想(txt+pdf+epub+mobi电子书下载)


发布时间:2020-06-22 13:19:02

点击下载

作者:周爱民

出版社:人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

大道至易:实践者的思想

大道至易:实践者的思想试读:

前言

易是变化

台湾的高焕堂先生曾说架构的要旨是“以序容易”,我解释成“用规则来包容变化”,高老师说很合他的本意。这里的“易”,指的就是变化。既是变化,那当然是艰难而复杂的了。然而我们通常说一件事易做或另一件事不易做,这里的“易”却都是指简单的意思。所以“易”既是无穷的复杂,也是至极的简单,关键在于如何“容”它。

我们得看清什么是变化。

盲人摸象是一个很好的故事,因为每一个盲人的认识都是其固见的、自见的,以及自证的真理。然而盲人们的观点放在一起的时候,却是一个笑话。因为看笑话的人看到了“变化”,而这些局外者原本认为那头大象是不变的、确定的、唯只一个形象的。同样,面对任何我们所见的变化,或对变化中的任何一个认识,我们都认为那不过是笑话。再深彻地透视这一点,其根本在于:我们也有一个对大象的“认识”,只因为这一认识看起来——或我们认为——比那些盲人更为高明、正确,所以我们才别出了盲人,看到了笑话。

正是我们对一个事物固有的认识,制造了盲人与盲人的笑话。

倘若我们的认识是不可易变的,那么我们今天就已经看到了真理,看透了世事万象,我们已成至人,故而我们不需要存在亦无需进化:一切于我们而言,必须静止;一切于我们的认识而言,不可复加;一切于我们的思维而言,不可偏侧。而这,看起来不正是我们自盲了双目,自演了笑话吗?

反过来,我们得承认变化的存在。我们所要做的,只是承认自己是一个盲人,可以从一个方面去触及这一事物,形成一个认识,用一些规则、规格或概念去确指它。用同样的方法,我们触及这个事物的方方面面,进而得到与这个事物最为接近的一个全像,这就是我们关于这一事物所有的、而又未尽的知识。

知音变而得律,有容则易。简也不是简单

这本书是《大道至简》(以下称“《简》”)的续作,那我又是怎么认识《简》的呢?究我们的认识的根底来说,我们向来不是缺乏思考的。我们有着种种在实践中的选择,这些选择是基于一些认识的,而又产生了一些新的认识。而我所有的醒觉,并不来源于对后一种认识的反复持续,反而在于对前一种——既有的认识的观察。《简》一书的源起,正是一次对“我在干什么”的发问。在这一反思中,我最终找到了我在工程中的种种位置,并将这些位置在我既有的知识中一一标点。然后,我们就看到了那幅EHM(工程层状模型)图(参见“总论”图0-1)。

追究起来,EHM图以及它所代表的我的认识已经是8年前的事情了;完成《简》一书,也已经是6年前的事情了。6年前,我将《简》作为电子版发布的时候,也同时得到了一个新的职务:架构师。然而如果你仔细地观察EHM图,就会发现它根本上是不能容纳“架构”这个角色与职责的。“我在干什么”,仍然是我这6年来最主要的思考。事实上,这也促使我抬起头来,观察周围营营碌碌的人们,了解他们在做什么,在围绕什么去做,以及——也是最重要的是:他们得到了什么。如同《简》中所说的愚公一家,数百年挖山不止,最终却不得不筑关自守,我们是不是也一样背离了初衷,成为一个不知所为的愚者?《简》事实上是打开了我思维的一扇门,让我看到“我既有的那些东西”是何等粗糙,又曾经是如何粗暴地塞入了我的头脑。例如我在计算机专业中所学的第一门功课是《数据结构》,这本书的第一页便写着:“用计算机解决具体问题,首先要加以抽象。”但十余年来,我从未思考过“什么是抽象”,又或者我的思维以及由此驱动着的软件开发活动中“何处是抽象”。抽象被作为我们——程序员的一种事实的本能,或被驯育的技能塞入了我们的举手投足,控制着我们而又让我们无知无觉。《简》在这“无知无觉”的宁静中轻一叩击,“叮”的一声,我的眼前便亮了。观之简,便在其原始的粗鄙;思之得,便在行道中的一凛。没有答案《简》一书只提出了现象,而无有答案。2009年在北京的QCon大会中,我跟几位朋友谈到过这个问题。我坦承这一事实:若《简》尚有一点可读处,便在于它粗暴而又挑衅地把种种问题摆在我们的面前。但对许多人来说,这毫无益处。因为他们或是已经看了这些,或已经为之麻木,或是在贪求某种法子来逃避这些东西带来的影响。

总而言之,《简》是“没有答案”的。我彼时也是“没有答案”的,我只是觉醒过来,并看到了一些事实上存在已久的东西而已。与此相同,《大道至易》这本书也“没有答案”。尽管我提出了一些貌似答案的东西,但我确实是在保守地、谨慎地谈论它们,并且时时地(譬如现在)警示读者:这是在某些背景下的一时之选。“讲述某些我知道或想到的答案”是本书中最没有价值的部分,即使它们存在,即使看起来“非常有用”,也仅是一时的表象而已。

与《简》不同的是,《大道至易》提出了种种问题。就我的认识来说,现象与问题之间是有着一个巨大的跨越的。例如《简》中提到的“跑不动了”,它可以成为一种催人奋进的现象,也可以是脱水这样的问题。作为旁观者,若只见现象,便只会责骂鞭策;若能见问题,则知道“一杯冰水”才是解决之道。在我看来,正确的问题与“解”之间的距离是可显见的,而一个表面的现象或错误的问题,就离真正的解淼远而无际了。《大道至易》是一本提出问题的书。不设节名

正因为问题重要,而答案不重要,所以我认为给每段内容加以一个“有诱惑力的标题”是多余的。因此本书分篇、章、节三级目录,但节下的小节只有“一、二……九”这样的中文标号,没有标题,是谓“不设节名”。

事实上在我撰写的过程中,这些小节多数是有标题的。但最终我发现,若是有一个标题,则读者便非常容易陷入这个标题的“含义”之中,以之作为小节之纲要、主旨或主张。而这又正是我所不愿意的,因为我原本只是拿这些标题来搭个架子而已。

也就是说,本书原本是只有骨架,而没有血肉的。真正有血肉的,是你面对它的种种思考:那些没有名字的小节,是可以由你去补个标题的;那些没有定论的观见,是可以由你去设定的。我要做的,只是把问题写出来,把我的想法写出来,把我的观见写出来。这些,既不是真理,也不是我自作了固见的认识。

我之于盲人,相距并不甚远,只是我惊觉我的盲目,故而对周围多做了些探索;又或者我还能觉出蒙眼的黑布才是真实的问题,揭去之后,便一切历历在目、观之若即了。

只不过一刹那,定是相当刺目的。不为读者

对于许多读者而言,本书的“总论”是一个过高的阅读起点。因此本书的编审老师曾建议将“总论”移至最末一篇。为此我犹豫了很久,并也曾数次动摇。最终,我仍坚持将它作为本书的开篇。尽管编审在来信中写道:“根据我们的经验,好的开头对销量的影响可能达到三成。”

这真的是不小的诱惑。

相比来说,本书的第一篇“似乎”更适合作为“好的开头”——这也确实是编审老师们所推荐的。然而,事实上这一篇我是最晚成稿,写得最累,以及认为它是最不易读的。尽管表面来看,读者可以从这里轻松入手读上几页,然后觉得这是本“还有点趣”的书。然而它到底写的是什么呢?

离开总论的框架,所谓第一篇,不过是可以换得你的同感的抱怨而已。而真相,绝非如此。就写书出书而言,我当然可以用读者喜欢的方式去写作,并用读者喜欢的方式去包装那些篇章,然而这样一来,读者便会在“一开始”就失去整体的、系统性的认识,并认为这本书不过是又一本讲述软件工程的《大道至简》。

我可以为了“读者的口味”而改变这本书的著述体系吗?这是我最终的设问。而我很快地给出了答案:不!

总论是本书所述思想的核心,而后续几篇则是这一思想下的几个视角。让读者抛开总论而去窥见某个视角,与盲其目使之摸象何异?与予其管使之窥豹何异?我在前言中所反对的思想与方法,何以成了我去争取“读者人数”与迎合“读者口味”的手段?!

因此写下这段文字,以此自勉:莫因读者“买书如买纸”,便将书作了“字纸”去写,又或将书作了“纸页”去卖。

既如此,便仍让总论做了第一篇罢。这样一来,即便读者从它处读起,也总还能时时记得:有一篇“总论”在前头,或许蕴含着作者思想的主旨。致谢

感谢所有的读者、编者以及一直以来支持我的朋友们。

感谢孟岩先生为本书作序。

感谢图灵出版公司。

感谢我的小学数学老师。

感谢Joy。En,……我最爱的妻。总论领域角色的关注

总论共3小节

第一节 什么是领域角色的关注

第二节 基于组织视角的观察

第三节 工程的本质问题是组织

本书分篇、章、节三级目录,但节下的小节只有“一、二……九”这样的中文标号,没有标题,是谓“不设节名”。

事实上在我撰写的过程中,这些小节多数是有标题的。但最终我发现,若是有一个标题,则读者便非常容易陷入这个标题的“含义”之中,以之作为小节之纲要、主旨或主张。而这又正是我所不愿意的,因为我原本只是拿这些标题来搭个架子而已。

也就是说,本书原本是只有骨架,而没有血肉的。真正有血肉的,是你面对它的种种思考:那些没有名字的小节,是可以由你去补个标题的;那些没有定论的观见,是可以由你去设定的。我要做的,只是把问题写出来,把我的想法写出来,把我的观见写出来。这些,既不是真理,也不是我自作了固见的认识。第一节什么是领域角色的关注

屁股决定脑袋,这其实并没有什么不对。但首先不要关注屁股的大小,而要关注它的位置。在一个系统中,如果你都不知道自己坐在哪里,那么绝对不会知道自己该说什么、该做什么。位置的价值并不存在高下,也不可以拿某种方式去度量。尽管我们可以用收入或财产去衡量一个清洁工与一个老总的身价差异,但你无法去衡量“清洁一间厕所”与“看一个小时报告”这样两件日常事务之间的不同意义。清洁工与老总,这两个角色所关注的对象本身并不同质,因此无法将这些具体事务纳入到同一个体系中去评判价值。

关注位置,是观察这个系统的一个视角。你在哪里?是谁?在做什么?

作为一个系统的组成部分,如果要观察这个系统,那么就必须清楚三个问题:你在哪里?是谁?在做什么?从这个系统中别出了“我”,才能分出“其他”,才能分清“我与其他”之于系统间的种种不同影响,从而把这个系统分析透彻。大多数人在做这样的分析的时候,忘记了观察者是“观察—被观察”系统中的一个组成部分,忘掉了“我”的位置,因而少了一半的观察。《大道至简》这本书通过“工程层状模型”(EHM),从“实现者”这一角色出发,并论及 “团队”和“经营”角色。但是——如同上面的问题一样,EHM模型将这些角色析别出来的时候,也少了一半的观察。举例来说,“实现者”是程序员,“被实现者”是程序,在《大道至简》中却甚少论及程序的本质。又举例来说,“团队”的组成是项目成员,要真正成为“团队”则还有赖于项目目标,在《大道至简》中也只讨论到成员问题,而少掉了对约束或设定目标的那些角色的思考。至于“经营”角色,也存有相似的问题。

反思“工程层状模型”(EHM)的本质,是在讨论一系列工程相关问题在一个轴向上的延伸变化,以及这个轴向的不同领域间的关系。如图0-1所示。图0-1 EHM图及其隐含着的轴向

然而这个轴向带来了一个致命的问题:难于承载新的领域角色的加入。换言之,层状模型中加入新的角色就会带来新的分层与界面(关注点),这暗示着该模型下的世界是一对一的、面对面的。这个问题使得我在2006年间陷入了一个困境,不知该如何将“架构师”这个角色放入到这个模型中去。一旦我尝试在EHM模型中为架构师加入一个领域或一个层次,EHM立即就崩溃了——无法再解释清楚。

其实原因就在于,EHM对问题少掉了一半的观察。领域角色的关注

在我们对EHM模型背后的全景——软件工程——作出本质性思考的时候,“在哪里?是谁?在做什么?”这三个问题的提出,将会带来一个全新的视角。因为这三个问题代表的是:领域,角色,关注。

如此前所讨论的,我们可以将EHM模型简单地抽象为一个单向的轴线(对这里要讨论的话题来说,轴上的刻度是没有数值意义的),如图0-2所示。图0-2 将EHM图抽象为单向的轴线

在《大道至简》中我讲述过一个细节,即所谓的“工程中没有BOSS”。简单地说,就是经营者这个角色与我们要讨论的工程问题“几乎”无限之遥远。所以我们先把这个轴线向右无限延伸,也就是说,首先要在工程问题中析出“经营”这个角色,如图0-3所示。图0-3 轴线中的经营角色

然而,我们又必须认识到:任何一个有意义的工程实施,都是与企业的最终利益相关的,因此也必然会受到经营决策的影响。这种影响可能会很直接地立刻体现,也可能在相当长的时间之后才会表现出来。因此在上面这个图例中,我用虚线来指明这种影响。这一点在后续的讨论中将会相当重要。

剩下的是两类角色,一类是实现角色,另一类是团队角色。在《大道至简》中我们强调了二者本质的不同,以及我在跨越这一边界的过程中最主要的醒觉:语言只是工具。在这一过程中,我留意到:

若某角色在“实现”与“团队”两个领域边界上切换,其成本消耗是不可控的。

由此,《大道至简》中的EHM工程模型通过一个界面(临界点)来分隔二者,认为最好的法子是,让实现角色根据不知道所谓的工程,而又在遵循工程的原则下来推进项目。这种分析和推论有一定的合理性,但又忽略了其背后的本质原因,这一点在后面的讨论中将越来越明显。

在使用“在哪里?是谁?在做什么?”这一工具来仔细分析这两类角色时,我们会发现他们所在的领域也是有区别的:实现角色是在技术领域,团队角色则是在工程领域。技术领域关注的是实现的细节,即通过何种方法能将目标有效地实现出来,因而会追求这一实现过程的最优解;工程领域关注的是团队及其所应对目标的规模,在大多数的情况下,这一角色期望控制这一规模以使“目标、资源与质量”可按某种预期、整体地得到保障。有趣的是,从技术领域来说,一旦更细节的或者更宏大的实现成为可能,那么他们将毫不犹豫地将这种“可能”升级为“必须”,并为之充满激情;而这一切,往往又是以牺牲规模为代价的。

对于这两个角色,以及其不同的关注,可以描述成图0-4(与上面的图类似,两条轴线之间的角度也是没有数值意义的)。图0-4 模型1:对EHM模型进一步抽象所得的新模型

这个模型直接抽象自EHM中的实现和团队这两个主要角色,并在一定程度上将二者对立起来。这可以让我们清楚地看到二者的不同,和这种差异的本质原因,亦即是它们所面向领域的思维方式与关注对象的差异。另一方面:

●它狭义地将工程问题等同于团队问题;

●它限制了实现角色对工程问题的探讨。

因此它更加清晰地刻画了《大道至简》中所论的“工程”内在的关系和冲突。谁关注方向问题?

接下来我们问一个问题:最初从EHM模型中应当继承过来的“经营”角色,现在到哪里去了呢?

如果任由技术和工程这两个方向发展,可以想见的是:二者永远是存有分歧的。唯一能平衡这两种分歧的原则、条件、限定等,都必然是来自经营角色。因为,正是经营角色:

●确定和分解了经营需求并细化成各个目标(例如发起某个项目或计划);

●构建了特定的组织(例如部门)来推进它。

注意,这里的“经营角色”指代着另外的一个领域,而非是指某一个具体的个人,例如BOSS。“经营角色”所指代的领域关注什么呢?它既不关注细节,也不关注规模,而是关注于目标的达成。更进一步地来说,是整个的目标簇是否能维持原定的经营方向:一个或多个目标的方向在短时间的迟滞或偏离可能都不重要,而整个目标簇,以及由目标簇所指示的整体方向才是经营者所关注的。事实上,工程管理与技术实现,以及背后的“某个项目”仍只是经营者所关注的一隅,因为他们还有更多要关注的内容,这甚至包括了公司的张三是否需要提职,业界的李四刚刚与王五达成的“战略合作”究竟是烟雾还是毒刃,如此等等。“平衡两种分歧”是我们需要在这里讨论这一角色最基本的理由。因此在本质上,就“经营”这个领域来讲,它所立足的是“组织视角”,而关注的则是一个方向问题。将这个视角放在上面这张图中,我们得到图0-5。图0-5 模型2:“工程的组织视角”对模型1的影响

所以,我们看到了“经营”这个领域对工程的影响既深刻又浅末,既是必要条件又难以形成约束。这其中不仅仅有经营角色本身的精力问题,也涉及能力问题。因为,要确保图0-5所展示的“工程活动”的实效性,那么我们还需要注意到一个事实:

所谓“规模”与“细节”,其实只是“目标”在两个领域中的投影。

如图0-6所示。图0-6 模型3:目标在模型2中的投影关系

也就是说,“工程的组织视角”还暗含着这样的三条推论:(1)目标在工程和实现上的投影正确并相互匹配时,项目能最佳推进;(2)目标的设定影响“工程与实现”整体的代价,较小的目标(例如里程碑)是更易实现的,反之亦然;(3)真实的方向与现阶段的目标通常有相当长的距离,其实现通常是以组织的倍增为代价的。

上面的第2条和第3条推论其实和我们现实的观察与实践是一致的。反过来说,也可以认为该模型体现了工程的现实状况。工程的组织视角下的视图原型

既然上面的模型3中考虑的是组织视角对工程的影响,亦即整体上是讨论该视角下的工程模型,那么仍将其纵轴称为“工程(领域)”就并不合适了。事实上,这个纵轴所代表的仅仅是原始的EHM图中由“团队(及其组织与功能)”所映射的领域,是一个相对狭义了很多的工程概念。因此,在继续讨论之前,需要先修正一下模型3的概念以得到图0-7所示的一个原型。图0-7 模型4:对模型3的概念修正

首先,我们明确了模型阐述的主题。整个模型被称为“组织视角下的工程视图”(请留意这仅仅是该视图的一个“过渡版本”),意在将这张图的整体视为对“工程”的描述。

其次,我们将纵向轴称为“项目管理”。这个领域中的角色围绕一个“明确的目标”的投影工作,主要职责在于管理其规模(scope),包括对团队组织、产品特性、项目质量、消耗成本等进行明确的或可预期的管理。以现实的工程角色为例,可能包括团队负责人、项目经理、产品经理、市场经理等。

最后,我们将横向轴称为“技术实现”。这个领域中的角色围绕“与‘项目管理’角色相同目标”的投影工作,主要职责在于实现其细节(specific)。以现实的工程角色为例,可能包括工程师、设计师、分析师等。

上述“技术实现”与“项目管理”二者所关注投影的原始目标“应当”是同一的。在现实的工程中,我们通常称之为“产品”。VEO模型:架构角色出现的必然性

对于一个小型的组织,或一个较短期的目标/方向来说,若要求“经营者”来保证两个投影的原始目标同一,并在实施过程中持续稳定,是有可能做到的。这也是一些小公司或小型团队能有良好的组织与合作的根本原因:经营者直接参与规模与细节的平衡。但是,在以下时候:

●规模持续扩大、技术渐趋复杂;

●经营者的方向与阶段目标间的距离越来越远;

●方向由多个方向簇构成。

经营者将难以通过亲历亲为的形式来实现上述的平衡。这些情况下,经营者通常需要通过组织调整来保证其战略推进的有效性。“组织”既是一种经营工具,也是一种管理工具。所以无论经营者还是管理者,都有可能使用这一工具带来系统整体或局部的变化。换一个角度,管理者其实也可能参与或直接行使经营职责。因此《大道至简》中所述的:

你可以更直接地观察到“经营者”与“组织者”之间的差异。例如公司的大小股东是“经营者”,董事会通常是解决经营问题的地方;而总经理、执行经理及各个部门经理则是各级的“组织者”,经理办公会则是解决组织问题的地方。

这样来将“组织者”作为角色讨论是并不适当的——“组织”,是管理职能的一种工具而非其全部。所以《大道至简》其实是用一种极端情况来区分出了“经营角色”,使我们在EHM中的模型可以被讨论而已。

经营者选择组织工具而非其他,是有一定合理性的。首先,模型4在“方向”轴上的缺失是局部问题而非全局问题,因此通过组织工具来调适不会带来全局性的风险。其次,经营者可能并不期望颠覆正在进行中的阶段性目标,因此选择组织工具而非战术手段(例如裁撤项目)相对会更为温和。

经营者需要在模型4中解决的问题是规模与细节的平衡,以使得工程角色的实施与目标、方向的设定一致。正是这一需求导致架构角色的引入,因为“架构”角色本质责任与这一需求不谋而合。

所谓架构,包含了“范围”与“联接件”两个方面。“架构”一词源于建筑学,中文所说的架构,意指“间架结构”。其中的间、架,在建筑中是对房屋规模的度量用词;结、构则是指建筑的关键位置上的技术构件。

但是,如果我们将架构角色锁定在“某种描述范围与联接件的文书”这样的产出上,无异于将架构角色当成技术工人:使用某些工具,生产某种产品。我在这里讨论 “架构”一词的本义,是强调应从本质特性上来看清架构角色所关注的方面。而这些方面,又与在现今软件工程中经营角色对软件系统的关注,例如问题的识别与控制等等存在一致性。正是因为这种一致性,由架构角色来介入模型4中的“方向”这个轴线所指代的领域,才会成为一种组织选择的必然,如图0-8所示。图0-8 模型5:组织视角下的工程视图

在从EHM模型推进到图0-8所示模型的过程中,我们让经营角色介入进来,又渐渐地将这个角色分离出去,代之以“系统架构”这样的领域与角色。以下我们把工程视图模型简称为VEO模型(View of Engineering Organization)。在开始后续的讨论之前,我们需要再次强调引入架构角色的本意与背景。(1)目标。架构角色围绕一个阶段目标,以及该目标在规模与细节上的投影工作。这是能将架构角色与其他两个角色纳入同一个系统(具体的工程实施)来讨论的前提。(2)方向。架构角色在方向领域上与经营者(或更宽泛地称为架构需求的提出者)保持一致,了解阶段目标与方向之间的关系,并通过架构产出、指导、推进和实施等一系列工作来把握这种关系。(3)范围与联接件。架构的主要产出是对范围进行的约束,对目标的关键构件之间的联接件的设定。并且还需要在实施过程中调适架构最初的约束与设定,平衡由时间、信息等因素带来的目标与方向之间的衍变。第二节基于组织视角的观察

我曾经说“记事本这样的软件不需要架构”,这句话并不对,因为彼时我不能将记事本作为一个系统来看待。事实上“系统”这个词并没有“大小”的限定条件,就如同说“人”这个概念本身没有“群体”的限定条件一样:并不是说一群人是人,一个人就不是人。

从组织的视角来看一个系统各个独立的部分,这些部分都可称为角色。系统中的不同角色

在(系统)架构角色的眼中,目标是一个系统。所以记事本既然是一个系统,则也可以有工作在该系统上的架构角色。记事本系统与整个桌面操作系统之间仅存在复杂性的区别,这在VEO模型上体现得尤其明显(就我们这里要讨论的话题来说,图0-9中规模的绝对大小是没有数值意义的)。图0-9 模型6:不同规模的系统在VEO模型上的映像

现实的工作中,我们没有为记事本的开发指派一个“系统架构师”的原因是:它的规模与技术复杂度一个人就可以控制。但这并不是说,这个“个人”在软件开发过程中就没有过规模、细节、方向这三个领域上的思考。简单地说,我们在很小规模的软件开发中,可能是由一两个开发人员同时负担了管理、架构、实现三类职责而已。所以——

我们要讨论的是“角色”,而非某个职务或具体的人。

以架构为例,我们讨论的不是“谁来做架构师”的问题,而是“架构这个角色应该起到什么作用”的问题。首先,最迫切的问题是要弄清楚项目目标,这是必然的。在这个目标被作为一个产品指派到某个项目组之前,架构师就应该清楚在更大范围的“系统”中,当前这个目标的真实意图。例如记事本从Windows 1.0开始就在系统中存在,有着诸如此类的原始设定:

●作为对DOS等早期命令行系统中的行文本编辑器的替代;

●是操作系统缺省的文本处理工具。

而在这个目标之下,规模问题是项目管理这个角色所主要关注的,更确切地说:

规模问题的核心是项目目标的投入与产出。

所谓投入,包括时间、人力、资金、设施等,项目管理者必须考虑项目在各个阶段的投入情况并确保它在一个可控的规模。所谓产出,是指项目目标(例如产品)的特性及其细节,项目经理必须保证这些特性是在一定边界上增减的,是可测试与交付的。

这看起来与质量的三要素,以及软件工程的体系层次等模型有隐约的相似,如图0-10所示。这些用来阐述软件项目或软件工程的传统模型,是从工程质量保障或实现方法的视角来考察工程的。然而关注质量平衡或关注实现层次,仅是在规模控制中的手法,是部分的要件而非其全部,例如在《大道至简》第三版中,就将做得“更多”或“更好”等等都作为规模失控的一种形式来看待。图0-10 软件工程的质量三要素和体系层次

所以事实上架构角色与项目管理角色都在关注记事本的规模问题,但仍然存在着一些不同。例如,如果相较于复杂的jEdit、Editplus,或者便捷一些的Notepad++、Win32pad等来说,有人提出了类似“设置字体颜色与背景颜色”这样的特性时,架构角色可能会首先考虑以下因素。(1)记事本作为操作系统的默认组件,其外观表现和交互特性应当是由系统的全局设置来控制的。对于前者,例如桌面主题导致的记事本前景与背景变化;对于后者,例如系统默认打印设备的设置,或者输入法设置。(2)如果操作系统的默认设置不能影响到记事本,则系统的其他默认组件也会存在类似的问题或需求,这意味着整体实施的复杂度会增加。(3)类似于jEdit、EditPlus等产品的用户只是操作系统用户群体的一个较小子集,其需求不具有代表性。(4)以记事本通常处理的文本长度来说,是不需要用颜色来区分文本的不同部分的。

对于项目管理角色来说,他否决这项需求的理由会更简单直接:(1)在当前的记事本版本中,未定义该项特性;(2)该项特性与原始的设定“文本处理工具”没有必然关系,可以延后决定;(3)该项特性在来自产品、市场等各方的报告中有明显分歧,存在实施风险;(4)在项目实施阶段,增加该特性对项目过程控制存在不确定的影响。

然而与上述两类思考不同,技术实现角色将更多地关注实现的细节问题。其中一类问题是与项目经理共同关注的,通常与项目背景以及实施环境有关系。例如:(1)可能的代码量与要求的代码质量;(2)后续维护人员的水平以及因此所需要的注释详细程度;(3)开发环境与测试环境的部署以及性能。

当然,类似于在何种团队中工作,以及开发部门中是否可以玩桌游等,也是技术实现角色经常关注的问题。不过这类问题的特点是:与具体项目并没有关系,因此大多数情况下会由公司的技术部门或整体组织来平衡。

在具体的项目中,开发人员通常更关注的是另一类更加细节的专业问题,例如:(1)产品性能的具体要求,例如运行在何种设备上,以及定量的稳定性要求如何;(2)采用的语言、框架、程序库,其技术复杂度如何,以及资料是否翔实等;(3)待处理的标准文本格式规范,例如UTF-8编码以及BOM头规格;(4)需测试操作系统初始环境中所有类型的文本,包括.ini、.xml和.reg等;(5)该产品应由多行(ES_MULTILINE)的Edit来实现。

这些问题的部分或全部也会对项目的规模构成影响,从而改变项目原始目标的设定。例如说,如果记事本不是由标准的Edit来实现,而是使用RichEdit来实现,那么它就具有了与写字板相同的规模与特性。所以架构师同时也需要站在技术实现的角度上,考虑技术的选型问题,因为只有架构师知道“系统的其他部分还存在一个使用了RichEdit组件的写字板产品”,并且又具有控制记事本向写字板演化的职责。

我们看到:

●架构角色不单单关注记事本自身的规模,还关注其外在系统的规模,以及二者的关系,例如他关注记事本与写字板之间同质问题,并设定原则来辨识它们;

●技术实现角色则关注实现技术是否便捷、有效,以及是否能把控实现过程,他的这些需求来自于对项目产出的责任,以及对自身实现能力的衡量;

●而对于项目管理角色来说,一旦产品规格书上有确定描述,他就不需要关注“该项目是不是把记事本做成了写字板”。

当然,架构师就要为类似的规模失控问题挨板子——这也可能是产品架构师的问题。不过要到本书的最后一部分,我们才会来讨论架构角色的分类问题。透视:一体的两面与多面

回顾VEO这个模型与项目的关系,我们可以将“整个系统”所涉的子系统划分在不同的业务领域中。这时我们会发现,VEO也展示了子系统与系统全局之间在方向上的不一致性。它们既有可能是同向或基本同向的,也有可能是异向的,或者无关的。图0-11部分展示了在Windows操作系统中的“多媒体子系统”可能涉及的一些细分子系统、业务领域。

在将操作系统或“多媒体子系统”的细节投影到VEO模型时,我们会发现:(1)目标跟“规模和细节”之间是一体两面的关系;(2)系统全局的目标,与“不同子项目的规模与细节”又是一体多面的关系;(3)局部目标与全局目标并不存在简单累加关系,因此全局规模与局部规模也不存在累加关系,“细节”轴线也存在相同的问题;(4)目标在不同方向上越分散,子系统在规模与细节上冲突的可能性就越高,系统复杂度(管理成本与实现成本)也越高;(5)不同的方向间产生的内耗极大地增加了系统的代价,而规模与细节的失控只是这个问题在两个轴向上的表现。图0-11 模型7:系统局部与全局的关系

面对这样复杂的系统分析,架构角色应当要有能力来回顾(review)各个子项目,有意识地放弃掉一些不重要的、投入与产出关系不明朗的,或者对系统全局会有负面影响的子系统。同样,架构角色也可以将部分力量聚焦在一些子项目中,以使战略方向更为明确和落到实处。最后,也是最重要的,架构师要能把握全局力量的投放,对于某些有远见的方向,或暂时不清晰的方向予以持久的关注,这是架构师在系统整体调控能力上的最终体现。组织:组织力下的VEO基本模型

VEO模型表达了技术、管理之与架构,是一体的两面,这种关系可简单描述为图0-12,但这只是一种理想状况——准确地说,是相对理想的状况当中的一种。图0-12 技术、管理之于架构是一体两面的关系

在我们最初做软件开发工作的时候,例如个体开发项目中,所谓技术角色与管理角色是一体的,这是最简洁的开发模式。接下来,当项目规模大到一定程度时,我们发现需要一个管理角色来参与项目的过程,让他通过控制这一过程来限制项目的规模,保障输出质量与投入成本的平衡。这催生了传统的软件工程模型。

传统软件工程模型其实就是一个软件开发方法论在过程与工具上的投影。

然而尽管我们已经基于这样的模式实践了几十年,却仍然在不停地探索管理与技术之间协调工作的方法。从这个角度上,即从实施的视角,对传统的软件工程模型加以审视,如图0-13所示。图0-13 基于实施视角,对传统工程模型的另一种抽象描述

这事实上也说明了传统的软件工程为什么都是在某种方法论上的具体实施。然而我们观察实施视角下的软件工程,(基于某种方法论,)它除了引入更复杂的过程/流程,以及更多门类的工具来协助工程的推进之外,并不能解决组织问题。

现在,为了保障更大规模下的目标,我们引入了架构角色。架构这一角色,在组织关系上介于管理与技术二者之间,在工作内容上与二者有所重叠,在职责权力上又难以对当前项目与产品产生直接效果。这三个方面的关系,使架构角色在组织结构上显得尴尬。而与这种尴尬的状况不匹配的,是它可能带来的负面效应。

架构角色对目标投影的失控将不可避免地导致组织规模扩大,以及管理与实施之间失联,图0-14表现了这样一种状态(图中的角度值仅用来与VEO基本模型比较,并非有确切含义的数值)。图0-14 模型8:组织结构调整带来的问题

所谓组织失联,是指在组织结点之间(例如管理与技术)所工作的方向不一致、沟通成本增加,以及信息不对称——例如架构角色所展示的“目标映射”在其他角色有不同理解。进一步的结果,随着失联愈趋明显,最终有效的工作集变得越来越小。与此同时,组织的规模却在增长,管理边界与成本也增大了。这一过程,其实就是所谓的组织结构调整所带来的内耗。

积极的管理或技术角色会趋向于弥补这种内耗,无论是二者谁占据主动(话语权或说服力),其结果无非是图0-15所示的两种情况中的一种。尽管这两种模型从本质上来说是一样的——因为“实际的规模”中的内耗与模型8中是等量的,但是架构失控偏向于某一侧,其结果却可能不同。图0-15 模型9:积极的组织适应带来的效果

在模型9a中,由于架构角色对细节失控,因此他只能尽量争取管理角色的支持。如果他有足够的组织责权,管理角色又能很好地配合,那么业务会朝向架构目标推进。但即使如此,由于技术角色所能感受到的方向是趋于变化,所以技术调整的成本会相当高(例如技术人员离职、框架废弃等)。另一方面,如果架构与管理无法配合工作,那么最终的结果是管理能力决定了项目是否“按时完成”,但项目产出与原始需求会相距甚远。

在模型9b中,由于架构角色对管理失控,因此他只能尽量争取技术角色的支持。如果他有足够的技术影响力,并且可以在需求和目标上与技术角色达成一致,那么业务也会朝向于架构目标推进。与上一个例子类似,管理角色将会缺席,事实的情况变成了由架构角色来驱动一个技术产品的研发过程。架构角色可能会在细节上与技术角色沟通,而忽略了在时间、资源等成本上做好控制。更或者存在另一种可能,即架构与技术角色仍然无法达成一致,那么最终的“业务推进方向”将变成“技术创新产品”——当心,完全无规划的技术创新,既可能是全新的业务,也可能是耗尽资源的垃圾。

面对组织失联,积极的愚公可能挖山不止而终无所成(或神话般地感天动地),消极的管理或技术角色则可能会让经营者看到一个“貌似可喜”的局面。当管理、技术与架构角色之间都不能相互配合时,他们各自为阵进而达到一种平衡势态,如图0-16所示。图0-16 模型10:消极的组织对抗带来的平衡态势

之所以说这是“貌似可喜”的,是因为这个模型表面来看不存在问题:组织的要义在于能以一种稳定的模型持续推进,而不稳定的组织结构意味着自我调适带来的内耗。同时,这种平衡态势也是组织力影响VEO模型的正常结果。如上所述,无论以何种结果(例如大量内耗)为代价,组织的自我调控都将是趋向于衡态的。具体来说,在信息的分享上,完全无分享是最确定的衡态;在目标方向上,各向的牵制是最确定的衡态;在组织规模上,各角色等量发展是最确定的衡态,等等。

所以,如果仅仅构建(或自然形成)VEO模型中所述的架构、管理与技术角色关系,并依赖他们完全自发地调适,模型10将会是最有可能的结果,也将是消耗最大的一种衡态:系统的规模最大而有效的工作集最小,并且在目标和实施上存在不对等和不确定性。合作:VEO模型工程的人为因素

我们讨论到了组织衡态的一种形式,即因为“架构角色对目标投影的失控”而导致各个角色的方向/目标不一致,由此各自发展而形成彼此独立的衡态。事实上我们大多数时候处在组织演进的过程中,“不是东风压倒西风,就是西风压倒东风”,因而上述衡态是一个理想的(但并不是良好的)结果。

我们必须讨论事物的另一面,即如果目标投影能准确地映射到规模和细节上,架构角色在这一过程完全履行了自己的职责的话,又当如何呢?如果这一切发生的话,则管理角色与技术角色将完全理解并忠实执行架构角色所述的目标,这一过程在VEO图上可以表现为图0-17。图0-17 模型11:架构角色的职责可能对组织产生的影响

由于目标趋向一致,因而三个角色趋向于合作。随着组织规模渐趋紧凑,组织变得愈加高效,目标细化而又锁定在一定的范围之内,其最终的实施结果无限趋近于目标的预设。也就是说,最终的衡态也可能是三者在关注的方向和内容上相同,仅存在责权范围的不同,如图0-18所示。图0-18 模型12:面向合作的组织适应带来的效果

显然,这种衡态是一个理想的(也是良好的)结果。而这种结果——在这一个阶段中——是由架构职责的忠实履行,并与其他两种角色切实合作带来的。这意味着两件事:(1)架构角色完全理解自己的职责;(2)管理与技术角色完全理解架构角色的作为,并努力配合之。

然而我们面临的现实并不乐观。一方面,争取管理与技术角色的合作必然要求架构角色在这个组织中存在一定的领导力。领导力并不是组织能力,否则当某人被任命为架构师时,他就应当有领导力了;领导力也不是管理能力,否则找个高管来当架构师就好了。所以:

架构角色的领导力(以及其话语权)另有来处,而组织行为与管理行为只是保障这个目标的两个可选工具。

另一方面,对于架构角色,其责权的重要性与职务的确定性存在明显的不匹配:到底架构是什么、如何做,它的产出以及影响工程的具体方式等,难以在项目团队中界定清楚。无法确定这些行为,也就无法领导这一个阶段的工作,所以当“角色的关注”变成不可实施的空话时,领导力本身便没有了价值。这从另一个角度说明,架构角色的领导力,部分来自于实施架构过程中的确定行为。

是所谓行胜于言,清谈无架构。调适:变化中的VEO模型

有三种组织模型能够描述“有着某种领导风格”的组织,分别是Owner、Center与Core。在这三种模型中,领导者将自己作为一个点,代表、凝聚了这个组织,或作为组织的一个缩影。但这样的组织模型只表明“领导力”的一个结果,即“如果某些角色是有领导力的”,则他们的推进结果可能使组织演变为这样的一种形态。我们不能反过来说,一个结果(如形态)就是领导力本身。

VEO模型在角色职能出现了架构、管理与技术三个方向,从团队/项目组织职能上来说,这三个方向也就存在三个(可能的)领导角色,即架构师、项目经理、技术经理。如VEO模型所阐明的事实一样,图0-19表明这三类领导角色在组织上是趋于衡态的(领导力下的衡态,以下简称LoE,即Leadership of Equilibrium)。图0-19 (与领域相关的)领导力下的衡态

如何让LoE模型趋向于一个“有领导力”的组织模型,是这一系统中的各角色间存在冲突的主要原因——换个简单的说法,就是大家都想当领导。在另一方面,这些角色将受到更外层的角色的影响,外层角色级别可能更高,或更为具体(如开发团队、产品)或宏观(如更高级别架构决策者、产品线),如图0-20所示。

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载