閱讀此書痛快且過癮江耀，隨著心態(tài)的越發(fā)浮躁屈张，很難專注不開小差的閱讀一本技術(shù)書籍，這本書是例外袱巨。
在工作中阁谆，除了編碼，我最喜歡的事情就是思考如何行之有效的提高團隊開發(fā)效率愉老，由于自己閱歷尚淺场绿，很多想法都是紙上談兵。每個人所處工作環(huán)境嫉入，項目的級別分量焰盗、研發(fā)文化都迥然不同，當你的研發(fā)生涯的某個階段里咒林，項目比較普通熬拒，管理比較混亂時，都不要放棄對規(guī)范的研發(fā)流程的思考和探索垫竞，閱讀這本書澎粟，我似乎得到了一直以來理想中的無線團隊開發(fā)和管理模式。
真正讓我獲益匪淺的是欢瞪，作者總在尋求技術(shù)和管理的落地活烙。無論多牛逼的技術(shù)，或者多高端多學(xué)術(shù)的管理思想遣鼓，如果無法落地付諸實踐啸盏，都是扯蛋。
以下骑祟，是自己的在閱讀過程中一些體驗和筆記：
（一）App框架設(shè)計與重構(gòu)
這部分內(nèi)容講述的是大部分app開發(fā)都會涉及到的基礎(chǔ)技術(shù)問題和業(yè)務(wù)場景回懦，如自動登錄气笙、網(wǎng)絡(luò)請求數(shù)據(jù)緩存、登錄過期處理粉怕、時間校準等健民，這些功能是大部分公司的技術(shù)團隊需要重復(fù)造輪子的，閱讀這部分內(nèi)容贫贝，言簡意賅秉犹，思維流暢，能更深入的了解框架設(shè)計所要解決的業(yè)務(wù)問題稚晚。
另外崇堵，關(guān)于規(guī)劃Android的項目結(jié)構(gòu)以及編碼規(guī)范，書中并無特別的地方客燕，也可參考以下Github上的此文章《Android 開發(fā)最佳實踐》鸳劳。
（二）Crash收集、統(tǒng)計與分析
這部分內(nèi)容也搓，作者花了6個月的時間赏廓，介紹了一百多個崩潰，對作者嚴謹?shù)膽B(tài)度表示敬佩傍妒。在此之前幔摸，作者介紹了如何在項目開發(fā)中，將Crash分門別類的收集到本地數(shù)據(jù)庫颤练，如何對大量的Crash去重既忆，并將Crash自動分發(fā)到相應(yīng)的開發(fā)人員處理，提供了Crash從產(chǎn)生到解決的一整套方案嗦玖。
對于一個長期運營的App來說患雇，如果有這樣一份長期積累沉淀的Crash庫以及解決方案，可以提高解決crash的效率宇挫，從而提高產(chǎn)品的穩(wěn)定性苛吱。因此，對于一個團隊來說器瘪，有必要將此項工作列入計劃之中又谋。
（三）敏捷開發(fā)
對于多數(shù)互聯(lián)網(wǎng)產(chǎn)品開發(fā)團隊，在每周的開發(fā)工作里娱局，既要維護舊版本bug彰亥，又要開發(fā)新功能，于此同時衰齐，在技術(shù)方面還有些重構(gòu)的想法任斋，在這種情況下，如果你是一名稱職的管理者，請把握好開發(fā)節(jié)奏废酷，控制好時間點瘟檩，減少無謂的加班，盡可能的多快好省澈蟆，讓團隊處于一種身心比較健康的開發(fā)狀態(tài)墨辛。
書中對于四周、兩周和一周為單位的迭代周期里趴俘，如何把握工作節(jié)奏睹簇，有效控制時間點，做了詳盡的描述寥闪，如下圖：
在這一個月中太惠，前兩周為開發(fā)周期，在此期間可能會碰到的種種問題疲憋，以及如何解決：
1.上一版本發(fā)現(xiàn)重大bug凿渊，需要緊急處理——部分低優(yōu)先級的需求delay到下一迭代。
2.上一版本陸續(xù)發(fā)現(xiàn)bug缚柳，不嚴重埃脏，但需在本次迭代內(nèi)修復(fù)——根據(jù)bug情況決定要修復(fù)的版本。
3.產(chǎn)品經(jīng)理經(jīng)常插入一些緊急的需求——如果測試團隊無法消化這些需求秋忙，則開發(fā)團隊在新分支開發(fā)彩掐，下次迭代合并并測試。如果開發(fā)團隊無法消化翰绊，則同1的情況佩谷。
4.一些需求臨時決定本次迭代不做——這些額外時間靈活分配旁壮，或是做重構(gòu)工作监嗜，或是解決之前拖欠的Task。
在第三周迭代工作的尾聲抡谐，開發(fā)團隊可發(fā)布“小流量包”裁奇，這里解釋下小流量包的概念：
關(guān)于小流量包：
1.版本號=當前線上的版本號，即老用戶無法升級麦撵。
2.在主渠道上（如網(wǎng)站首頁上）提前一周上架小流量包刽肠，即新用戶才可下載。
3.為小流量包重新申請一個渠道號免胃，方便統(tǒng)計該包的相關(guān)數(shù)據(jù)音五。
4.意義：可盡快獲得用戶反饋；可減少部分用戶更新App的頻次羔沙；可減少緊急發(fā)版本帶來的繁重的發(fā)布任務(wù)躺涝。
當?shù)芷趬嚎s至兩周時，工作節(jié)奏將更加緊湊：
（四）技術(shù)分享和Code-Review
這部分內(nèi)容作者的篇幅較少扼雏，但筆者對這兩塊十分感興趣坚嗜。
先來談?wù)劶夹g(shù)分享夯膀，大多數(shù)leader對技術(shù)分享很感興趣，出發(fā)點有二苍蔬，其一诱建，覺得技術(shù)分享可提高團隊的技術(shù)實力，其二碟绑，每次技術(shù)分享過程中俺猿，必不可少的拍照發(fā)微信發(fā)微博，因為公司的績效考核欄目里往往有團隊技術(shù)分享次數(shù)的考核蜈敢。
然而辜荠，往往第二點占據(jù)了主導(dǎo)，導(dǎo)致技術(shù)分享的變質(zhì)抓狭。來看下此文作者的做法:
接下來談?wù)凜ode-Review伯病。
關(guān)于Code-Review，它的好處不必多說否过，然而實踐起來卻困難重重午笛，頗有點“此曲只應(yīng)天上有，人間哪得幾回聞”的感覺苗桂。對于這部分內(nèi)容药磺，若想深入探討，可閱讀下左耳朵耗子的《從Code Review 談如何做技術(shù)》煤伟。作者在團隊中對于Code-Review的實踐如下：
除此之外癌佩，文中還介紹了代碼混淆的方案，如何進行App競品分析等便锨，這些部分的內(nèi)容也寫得很精彩围辙。
“落地”，是閱讀此書的最大感受放案，大到技術(shù)架構(gòu)姚建、競品分析、發(fā)布流程吱殉，小到每個Crash掸冤、員工座位安排、開展技術(shù)分享友雳、簡歷篩選稿湿，作者總在尋求落地的解決方案，細細閱讀押赊，你不覺得這種方案有多么高大上饺藤，不覺得背后有多么華麗的理論支撐，但是你會覺得，一切都是踏踏實實策精、真真切切可落地實踐的舰始，為工作帶來不少的實踐指導(dǎo)。
建議移動開發(fā)從業(yè)者都閱讀一下本書咽袜，如果你是一名程序員丸卷，有必要了解下你的leader背后要考慮的大局，以及做出某些決策的原因询刹，這能幫助你更好的為團隊分憂谜嫉，承擔更多的責任，獲得更多的晉升空間凹联。如果你是一名技術(shù)管理者沐兰，反思一下你的決策是否能落地，是否只是空談蔽挠，或者你的決策與你想達到的目標其實是兩碼事住闯，從而避免做無用的管理，避免團隊毫無意義的精力渙散澳淑。
