感悟篇之組件的設計

　　之前一直據說組件的編寫要高封裝、低耦合什麼的，對此徹底沒什麼概念，只能是憑着本身的理解去寫，可是寫完也沒有人給出評價，也就沒啥感悟可言，這兩天老大讓我弄一下小程序的背景音樂播放組件，在老大的領導下也算勉強合格的弄了出來，特此記錄感想。

—— 序言

 

成果

gitlab： https://gitlab.com/zhazhanitian/sl-background-sound

 

需求分析

　　最初的需求是作一個單獨播放專輯單曲的小程序背景音樂播放組件，一個專輯下有數目不定的單曲，單曲根據是多字段判斷是否能夠播放。然而由於小程序的 getBackgroundAudioManager 接口開始支持直播流後，需求改版，須要將直播間的音頻、歷史直播回聽也使用背景音樂組件來進行播放

 

設計旅途

　　開始設計組件之初只是瞭解了一波需求，而後就根據需求來寫component，寫着寫着發現好像偏離最初的需求—組件，在開始寫的時候徹底沒有理解清楚什麼是組件，組件存在的意義又是什麼，因此開始時寫得一團糟。

　　發現問題固然接着就得想辦法解決，至此我直接中止了組件的繼續編輯，先是認認真真的從新瞭解了一些組件的設計思想，設計原則，組件存在的意義，組件應該承擔的責任。而後又向組長虛心求教了一波，當時大神的一句話至今猶記心中，大神：「組件就是功能的提早，也就相對於一個大一點的方法而已，要麼高業務，要麼低耦合」，當時聽得一臉茫然，歷來都只聽過組件要低耦合，還沒據說過什麼叫高業務的邏輯，大神看我一臉小菜鳥的樣子就知道不理解咯，就給我解釋了一下，經過大神的講解大底理解是，「高業務就是設計一個符合某種很是少見的狀況的組件，這種組件自己侷限性很是高，不少業務邏輯都涉及到了組件內部，複用可能性很是低，若是將其作成低耦合的組件可能會出現成本過高，維護困難等狀況；而低耦合則是儘量的減小組件涉及到業務邏輯，業務儘量經過配置傳入組件內部，組件經過發射事件來想外部傳遞信息，固然這種組件的複用率相對高不少，侷限性相對較低」。

　　有了相關知識的支撐，再次來到當初的斷點，也再也不以爲無從下手，原本以爲可能要逾期的項目沒想到最終提早完成了任務。

 

設計感悟

　　有了此次親身體驗完整過程，感觸頗多，本身也摸索出了一套流程，大致就是：

　　一、瞭解需求及使用場景，只有足夠了解了需求和場景才能作到成竹在胸，不至於開發過程當中出現偏離

　　二、肯定是高業務仍是低耦合，這一點只要第一條作好應該就無壓力

　　三、需求細化，先理出一個大綱，而後一點一點的塞入組件中

　　四、自測、兼容、優化，這個固然不用多說，基本的開發環節

　　固然上面的流程給人的感受可能就是一一個字—虛，我也以爲。不過我給它的定位是隻是招式而已，徒有招式沒有心法固然難以立足江湖，若是外加在下的成名絕技—「謀然後動」，嘿嘿嘿。。。