在剛入行的時候，我從事的是企業服務，在當前業務下開發元件或者頁面的時候遇到需要表示 boolean 值屬性的時候，往往以 can 作為變數字首來表示元件是否可以執行某一類或者某一個操作。這種命名習慣跟隨了我很久。
直到有一天，我去了另一家公司開發拖拽設計器的時候，領導告訴我：雖然 can 開頭表示 boolean 值是沒什麼問題，但是對於元件開發來說，應該是 able 結束或者 is 開頭更合適。然後我在檢視了市面上較為知名的幾個的元件庫，它們在表示 boolean 值時候都是以 able 結尾，我就默默的把當前的變數修改了一下。
可惜的是：當時沒有仔細分析這個問題以及問題背後的邏輯。但是做一件事總是要有一個理由的，即使這個理由無法說服別人，但至少也要說服自己。下面我就來分析一下，兩者的異同。
我們來看一看 can，able 這兩者的實際意思，is 後面再聊。
以編輯為例子： 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 一下。