一个Android应用对于用户而言由若干个界面构成，这其中不乏有界面元素较多、请求接口频繁、跳转逻辑复杂的界面。为了提高工作效率、减少出错率，我一直在思考一个问题：有没有一个生产线般的模型：第一步做什么、第二步做什么...有模有样的按照某种特定步骤，完成一个个类型各异的界面？功夫不负有心人，这样一个模型真被我总结出来了。特此记录，以便温习。
就一个模块而言
记得刚来公司，小白的我写到一个关于服务器数据展示的界面，简单的UI很快搞定，但OkhttpUtils.execute的执行并没有给我带回后台的数据。检查一番，代码没有问题，没有数据的原因是后台数据库空空如也。
我就笑眯眯地让后台大神添加一些测试数据。
大神则不耐烦悠悠的回答说，你为什么不自己添加？
项目经理见状，照顾新人的他给我说了一番话：发的接口文档要完整的看一遍，问题之所以出现，是因为我没有按照套路出牌。我要求添加的数据是从移动端收集过来的，这问题完全可以通过先实现数据收集性质的界面，调用数据收集性质的接口而解决。后台大神也是很忙的，不要因为流程问题而为后台增加哪些没必要的工作。
好吧，这确确实实是因为我没“经验”造成的。
在这之后，我就有了这样的理解：
- 产品流程图是为了理解某个模块的整体功能而存在的，是为了前期美工画出效果图而存在的，是为了后期按部就班的测试而存在的，而不是为了让码代码的我按照上面的流程导向依次开发界面而存在的；
- 对于有数据展示的界面，要判定数据是属于后台添加型还是移动端收集型。对于前者，让后台添加测试数据是理所应当的；但对于后者，还是应该老老实实的先实现数据收集型界面。
就一个界面而言
一个功能多，元素杂，跳转逻辑乱的界面，即使小心翼翼地把它搞出来了，它还是会一而再，再而三的拿出名叫bug的大杀器折磨我。
bug在很多情况下是难以消除的，但许多bug是由于我不良的编码习惯导致的。
代码体现的是我们的思路，是我们的解决方案。
我觉得：
- 没有按某种套路出牌的我，导致了很多bug的出现（即使我的思路很清晰）
- 与其等bug出来了消灭它，不如在码代码的时候就不要让它产生
- 实物产品通过生产线，一环套一环的来保证产品质量；代码作为产品，也应该具有通过某种流程生产，进而减少次品率的特性。减少bug的方法可以具体化，可以流程化，可以规范化
那么，该以谁为切入点呢？
我就扒我的代码，发现接口调用的方法体那叫一个乱：各种判断，各种跳转。
判断对应着不同的情形，情形之间操作紊乱往往是导致bug出现的原因。
此时脑袋里浮现出了：单一职责原则（Single Responsibility Principle）这一概念。不仅仅类的设计要遵循SRP，方法的设计也要按照SRP思想设计。
这里我将方法分为两种：
- 奴隶方法，负责具体某一个件事，比如播放一首音乐(A)，比如生成一张图片(B)，比如展示一张图片(C)
- 奴隶主方法，负责调用下级方法的方法叫做上级方法，比如依次调用B-C-A的方法
我发现了：
- 同一个接口可能会在不同的情景下被调用：可以是进入页面时候的例行调用，可以是用户的手动调用（比如例行调用获取数据失败的时候，比如分页数据的手动刷新和自动加载）...
- 接口调用有前、中、后三个阶段，不同情形的同一阶段，需要做的操作往往也是不一样的。
即：
- 同一个接口，接口触发的情形可以不一样
- 不同情形下，接口请求过程期间（收到响应前），界面的表现方式不一样
- 不同情境下，收到接口响应时对数据的展示方式也有不同（无数据状态切换为有数据展示状态，或有数据状态时候的的数据追加）
因此，即使是调用同一个接口，在需要的时候，也需要设计成不同的奴隶方法。针对一种情形而设计，减少判断，减少跳转。
结论
- 方法的设计目的要明确：奴隶还是奴隶主？
- 区分某个接口的触发条件（调用情形），每一种情形设计成一个方法
- 针对某一种情形，明确响应前和响应后的操作
网友评论