Question

·第1章　重构，夜未眠

·第2章　Android网络底层框架设计

·第3章　Android经典场景设计

·第4章　Android命名规范和编码规范

对于App来说，要么就一次性把它设计好，否则，就只能重构了。

什么时候做重构？作为App技术团队的负责人，我每次想到这一点，都会掂量再三。在我看来，产品需求是优先级最高的。开发团队要使尽浑身解数，优先完成这些需求。但这样一来，就没有时间做重构了。长此以往，积弊难返，代码会越来越难维护。

另一个更重要的问题是，现在互联网严重缺人，各大公司的各个部门都不饱和。也就是说，我们可能连需求都做不完，更不要提重构的事情了。

对于新项目，一开始就要把它设计好了，因为我们不会再有重构的机会了。互联网的发展现状是：没有时间给我们来回折腾。

对于老项目，我们就得掰着手指头仔细盘算盘算是否要重构：

1）如果不重构，会导致很严重的App功能问题，那么这是很严重的bug，宁肯砍掉1~2个功能也一定要修复的，需要和产品经理商量，由他们决策。

2）本次迭代是否还有空余的开发人员来做重构？有，就做；没有，也不勉强。同时，重构也会导致测试团队额外的工时，如果测试团队没有额外的人力对重构进行测试，那么开发人员就要把重构做在新建的代码分支上，本期迭代上线后，再把代码合并，放到下期迭代。

3）重构计划要事先给出，但是绝对不能超过两周，这对于重构小的功能是可以的，但是要重构大的模块或者底层架构，就要考虑拆分重构计划的事情了。我们可以把重构划分为几次迭代，分期上线，先把最严重的问题解决了。

当前移动互联网已经过了几年前的草创时期，目前各家公司比拼的都是内功，就是看谁做得细致。谁家的交互做得好，谁家的崩溃少，谁就占据了市场和用户，马虎不得。然而说得不客气些，目前市面上的App做得都很糙。

本书第一部分要讲的就是怎么设计App应用开发框架，怎么进行重构。

好戏即将上演。