隨著工具鏈的完善，語言的升級以及各種優質教程的涌現，做一個App的成本也越來越低了。盡管如此，有些事情最好前期就做起來，避免當App有了一定規模后，再感慨當初為什么沒有多留點心。

完善的日志系統

以iOS為例，有時圖方便，就直接用NSLog了，甚至線上都一直開著。一方面會影響性能，尤其是輸出比較頻繁的時候，另一方面也容易泄露敏感信息，所以一般做法是在Release模式下禁用NSLog，比如在pch文件中，通過對環境的判斷，對NSLog做不同的處理。

但這樣仍會有問題，比如我們發現線上的App在特定場景下會有某種異常的表現，這時就很希望能有日志來提供更多的信息。可以考慮使用像cocoalumberjack這樣功能更完善的第三方日志工具，在線上仍然開著日志，但不消費，這樣就不會泄露敏感信息。當我們需要看日志時，可以通過“調試模式”打開它，然后連上iOS Console來看。

因為Log是一個很普遍的行為，所以最好前期就規范起來，后期遍地都是NSLog時，再要改動會有點麻煩，當然也可以偷懶點，直接把NSLog的宏定義改了。

Commit Message 規范

在前期開發的時候，往往為了快速實現功能，而忽略了Commit Message的規范，然后就會出現很隨意的Commit信息。這樣別人在Review代碼時就會很累，寫某個版本的Release Notes也會變得艱辛，甚至過一段時間自己都不知道這些Commit代表的意思。而如果自己也講不清這次改動究竟該怎么描述時，往往是這次改動混雜了較多的信息。

這篇文章簡潔精確地描述了為什么要寫好Commit Message，以及如何寫。遵守這些規范后，就很方便產出這樣的Release Notes了。

代碼規范

這個最好在前期就抓起來，如果前期不做約束，每個人的風格往往會有比較大的差異，導致代碼看起來會比較累，甚至有些人是從其他語言轉過來的，還會保留之前語言的一些書寫習慣，就容易有“出戲”的感覺。一致的代碼規范不僅看起來舒服，而且讓團隊更像一個整體。

這個實施起來會有一定難度，尤其是團隊中有一些“老人”的時候，他們往往積累了一套自己的編程習慣，而且不容易被說服。

準備一份編程守則

里面包含了“最佳實踐”和“不要踩的坑”，這個可以一定程度上提高開發效率，避免一些低級錯誤。比如以iOS為例，“不要隨便使用通知”，因為通知使用起來太方便了，用得多了調試起來就會很累，而且也不好管理;“通知用完之后記得remove observer”;不要使用containsString (如果還需要支持iOS 7 的話)。隨著時間的累積，這份守則里的內容會越來越多，也是一件挺寶貴的財富。

頁面布局規范

這個在Android相對還好，基本都是通過xml來進行布局。在iOS里玩法就多了，有用storyboard的，有用xib的，有直接計算坐標和大小的，有用原生autolayout的，有用第三方布局類的。總之就是各顯神通，盡量用同一種布局規范(但不建議直接計算坐標和大小)，看起來也會方便些。

統計埋點

這是很重要的一塊，客戶端所有的數據基本就靠它了，所以盡量選擇一個靈活、穩定的數據方案，同時最好在他們提供的SDK上再封一層，方便做一些額外的事情(比如想同時接入另一家服務作對比)。

統計埋點還有很重要的一點是“驗證”，是否有錯打、漏打等現象;iOS / Android是否有用同一個點;有些點還需要額外的參數，這些參數的格式是否正確等。這些工具往往只能自己來做了，這也是比較花時間的一部分。

App 架構

App架構會隨著業務、人員的增長而演進，所以當發現當前的架構無法滿足日常的業務迭代時，就需要考慮對它做調整了。一般來說，大方向上也就是MVP / MVVM，等人員多起來時，基本就是組件化開發，當然組件化也會有它的問題(比如資源/類重用、組件間通信等)，這里就不展開了。

在前期選擇一個相對輕量級，但比較清晰的架構(盡量不要選擇MVC)，大家都遵守這個架構開發，也能一定程度上提高效率。

頁面跳轉機制

雖然Android、iOS都原生支持open特定scheme的url，不過可能的話，還是通過router統一處理會比較方便，也更靈活。比如可以知道注冊了哪些URL;可以知道頁面的跳轉成功率;方便處理一些奇奇怪怪的需求等。

在線配置

在線配置可以賦予App極大的靈活性，比如運營的一些活動、banner位調整、首頁彈窗等;還可以針對特定機型、系統分發特定的內容，結合規則引擎甚至可以給一部分有相同特征的用戶發推送;可以做流量切分等。所以一個強大/穩定的配置中心就顯得尤為重要，A/B Test也可以基于配置中心來做。

這里有些注意事項，因為不少配置的值是運營填的，她們對value不那么敏感，所以會出現value為空，或者不是想要的類型，或者配了張圖片，但是體積超大等，有可能造成客戶端crash / OOM等異常表現，所以客戶端要有足夠強大的容錯能力。

選擇合適的Crash平臺

Crash會給用戶造成極大的負面體驗，所以需要經常關注Crash情況，尤其是剛發版的那段時間。這塊fabric做的比較好，只是由于是國外的服務，會有些許數據上的丟失，不過問題倒也不是很大，也可以考慮國內的一些服務，如bugly，畢竟騰訊自己也在用。

Code Review

這也是容易忽視的一點，當業務需求壓過來時，先把功能實現了再說，而且在初期往往人手也不夠，抽不出時間來做Code Review。如果是這樣的話，可以先Review一些核心的點，保證重要的代碼是經過Review的，不太重要的業務代碼可以先放放，等人員充足后再覆蓋更大的范圍。

Code Review的主要作用是保障代碼質量，同時促進雙方成長，一個擔心點是質量偏低的代碼比例如果較大的話，會影響開發者的心情，增加維護成本，日積月累就成了重重的“歷史包袱”。

選擇合適的開發模式

如果是使用git來做源碼管理的話，可以采用flow模式，基本能滿足大部分的需求，而且不少git工具也內置了flow的支持。這樣當需要處理feature / hotfix / 發版等場景時，就會很方便。

持續集成

持續集成的目的是讓產品在快速迭代的過程中還能保證質量，當有錯誤發生時，可以第一時間被檢查出來，方便修復。如果想偷懶的話，可以直接使用成熟的服務，如travis，也可以自己基于Jenkins來搭，iOS的話，配合fastlane效果會更好。自己搭的好處是靈活度更大，可以加入一些個性化需求。

如果有打包平臺的話，還可以定時出一個包，這樣當發現某個功能使用起來有問題，代碼上又沒什么頭緒時，可以對比以前的包來定位。

Bug 管理系統

這個Bug包括測試階段和線上的Bug，Bug管理工具有很多，使用在線服務或自己搭都可以，但要有，不然很有可能忘了還有哪些問題需要修復，哪些已經修復了。

項目管理工具

在App開發初期，人員較少，溝通起來比較方便，所以很多需求當面就說了，一些原型/設計圖可能也是直接AirDrop過來的，這樣效率自然高，但不便管理。比如沒有prd，產品、開發的理解可能不一致，到頭來發現做的不是產品想要的，或者一些細節不符合要求;設計圖有更新，但沒有同步到所有的開發;需求有變更，但當時在專心做某個feature，可能就忘了，或者沒有理解全面等。所以最好還是有一個項目管理工具來統一處理，再結合敏捷開發，項目的質量和進度就容易得到保障。

Checklist

一個App發布上線之后，要保證不出大的問題，就要在發布之前，先檢查一下“一定不能出問題”的點是否正常，就像飛機起飛之前一定會走一遍checklist一樣。比如推送是否正常、log是否關閉、組件版本是否正確等，隨著App功能的增加，這個list也會越來越長，雖然過一遍checklist會花費些時間，但跟收益相比還是值得的。