1. 接觸一個新項目時新建一個「閱讀」分支
接手一個已經(jīng)上線的項目時，為了解架構(gòu)和業(yè)務(wù)實現(xiàn)，閱讀項目源碼是必要的。而很多優(yōu)秀團隊是不需要且不允許寫注釋的，原因有：
- 如果編碼風(fēng)格足夠規(guī)范，代碼便是說明書，看代碼就能懂，注釋很多時候是多余的；
- 倒不是完完全全說“彪悍的代碼不需要注釋”，而可能是對于一個兩周更新一次的上線APP來說，寫注釋和文檔意味著要花費更多寶貴的維護時間，所以團隊會更傾向于Team Lead花多點時間把控代碼質(zhì)量，并且允許團隊成員對代碼的命名稍微長點（表達得仔細點）。
對于沒有注釋或有了注釋也不理解業(yè)務(wù)的項目，可以嘗試新開一個“注釋”分支，我們可以在上面隨意注釋、隨意標注，作為短時間內(nèi)的“筆記”分支，有利于快速熟悉新項目。
2. 盡量在正版電子書平臺閱讀技術(shù)書籍
先不討論電子書與紙質(zhì)書的主觀喜好。從便利性上，有一個iPad或手機，到哪都能看電子書，所做的筆記可以搜索、復(fù)制、回顧、同步及分享。電子書是永久、輕薄的，更重要的是我們可以復(fù)制出書中想實踐的代碼示例，而紙質(zhì)書沒有這優(yōu)勢。目前絕大數(shù)書都能在亞馬遜、多看、微信讀書等平臺找到。
3. 配置文件中配置項或依賴包以字典排序的方式排列
之后維護和查找時會比較高效。
4. 項目進入標準化后，視覺設(shè)計者應(yīng)該發(fā)展并提出Style Guide（視覺風(fēng)格指南）
Style Guide指的是整個APP的視覺風(fēng)格指南，將指定的風(fēng)格統(tǒng)一管理，方便團隊交流與開發(fā)。
比如整個APP中，整個APP的文字主題色是#00dc55，我們把它叫做main_blue，在之后的設(shè)計稿和交流中，當我們使用這個顏色時，直接稱顏色為main_blue就可以了；又比如微信的綠色按鈕風(fēng)格，我們可以封裝成一個叫full_green_btn的style變量，日后說某個按鈕是full_green_btn風(fēng)格，直接設(shè)置它的style值就可以了。風(fēng)格一致、命名統(tǒng)一，這便是視覺指南。
5. 對整個APP的布局進行優(yōu)化時，可以對layout文件的大小進行降序排列，從占用空間最大的文件開始優(yōu)化
很明顯，占用空間大的布局文件里，涉及到的xml代碼和控件使用會更加的多，優(yōu)化起來有更大的空間。
6. 使用項目中的單元測試模塊快速實現(xiàn)小規(guī)模程序的驗證和調(diào)試
當我們想通過編程來驗證一個小程序或想法時，通常是挺麻煩的。如果直接用手頭開發(fā)的大型IDE（比如AS或VS）新建一個項目，需要很多步驟和初始化工作；如果把要驗證的代碼寫在項目中，項目跑起來可能也過于龐大。
我們可以直接在單元測試模塊中新建一個測試方法，在方法里寫要跑的代碼，然后進行單元測試就可以驗證程序了。同樣支持調(diào)試和斷點，代碼跑起來也非?？烨也挥绊懙巾椖績?nèi)容。
7. 一個功能一個Git分支
在開發(fā)過程中，每完成一個功能點就創(chuàng)建一個分支。
這在后期的代碼找回和代碼管理是非常有效的。比如我們完成登錄功能，就新建一個分支，做完后把這個分支提交到github，之后直接去做其它任務(wù)（繼續(xù)創(chuàng)建新的分支，如果新任務(wù)需要用到登錄功能的代碼就基于這個分支創(chuàng)建分支，不依賴登錄的代碼就基于主分支創(chuàng)建分支）。
在技術(shù)老大檢查代碼時，如果同意合并代碼就合并，如果需要修改代碼，我們只需要切換到對應(yīng)的分支并修改代碼，隨后再次提交。
在功能點明確的情況下，這樣任務(wù)與代碼分明的開發(fā)方式是比較高效的。
如何命名分支？
看個人習(xí)慣而定，我個人的分支命名習(xí)慣是【名字/日期+任務(wù)類型_任務(wù)簡單表達】，其中任務(wù)類型是指故事點的類型（featrue、bug、chore）。如命名我做的登錄功能分支可以是Leslie/1012feature_userLogin，這樣的命名方式包括了作者、日期、任務(wù)分類和任務(wù)簡更描述，日后搜索起來也方便。
缺點
隨著時間的推移，做過的任務(wù)越來越多，分支就越來越多，一年下來上千個分支是有可能的。但Android Studio貌似不支持批量刪除分支。
8. 批量刪除Git本地分支
我們可以去刪除Git的配置文件。在項目的根目錄下，我們可以看到隱藏文件夾.git，里面包含了各種信息。
我們把分支的文件批量刪除，重啟Android Studio，對應(yīng)的分支便不會出現(xiàn)在Android Studio的分支列表了。
9. 跨項目搬運代碼時，盡量不要過早對源碼進行重命名
當我們從甲項目搬運大量代碼到乙項目時，搬運的代碼一定會含有原來項目特定的命名。在搬運工作完成前，不要過早對代碼進行重命名，原因是如果過早對代碼重命名，之后再次搬運相關(guān)代碼到新項目時，新項目是無法自動地對對象實現(xiàn)引用的。這時候只能自己手動修改名字，一是低效，二是容易出錯。所以，重命名的工作最好在代碼搬運工作完成后再做。
10. 前端后端分開工作
移動端依賴的服務(wù)器后臺在測試和維護時，應(yīng)該將代碼跑在另一個備用服務(wù)器，不影響移動端繼續(xù)開發(fā)，等后臺完成更新后，再占用短暫的時間停掉正在使用的服務(wù)器，把新功能推到正式的后臺。即區(qū)分QA和Release環(huán)境。
11. 做報表時使用PS工具實現(xiàn)比例的計算
拉取標尺線到需要的邊界上，形成了排版區(qū)域的區(qū)分。
這樣做的目的是方便換算。效果如下圖，我們可以通過藍線在標尺上的刻度直接知道這個位置是水平方向的百分之多少的位置。
12. 做運維部署時，使用流程文檔進行操作和部署
不要對自己的思路和記憶力過分自信，配置和部署是非常無聊的事情，如果中間環(huán)節(jié)出現(xiàn)問題，人可能會變得煩躁，隨著思路會被打亂。最穩(wěn)當?shù)姆椒ㄊ鞘孪葘懞貌渴鸬牧鞒?，按著上面的?nèi)容和步驟做，如果一步做錯了，解決完問題，再從頭或繼續(xù)著做，這樣能更好地達到目的。
