从加班论客户端开发中的建模

本文来自网易云社区

作者：孙建顺

互联网公司的“996模式“常被人们津津乐道，尤其是开发岗位的加班现象尤为严重。细细想来，导致加班的原因大致分为如下几条：

1.突然收到BOSS的特殊指示，需要在短期内交付产出；

2.市场迅速扩张，导致现有系统在新的形势下千疮百孔，到处打补丁导致加班；

3.系统积重难返，维护成本居高不下，甚至到了岌岌可危的地步，不得已挤出时间来重构；

4.对需求理解不够深刻，导致预估不足，为了达到誓死不延期的目标不得不加班。

对于第一种情况很难避免，后面三种情况，都可以通过技术手段的深耕细作得到解决。那么如何操作呢？最好的办法就是踩在巨人的肩膀上，直接获取成功的经验。但是千人千面，每个项目都有自己的特点，每个团队人员的组成不尽相同，很难像工厂里面的生产线一样直接Copy。在这个过程中，只能是各自摸索与实践，本文就从客户端建模这一点展开来讨论一番。

在接触了大量的客户端软件之后，发现一个普遍性的现象，互联网产品的客户端开发不注重建模，面向对象思想体现的不够，从而导致对需求变动的应变性差，对服务器接口重度依赖，改动代码往往牵一发而动全身。为何会如此呢？大概是这两方面的原因：1.风气；2.人员。

风气：自从小米取得成功以来，雷布斯的七字口诀，得到了广泛的传播，其中有一条就是“快“。没错，“天下武功唯快不破“，但是在追求快速的同时，往往忽略了“稳“。若以周为时间单位来衡量的项目进度，“快“跟“稳“是矛盾的，“稳“要求的是稳扎稳打，打好根基，在短期内势必见效没那么快。若以月为尺度去衡量的话，其实开始的稳扎稳打是事半功倍的。在目前的形势下，互联网产品大部分的业务基本是有规律可循的，完全可以做到“稳“。

人员：随着近年来移动应用的火爆，从业人员大量涌入，很多并不具备专业技术背景的人员跟随着互联网的大潮坐上了移动开发的位置。由于移动应用开发门槛不高，大部分与计算机相关专业的在校生经过短期的强化学习基本都能入门，从而导致开发人员的水平参差不齐。没有受到良好的入门熏陶，很多人甚至不知道建模为何物，只听说过面向对象，虽然用的是Java语言，写的却是面向过程的代码。

下面以云课堂Android客户端的实践经验为例，从下面几个方面描述客户端开发过程中建模问题。

1. 模型是核心

在线教育领域内最为重要的概念即为课程，其他一切概念均可认为从课程模型衍生而来。从策划的角度去思考会有很多产品上的概念存在。例如微专业、系列课程、课程、学期、章节、课时、单元；课程类型又有模拟真实学校学期制逐步释放内容的开课形式，以及资源打包性质的普通课程形式等等诸多概念。若程序设计时没有针对策划的需求进行详尽的分析，草草上马就会导致引入诸多不合理的模型。比较典型的例子就是不同的开课形式构建两套不同的课程模型，短期内可以应付需求的交付，从稍微长远来看，存在代码无法融合，概念无法统一，即模块不能达到很好的复用效果，甚至抽取模块都需要大量的改动。可谓是从源头上埋下加班的祸根。另外一个典型的案例就是很多相似概念没有抽取出其共同的本质特征，引入了不必要的模型，增加了系统的复杂性。例如在程序上引入了微专业、系列课程、学期、章节、课时这些来自策划的概念，其实仔细分析它们的共同本质无非就是真正的资源以及资源的容器，将这一切均归结到一个概念体系下模型将变为及其简洁。更深层次地去思考，所谓资源的容器其本质也是资源，只不过是组合型资源。如此一来所有的概念就归结为资源一个概念，其他的策划层面的东西都可以通过派生或者组合到资源体系之下，也具备了足够的扩展性，为后续处理需求的变化奠定了坚实的基础。

2. 分离网络请求模型

由于客户端处于产品线中的末端位置，其建模更容易被忽视。很多App都没有模型的概念，完全依赖于后端建立的业务模型以及网络请求传输回来的数据模型。直接在App层面处处使用数据传输模型，对于接口设计时比较讲究的团队也许还能忍受，不过其中的沟通成本，接口的维护成本还是会居高不下的。一旦遇上与后端并行开发，或者当接口有所调整时，则会让客户端的代码处于非常被动的境地。不停地会去调整代码，虽然此种调整难度不大，不过这种由于架构上对网络传输模型的强依赖，对于客户端开发人员来说始终是如鲠在喉。因此，我们在云课堂开发过程中为了彻底解决该问题，在客户端进行了重新建模。客户端拥有属于自己的模型体系，网络传输只是作为一种数据源，仅此而已。

    收益：适应接口调整（迫于服务器性能压力、系统重构、版本升级等诸多不确定因素接口总是会升级的）

    付出：多一步数据模型转换操作（数据模型转换有一些常用的手段跟技巧，操作也不是太麻烦）

3. 分离数据存储的模型

项目刚启动时，往往对数据的缓存要求比较低，随着对用户体验的追求，App需要支持离线使用的场景会越来越多。一旦涉及到数据的存储，随着数据量的增长，对读写性能的要求便会随之产生。而业务模型或者数据传输的模型一般来说并不符合能够支持高性能的数据读写的特点。假设在项目之初没有分离存储模型的设计，那么当产品发展了，重构是无可避免的。在产品高速发展的过程中同时又要投入人力去重构，只能得出一个结论——加班。

    收益：适应存储变化（为存储优化与扩展留下足够的空间）

    付出：多一层面向存储的模型结构（可以只定义好接口并简单实现，待到有需要时强化实现）

4. 分离视图展示的模型

在客户端开发中最常见的设计模式MVC，将视图与逻辑分离，想必大家都能有所了解。现下流行的MVP、MVVM等模式也是基于MVC思想的进一步衍生与发展。但是很多时候很多人员都是将视图模型等价于领域模型去对待，并没有真正意义上的根据视图去抽象出其固有的模型概念，只是将其它模型做简单的裁剪或者字段扩充，并未真正理解何为视图模型。所谓的视图模型其根本是基于视图去抽象的模型。例如TextView是一个视图，其可以支持配置颜色、字体大小等属性，这些属性事实上都是基于视图本身的，而非给予某项业务来设计的。只有做到这样，设计出来的视图才具有最高程度的可复用，任何模块或者产品想要使用的时候，可以直接创建对象直接使用。

收益：高度可复用（根据视图去设计符合其自身属性的模型）

付出：摒弃业务相关的概念，提取本质的特征建立视图自己的模型

事倍功半 VS 事半功倍

上面提出了四点模型相关的观点，无可避免会增加一些开发工作量，也许有人会觉得把简单的事情做复杂了。经过云课堂客户端的实践证明：利大于弊。需要多花的时间一般来说 不会太多，对于一周的开发量来说是增加几个小时的工作量，但其收益是深远的。如果不这么做，后续的维护成本往往都是以天数为衡量，甚至需要一个完整版本周期去应对代码的改动。况且这些设计都是在计划内去完成的，而在后期由于代码无法适应而导致重构往往是计划外的事情，因此这对于整体的开发体验以及项目风险都有比较好的正向激励作用。回到话题之初，这样做给项目开发人员带来的直接收益就是减少加班。

网易云免费体验馆，0成本体验20+款云产品！

更多网易研发、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 双11背后的黑科技：大数据实时计算如何为你量身定制？
【推荐】 abtest-system后台系统设计与搭建
【推荐】 HBase–存储文件HFile结构解析