阅读此书痛快且过瘾，随着心态的越发浮躁，很难专注不开小差的阅读一本技术书籍，这本书是例外。
在工作中，除了编码，我最喜欢的事情就是思考如何行之有效的提高团队开发效率，由于自己阅历尚浅，很多想法都是纸上谈兵。每个人所处工作环境，项目的级别分量、研发文化都迥然不同，当你的研发生涯的某个阶段里，项目比较普通，管理比较混乱时，都不要放弃对规范的研发流程的思考和探索，阅读这本书，我似乎得到了一直以来理想中的无线团队开发和管理模式。
真正让我获益匪浅的是，作者总在寻求技术和管理的落地。无论多牛逼的技术，或者多高端多学术的管理思想，如果无法落地付诸实践，都是扯蛋。
以下，是自己的在阅读过程中一些体验和笔记：
（一）App框架设计与重构
这部分内容讲述的是大部分app开发都会涉及到的基础技术问题和业务场景，如自动登录、网络请求数据缓存、登录过期处理、时间校准等，这些功能是大部分公司的技术团队需要重复造轮子的，阅读这部分内容，言简意赅，思维流畅，能更深入的了解框架设计所要解决的业务问题。
另外，关于规划Android的项目结构以及编码规范，书中并无特别的地方，也可参考以下Github上的此文章《Android 开发最佳实践》。
（二）Crash收集、统计与分析
这部分内容，作者花了6个月的时间，介绍了一百多个崩溃，对作者严谨的态度表示敬佩。在此之前，作者介绍了如何在项目开发中，将Crash分门别类的收集到本地数据库，如何对大量的Crash去重，并将Crash自动分发到相应的开发人员处理，提供了Crash从产生到解决的一整套方案。
对于一个长期运营的App来说，如果有这样一份长期积累沉淀的Crash库以及解决方案，可以提高解决crash的效率，从而提高产品的稳定性。因此，对于一个团队来说，有必要将此项工作列入计划之中。
（三）敏捷开发
对于多数互联网产品开发团队，在每周的开发工作里，既要维护旧版本bug，又要开发新功能，于此同时，在技术方面还有些重构的想法，在这种情况下，如果你是一名称职的管理者，请把握好开发节奏，控制好时间点，减少无谓的加班，尽可能的多快好省，让团队处于一种身心比较健康的开发状态。
书中对于四周、两周和一周为单位的迭代周期里，如何把握工作节奏，有效控制时间点，做了详尽的描述，如下图：
在这一个月中，前两周为开发周期，在此期间可能会碰到的种种问题，以及如何解决：
1.上一版本发现重大bug，需要紧急处理——部分低优先级的需求delay到下一迭代。
2.上一版本陆续发现bug，不严重，但需在本次迭代内修复——根据bug情况决定要修复的版本。
3.产品经理经常插入一些紧急的需求——如果测试团队无法消化这些需求，则开发团队在新分支开发，下次迭代合并并测试。如果开发团队无法消化，则同1的情况。
4.一些需求临时决定本次迭代不做——这些额外时间灵活分配，或是做重构工作，或是解决之前拖欠的Task。
在第三周迭代工作的尾声，开发团队可发布“小流量包”，这里解释下小流量包的概念：
关于小流量包：
1.版本号=当前线上的版本号，即老用户无法升级。
2.在主渠道上（如网站首页上）提前一周上架小流量包，即新用户才可下载。
3.为小流量包重新申请一个渠道号，方便统计该包的相关数据。
4.意义：可尽快获得用户反馈；可减少部分用户更新App的频次；可减少紧急发版本带来的繁重的发布任务。
当迭代周期压缩至两周时，工作节奏将更加紧凑：
（四）技术分享和Code-Review
这部分内容作者的篇幅较少，但笔者对这两块十分感兴趣。
先来谈谈技术分享，大多数leader对技术分享很感兴趣，出发点有二，其一，觉得技术分享可提高团队的技术实力，其二，每次技术分享过程中，必不可少的拍照发微信发微博，因为公司的绩效考核栏目里往往有团队技术分享次数的考核。
然而，往往第二点占据了主导，导致技术分享的变质。来看下此文作者的做法:
接下来谈谈Code-Review。
关于Code-Review，它的好处不必多说，然而实践起来却困难重重，颇有点“此曲只应天上有，人间哪得几回闻”的感觉。对于这部分内容，若想深入探讨，可阅读下左耳朵耗子的《从Code Review 谈如何做技术》。作者在团队中对于Code-Review的实践如下：
除此之外，文中还介绍了代码混淆的方案，如何进行App竞品分析等，这些部分的内容也写得很精彩。
“落地”，是阅读此书的最大感受，大到技术架构、竞品分析、发布流程，小到每个Crash、员工座位安排、开展技术分享、简历筛选，作者总在寻求落地的解决方案，细细阅读，你不觉得这种方案有多么高大上，不觉得背后有多么华丽的理论支撑，但是你会觉得，一切都是踏踏实实、真真切切可落地实践的，为工作带来不少的实践指导。
建议移动开发从业者都阅读一下本书，如果你是一名程序员，有必要了解下你的leader背后要考虑的大局，以及做出某些决策的原因，这能帮助你更好的为团队分忧，承担更多的责任，获得更多的晋升空间。如果你是一名技术管理者，反思一下你的决策是否能落地，是否只是空谈，或者你的决策与你想达到的目标其实是两码事，从而避免做无用的管理，避免团队毫无意义的精力涣散。
