Review&Refactor 张 戈 2015.12.05 在短拍这边主要工作的总结 来YY这么久了就没有写过一些实际性的PPT（分享给大家看） 张 戈 2015.12.05
目录 工作概述 视频生产流程重构 断点续传 本地视频 录制 编辑发布
工作概述 搜索本地视频 滤镜编辑 话题分类 录制视频 配乐编辑 平台分享 图片合成视频 标签编辑 发布上传 欢聚云SDK 录制、转码、截图 视频特效 续点上传 HttpRequestManager BS2欢聚云点播服务 后端支持 神曲Web后端服务 神曲Service后端服务
重构做了什么 从录制到发布的流程控制设计 断点续传状态机 录制，编辑的MVP模式 本地视频搜索 其他小点： 去掉废弃的业务代码，更改不规范的变量命名，方法命名，类名，布局文件名，布局id名，规范化所打的日志，包括等级，适当的时机，日志的标记，延迟加载view，布局overdraw问题，层级优化…………. Core层一些sdk的回调，http网络回调，协议回调，FileRequest的回调，都是使用UI线程的Handler处理的，如果我们的操作不涉及UI，就用ScheduleTask来处理。 每重构一个地方都要跑一次测试，并通知测试进行回归。 一直都在改善代码，从未停止………
重构前存在的问题 毫无面向对象的思想，尽管我知道，但是代码里面全都是面向过程的步骤，何来封装？何来抽象？何来多态？何来继承？只会模块化分成多个方法（函数），或者抽取一些通用的代码到工具类里面去而已。 所有的代码都写在同一个类里面去了，录制两千多，编辑三千多，发布一千多，上传两千多，cameracore三千多 虽然有把代码抽离成多个类，那纯粹是类的抽离而已，没有做到真正的模块独立性，时间长了依旧会变成几千行，耦合性依然越来越大。 在开发需求的时候，速度很快，很直观，流程化地完成工作，毕竟同步总比异步易于理解，代码也易读，但是时间久了，需求再反复地变化了，出现bug维护起来简直痛不欲生，完全忘记了之前为什么写这么烂的代码，如果让下一个人接受，肯定得到一篇骂声。 这不是知识，也不是智商的问题，是态度和意识问题，总是想着现在简简单单完成需求功能，没有意识到怎么去设计让自己的代码更加合理。不要等到以后重构再做这样的工作，带来的开发和测试成本也不低
视频生产流程 话题 大于2M才转码，后来改成所有都转码 本地视频 转码 带有话题和跳转路径？ 区分合成的视频有没有加特效 放弃编辑？ 首页等入口 录制 编辑 合成 发布 只保存录制的高清视频？ 放弃发布？ 带有话题，发布成功回到本页面？ 保存本地/发布 图片合成 本地作品 web
出现问题 逻辑复杂，不好理解，原本只是一个简单的流程却变得极其复杂 耦合度太高了，牵一发而动全身，之前温灿改一下代码就导致本地视频被删除了。 实在不易于维护和扩展，假设需求又增加一个入口，那么又必须去修改后面流程的每一个步骤，并且不能应该影响到原有的功能 ………
重构的设计原则 解决方法： 注意录制，本地视频，本地作品，图片合成，编辑，发布这些都是独立的模块，是需求只是调用这些模块来完成视频的生产发布而已。于是想到工作流的模式，但是这些模块都是Activity的界面，是系统管理的，想要在工作流中用拦截器是比较困难的，想用代理模式的，但是代理activity是插件化的黑科技，引进的东西会比较多。 最后采用的是策略模式，一个工作流也就是一个模块，或者多个模块组成的策略流程，这有点像递归的抽象思想，比较像进程的fork机制，父进程可以跟子进程通信，这里的父workflow也是可以跟子workflow通信的。 这肯定是把简单的东西复杂化了的，不然就不叫设计模式了。 低耦合，高内聚。每个模块都只干自己的事情，所有的控制都交给策略。 在不改变原来的逻辑前提下新增逻辑，而且不会引入新bug。 并不是说简单调几行代码就是很好的设计了，那样耦合的逻辑太多了，容易出现问题，虽然是看起来开发简单，实际上带来的维护成本很高了。更好的方式是开放更多扩展性的接口让开发者去编程，而不是写几行代码来调用方法。 工作流策略只是控制工作流，入口跟出口参数，未来如果可能希望重构策略可以控制界面。 父工作流策略知道子工作流采用什么策略，实际是父工作流指定子工作流的。 代码会越来越多，但是多而不乱，新增一个需求的成本比以前（仅调用方法）要高，但是带来的维护成本低。
工作流+策略控制 工作流 录制策略 编辑策略 发布策略 …….. 录制模块 编辑模块 发布模块 录制完成以后直接分享出去，或在IM发出去，或直接上传，或直接发布 编辑完成以后直接发布上传 直接编辑某视频 直接发布某视频 假设编辑完成以后，红灿有一个奇葩需求，再进行一次编辑处理，那么就需要新增加一个模块了。 ……..
断点续传 总体的短视频上传和发布设计归纳为下图
上传有限状态机
END Thank you