仓库源文

.. Kenneth Lee 版权所有 2020

:Authors: Kenneth Lee :Version: 1.0

例子和全集定义

最近评审了一个设计，其中提到，某某特性实现在$project/src/feature1/xxxx.c中。

这个约束明显不是一个真正的约束，因为要说，我们在实际编码的时候，把xxxx.c改为叫 xxxxA.c，没有任何问题。关键在于你放这么硬的约束，我还以为你还有一个脚本，非要 用这种方法来扫描到这个特性，到时要做点什么呢。

实际上，设计者本身也不关心这个特性的实现文件叫什么名字，他加这句话其实是想通过 一个例子，简单地对开发者做一个暗示：这个特性，其实可以放到feature1中，作为 feature1的一个模块。因为在我们讨论的这个例子中，惯例是，feature1目录就是放 feature1的几个模块的，比如原来就是放这些文件的：::

    main.c
    adaptor.c
    adaptor.h
    filter.c
    filter.h
    plugins/*
    cdev.c

那么他暗示这个文件应该叫feature1/xxxx.c，就简单说明了：

• 这必须成为feature1的一个模块

• 这不是feature1的plugin，而是和main平起平坐的模块

至于名字叫xxxx还是xxxxA，其实不是他的重点。

这个例子说明了一点，要精细表达一个设计意图其实非常困难。只要还没有变成代码，设 计阶段很多东西都可以是变数，但你要清晰表达这个变数，这个成本比最终变成代码都高 。

所以，我们不能追求精确，这种时候，表述能力和技巧就很重要的，比如，这里我们可以 这样表述：::

    本特性可以考虑实现为$project/src/feature1/xxxx.c

这清晰地传递了我们的期望，同时有不至于让这个要求变成一个硬约束。