从组件 boolean 值属性谈谈分层架构

在刚入行的时候，我从事的是企业服务，在当前业务下开发组件或者页面的时候遇到需要表示 boolean 值属性的时候，往往以 can 作为变量前缀来表示组件是否可以执行某一类或者某一个操作。这种命名习惯跟随了我很久。

直到有一天，我去了另一家公司开发拖拽设计器的时候，领导告诉我：虽然 can 开头表示 boolean 值是没什么问题，但是对于组件开发来说，应该是 able 结束或者 is 开头更合适。然后我在查看了市面上较为知名的几个的组件库，它们在表示 boolean 值时候都是以 able 结尾，我就默默的把当前的变量修改了一下。

可惜的是：当时没有仔细分析这个问题以及问题背后的逻辑。但是做一件事总是要有一个理由的，即使这个理由无法说服别人，但至少也要说服自己。下面我就来分析一下，两者的异同。

属性实意

我们来看一看 can，able 这两者的实际意思，is 后面再聊。

• can (表示有能力做或能够发生)能，会;(表示知道如何做) 懂得; 与动词feel、hear、see、smell、taste 连用
• able 能;能够;有才智的;有才能的

以编辑为例子： canEdit 表示可以编辑，而 editable 表示可编辑的。前者着重表示能够实现某事，后者着重表示具备能力实现某事。

在不同的命名下，我们可以看出决定当前命名的内在逻辑在于当前工作的重点是什么：在之前的工作中，我们是开发业务系统，而对于当时的业务系统来说，有大量的权限控制。而在后来的工作中，我们更多开发的是配置（基础）组件。

我们不妨再来看一看 is 前缀，is 前缀可能更接近 boolean 的意思。如 isInternalStaff 表示是否是内部员工。 但同样，对比前两个单词的意思，它能够表示的粒度太粗。在没有实际深入分析业务前，你无法通过该变量分析出任何实际意义。

分层模式

分层模式是最常用的架构模式。大部分软件系统都是由多人开发的。根据某种方式或规则可以将系统分层，方便开发人员协同工作。分层实现了层间低耦合和层内高内聚，提升了系统的可维护性。

特点

从规则上来看，分层的所有代码必须属于某一层内，上层代码可以使用下一层，但这种关系必须是单向的。不可以进行循环依赖。当然，从浏览器运行实际分析，依次加载和执行 js 无疑是分层模式的天然应用场景。

当然，分层模式的优势和劣势也是较为明显的，优势无疑是把基础，不易变化的单独提取出来。提高系统的可复用性，可测试性。更容易修改。同时系统分层非常容易实施。但同时，每一次分层都引入了额外的抽象，增加了系统的复杂度，并且有可能会影响性能（清晰的结构比那一点点性能损失要有用的多），同时也可能导致开发有一定的痛苦。

分层模式有许多变种，但无论分为多少层，它的关系，使用规则是不变的。

效率提升

Flux 架构就像眼镜：您自会知道什么时候需要它。

对待任何系统，都有符合自身的代码架构。但对于分层来说，它太棒了。除非你在进行 demo 测试，否则我一定会推荐你使用分层架构。

分层模式还有一个特点是知识屏蔽（封装），分层可以减少不相关事务间的影响，对于一个成熟的开发团队来说，一定会有人才梯度设计。当团队进入新人的情况下，成熟的分层可以让开发人员不清楚下层细节的情况下，依然可以利用下层技术文档以及 cv 大法进行系统开发。但如果所有的代码都在一个层内，所有人面向同样的问题。虽然我们已经很努力的让新人处理简单的问题，但是错综复杂的调用依然会降低实际开发效率。所以分层模式会帮助团队提效。同时也起到一定代码保护的作用。

分层模式也可以帮你分析实际问题，当你清楚这个问题属于谁，其实问题已经解决了一大半了。我们当然需要具有主人翁精神，但事实上，找到更了解它的人无疑是更有效的方案。

从架构上来说，我们也尽可能的从下层解决问题，因为下层的代码有强大的复用能力。虽然越接近代码细节，修改越有效，性能提升越高。但是对于系统架构来说，细节的解决方案反而是最后考虑的。

实际分析

我们再回头看一下 boolean 值属性。able 适合与基础组件设计，用于表示基础组件拥有的能力。

can 表明权限控制，在业务块（business block）中使用，利用基础组件，但往往有一定的业务属性,但还可以提炼出一套通用的逻辑。例如 Vant 地址选择 这种，有添加，删除，排序以及修改默认地址的业务逻辑。

最后的 is 适合于是业务系统（页面），我们可以基于不同的角色等构建不同的业务，利用基础组件和业务块来构建。同时我们也可以看出，我们不应该在基础组件和业务块中使用 redux 等状态管理库，以避免耦合。

不过在业务系统上，我们更要分析出当前的代码重复是否是知识的重复。在很多团队编程规则中，都会列举 DRY 原则，甚至 CI 系统中，会指出代码重复，并且禁止你提交代码。这时候，你也需要告诉他们你的理由，代码的确相同，但是当前代码所表示的知识并不相同，这仅仅是一个巧合罢了。

在实际项目开发中，我们可以逐步前进，先在代码中使用 components 文件夹封装组件和块。发展到一定阶段后，然后再利用 monorepo （多项目一个仓库管理）去管理当前系统，最终在稳定之后，提取各个层级形成 multirepo 以便新的项目复用。

分层架构简单但是十分强大，不过想要用好可不是一件简单的事。

鼓励一下

如果你觉得这篇文章不错，希望可以给与我一些鼓励，在我的 github 博客下帮忙 star 一下。

博客地址