隨著工具鏈的完善，語言的升級以及各種優質教程的湧現，做一個 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 會花費些時間，但跟收益相比還是值得的。

以上這些點是在感受不過不同量級的 App 開發後整理的，肯定還會有疏漏，不過如果真能做到這些，就已經很不錯了，至少當有新人進來時，不會背上沉重的「歷史包袱」。