在刚入行的时候，我从事的是企业服务，在以后业务下开发组件或者页面的时候遇到须要示意 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 一下。
博客地址