原来想起的标题是记一次写业务的经历，想了想，做一个善于总结的人更为适合。
善于总结，所有程序员看的程序员鸡汤文里都有这个词，大家都觉得他很对，但是都没有思考过，有，也是思考的很浅。这个词在我这两天做业务的时候，冒出来了。
这两天我被复杂的业务逻辑搞的想哭。我这里先总结下如何更好地写业务。
我的自定义View，采用了3-4种方式去实现，并不是事先想好的，而是粗略一看，感觉这个方法和很完美就去做了，然后发现不行，需要重构，然后继续做，继续重构，是重构，不是修改。我为啥不能一开始就想出所有方案，然后比对各个方案，然后思考每个方案的每个细节看是否可能，哪个方案最优呢？这样一来我前期会话巨额的时间去分析，我不能上手就能code，我要等很长时间以后，1-2个小时后才能code。这在一般人眼里是不可想象的，1-2个小时，这个自定义View别人可能都已经完成了，你还在想？可是事实上，我花了1天左右的时间。想想你自己平时给自己的思考成本有几个小时？你给自己思考和code时间的比例是多少？0:100就是我之前的做法。正确的做法是100:0。业务逻辑，想透彻了，代码其实已经有了。
还有网络框架不允许新增ServiceCode。我想出第一个方法，hook uri的build。结果fail，因为我太粗心了，结果发现不行。后来换反射修改父类Request的url，成功了。当我第一次hook的时候，多开心，我想的是我能好好秀一波操作了，我当时真的是被蒙蔽了。所以真的白浪费这么久了。事先我就应该列举出所有方案并仔细研究比对的啊。
复杂的业务搞的我头晕。这个时候就要清晰地注释了，每小点都要注释，每大点也都要注释。同时code业务之前也需要想业务，甚至把业务用流程图都画在纸上，同时每个流程附近都要标注出所有细节，并且分清楚不同的功能模块。这样最后会发现注释和业务流程图的文字几乎是一样的。
更灵巧的测试。从gradle到install，到app操作一些列页面到达测试目标页，这一系列流程要很久。这个时候就可以用instant run加快，改路由获取参数让目标页面第一个出来。也要拥有更强的拿数据的手段，log好request、response或者用charles代理从而获取报文。总之，测试，在第一次的时候，应该是最花时间的。你不仅要想好这个功能怎么改可能好，还要想好这个功能到底哪里不行怎么才能一定好，我现在能获取哪些数据分析个透彻，后续测试的时候我一定要节省百分之90的时间在测试上。
可以损失点性能，让维护更方便，一次计算没有必要得出所有的数据。小数据操作对性能优化毫无影响，损失掉一点，将会获得巨大的清晰逻辑与架构，极大地方便维护。
这样一总结，我一定会在未来的任务中，以我现在10倍的效率工作！！我坚信。
这就是善于总结的力量，总结、剖析的越厉害，就能获得的更多，进步的更快。请务必把这个养成习惯。浅思考总结可能是无用的，低效的，深思考才能发现自己的一举一动，每一个思维，能否更好，快速让自己达成完美。