Question

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

图附 3-9 模型 6：不同规模的系统在 VEO 模型上的映像

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

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

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

• 作为对 DOS 等早期命令行系统中的行文本编辑器的替代；
• 是操作系统缺省的文本处理工具。

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

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

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

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

图附 3-10　软件工程的质量三要素和体系层次

所以事实上架构角色与项目管理角色都在关注记事本的规模问题，但仍然存在着一些不同。例如，如果相较于复杂的 jEdit、Editplus，或者便捷一些的 Notepad++、Win32pad 等来说，有人提出了类似“设置字体颜色与背景颜色”这样的特性时， 架构角色 可能会首先考虑以下因素：

1. 记事本作为操作系统的默认组件，其外观表现和交互特性应当是由系统的全局设置来控制的。对于前者，例如桌面主题导致的记事本前景与背景变化；对于后者，例如系统默认打印设备的设置，或者输入法设置。
2. 如果操作系统的默认设置不能影响到记事本，则系统的其他默认组件也会存在类似的问题或需求，这意味着整体实施的复杂度会增加。
3. 类似于 jEdit、EditPlus 等产品的用户只是操作系统用户群体的一个较小子集，其需求不具有代表性。
4. 以记事本通常处理的文本长度来说，是不需要用颜色来区分文本的不同部分的。

而对于 项目管理 角色来说，他否决这项需求的理由会更简单直接：

1. 在当前的记事本版本中，未定义该项特性；
2. 该项特性与原始的设定“文本处理工具”没有必然关系，可以延后决定；
3. 该项特性在来自产品、市场等各方的报告中有明显分歧，存在实施风险；
4. 在项目实施阶段，增加该特性对项目过程控制存在不确定的影响。

然而与上述两类思考不同， 技术实现 角色将更多地关注实现的细节问题。其中一类问题是与项目经理共同关注的，通常与项目背景以及实施环境有关系。例如：

1. 可能的代码量与要求的代码质量；
2. 后续维护人员的水平以及因此所需要的注释详细程度；
3. 开发环境与测试环境的部署以及性能。

当然，类似于在何种团队中工作，以及开发部门中是否可以玩桌游等，也是技术实现角色经常关注的问题。不过这类问题的特点是：与具体项目并没有关系，因此大多数情况下会由公司的技术部门或整体组织来平衡 3 。当把上述决策过程放在具体的项目中时，开发人员通常更关注的是另一类更加细节的专业问题，例如：

1. 产品性能的具体要求，例如运行在何种设备上，以及定量的稳定性要求如何；
2. 采用的语言、框架、程序库，其技术复杂度如何，以及资料是否翔实等；
3. 待处理的标准文本格式规范，例如 UTF-8 编码以及 BOM 头规格；
4. 需测试操作系统初始环境中所有类型的文本，包括.ini、.xml 和.reg 等；
5. 该产品应由多行（ES_MULTILINE）的 Edit 来实现。

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

我们看到：

• 架构角色 不单单关注记事本自身的规模，还关注其外在系统的规模，以及二者的关系，例如他关注记事本与写字板之间同质问题，并设定原则来辨识它们；
• 技术实现角色 则关注实现技术是否便捷、有效，以及是否能把控实现过程，他的这些需求来自于对项目产出的责任，以及对自身实现能力的衡量；
• 而对于 项目管理角色 来说，一旦产品规格书上有确定描述，他就不需要关注“该项目是不是把记事本做成了写字板”。

当然，架构师就要为类似的规模失控问题挨板子——这也可能是产品架构师的问题（不过架构角色的分类问题并不是这里要讨论的话题）。