感悟篇之组件的设计

　　之前一直据说组件的编写要高封装、低耦合什么的，对此彻底没什么概念，只能是凭着本身的理解去写，可是写完也没有人给出评价，也就没啥感悟可言，这两天老大让我弄一下小程序的背景音乐播放组件，在老大的领导下也算勉强合格的弄了出来，特此记录感想。

—— 序言

 

成果

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

 

需求分析

　　最初的需求是作一个单独播放专辑单曲的小程序背景音乐播放组件，一个专辑下有数目不定的单曲，单曲根据是多字段判断是否能够播放。然而由于小程序的 getBackgroundAudioManager 接口开始支持直播流后，需求改版，须要将直播间的音频、历史直播回听也使用背景音乐组件来进行播放

 

设计旅途

　　开始设计组件之初只是了解了一波需求，而后就根据需求来写component，写着写着发现好像偏离最初的需求—组件，在开始写的时候彻底没有理解清楚什么是组件，组件存在的意义又是什么，因此开始时写得一团糟。

　　发现问题固然接着就得想办法解决，至此我直接中止了组件的继续编辑，先是认认真真的从新了解了一些组件的设计思想，设计原则，组件存在的意义，组件应该承担的责任。而后又向组长虚心求教了一波，当时大神的一句话至今犹记心中，大神：“组件就是功能的提早，也就相对于一个大一点的方法而已，要么高业务，要么低耦合”，当时听得一脸茫然，历来都只听过组件要低耦合，还没据说过什么叫高业务的逻辑，大神看我一脸小菜鸟的样子就知道不理解咯，就给我解释了一下，经过大神的讲解大底理解是，“高业务就是设计一个符合某种很是少见的状况的组件，这种组件自己局限性很是高，不少业务逻辑都涉及到了组件内部，复用可能性很是低，若是将其作成低耦合的组件可能会出现成本过高，维护困难等状况；而低耦合则是尽量的减小组件涉及到业务逻辑，业务尽量经过配置传入组件内部，组件经过发射事件来想外部传递信息，固然这种组件的复用率相对高不少，局限性相对较低”。

　　有了相关知识的支撑，再次来到当初的断点，也再也不以为无从下手，原本以为可能要逾期的项目没想到最终提早完成了任务。

 

设计感悟

　　有了此次亲身体验完整过程，感触颇多，本身也摸索出了一套流程，大致就是：

　　一、了解需求及使用场景，只有足够了解了需求和场景才能作到成竹在胸，不至于开发过程当中出现偏离

　　二、肯定是高业务仍是低耦合，这一点只要第一条作好应该就无压力

　　三、需求细化，先理出一个大纲，而后一点一点的塞入组件中

　　四、自测、兼容、优化，这个固然不用多说，基本的开发环节

　　固然上面的流程给人的感受可能就是一一个字—虚，我也以为。不过我给它的定位是只是招式而已，徒有招式没有心法固然难以立足江湖，若是外加在下的成名绝技—“谋然后动”，嘿嘿嘿。。。