大道至易:实践者的思想(十三):任人治事,组织行为的基本认知——看到别人能做什么(架构师的职责:将“切实有效的架构”解构为具体可行的“系统化方法”)

阅读数:28 2019 年 10 月 5 日 14:12

大道至易:实践者的思想(十三):任人治事,组织行为的基本认知——看到别人能做什么(架构师的职责:将“切实有效的架构”解构为具体可行的“系统化方法”)

事实上,程序员讨厌架构师的未雨绸缪。而且同时,管理者也不喜欢这样。

有趣的事情是,在大多数情况下,在危机出现之前是没有人相信危险的,并且也是没有人愿意为此投入资源的。因此大多数架构师提出的“方案”都可能面临实施者的质疑:那个架构师的想法是多余的,是没用的空中楼阁。没人愿意为这些“可能的异常”付出代码、时间与防护性的子系统。

我至今所知道的唯一一件能让程序员——以及包括项目经理在内的整个团队——所接受的预防性实施技术,大概就是“结构化异常”(try…catch…finally)。但仔细地探究也会发现,其实越是在项目中面临过工期拖延、系统崩溃以及未知 BUG 折磨的开发人员与团队,就越能接受在代码中出现更多的、貌似无用的异常捕获。所以看起来,真正的问题并不是程序员以及管理者不愿意推进“预防性的”架构,而是在于:一是他们无法感受到反复的系统危机所带来的痛苦折磨,二是他们无法找到有效的、可实施的方法来应对上述危机。

层次系统是极有可能符合这一要求的架构方法。但是就程序员与管理层所能接受的观念来讲,层次系统是过于复杂而随意的——只要会说“增加一层抽象”的,就都成了架构师。但正确的层次抽象是确实可以隔离复杂性的1,而且通过接口设计可以进一步减少、屏蔽或确指层间的依赖。然而这些工作必然带来程序员的不满,因为接口的抽象与使用是多余的工作;也必然带来管理层的不满,因为“层次”这一系统抽象在事实上也约定了组织结构的规划。

1 在《我的架构思想》一书中会更加详细地说明这一事实,并探究层次系统隔离“可变性”的本质。

测试驱动开发过程是另一个视角下的解决方法。从工程过程的角度上来讲,它通过明确系统的“问题”、“关键点”与“指标”等来将系统参数化,并将这样的参数作为过程中贯彻始终的标准加以推进。尤其重要的是,它事实上也内在地要求了系统构件间的“接口化”与“复杂性隔离”,因此它可以与层次系统有着相当良性的配合。

迄今为止,我没有看到过一个更好的、更简单的“架构”,能切实地应用于项目之中,将可能发生的危机阻隔在一定的范围之内。我在这里所说的“架构”是指两个方面,其一是架构师对系统的抽象方法,例如层次架构方法;其二是指由“软件架构”与“软件开发方法”配合所产生的整体效果,例如层次系统与驱动开发过程的配合。因而,我所指的“切实有效的架构”可以简单地描述为:

目标系统、架构方法与开发过程协调统一的整体。

事实上,我认为只有这样(包括组织的、过程的、实施的等在内)的架构才是对“预防性”的整体求解2

2 例如,正是因为开发过程是测试驱动的,所以可以将测试视为“catch (…)”,而将“catch() {…} finally {…}”视为包含于一个迭代中的补偿。又例如,正是因为系统是层次化的,因此“try …”才是有确定范围的,且“catch (…)”的捕获才是有效的。

然而,这带来了很高的组织成本。管理者喜欢简化问题,喜欢尽快投入行动并看到结果——在这些方面,管理者能很快与实施者达成一致,但与架构师则很难。追究这一问题,事实上症结在于架构与管理二者的相互脱责。首先,架构师所要做的事情,就是推进这些“看起来多余”的事情的实施。架构师若一力担之,便出现了架构师领导下的应急小组;架构师若置身事外,整个团队失去了在这件事情上的基本动力。所以,架构师必须在“方法”问题上迎合管理者,必须使架构的具体实施方法简化、可行、有效。

因此,真正有效的架构方法,就是让整个团队都把这些“看起来多余”的事情视为系统实施所必须的一部分,即“系统化方法”,亦即是团队可以应用的法子。若架构师的主意总是“我们需要一两个高手来做这件事”,或“我们需要一两个突击队”,那这并不会影响团队整体,对管理者来说也必是“可选的”。大多数情况下,管理者只会在不影响团队整体资源的配给时,才会同意这些想法。

而反过来,如果一个方法是“系统化方法”,它影响到团队整体的投入与产出,并且将深刻地影响到系统的推进,这时管理者才会真正地重视起来。这也才是考验管理者的团队决策能力的地方,即我们——整体地——要使用什么样的方法来工作。因为一旦管理者认为“这不可行”时,这个系统化方法便失去了价值。所谓不可行,本质上来说仍然是“对于当前的系统(团队、项目与产品目标)来说,是难于实施的”。

架构师必须与管理者在“系统化方法”上达成一致,从而在团队、方向、目标以及整体策略上,对系统施加约束。

评论

发布