雕蟲曉技之編碼

1、功能優先 程序員主要工做是寫代碼，最終目標則是產品，而產品的核心是其中的功能，若是功能沒有完成，代碼寫得再漂亮也沒用，因此第一點是功能優先。

因爲每一個人接觸到的知識是很是有限的，不可能像搜索引擎同樣什麼都知道，因此在面對具體的功能開發時，要優先從本身現有的知識庫裏面尋找最可靠有效的解決方案，先利用已有的知識設計出大體的框架，而後在不考慮編碼複雜度的狀況下先完成第一個版本功能的開發，把功能作出來以後，再進行迭代優化，使其逐漸接近完美。

對於功能開發來講，也要注意偏重，用戶須要的是內容，而不是一個應用，在初期階段要注意將內容展現作好，至於其中的一些動畫效果和細節處理，在這一階段都屬於次要內容，具體的細節能夠等功能基本完善以後慢慢調整。

2、適當測試 測試有黑盒測試和白盒測試，黑盒測試就是把本身當成用戶來體驗這些功能，看功能是否正常，而白盒測試在Android中一般是指單元測試。

雖然公司有專業的測試人員，可是本身寫的代碼仍是本身最清楚哪裏可能出現問題，因此建議在交付給專業測試以前本身先簡單的測試一遍，避免一些常見的漏洞。

在這裏說明一下有關單元測試的問題，你們都知道單元測試是好的，可是據我觀察，有不少程序員基本不寫單元測試，那麼單元測試究竟是不是必須的呢？

我的以爲，是否進行單元測試要依照具體狀況而定，不是全部的方法都須要單元測試，例如：讀取數據庫操做，獲取網絡數據，這些自己就不包含什麼複雜邏輯的內容是不須要測試的，假如數據出現了問題，十有八九是其餘地方寫入了錯誤數據，而不是由於讀取才出現的，所以這些也就沒有必要進行測試了。具體的業務邏輯也不須要單元測試，不然產品一旦修改需求，測試代碼也要跟着大動干戈，豈不是自找麻煩。

真正須要測試的是那些基礎函數，尤爲是具備分支判斷的函數，這些函數纔是最容易出現問題的地方，寫測試代碼的時候，重點要進行邊界數值測試，以及特殊狀況的測試，固然，若是是一些通用的基礎組件，我的更喜歡寫一個 Demo，在測試的同時就把用法示例也寫出來了。

3、代碼風格 相信每一個人都有本身的編碼風格，我的但願在保持本身風格的同時，也可以讓別人更容易看懂本身的代碼，因此設計了一個固定的結構，即適合編碼，又適合閱讀。

我的習慣將常量和變量放在最上面，而後是生命週期和應用的核心方法，依次進行排列，最後是外部調用的接口。這樣作主要是爲了後期查看方便，什麼方法在什麼位置很容易就能找到，避免了上下來回滾動去尋找一個方法的麻煩。

下面是本身使用的規範，一個大體的例子：

public class GcsSloop {  

// 對外常量
public static final String HAHA = "haha"; 

// 對內常量

private static final int  mVal = -1;    
// 全局變量
private int mVar;    

//--- 構造函數(生命週期)與核心功能 ---

public GcsSloop() {        
    this(-1);
}    
public GcsSloop(int var) {        
    this.mVar = var;
}    

// 核心方法，通常均爲 private
private void doSomthing(){
    System.out.println("LALA");
}

//--- 對外方法或接口 ---

// 對外方法，均爲 public
public void sayHaha(){
    System.out.println("HAHA");
}
複製代碼

} 這樣的編碼風格也是我調整了若干次後總結的，規則很簡單，也沒有太大的束縛，但很實用。

一個類寫完以後它的內部邏輯可能很長時間都不會改變，而調用者也不關心它的內部邏輯，因此就將內部邏輯放在中間位置，公開常量放在開頭，接口放在結尾，相比於中間，開頭和結尾更容易定位，這樣在使用的時候最容易尋找。

例如：我以前寫了一個類，我知道它的具體做用，但很長以前沒有使用了，忘了怎麼使用，我就能夠打開這個類，直接跳到末尾看一下調用接口就知道怎麼使用了，而不用再去看它的具體實現邏輯。

也有人習慣將公開常量和調用接口所有放在最開始的部分，這個就看我的的編碼習慣了，只要不是把公開的方法接口混雜到具體內部邏輯中就好。

4、技術選型 最後一個話題是技術選型，有句俗話叫」條條大路通羅馬」，在技術上尤爲如此，對於同一個業務來講，不一樣的人進行開發可能會選擇不一樣的技術方案，使用不一樣的思路。那麼具體到咱們開發時，應該如何選擇方案呢？

我的以爲應該有如下幾條原則：

1. 首選本身實踐過的

若是是本身實踐過的內容，會對這套流程比較熟悉，能快速上手開發，也踩過裏面常見的坑，知道如何規避。因此這套是首選方案，能夠快速穩定的實現業務。

2. 次選官方推薦或者你們都在用的

若是本身自己對這方面不熟悉，則建議選擇官方推薦方案，或者用的人比較多的方案。對於官方推薦來講，有後臺撐腰，文檔清晰明確，使用起來會少走彎路。而使用人數較多的則說明有不少前人幫忙踩坑，不少坑在沒遇到的時候就被填平了，即使遇到了，基本也能找到輕鬆繞過去的方案。

3. 慎選熱門新技術

其實這一點有悖程序員文化，程序員都喜歡新潮的，酷酷的技術，並且使用新技術能夠爲未來的簡歷添加上濃墨重彩的一筆，因此不少程序員都喜歡使用新技術。

我的以爲，喜歡新技術沒錯，任何新技術的興起，必然是由於它擁有着舊技術所沒有的特色，纔會受到人們的追捧，但也不要盲目的去使用新技術。對於新技術的出現，咱們能夠去學習，研究分析它的優缺點，但不要當即在商業項目中使用，由於任何技術都須要必定時間的沉澱才能逐漸完善，一項新技術的出現可能會解決某一方面的痛點，但同時也可能引入其餘麻煩，若是使用新技術出現了麻煩，將沒有任何能夠參考的東西，只能去看源碼分析，這將會大大的拖慢項目進度。

對於新技術的出現，我的的觀點是，默默學習，持續觀望，等沉澱幾個月以後再嘗試將這項技術應用到實際的項目中。

4. 不選冷門技術

若是不是無可奈何，不要去選擇沒什麼人用的技術方案，這些方案沒人使用必定是由於有更好的替代方案，或者是這項技術自己存在缺陷。固然，對於這些缺陷，做者通常不會明確的告訴咱們。這些技術方案可能一開始使用起來沒問題，但若是遇到問題，就會讓人很是頭疼，在某些狀況下，修復這個問題所花費的時間甚至會超過本身從頭再寫一遍。因此使用冷門技術以前請先祈禱一下本身不會踩到坑。