感悟篇之组件的设计

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

—— 序言

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

转载于:https://www.cnblogs.com/zhazhanitian/p/9360535.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值