作一個App前須要考慮的幾件事

 

本文轉載於文章原文連接，版本歸原做者全部！

 

隨着工具鏈的完善，語言的升級以及各類優質教程的涌現，作一個 App 的成本也愈來愈低了。儘管如此，有些事情最好前期就作起來，避免當 App 有了必定規模後，再感慨當初爲何沒有多留點心。

此處由標哥的技術博客站長點評：

看完本篇文章以後，也讓我想起了很多之前作過的蠢事，作過不少重複的工做。以前在項目中使用過cocoalumberjack，我的感受是很不錯的日誌管理框架。固然，不必定要求使用它，也在另外一家公司裏，原來的人將NSLog重定義了，改寫了輸出，可是整體並無cocoalumberjack的強大。

使用git或者SVN提交代碼時，必定要加上詳細註釋，不然出現問題時，都找不到是哪次提交的，並且沒有好的註釋也不利於code review。對於代碼規範和編程準則，在公司一般都有要求的，除非你是來公司的第一人。其餘就很少說了，你們慢慢體會吧，這些是很經常使用的！

完善的日誌系統

以 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 開發後整理的，確定還會有疏漏，不過若是真能作到這些，就已經很不錯了，至少當有新人進來時，不會背上沉重的「歷史包袱」。