在剛入行的時候，我從事的是企業服務，在當前業務下開發組件或者頁面的時候遇到需要表示 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 一下。