Android開發經驗記錄

標籤：

一、    代碼規範

定一個規範的主要目的，是為了讓不同的開發人員寫的代碼能保持一致性，方便別人看自己的代碼。另外，對個人來說，也能起到讓自己看著舒服的作用。

 

1.      基本

* 使用UTF-8編碼

* 使用Tab進行縮排

* 對待舊代碼的態度：許多舊代碼的風格比較亂，我們沒有必要專門全部改一遍，只需要“順帶手”改了就好，例如你改了一箇舊的函數，那就順便把裡面的代碼風格都統一一下就好，自己看著也舒服

* 採用Java標準方式寫大括弧，即大括弧跟在代碼的最右邊而不是另起一行：

void funcName() {     if(a == 0) {           //...     }}

 

2.      命名

* 所有Java代碼採用駝峰命名法：isFavorite、ActivityMain

* 所有xml檔案、資源檔採用底線命名法，首字母小寫：activity_main.xml、ic_launcher.png

* 所有類名首字母大寫：BaseAPI

* 所有方法首字母小寫：requestList()

* 所有變數首字母小寫，且成員變數推薦採用小m開頭：mContext

* 所有常量全大寫，使用底線串連：DEBUG_PRINT

 

3.      注釋

* 注釋的作用是讓別人容易看懂我們的代碼，所以注釋只需要在必要的地方出現即可，更多的時候，我們應該通過起一個好名字（函數、類、變數、常量）來減少注釋

* 以下地方必須要有注釋：類的說明、類對外提供的函數的說明、類對外提供的變數及常量，且應該使用 /** 式的注釋，這樣在IDE裡能夠直接把滑鼠放上去看到東西

* 在關鍵程式段，應該添加註釋，例如某段很拗口的邏輯，應該要說明它是做什麼用的，注釋應主要說明 目的 而不是 過程

* 函數的注釋應該說明各個參數的作用，以及傳回值

* 要養成做好事留名的習慣，在自己建立的類，應該在類說明裡留自己的名字。如果在別人的類裡加函數，應該在函數裡留下自己的名字。變數、常量也類似

 

4.      關於第三方庫

* 對待第三方庫的態度：第三方庫能夠大大減少我們的工作量，但是使用不當也會讓我們陷入泥潭，一般來說遵循一些簡單的規則就可以協助你選擇第三方庫：

     ** 複雜度：如果某個功能需要考慮大量異常處理和細節，而且又是十分通用的，那麼就應該考慮使用第三方庫，典型的例子是：網路訪問（Volley）、圖片載入（UniversalImageLoader）、JSON解析（FastJSON、GSON）

     ** 成熟度等級：一般來說，我們應盡量選擇成熟的第三方庫，判斷的標準包括：發布地點（例如Github）、是否持續維護（看提交記錄）、通過搜尋查看排名、通過Github搜尋查看排名

     ** 修改規模：有些第三方庫我們拿過來並不能直接用，可能需要進行一些修改，這時候我們就需要注意了。如果需要修改的部分（或者是未來可能需要修改的部分）不少，那我們很可能需要考慮自己來寫，因為有時候修改花得時間比自己寫還要多的多，事實上，無數前車之鑒已經展示了這一點。此外，盡量不要修改第三方庫，因為許多第三方庫本身會進行升級

 

* 此外，引入第三方代碼有兩種方法：

     ** 把第三方庫作為外部庫的方式引用：即在工程屬性裡添加依賴關係，這樣做的好處是可以保持工程的獨立性，缺點是工作環境下會有好多工程，而且如果修改了依賴的工程，需要clean一下才會生效。

     ** 把第三方庫代碼直接放到主工程裡：這樣的好處是不會有很多外部工程，但缺點是需要把資源檔（res等）也加進來，如果哪天你要刪掉這個庫，那就蛋疼了。

     其實權衡的方法也很簡單，如果第三方庫的資源檔特別多，那我建議用外部庫方式，如果第三方庫代碼檔案比較少，可以考慮直接放到主工程裡。

 

二、  多人協作

多人協作時需要注意的問題是如何合理分工，同時保證效率，降低溝通成本，有一些基本經驗：

* 劃分模組：一般按照介面進行劃分是比較合理的，對於公用的資料模型及網路訪問函數，可以統一由一個人寫，也可以讓負責某個介面的人來負責對應的網路函數；

* 不重複造輪子：有些介面控制項是通用的，就不要重複寫，有些網路訪問函數是通用的，就用一份。要做到這些，最重要的是主動溝通，在意識到別人有可能需要自己的代碼時儘早溝通；

* 防止svn衝突：兩個人寫同一個檔案（特別是網路訪問類）時，容易出現衝突，一些小技巧：

* 把可能會多個人同時寫的檔案分區塊，用多個斷行符號分隔開，然後用注釋寫上是誰的地區。。。

* 盡量一個檔案只有一個負責人。。。

* 養成經常更新代碼的好習慣。。。

 

三、  版本發布

在發布版本時，需要按照一定步驟，另外需要注意一些svn的操作方法：

1、   首先，完成各個功能的開發，進行自測；

2、   自測沒問題後，使用dealmoon下的dealmoon.key進行簽名，密碼在代碼目錄的說明文檔裡。把apk給測試人員測試；

3、   測試人員測出問題，各個模組的負責人進行修改；

4、   經過若干輪修正，基本沒有大bug，這時就發行就緒了，將最後定稿的apk交給產品經理進行發布；

5、   確定發布版本後，使用svn，建立一個發布分支，在/branches/release_Vx.x目錄下，其中Vx.x是版本號碼，用於備份發布的版本；

如果發布版本遲遲沒有確定，而主線版本又要做下一個功能，可以先建立發布分支，然後如果有bug，就在發布分支修改，然後將改動merge到主線上。注意：一定要保證merge的單向性，即只從發布分支合并到主幹，而不是從主幹合并到發布，那樣一會就亂了；

Android開發經驗記錄