本文定义一对概念，用于其他的设计文档写作的讨论。

我们从工程上的精确和准确来引申我们的概念。测量一段距离的长度，得到结果是0.34米，我们可以提高测量的水平，得到一个更好的结果，比如0.342377946米。后者比前者具有更高的精确度（或者简称精度）。我们说后者比前者更“精确”。

精确度表现出来是更多的信息或者说细节，但更多的信息和细节，并不意味着正确。比如，我们做了一个错误的测量或者记录，得到上面的结果是3.42377946米。这个结果比0.34米更精确，但后者比它更准确。

我们描述一个设计，也有近似的（但不完全一样的）问题。比如我要做一个安装包，我这样描述：

1. 所有要拷贝到目标系统中的文件都集成到安装包中
2. 安装包中这些文件的路径和将要安装到的目标系统的位置一样
3. 安装时解开其中的文件，拷贝到目标系统对应目录中

当我们评价这个设计逻辑不严密的时候，有些设计者会这样修改：

1. 所有要拷贝到目标系统中的文件都集成到安装包中。此处的“目标系统的文件”，是指应用程序在被安装系统运行时需要的运行二进制，动态库，以及其他资源文件。而安装包，是一个以.apk为扩展名的，7z格式的压缩文件，其中包含所有的“目标系统的文件”
2. 安装包中这些文件的路径和将要安装到的目标系统的位置一样。
3. 安装时解开其中的文件，拷贝到目标系统对应目录中。如果目标系统中已经存在该文件，则安装失败，安装程序回退对原系统的修改。所谓回退，包含如下步骤：……

但这里提高的是描述的细致度，而不是让逻辑更严密，要让逻辑更严密，我们首先应该问这里的逻辑有什么“破绽”，比如，这里存在的破绽可以是：拷贝到目标系统中的文件是有权限和属性的，按当前的逻辑，并没有任何信息说明每个文件的属性。

那么，更严密的逻辑应该是这样的：

1. 所有要拷贝到目标系统中的文件都集成到安装包中
2. 安装包中包含一个名字叫metadata的文本文件，其中包含每个文件的属性信息
3. 安装包中这些文件的路径和将要安装到的目标系统的位置一样
4. 安装时解开其中的文件，根据metadata文件的要求的路径和属性，拷贝到目标系统对应目录中

在设计的讨论中，我们有时需要提高逻辑的细致程度，有时需要提高逻辑的严密程度。但对于设计文档，通常后者更重要，就好像在前面工程测量的概念中，准确比精确更重要，因为没有了准确，精确毫无意义。

在设计中，保证逻辑的严密，比更细致更重要。因为如果逻辑的破绽不消除，细致很可能毫无意义。

有时，逻辑描述不细致，我们从表面上并不能发现逻辑并不严密。还是前面这个例子，如果我根本不谈细节，直接说：

1. 通过在单独的.apk文件中包含需要安装的所有文件实现安装包

这句话表面就是没有逻辑破绽的，因为设计者并不反对在其中包含Metadata来解决路径和属性问题。这种情况，其实我们进入了“细节盲区”：每个设计都只能细致到某个程度。就好比工程测量的精确度也是有限的，精确度覆盖之外是一个盲区。对于工程测量，我们仍可以把逻辑建立在“无论盲区的值是多少，我们的逻辑链都可以处理”。但对于设计的细节盲区，如果这个定义本身不能成立，我们最终在工程上就无法实现它了。

这种情形，如果我们已经知道这个细节了（即使你没有把它写出来），我们仍把它称为“不严密”。但这种类型的不严密，有可能是我们知道的，也有可能是我们不知道的。当我们看到一个表面“严密”的设计逻辑。但我们对某个逻辑要素没有信心，我们会这样评价它：这个逻辑链不够细致，缺乏足够的信息判断它是否严密。

在本文中，我们做出的定义（细致和严密的定义）并不“细致”，因为一个细致的定义需要首先描述一个概念空间的全集，但我们现在是用概念空间去描述概念空间，我们永远无法描述这个全集：如果我们增加一个描述来描述这个全集，这个描述必然在这个全集之外（名可名，非常名）。所以，设计永远是个共识的问题，只要我们有共识，我们就可以判断一个逻辑是否严密和足够细致让我们判断它是否严密。但如果你非要否定共识的存在，沟通总是可以失败的。

原文：https://zhuanlan.zhihu.com/p/106911072

链接: https://www.fly63.com/article/detial/7474