項目結束一段時間，寫個文章總結下。初入項目組，看到了3000行的vue文件，一口血差點捧出，無奈上一個程序員已經離職，留下的坑，只能自己填上了。在重構項目的過程中，也發現了一些別的問題，組內分享會做了總結分享，這次總結成文章特此記錄。
用搭積木的方式構建vue組件，就如同搭積木一樣，構建我們的項目
在項目中，對於組件的劃分，我們一般會劃分爲業務組件和功能組件，也可以稱爲視圖組件和容器組件。在react中也被稱爲無狀態組件和UI組件。組件劃分明確，對於代碼的可維護性和閱讀性有一定的便利性。劃分方式如下圖所示：
組件設計考量，分而治之
天下大事，分久必合，合久必分。組件亦然，由以前的寫在一起，到如今的明確劃分。分而治之的思想，也可以讓我們更加專注於主要的功能實現，便於擴展和複用。
在組件的設計中，需要考慮以下幾點：
可擴展性強
擴展性首先是我們要考慮的點，如果不能擴展，就代表着代碼寫死，失去了代碼的靈活性
組件中方法函數的抽離，便於複用，適用程度高。
儘可能使用方法定義，避免使用template表達式，不便於複用
文檔清楚詳細
畢竟寫的組件是給人用的，不完善的文檔讓別人如何使用，肯定不能手把手教別人怎麼使用吧，所以一個組件詳細的使用說明是必須的。
顆粒度合適，適度抽象
這個是一個經驗的問題，如何衡量顆粒度是否合適，其實是一個度的問題，每個人有每個人的看法，但是儘量保證一個組件完成的功能是單一的，而不是多個功能的結合體。
功能儘可能單一，代碼行數適中
這一點和上面顆粒度類似，以代碼行數衡量也可以，一般的組件如果抽離合適的話，絕對不會超過1000行，如果代碼太多，就說明組件劃分不合理，抽離不完善，需要重新設計。
必要的時候需要ui的配合（設計不止於好看，更關乎好用。—喬布斯）
有的組件設計出來太醜，程序員的眼光和一個專業的設計師的眼光還是有一定差距的，所以如果可以的話可以請專業的設計師設計以下ui界面，在一定程度上可以吸引到別人。
組件設計參考點
組件間props原子化
父子組件通過 props 屬性傳值時，儘可能的規定數據類型並且使用原始類型的數據。儘量只使用 JavaScript 原始類型（字符串、數字、布爾值）和函數。儘量避免複雜的對象。
有以下幾點注意：
- 保證組件API清晰直觀
- 更好的理解每一個prop的含義和作用
- 傳遞過於複雜的對象使得我們不能夠清楚的知道哪些屬性或方法被自定義組件使用，這使得代碼難以重構和維護。
- 保證組件可用（防禦性編程）
示例：
巧妙利用slot擴展組件
用好slot可以設計出很多優秀的組件。
合理使用mixin實現複用
Mixins封裝可重用的代碼，避免重複。如果多個組件共享相同功能，則可以使用mixin。通過mixin，可以專注於單個組件的任務和抽象的通用代碼。這有助於更好地維護應用程序。
及時模塊化
在決定抽離成組件之前，先問一下自己下面幾個問題：
- 是否有足夠的頁面結構/邏輯來保證它？
- 代碼重複（或可能重複）？
- 它會減少需要書寫的模板嗎？
- 性能會收到影響嗎？
- 你是否會在測試代碼的所有部分時遇到問題？
- 你是否有一個明確的理由？
- 這些好處是否超過了成本？
當你明確了上面幾個問題後，是否抽離組件相信你已經有了明確的答案。
如何設計組件？何時抽離組件？如何抽離一個合適的組件？都是一些設計原則加上實際經驗相互作用下作出的判斷，理論指導，實踐判斷。
最後用一段雞湯文結尾：
在一天結束時，雖然你的直接責任可能是“編寫代碼”，但你不應忽視你的最終目標，即建立一些東西。創建產品。爲了產生一些你可以引以爲豪的東西並幫助別人，即使它在技術上並不完美，永遠記得找到一個平衡點。不幸的是，在一週內每天 8 小時盯着眼前的代碼會使得眼界和角度變得更爲“狹窄”，這個時候你需要的你是退後一步，確保你不要爲了一顆樹而失去整個森林。
感謝各位大佬的閱讀，讀完希望給點個贊再走哦，謝謝！🙏🙏🙏