【乾貨】11 條編程經驗分享

從小白到入門，從入門到進階，從進階到高級，從高級到資深，再從資深走不一樣到路線。這條路能夠說是大多數程序員的發展路線，在這個過程當中經驗就顯得尤其重要，尤爲是後期，經驗能夠佔據很大的優點。

 

1. 從小事作起，而後再擴展

不管是建立一個新的系統，仍是在現有的系統中添加新的功能，我老是從一個簡單到幾乎沒有任何所需功能的版本開始，而後再一步一步地解決問題，直到滿意爲止。我歷來沒有妄想過可以一步登天。相反，我一邊開發一邊學習，同時新掌握的信息還能夠用於解決方案中。 我很喜歡 John Gall 的這句話：「複雜系統老是源於簡單系統的演化。」

 

2. 一次只作一件事

當咱們在開發時，碰到測試失敗和功能無效的狀況，若是你一次只研究一個問題，那將會更容易找到問題的關鍵。換言之，就是使用短迭代。必須確保這個問題解決以後，再轉移到另外一個問題上。這適用於向下提交。若是在你添加新功能以前須要先重構代碼，那麼先提交重構，而後再添加新的功能。

 

3. 儘早地添加日誌和錯誤處理

在開發新系統時，我作的第一件事就是添加日誌和錯誤處理，由於這二者從一開始就很是有用。對系統來講它比一大把代碼更有用，你須要一些瞭解程序狀態的方法。若是系統不能照常工做，那麼你就須要知道程序中發生了什麼——這是日誌的做用。錯誤處理也是如此——錯誤和異常越早處理越好。

 

4. 每一行新代碼必須至少執行一次

在你真正完成一個功能以前，你必須對它進行測試。否則，你怎麼知道它是否是按照你的想法在執行呢?一般狀況下，最好的方法是經過自動測試，但並不是老是如此。不過，無論怎麼說，每一行新代碼必須至少執行一次。 通常，咱們想觸發某種條件很難。但幸運的是，咱們能夠做弊。例如，數據的錯誤處理能夠經過臨時拼寫錯一個列名來觸發。或者，一個if語句能夠暫時顛倒過來（從 if error 變成 if not error），這樣來觸發那些平時很難觸發的條件，這樣只是爲了肯定代碼是否正常運行和它會出現什麼結果。有時，我發現有一些行代碼永遠都不會被運行。當咱們作代碼檢查是它看起來沒有什麼問題，但就是不工做。你要避免這樣的尷尬情況，若是你想你的每一行新代碼都會被執行。

 

5. 在總體測試以前先進行模塊測試

先進行部分模塊測試能夠節省時間。一般說來，咱們在整合不一樣的模塊時也會出現問題，例如模塊之間的接口不匹配。可是若是咱們可以信任各個組件的話，那麼跟蹤集成問題就會變得簡單得多。

 

 

6. 全部事情所花費的時間老是比你預期的要長

特別是在編程中，即便一切進展順利，咱們也很難對功能所需的時間作出正確的預算。而且，開發軟件時碰到各類意想不到的問題是很是常見的。一個簡單的合併操做會致使一系列小bug，一次框架升級意味着一些函數必須改變或者一些API不按照你想象的那樣工做。

 

Hofstadter Law（ 霍夫施塔特定律）其實道出了真諦：作事所花費的時間老是比你預期的要長，即便你在預期中已經考慮了 Hofstadter Law（ 霍夫施塔特定律）。

 

7. 先了解現有的代碼

大多數的編碼都須要以某種方式改變現有的代碼。即便是新功能，也須要適應現有的程序。因此，在你加進去新的內容前，首先須要瞭解當前的解決方案。不然，你一不當心就頗有可能會打破現有的功能。這意味着，閱讀代碼和編寫代碼都是必要的技能。這也是爲何看似微小的變化仍可能須要很長時間才能解決的緣由之一，由於你首先必須瞭解上下文。

 

8.閱讀和運行代碼

幸運的是，對於理解代碼，咱們有兩種互補的方法。你能夠閱讀代碼，也能夠運行代碼。運行代碼的確是個很是棒的好方法。因此，請確保充分利用這兩種方法。

 

9. Bug 老是不免的

我不喜歡那些宣稱軟件開發能夠「一蹴而就」的高談闊論。不論你再怎麼努力，bug老是不免的（BUG的定義基本上是:「咱們沒有想到」）。最好可以作成能夠快速故障排除、修復bug和部署修復的系統。

 

10. 解決故障報告

每一個開發人員都應該花時間去處理來自客戶的故障報告，並修復bug。這能讓你更好地理解客戶的意圖，明白如何使用系統，知道排除故障的難易程度，瞭解系統的設計狀況。這也是爲本身的開發成果負責的好方法。不要錯過這些好處。

 

11. 重現問題

修復bug的第一步就是重現問題。而後你得確保修復以後，問題可以不折不扣地消失。這樣一個簡單的規則，能夠確保你不會誤將非問題看成是問題，並確保解決方案真的可以奏效。