開發規範

# 代碼提交規範篇
1. 【推薦】代碼提交應該短小而頻繁，儘量避免單次提交大量代碼。
說明：約束單次提交的範圍有利於寫出更加針對性的說明，也對代碼審覈更加友好。
反例：單次提交超過200+行的代碼或20+的文件；只在休息的時候（午休、下班）提交代碼；很難一句話說清楚這次提交的內容
2. 【強制】代碼提交說明應該描述本次提交的具體內容，並帶上適當的前綴
 * feat：新功能的說明
 * fix：修補bug的說明
 * docs：增加文檔、註釋
 * style： 調整代碼格式（不影響任何代碼邏輯的變動）
 * refactor：代碼重構（既不是新增功能，也不是修改bug的代碼變動）
 * test：增加測試
 * chore：構建過程或輔助工具的變動
 * 反例：無意義的說明比如“優化”、“bug fix”、“test”
3. 【推薦】代碼提交說明字數控制在20字以內
4. 【推薦】代碼提交說明無須以句號結尾

#### 爲什麼需要規範化代碼提交？
1. 提供更多的歷史信息，方便快速瀏覽
git log HEAD --pretty=format:%s
2. 可以過濾某些commit（比如功能性提交），便於快速查找信息
git log HEAD --pretty=format:%s | grep feat
3. 可以直接從commit生成某個release的變更日誌
參考[conventional-changelog](https://github.com/conventional-changelog/conventional-changelog)工具
4. 可以利用工具自動生成符合規範的commit message前綴
參考[commitizen](https://github.com/commitizen/cz-cli)工具
5. 對代碼審覈更加友好，通常直接review一個大的版本非常困難，而篩選出所有功能性提交（feat前綴）單獨review則簡單很多

#### 分支管理規範
1. 普通倉庫
如果一個倉庫的每個版本包含的功能列表是相對穩定的，一旦版本確定就不會隨意增刪功能，那麼這就是一個普通類型的倉庫，這類倉庫通常功能相對簡
單，只包含特定的服務/App。
這類倉庫可以採用develop分支集成開發中的代碼，並在該分支進行自動化構建測試。
![git](https://github.com/529523346/pics/blob/master/git_pic.png)
#### 分支策略
一共只存在兩個永久分支：
* master
* origin/master分支的HEAD版本/tags反映了生產環境部署的最新代碼。
下面幾類分支都是臨時性分支，有各自的生命週期：
   1. feature/* (zxf_v1.0.0)
   2. release/* (v1.0.0)
   3. hotfix/*  (zxf_v1.0.0)
* feature分支來自特定功能的開發、重構和優化，在適當的時候將合回develop分支。
* release分支從某個develop版本產生，當develop分支積累的代碼適合做一次發佈時，創建此分支進行測試和bug修復。
* hotfix分支來自線上產生的需緊急修復的bug。
* 這幾類分支都有嚴格的創建流程和操作規範，下面將進行具體描述。
#### 項目操作流程
1. 創建項目：創建項目後，需要立即從master上創建永久性分支：develop ，
將此分支推入遠程倉庫origin/develop，master與develop兩個永久分支的權限都需設置爲只允許Merge不允許Push，即代碼合併必須在git網頁端發起Merge Request流程
2. 開發某個功能
 分支來源：origin/develop
 新建分支名稱：feature/xxx
 xxx爲本分支功能名稱，不鼓勵一個分支中包含多個功能。
 創建分支後切換到本分支進行開發和本地測試。
 準備提交QA測試是本分支結束的必要條件。
 發起Merge Request合併回：origin/develop，模塊負責人/主管負責code review
 刪除origin/feature/xxx分支
3. 完成某個版本提交測試
 分支來源：origin/develop
 新建分支名稱：release/xxx
 xxx爲本次發佈的版本名稱
4. QA測試中，修復BUG： 在release/xxx的分支上進行bug修改
 在本分支中，只能修改測試產生的相關bug，其他功能調整不可在本分支修改
5. 測試完成，準備上線：
 發起Merge Request將分支分別合併回：origin/master + origin/develop
 刪除origin/release/xxx分支
 master分支添加tag：X.X.X，並在描述中說明本次版本的feature內容（可根據commit message生成）


# 編碼規範篇
#### 爲什麼需要編碼規範?


編碼規範對於程序員而言尤爲重要，有以下幾個原因：

* 一個軟件的生命週期中，80%的花費在於維護
* 幾乎沒有任何一個軟件，在其整個生命週期中，均由最初的開發人員來維護
* 編碼規範可以改善軟件的可讀性，可以讓程序員儘快而徹底地理解新的代碼
* 如果你將源碼作爲產品發佈，就需要確任它是否被很好的打包並且清晰無誤，一如你已構建的其它任何產品

####強制性規範:
* 代碼中的命名均不能以下劃線或美元符號開始，也不能以下劃線或美元符號結束。
* 代碼中的命名嚴禁使用拼音與英文混合的方式，更不允許直接使用中文的方式。
* 類名使用UpperCamelCase 風格，必須遵從駝峯形式。
* 方法名、參數名、成員變量、局部變量都統一使用 lowerCamelCase 風格，必須遵從駝峯形式。
* 常量命名全部大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長例如：MAX_STOCK_COUNT。
* 抽象類命名使用 Abstract 或 Base 開頭;異常類命名使用 Exception 結尾;測試類 命名以它要測試的類的名稱開始。
* 杜絕不規範的英文縮寫：AbstractClass 縮寫成AbsClass；condition縮寫成condi;此類隨意縮寫嚴重降低了代碼的可閱讀性。
* 如果使用到了設計模式，建議在類名中體現出具體的模式，例如：

`public class ComponentFactory`

`public class BufferStrategy`

`public class ScrollerProxy `
   
####關於Dao層或ArrayList的命名
* 插入：insert（推薦）或save
* 刪除：delete
* 修改：update(推薦)或modify
* 查詢單個對象：get
* 查詢多個對象：list
* 實體類必須重載toString()方法，這樣可以通過調用對象的toString()來排查問題。
* Object 的 equals 方法容易拋空指針異常，應使用常量或確定有值的對象來調用 equals。
正例: `"test".equals(object);`
反例: `object.equals("test");`
* 避免通過一個類的對象引用訪問此類的靜態變量或靜態方法，無謂增加編譯器解析成本，直接用類名來訪問即可。
推薦規範：
* 集合初始化時，儘量指定集合初始值大小；ArrayList儘量使用ArrayList(int initialCapacity) 初始化 。
* 使用 entrySet 遍歷 Map 類集合 KV，而不是 keySet 方式進行遍歷
說明:keySet 其實是遍歷了 2 次，一次是轉爲 Iterator 對象，另一次是從 hashMap 中取出 key 所對應的 value。而 entrySet 只是遍歷了一次就把 key 和 value 都放到了 entry 中，效 率更高。如果是 JDK8，使用 Map.foreach 方法。
* 高度注意 Map 類集合 K/V 能不能存儲 null 值的情況，如下表格:

集合類|Key|Value|Super|說明
  ------- | -------    |  ------- | -------
Hashtable|不允許爲null|不允許爲null|Dictionary| 線程安全
ConcurrentHashMap  | 不允許爲null | 不允許爲null | AbstractMap  | 分段鎖技術
TreeMap    | 不允許爲null | 允許爲null  | AbstractMap|     線程不安全
HashMap    | 允許爲null  | 允許爲null  | AbstractMap  | 線程不安全
 
* 利用 Set 元素唯一的特性，可以快速對一個集合進行去重操作，避免使用 List 的 contains 方法進行遍歷、對比、去重操作。
* 通過雙重檢查鎖(double-checked locking)(在併發場景)實現延遲初始化的優 化問題隱患(可參考 The "Double-Checked Locking is Broken" Declaration),推薦問題 解決方案中較爲簡單一種(適用於 JDK5 及以上版本)，將目標屬性聲明爲 volatile 型。  

 *反例*

```
class Foo {
    private Helper helper = null;
    
    public Helper getHelper() {
     if (helper == null) 
            synchronized(this) { 
                if (helper == null)
                    helper = new Helper(); 
            } 
            return helper; 
    } // other functions and members... 
     } 
```
應該爲：

```
class Foo {
    private volatile static Helper helper = null;
    
    public Helper getHelper() {
     if (helper == null) 
            synchronized(this) { 
                if (helper == null)
                    helper = new Helper(); 
            } 
            return helper; 
    } // other functions and members... 
     } 
```

####Android代碼規範
***代碼：***  

* Activity 命名一律使用 模塊名+Activity 的方式。例如，LoginActivity、SignupActivity；  
* Fragment 命名一律使用 模塊名+Fragment 的方式；  
* 自定義View：Custom(建議)+功能名+View/ViewGroup(具體的組件名稱)。例如：CustomImageScroller、CustomRatingBar。  
* Widget 小組件：ScanWidget、WeatherWidget。
* Dialog對話框：功能名+Dialog。例如：LoginDialog、ProgressDialog 
* 儘量在每一個Activity或類中加入TAG,方便我們查看Activity的信息，這裏Android Studio提供了快捷方式logt方式即可快速生成當前類的常量。
* 對於使用Intent傳遞數據，聲明一些Key的時候：
EXTRA_KEY_+具體Key名稱，例如我們現在有一個人的名字和年齡要傳那麼首先定義：  
`public static final String EXTRA_KEY_PERSON_NAME="EXTRA_KEY_PERSON_NAME"`  
`public static final String EXTRA_KEY_PERSON_NAME="EXTRA_KEY_PERSON_AGE"`  
然後在具體的頁面 `new Intent()`，依次傳遞進去值，這樣寫其實沒什麼問題；但是試想一下，如果你要調用的Activity是類似於一個工具性質或通用的Activity（圖片選擇器、登錄、註冊等等），這時候你要傳遞的key又很多，如果業務複雜的話，你應該會被這樣冗餘且不易閱讀的代碼直接搞崩潰掉。
所以最好的辦法就是在你要調用Activity提供一個靜態工廠方法，要知道靜態工廠方法所帶來的好處太多了，由於Activity是不允許通過new的方式來初始化的，所以靜態工廠方法的好處在此就不那麼明顯，但是已經足夠我們優化我們的代碼了。舉個例子，我們有一個筆記 NoteActivity，用於創建筆記和修改筆記

 ```
Idprivate static final String EXTRA_KEY_NOTE_ID ="EXTRA_KEY_NOTE_ID" ;//筆記 
private static final String EXTRA_KEY_NOTE_CONTENT ="EXTRA_KEY_NOTE_CONTENT" ;//筆記內容
private static final String EXTRA_KEY_NOTE_MODE ="EXTRA_KEY_NOTE_MODE" ;//筆記模式
//用於創建筆記  
public static void startForCreate(Context context, int noteId) {
    start(context, noteId, null, MODE_CREATE);
}
    //用於編輯筆記
public static void startForEdit(Context context, int noteId, String content) {
    start(context, noteId, content, MODE_UPDATE);
}  
public static void start(Context context, int noteId, String content, int mode) {  
    Intent starter = new Intent(context, TableShareListSettingActivity.class);
    starter.putExtra(EXTRA_KEY_NOTE_ID,noteId);
    starter.putExtra(EXTRA_KEY_NOTE_CONTENT,content);
    starter.putExtra(EXTRA_KEY_NOTE_CONTENT,mode);
    context.startActivity(starter);
}
 ```

通過以上方法，我們能夠很好的解耦複雜的Activity之間的調用，再加上靜態方法工廠方法名，代碼可閱讀行大大提高，最終我們看到的調用NoteActivity將會是很簡潔的一段代碼：  
`NoteActivity.startForCreate(this,noteId);`  
`NoteActivity.startForEdit(this,noteId,content);`   
此外，Android Studio工具中其實已經在Live Template中提供了這樣的代碼:簡單的輸入starter就可以快速地在當前的Activity中添加一個Intent的靜態操作方法，這其實也說明了Android官方團隊也鼓勵我們這麼做。
* 增加類註釋

```
/**
 * @Title： 
 * @Description：
 * @Author：xuefeng.zhu
 * @Since：2020-03-22
 * @Version：1.0.0
 */
 ```

* 所有的常量加上註釋，且功能相同的排放在一起，不同的進行換行；
* Activity中全局變量採用m開頭+類名。例如，mTable、mPerson；
* Activity中的控件：m+模塊名+控件類型名稱。例如，mLoginEditText（mLoginEt）,mLoginTextView（mLoginTv）;
* 統一Activity中函數的排版規則也能提高我們的閱讀性；列如店播的loginActivity函數排版：

```
 LoginActivity extends BindingBaseActivity{

     @Override
     protected int getLayoutId() {
         return R.layout.user_activity_login;
     }
 
     @Override
     protected LoginViewModel getViewModel() {
         return new LoginViewModel(getBinding(), getIntent());
     }
 
     @ClickTrace
     @Override
     public void onClick(View v) {
         super.onClick(v);
         int i = v.getId();
         if (i == R.id.wx_login_tv_layout) { //微信登錄
             getBinding().getViewModel().authorize(new Wechat());
         } else if (i == R.id.pick_other_login_way_tv) { //選擇其他登錄方式
             getBinding().getViewModel().showLoginWayDialog(this);
         } else if (i == R.id.has_referrer_tv) { //我有推薦人
             requestRecommend();
         } else if (i == R.id.close_iv) {
             finish();
         }
     }

   @Override
   public String getEventCode(int viewId) {
        com.analysis.statistics.http.RequestParams params = new com.analysis.statistics.http.RequestParams();
        params.put(Constant.PAGE, "00100000000");
        if (viewId == R.id.has_referrer_tv) {
            params.put(Constant.ACTION_CODE, "008");
            params.put(Constant.Z_ACTION_CODE, "001");
        }
        //無子操作編碼不上報埋點
        String zActionCode = params.get(Constant.Z_ACTION_CODE);
        if (TextUtils.isEmpty(zActionCode)) {
            return "";
        }
        String code = params.formJsonString();
        params.clear();
        return code;
    }     
 }
```

先是實現父類的getLayoutId方法，顯示頁面佈局；之後返回當前頁面的viewModel;再然後是頁面的點擊事件...最後纔是頁面埋點方法；

資源Res
* 按照資源的類型，分爲以下幾種  
***命名規則:控件Id命名：模塊（module:goods)_功能（name)_控件縮寫(tv)***  

| Resources Type | 命名規則
  ------- | -------    
| TextView | goods_name_tv  
| EditText | goods_name_et
| ImageView    | goods_name_iv
| Button   | goods_name_bt
| ListView | goods_name_lv
| GridView | goods_name_gv
| CheckBox | goods_name_cb
| RadioButton  | goods_name_rb
| LinearLayout | goods_name_ll
| RelativeLayout   | goods_name_rl
| FrameLayout  | goods_name_fl
| GridLayout   | goods_name_gv


#####Color資源命名,String資源命名
***命名規則:模塊（module:user)_組件名_具體作用名***

  Color資源命名

| Resources Type | 命名規則
  ------- | -------    
| color    | 模塊（module)_具體作用名_color。例 R.color.goods_login_name_color

 String資源命名

| Resources Type | 命名規則
  ------- | -------    
| string   | 具體功能。 例 R.string.user_hello

 Drawable資源命名

| Resources Type | 命名規則
  ------- | -------    
| launcher icon    | ic_launcher。例R.drawable.user_ic_launcher
| normal icon  | ic_具體模塊_功能。例R.drawable.user_ic_audio_pause
| Toolbar icon | user_ic_ab_功能名。例如user_ic_ab_search
| selector | selector_模塊_功能名。例如 user_selector_login_button
| shape    | shape_模塊功能名狀態。例如 R.drawable.user_shape_login_button_normal
 
##### Layout命名規則
 ***命名規則:模塊（module:user)_功能名_具體作用名***

| Resources Type | 命名規則
  ------- | -------    
| activity | activity_模塊名。例如 R.layout.activity_login
| fragment | fragment_模塊名。例如 R.layout.fragment_login_layout_header
| include  | layout_模塊名_功能名。例如 @layout/layout_login_bottom
| adapter  | adapter_item_模塊名_功能名。例R.layout.adapter_item_simple_text
| dialog   | dialog_模塊_功能名。例如 R.layout.dialog_time_picker
| list header  | header_模塊_功能。例如 R.layout.header_main_top_ad
| list footer  | footer_模塊_功能。例如 R.layout.footer_main_bottom_action
| widget   | widget_模塊_功能。例如 R.layout.widget_app_clock

##### Menu資源命名
 ***命名規則:模塊（module:user)_menu_功能名***

| Resources Type | 命名規則
  ------- | -------    
| menu | menu_模塊名。例如 menu_login

##### MenuValues資源命名
 ***命名規則:模塊（module:user)_功能名(login)_組件(color)***

| Resources Type | 命名規則
  ------- | -------    
| color    | 模塊名_color。例如 user_login_text_color  
| dimens   | 模塊名_dimens。例如 user_login_textsize_dimens  
| style    | 模塊名_style。例如 user_login_text_style  
| themes   | 模塊名_themes。例如 user_login_themes  

#### 代碼規範插件安裝
 * checkstyle簡介  
 checkstyle是idea中的一個插件，可以很方便的幫我們檢查java代碼中的格式錯誤，它能夠自動化代碼規範檢查過程，從而使得開發人員從這項重要，但是枯燥的任務中解脫出來。
 * 使用步驟  
   下載checkstyle插件。在最上方的菜單欄中找到File中的settings，plugins即是下載插件的地方，我們再點擊下方的Browse repositories，在其中查找checkstyle，並點擊install就可以等待下載成功了
   配置checkstyle文件。下載好之後我們需要重啓idea來啓用插件，然後在settings>>Editor>>Inspections中可以確認是否啓用
   接着在settings>>Other settings>>checkstyles的Configration file最右邊有一個加號，點擊它來添加配置文件，配置文件在項目根目錄，文件名：code_template

#### 總結：
其實代碼規範只是一個Guideline，大家遵從規範的目的是爲了提高開發效率，並且使得代碼容易閱讀且維護性高！