從小白到入門，從入門到進階，從進階到高階，從高階到資深，再從資深走不同到路線。這條路可以說是大多數程式設計師的發展路線，在這個過程中經驗就顯得尤為重要，尤其是後期，經驗可以佔據很大的優勢。

 

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的第一步就是重現問題。然後你得確保修復之後，問題能夠徹徹底底地消失。這樣一個簡單的規則，可以確保你不會誤將非問題當作是問題，並確保解決方案真的能夠奏效。

 

相關推薦