第4章可变性建模基础

第4章：可变性建模基础：可变点与变体、特征模型入门、正交可变性模型

好，咱们进入产品线工程里最核心的一块——可变性建模。说实话，很多团队做产品线失败，不是技术不行，而是压根没把「变」这件事想清楚。你想想看，如果连哪些地方能变、怎么变都没理清，后面复用就是空谈。

这一章，我带你从三个角度切入：可变点与变体、特征模型、正交可变性模型。这三样东西，是我做产品线时最常用的三板斧。

先问个问题：你手头有多个产品，它们之间到底差在哪？

我个人的习惯是，先画一张表，把每个产品的功能列出来。然后找「相同」和「不同」。那些不同的地方，就是可变点（Variation Point）。每个可变点下，具体有哪些选项，就是变体（Variant）。

举个例子。我几年前帮一家公司做智能家居产品线。他们的网关设备，有的支持Wi-Fi，有的支持Zigbee，有的两个都支持。这里，「通信协议」就是一个可变点。而「仅Wi-Fi」「仅Zigbee」「Wi-Fi+Zigbee」就是三个变体。

核心定义：

嗯，这里要注意一点：可变点不是随便定的。你得问自己——这个变化，对业务有价值吗？如果只是实现细节不同，那不算真正的可变点。我见过有人把「数据库连接池大小」也当成可变点，这就过度设计了。

避坑指南：我曾经在一个项目中，把「日志级别」也列成了可变点。结果产品经理说，这玩意儿用户根本不在乎。后来我学乖了——可变点必须来自业务需求，而不是技术实现。

有了可变点和变体，下一步就是组织它们。特征模型就是干这个的。

说白了，特征模型是一棵树。根节点是产品线本身，子节点是各个特征。特征之间有关系：有的必须选（Mandatory），有的可选（Optional），有的互斥（Alternative），有的共存（Or）。

我画个简单的例子。假设我们做一个「智能音箱」产品线：

智能音箱
├── [必须] 语音唤醒
├── [可选] 蓝牙连接
├── [可选] 屏幕显示
│   ├── [互斥] 3.5寸屏
│   └── [互斥] 5寸屏
└── [可选] 语音助手
    ├── [或] 小爱同学
    └── [或] 天猫精灵

你看，这棵树把「哪些特征必须存在」「哪些可以选」「选了A就不能选B」都表达清楚了。这就是特征模型的价值。

我的经验：特征模型别画太大。我见过有人画了200多个节点，结果没人看得懂。建议控制在30-50个特征以内，超过就分层。先画核心层，再画扩展层。

特征模型里还有几个关键概念：

我记得有一次，团队里有人把约束写错了，导致一个产品配置出来，既选了A又选了B，但A和B其实是互斥的。结果测试阶段才发现，返工成本很高。所以，特征模型建好后，一定要做一致性检查。

特征模型虽然直观，但有个问题：它把所有特征都揉在一棵树里。当产品线复杂时，这棵树会变得又大又乱。

正交可变性模型（Orthogonal Variability Model，简称OVM）就是来解决这个问题的。它的核心思想是：把「可变性」和「功能」分开建模。

怎么理解？你想想看，一个产品线里，变化可能来自多个维度：

这些维度是正交的——它们互不干扰。正交可变性模型就把每个维度单独建模，然后用矩阵或表格把它们组合起来。

我举个例子。假设我们做一款「车载娱乐系统」：

你看，每个可变点都是独立的。屏幕选7寸，不影响导航引擎选百度。这就是「正交」的含义。

注意：正交可变性模型不是万能的。当可变点之间有强依赖时，强行正交反而会引入复杂度。我建议：先用特征模型梳理核心依赖，再用OVM处理独立维度。

正交可变性模型的好处很明显：

但缺点也有：它不太适合表达特征之间的约束。比如「选了12寸屏，就必须选高德地图」，这种跨维度的约束，在OVM里需要额外用规则来表达。

讲到这里，你可能想问：那我到底用哪个？

我的建议是：

当然，实际项目中我经常混合使用。比如先用特征模型画出核心功能树，然后把平台、市场等独立维度用OVM管理。这样既保留了特征模型的约束表达能力，又利用了OVM的维度分离优势。

嗯，最后说一句：建模不是目的，目的是让团队能高效地理解和管理变化。别为了建模而建模。工具是死的，人是活的。

本章小结：