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

原创
2021/04/13 01:27
阅读数 2.2K

在刚入行的时候,我从事的是企业服务,在当前业务下开发组件或者页面的时候遇到需要表示 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 一下。

博客地址

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部