以前一直听说组件的编写要高封装、低耦合什么的，对此完全没什么概念，只能是凭着自己的理解去写，但是写完也没有人给出评价，也就没啥感悟可言，这两天老大让我弄一下小程序的背景音乐播放组件，在老大的领导下也算勉强合格的弄了出来，特此记录感想。
—— 序言
成果
需求分析
最初的需求是做一个单独播放专辑单曲的小程序背景音乐播放组件，一个专辑下有数目不定的单曲，单曲根据是多字段判断是否可以播放。然而因为小程序的 getBackgroundAudioManager 接口开始支持直播流后，需求改版，需要将直播间的音频、历史直播回听也使用背景音乐组件来进行播放
设计旅途
开始设计组件之初只是了解了一波需求，然后就根据需求来写component，写着写着发现好像偏离最初的需求—组件，在开始写的时候完全没有理解清楚什么是组件，组件存在的意义又是什么，所以开始时写得一团糟。
发现问题当然接着就得想办法解决，至此我直接停止了组件的继续编辑，先是认认真真的重新了解了一些组件的设计思想，设计原则，组件存在的意义，组件应该承担的责任。然后又向组长虚心求教了一波，当时大神的一句话至今犹记心中，大神：“组件就是功能的提前，也就相对于一个大一点的方法而已，要么高业务，要么低耦合”，当时听得一脸茫然，从来都只听过组件要低耦合，还没听说过什么叫高业务的逻辑，大神看我一脸小菜鸟的样子就知道不理解咯，就给我解释了一下，通过大神的讲解大底理解是，“高业务就是设计一个符合某种非常少见的情况的组件，这种组件本身局限性非常高，很多业务逻辑都涉及到了组件内部，复用可能性非常低，如果将其做成低耦合的组件可能会出现成本太高，维护困难等情况；而低耦合则是尽可能的减少组件涉及到业务逻辑，业务尽可能通过配置传入组件内部，组件通过发射事件来想外部传递信息，当然这种组件的复用率相对高很多，局限性相对较低”。
有了相关知识的支撑，再次来到当初的断点，也不再觉得无从下手，本来觉得可能要逾期的项目没想到最终提前完成了任务。
设计感悟
有了这次亲身体验完整过程，感触颇多，自己也摸索出了一套流程，大体就是：
1、了解需求及使用场景，只有足够了解了需求和场景才能做到胸有成竹，不至于开发过程中出现偏离
2、确定是高业务还是低耦合，这一点只要第一条做好应该就无压力
3、需求细化，先理出一个大纲，然后一点一点的塞入组件中
4、自测、兼容、优化，这个当然不用多说，基本的开发环节
当然上面的流程给人的感觉可能就是一一个字—虚，我也觉得。不过我给它的定位是只是招式而已，徒有招式没有心法当然难以立足江湖，如果外加在下的成名绝技—“谋而后动”，嘿嘿嘿。。。