本周工作思考

AI生成课程介绍的功能中，文本编辑器是很重要的技术支撑，目前方案有2个，1是textarea的plain text编辑，另一个rich text的富文本编辑，通过调研发现现在涉及文本自由编辑的工具基本都实现了富文本编辑，还有一部分内容工具实现了协同编辑，对目前这需求来说，plain text也能勉强满足功能，从功能实现的完整度，难易度上看不如rich text方案。因为目前使用的ueditor编辑器从二次开发，性能，复杂度，稳定性上已经远远落后于现在市面上的同类产品，这次调研了ProseMirror，tinyMCE，slate.js等三款富文本编辑器，分别从技术原理及先进性，发展脉络，社区情况，哪些大厂在用，定制扩展能力，开箱即用的能力， TS支持，上手能力，中文开发资料的丰富度，和我们远期目标的匹配度上，ProseMirror无疑更适合我们，同时大家天天用的Anasa上的富文本编辑器也基于ProseMirror开发，后续我们也会基于proseMirror开发属于UMU产品的富文本编辑器。

今天是2024年的儿童节。距离上次写点六一儿童节的文字已经过去了整整10年北漂的日子（十）- 致我们终将逝去的童贞。

十年转瞬即逝，自己长大了许多，感慨却少了很多。这个日子不能说特别，只是很卡点，在这一天晒晒自己的内心，抒发些情绪，虽然没有别人在乎这些小心情，不过我想未来的自己也有想了解过去的自己的时候吧。现实中童真童趣离我们很远，很多的空闲时间被各种短视频充满，让我停止了思考，停止了回忆，甚至停止了发牢骚。扔掉手机，回到自己的世界，我想起20年春节，父亲带着他的孙女孙子们堆雪人的场景，我第一次在一个七十多岁的老人脸上看到了童趣。我希望当我是老年人的时候，也能保有一份童趣。

似乎很多节日都是为了纪念。但是很多节日的内涵在时间中的嬗变巨大，人们可能已经忘了节日的初衷。不过节日赋予了时间以具象，让时间可以被触摸，让时间可以被度量，让时间可以被回忆，也让平凡的人生多了一些可视化的褶皱。

今年的儿童节，让我多了很多思考。这个世界现在非常不太平，各种剧烈的矛盾开始显露出水面，俄乌战争，巴以战争正在进行，战争的乌云已经慢慢的聚拢，我不知道十年后的六一儿童节我们的孩子们会不会在战争中度过。

每个人都渴望和平，但是历史告诉我，和平和战争是整个人类的双胞胎孩子，这两个孩子都是被人类在细心呵护着成长。人类不止有和平，还有战争，和平和战争都是人类这个物种进化发展的方式。身为个体的我们，要在战争中保护好自己的孩子，要在和平中教育好的自己的孩子。

今天我送给孩子的礼物是，一个关于中国老一代顶尖科学家们的传记系列书籍。

希望他能通过了解学习老一辈科学家们波澜壮阔的的一生，过好自己的一生。

我希望他能通过经历过战争的老一辈科学家，老一辈的人们在面临战争，面临生死存亡之际，让自己如何追寻求知之路，如何坚定生存发展之念，如何秉持爱国爱家之心。我希望他能理解世界的复杂残酷，但是求知却又是那样的单纯，享受和平，不能忘却战争。我们不只有和平的生活，也会面对实实在在的战争的残酷。

生存，求知，发展，奉献，这才是孩子真正需要建立的大世界观，也是人类能在这个蓝色星球上能够存在的最高法则。

我给自己的礼物是一句话，保持童真。

人到中年，不管是身体还是灵魂都包裹了一层盔甲，这层盔甲能让我们这个世界上能够存活下去。保持童真就是让我们时不时的卸下这层盔甲，看看盔甲里面的自己。

保持童真，可能就是要保持初心。初心是自己所欲所求最根本的看法和出发点，初心是最有力量的，它不受现有世界规则运行的束缚，它是内心里的主宰，你站在灵魂之外审视自己的处境，审视自己的所思所想。初心会看着你的身体，看着你的精神。让你不迷失这个大森林，让你对生存充满大智慧。

保持童真，可能就是要坚定信仰。人生路上，苦难，挫折，顺遂，失败，成功，病痛，死亡都会一路相随，坚定信仰，不要让这些把自己打倒。

保持童真，可能就是要保持快乐。快乐是人生的动力源泉。童真是快乐的源泉，用清澈的心灵思考这个世界，才会让你在看清这个世界的真实之后仍然能坚定而乐观的生活下去。

不管环境如何变化，保持童真，才能勇敢的挑战那些不期而遇的磨难。

本周工作思考

提升保持专注的能力，本周的有了更多可以自己控制的时间专注的做开发上工作，感觉很充实，也很有效率，如何让自己保持专注，如何让团队保持专注，我觉得是一项非常重要的能力，我尝试过很多的方法，比如训练自己快速的切换工作模式，早上或者或晚上让自己有足够的时间，给自己设置工作计划，日历上设置工作排期等等，效果有一些，没有特别突出的，现在想想，我觉得可能有时候缺乏从容的态度，从容的专注，才能让自己既放松又紧张，保持较好的记忆力和创造力，同时又比较有激情，这样能比较轻松的解决有挑战有难度的问题，而这种状态产生结果又会让自己更加从容和专注，所以以后还要让想办法让自己变的更从容一些。
从团队角度上看，我还注意到一个情况，有时候保持专注不是一个人的事，我们部分工作需要即时性的协作和沟通才能做好，并且有的是需要立即响应并且出结果，很多时候时候我们在沟通和协作的机制里，你很难为了让自己保持专注手头的上工作，因为事情的优先级不同并且我们身处在某个需要快速处理的协作流程里，很难对这个协作流程Say No，会被推着放下手里正在做的工作，转向去做另外这件事情。可能的解决办法之一就是尽可能少的让自己身处这种需要及时响应处理的协作工作流里，当然也不能因为自己要专注工作，而影响了需要即时协作的其他伙伴的工作。
团队作为一个整体要有排除干扰的组织能力，保证整个团队的专注度最佳，这是保证团队按照计划进行的强执行力和高产出的重要基础。所以在团队内每个月有一两位伙伴可以解决各种需要即时响应的工作，让团队的其他伙伴保持专注按照计划确定性的工作，是一个最佳实践，目的就是让保证计划的执行。
另外的一个思考是一个月有4个周，至少要保证2个周的处于计划执行时间，所以我倾向于需要大量协作，沟通，会议，多人协同的工作放在第1周和第3周，而第2周和第4周保证90%的时间由自己控制，专注的完成OKR的工作。从敏捷开发的经验来看，一个sprint两周，大部分情况是一周的协调，会议，设计，评审，计划，另外一周就是完全的执行和少量的沟通，当然团队必须有一两位伙伴随时切入需要即时性的工作给大部分伙伴留出这种专注性的可能性。

本周工作思考

Q1疑难问题排查的总结
我理解的疑难问题是不容易复现，或者目前无法创造复现条件的Bug；
Q1 Web端陆续收到20个左右的疑难bug，包含，音频处理，视频处理，pdf文档处理，Scorm展示，Dom渲染，富文本编辑，时长打点，长连接，图片格式兼容等
视频处理疑难问题包括：
无法拖动回看
黑屏显现
视频点击播放无反应
极个别第三方浏览器自带视频播放无法禁用下载
音频处理疑难问题包括：
语音微课录音有爆音
语音语速突然加速
富文本编辑类包括：
语音微课的silde丢失
AI微课大量输入文本后的光标位置异常
文章小节编辑内容时，工具栏消失
pdf文档处理包括：
字体笔画缺少，模糊
乱码展示
个别手机上某页白屏，卡顿
Scorm展示包括（部分机型和第三方应用上必现，但是方案不完善，也列为疑难问题）：
尺寸适配不合适
内容不展示
Dom渲染包括：
课程目录页小节列表白屏
循环接口请求
时长打点包括：
打点丢失
长连接
问卷逐题互动，数据提交后，大屏幕数据无法更新
在修复优先级安排上，我们按照影响度和业务价值安排，业务价值大，对用户影响大的，用户反馈强烈的，我们重点跟进，优先解决；另外的问题则进入正常排期或者和大项目穿插处理
在解决方法上，这类问题修复难度一般比较大，花费的时间比较长，有的需要整体的方案解决，有的临时性解决，有些目前无有效的解决办法
目前的进展，PDF的问题在2月份和3月份做了专项处理，实现了Canvas，SVG，Image三种形式的展示方案，能够解决80%以上的pdf展示疑难问题；Q2我们会抽出时间重点看语音微课和AI微课中的音视频相关的疑难问题，其他问题则按照排期进行
这类问题的难点和挑战，
1是复现难度大，找到复现条件需要较长时间的深入的观察和分析，需要丰富的测试经验，充沛的测试条件，反复的探索和验证，用户的耐心和支持，还需要一些运气；
2是解决难度大，解决这类问题，不确定性因素多，需要大量的研究和探索，需要大胆的想象假设和严谨的推理求证，需要深厚的技术沉淀，需要多人协作，还需要一点技术悟性，最后可能还找不到完善的方案
3是解决成本较高，一些疑难问题经过研究后，可能需要方案性的解决，方案性的解决意味着为了解决这个疑难问题，我们可能要将现有功能推倒用新的技术重新实现，或者要牺牲掉其他的一些特性，或者比较长的开发时间；
我们如何应对
首先要积极务实的面对，这些疑难问题不是我们的累赘负担，而是有待我们开发的矿山，因为我们碰到的这些问题，友商的产品也会碰到，如果友商产品没有碰到，那也是我们学习探索，提升产品技术性能的好机会；如果友商产品也有类似问题，我们率先解决了，那我们在这块的技术竞争上就是领先的了，另外这些疑难问题，也会推动我们今后在技术选型，技术设计上更加谨慎，更加合理；
在今后的技术选型和设计开发上，做更严谨的调研，更完善的实现，多关注异常Case，做好关键步骤的日志记录
一旦识别为疑难问题，开发人员快速及时的介入，因为疑难问题拖的久一点，用户的配合度，测试的复现可能性都会减低，那这个问题的解决可能性也就极大的降低了
做好和客户的沟通和说明，哪家产品都会遇到难以解决的技术问题，我觉得可以以坦诚的态度，专业的视角和用户说明，一是我们会尽全力解决并及时同步解决进度，二是想其他办法绕过疑难的问题，解决用户的使用的问题，让用户用其他办法用起来
要切实提高整体的Web技术实力，对我们来说，前端不仅仅是“画页面”，也不仅仅是拉数据展示数据的页面级别“CURD”，我们的实现大量的使用了最新的音视频技术，复杂的富文本编辑和文档展示技术，支持多平台多语言的兼容性，较大规模代码量的业务逻辑设计，具有较丰富交互的用户体验，而且未来会更多更深入的使用前沿的Web技术以满足不断增强的用户需求，这些都要求Web组的伙伴们要有较高的技术水平，比较深厚的技术沉淀，才能接着住这些挑战和难题

本周工作思考

对当前Web前端技术设计工作的现状的总结
Q2和Q3Web前端持续专项解决如何降低线上bug的问题，这个我们会分为几个方面，包括提升代码及技术设计质量，提升需求功能实现度，优化CSS模块化写法，通过优化现有工程架构提升自测的效率，提升i18n的自动化水平等；
技术设计是我们会持续加重关注并持续深入一个动作，但是目前我们也会存在如下几个问题，主要体现在以下几个：
大部分技术设计停留在概要设计阶段的初期水平，基本包括主要功能简要说明，主要模块拆分，基本开发和排期计划，关键技术决策的简单说明；
大家普遍对技术设计的必要性认识不足，大概能听到几种说法， 第1种是说，这个技术设计文档写完了谁会认真看啊；第2种是说，写啥文档啊，浪费时间，有那个时间好几个组件都写完了，第3种是说，就是个形式，简单写点就好了，第4种是说，这个功能这么简单，没必要写技术设计啊；第5种是说，要写设计文档啊，有模板吗；
大家普遍不能清晰的描述理想中的，有用的，高要求的技术设计到底是啥样子
大家普遍不愿多花时间在项目前期做技术设计，主要考虑是投入产出低，即便写了感觉也没啥用；
很多技术设计没有切中要点，为了写而写，很多技术文档按照格式填空，反正是开放式问题，没有标准答案，于是技术文档参考来参考去，最后越来越水，越来越不实用，越来越觉得写技术设计文档没有用
针对以上的问题未来一段时间我们会逐步落地一些措施：
要求重点项目及重要的优化的的技术设计做到详细设计的层次并做严格的评审，包括关键技术决策，关键组件和关键思路的详细说明，使用一些常见设计工具，比如流程图，类图，组件结构图，时序图，逻辑视图，层级结构图等辅助说明设计
线上bug会和被引入的重点项目和重点优化点挂钩，反推技术设计的的那问题，引导大家从技术设计的角度规避线上bug，也通过经验来提升大家的技术设计能力
修改技术型和逻辑型bug先看产品设计文档和技术设计文档，以设计迭代的思路修复bug，保持技术设计的生命力
对重点项目及排期超过3天以上的优化点，改变边开发边设计，边改bug边设计的思路，逐渐变成先设计再开发的开发的模式；

本周工作思考

参加北京客户大会的点滴思考
全程认真的聆听了每一位嘉宾的演讲和分享，平时很少参加这样的活动，每次参加都十分珍惜，也受益匪浅，一点点不成熟的思考和大家分享
关于沟通和演讲，虽然每人分享的主题不同，但是每一位嘉宾在台上都是神采飞扬，自信沉着，思维清晰，吐词清楚，语速适当，控时准确，台下的我也会假设如果我在台上能否做有这样优秀的表现。在平时的沟通过程中，我发现我经常脑子和嘴对不齐，有时候会吐噜嘴, 有时候表达结构不清晰，有时候用词模糊有歧义，有时候嘴快于脑，没过脑子话就出嘴了，有时候逻辑不严谨，以上的种种问题会导致沟通效率偏低，甚至是负面的信息放大。我觉得在以后的工作中的言语沟通中可以尝试以演讲的技术和标准要求自己的语言沟通，虽然日常工作面对的场合不同，但是还是有一些共性，就像演讲嘉宾表现的一样，我想说话的时候思维里要有2个线，一个线是说话，清晰的吐词，不吞音，不漏词，不抢词，另一个线是不断的对说出去的话和没说的话做Review和重新整理，保持结构的完整和一致性，说之前要先快速的打个草稿，包括理解上下文，理解语境， 定一下中心意思和用意，结构和逻辑，用词，语气，语速，静一下心气。做到这些很难，但是看到嘉宾们榜样在前，只要有意练习自己的现状应该会有所改善。
关于产品使用，真心的很佩服我们的用户们，他们创造性的设计和使用，让代码的价值放大了很多倍，我甚至都觉得我们的代码因用户的灵活的使用而拥有了灵魂和生命的色彩，我喜欢这样富有创造力的用户们，我们和他们会相得益彰，创造实实在在的经济效益。让我感到意外的是两位嘉宾都提到了班级这个功能，我平时也会想一些如何增强产品功能的小点子，但是有很长时间没有关注班级了，我突然觉得我还是没有沉入业务场景，这可能是专业上的差异，但这也表明我对培训行业的理解还十分浅显，以后还要多沉在客户需求群，多看行业杂志，加深对业务的理解，这样才能更好指导在业务代码架构上的长远设计和思考。
关于AI飞轮，AI已来，或多或少的都会影响我们的工作和思维方式，我在思考一个命题，我们是在赋能AI还是AI赋能我们？在我个人看来，AI会持久且以温水煮青蛙的方式影响我们的工作生活方式和思考习惯，我们是让AI插上UMU的翅膀，还是UMU插上AI的翅膀，尽管我不知道最终的答案，但是显然我们现在在和AI一起飞翔，我觉这是一次AI的技术红利，AI技术可以用在UMU的各个功能上，比如学习圈的内容生成，比如拍照小节的照片生成，比如语音微课中语音和图片的相互生成等等，可想象的空间很大，chatGPT的优势是内容生成，但是她缺少互动，而我们的优势就是丰富的互动，这是完全的互补，从这个角度讲，我们天生具有和chatGPT的互补优势，虽然我们探索的路还很长，但是我们的天然优势会让我们牢牢的和她（AI）一起飞。

本周工作思考

关于本周的线上问题讨论会的思考
本周的和web组其他伙伴一起讨论了大家线上问题的理解和分析，这次会议主要是各自分享各自的总结或者经验分享， 从各自的开发的视角做了比较充分的讨论，从分类上看大家提到比较多的是：多语言适配，UI和UE类问题，可复用性问题（经验，规范，流程，组件，模块，功能，样式模块的复用能力及复用机制较差），这些问题都要找到切入点，从工程能力和研发能力上逐步去解决。
现在很多问题存在很长时间了，有些已经逐渐从量变到了质变的过程，需要系统性的改进，有些需要踏实而具体的措施去消除和规避，对我而言有点千头万绪的感觉，问题很多，要做的很多，也焦虑的很。虽然困难很多，大家对我们能否在下个半年是否做出有效的改进，切实减少线上问题，心存疑虑；
打消疑虑的关键是行动起来，做出效果。Q2和Q3我们做到的点，包括：
坚持细水长流的持续改进，不做大动作，把大计划拆成小动作，关注每月的小动作，小动作的累积效果就是我们的最后目标
平衡好业务开发和基建开发的投入和产出，工程技术部分的改进和迭代坚持做下去，这样才能保证基建迭代支撑研发迭代，研发迭代支撑业务迭代，工程基建和技术开发双腿走路，才能走的稳走的快
以专注的某个细点的策略建设好基础复用能力，包括经验，规范，流程，组件，模块，功能，样式，新人landing，每个月我们只专注一件事，直到做到新伙伴可以复用为止
严格对齐全团队的优先级安排和技术思路，避免出现不必要的折腾，浪费，把有限的精力的放在团队第一优先级的任务上

本周工作思考

线上bug修复的思考
1 线上问题经过漏斗处理，到研发这边的一般被确认为是需要代码修改或者需要开发人员分析排查的；所以到了开发侧的bug上，虽然被定级为P0，P1，P2，P3， 本质上讲都是比较严重的线上问题，因为都影响到了用户使用，损害客户既得利益和公司的商誉，进而影响续购率和订单率等公司经营核心指标；

2 截止到23年3月前端的线上问题数量上较多，最近半年的Bug总数如下，

月份
22-10
22-11
22-12
23-01
23-02
23-03（截止26日）
web端bug数
78
84
52
67
124
89

总数据上看，bug反馈数与单月用户工作天数成正比，也和用户使用频度成正比；
累计平均每人每月人的bug数是11.76，换句话说，Web组平均每人每月在完成项目交付的同时，也交付了12个线上bug，这么评价很扎心，但是作为Web负责人我不得不面对这样的惨痛的事实，而且还不是一蹴而就就能解决的，这个事实也不断在我的脑海里酝酿盘桓，也是我们Web组的心头大患：我们要如何系统性的根除这个大问题

3 按照 bug原因给这些bug分类，我们大概能分出20个左右的分类，包括，逻辑判断错误，逻辑实现不严谨，样式误用，样式被覆盖，功能补全等等，这也从侧面说明Web前端的现阶段工作面临的复杂性和挑战性，要兼顾的因素较多，功能的实现也是要考虑周全，这也从侧面说明为什么我们十分重视人才和团队的建设。我们追求C端的极致的用户体验，也必须追求B端的高附加的业务价值，这个要求不是我们给自己定的，这个要求是市场给我们的定，我们不这么做，我们就会死掉，就这么简单。

4 根据web前端22年，23年的路线图，质量部分的相应的规划和目标，也根据公司和团队的优先级灵活安排，也逐步有了一些落地效果和改善，虽然距离我们远景目标还差很远，不积跬步何以至千里，跬步已行，何忧不至千里呢； 在质量方向，未来2年内我们会坚定的有步骤有计划的推进以下四件事：
(1)搭建开发质量评估和优化体系
(2)完善并利用好前端可用的监控体系
(3)建议基于重点项目的质量跟踪及改进体系
(4)持续提升团队整体的技术水平和业务水平

5 近半年以来，在Web组伙伴们的共同努力下
(1) 我们逐渐开始建设bug分配流转等流程机制，逐渐提高bug的单月修复率， 季度修复率，单月达成85%的修复率的目标的月份也在不断增加，增加疑难问题Review，针对疑难的bug，定期和有关伙伴做专项的Review，加速技术性解决和方案性解决，尽量给客户以及时的反馈
(2) 不断完善bug统计机制，尝试从多维度去理解和分析bug产生的根本原因，推动对消除bug有影响的工程化和研发流程的完善
(3)尝试使用多种监控，提前发现功能bug和线上bug
(4)有意识的建立bug修复流程的Master doc，在排期，项目并行安排，提测代码合并，业务学习等方面做一些梳理和明确

6 未来六个月，我们专项系统性的解决线上bug问题，从开发理念，代码编写，工程化角度等以渐进的方式逐步做一些改进和提升，
（1）继续坚持执行和完善之前形成的最佳实践，
（2）执行技术路线图的规划，往深里走，往细处看，重点关注开发质量评估和优化体系的建设，特别是代码质量提升和bug原因分析；
以逐步解决以下我们的问题：
1 客户直接反馈的多
2 提前发现的少
3 内部发现的少
4 客户反馈问题的修复闭环不完善
5 bug溯源和分析粗浅，bug修复后没有明确的改进措施
6 重复性问题较多
7 部分系统问题没有及时的根本性解决
8 修复线上bug的研发侧附加收益不大
9 bug解决指南和流程不完善
10 解决紧急问题的流程不完善
11 线上问题修复及时性不高

本周工作思考

如何提高自己工作效率的思考
最近一两个月我都是每天忙碌，忙碌意味要处理应急的，非计划内的工作过多，最近几周都在记录自己每天都干了啥，如何改善这种应急的工作状态，经过反思和总结，我在几个方面做了改善：
1，总结一些工作模式的高效办法，提高效率，这一招是在《解密无印良品》上学到的，比如邮件工作模式，slack工作模式，工程例会工作模式，线上bug答复工作模式，Code Review工作模式等等，这些工作模式各自都有一些高效的小技巧多琢磨多总结，相应的会提高一些效率，比如Slack工作模式，因为我这加的频道有点多，所有的频道都看我觉得性价比不高，所以最高效的办法是定点看提及我的和@我的，有伙伴对我这种工作模式不利于一些工作的全面了解，所以我也尝试改善，在晚上的时间全部看完Slack消息，不过根本上要提高一下快速理解Slack上下文的能力和快速全面思考的能力；还比如Code Review工作模式，我会跟进代码提交人的不同侧重不同的Code Review的内容，不会所有的内容都去看，这样能保证我要关注的点始终是了解的；
2 快速切换工作模式的效率，比如从Slack模式快速切换到优化点开发模式，从工程例会模式快速切换到Code Review工作模式，这种快速切换可以不受时间控制，所以能够提高时间利用率，这个是受6顶思考帽的启发，这种6顶思考帽思想比较老套，但是很实用，在很短的时间内快速切换，也可以提高整体的工作效率
3 把应急的事变成常规的事，这个需要系统性的改进，第一个需要把当下的事情做到完善，第二个是把计划和执行做的彻底，把工作想的远一点深一点，做的细一点，第三个是把短期，中期和长期计划都排好了，提前做好准备
坦白来说，以上三个策略我也在修炼中，做的还远远没有达到理想状态，不过我想通过有意识的刻意改善我可以达到我想见到的那个状态；

本周工作思考

关于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提供了很成熟的视图设计模式，对于我们绝大多数复杂些的前端功能来说，把握两个基本设计准则就能解决很多设计困境：合理的分层和合适的命名，合理分层解决的关注点的分离就是扩展的问题，合适的命名体现了开发者对业务逻辑的理解程度和设计意图，分层包括组件内部的函数层次，组件间的调用，功能间的依赖设计，逻辑和逻辑之间的抽象和封装；命名则包括业务常量命名，重要组件，重要方法，重要服务类的命名，这两个设计准则虽然简单朴素却也能量巨大，与其花时间学习很艰深的设计模式和设计架构，不如把这两个设计准则吃透很准；