本周工作思考
关于MVC模式的思考
最近在修改视频播放器组件的过程中，目前的设计和实现存在一些不合理的地方，1是代码分层不清晰，UI层和Native层没有合理的分开，UI层中的各个UI部分没有合理的解耦；2是扩展点不清晰，设计意图模糊，如果要做一个需求迭代，不太好快速搞清楚如何迭代既有设计；3 修改麻烦， UI部分和Native解耦过度，分拆到了不同的包里，导致一个一处修改，多处部署；
前端H5播放器是很典型符合MVC的架构模式的例子，使用这种模式的关键点是主要三个分离，1是UI和Model的分离，2是UI和Controller分离，3是基础功能和扩展功能分离， 这里的Model就是播放进度，倍速， 播放时间，资源URL，码率，视频宽高比，字幕展示，播放状态，全屏状态等数据，UI包括，整体控制条，播放屏，字幕展示条，倍速控制，播放状态控制条，播放进度控制条，已经对对应Native Video的对应API调用等；UI很好理解， 就是界面布局，各种可以操作的元素，Controller不是很好理解，很多可见逻辑和不可见逻辑都在Controller里，主要职责是更改Model，同时同步更新UI；基础功能和扩展功能的分离这个比较难把握，首先哪些功能是基础功能，哪些功能是扩展功能不好界定，其实我们可以参照浏览器自带的默认浏览器功能为基础功能，其他都是扩展功能，从这个思路出发，字幕，倍速等都是扩展功能；扩展功能都应该以独立模块（插件）的形式注册到播放器系统，以类似微内核的机制运行插件实现功能扩展；
目前很多复杂功能的设计意图不清晰，导致很多功能无法实现设计的演进，进而导致所谓的“大泥团”的架构技术债的产生，在我看来，前端的React提供了很成熟的视图设计模式，对于我们绝大多数复杂些的前端功能来说，把握两个基本设计准则就能解决很多设计困境：合理的分层和合适的命名，合理分层解决的关注点的分离就是扩展的问题，合适的命名体现了开发者对业务逻辑的理解程度和设计意图，分层包括组件内部的函数层次，组件间的调用，功能间的依赖设计，逻辑和逻辑之间的抽象和封装；命名则包括业务常量命名，重要组件，重要方法，重要服务类的命名，这两个设计准则虽然简单朴素却也能量巨大，与其花时间学习很艰深的设计模式和设计架构，不如把这两个设计准则吃透很准；