以下是我作為一名程式設計師經過10幾年時間總結出的一些有關於軟體開發的經驗規則：

開發

1.從小事做起，然後再擴充套件

無論是建立一個新的系統，還是新增功能到現有的系統中，我總是從一個簡單到幾乎沒有任何所需功能的版本啟動，然後再一步一步地解決問題，直到滿意為止。我從來沒有妄想過能夠一步登天。相反，我一邊開發一邊學習，同時新掌握的資訊還可以用於解決方案中。

我很喜歡John Gall的這句話：“複雜系統總是源於簡單系統的演化。”

2.一次只改變一件事

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

3.儘早地新增日誌記錄和錯誤處理

在開發新系統時，我做的第一件事就是新增日誌和錯誤處理，因為這兩者從一開始就非常有用。如果系統不能照常工作，那麼你就需要知道程式中發生了什麼——這是日誌的作用。錯誤處理也是如此——錯誤和異常越早處理越好。

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

在你真正完成一個功能之前，你必須對它進行測試。不然，你怎麼知道它是不是按照你的想法在執行呢？通常情況下，最好的方法是通過自動測試，但並非總是如此。不過，不管怎麼說，每一行新程式碼必須至少執行一次。

5.在整體測試之前先進行模組測試

先進行部分模組測試可以節省時間。通常說來，我們在整合不同的模組時也會出現問題，例如模組之間的介面不匹配。但是如果我們能夠信任各個元件的話，那麼跟蹤整合問題就會變得簡單得多。

6.所有事情所花費的時間總是比你預期的要長

特別是在程式設計中，即使一切進展順利，我們也很難對功能所需的時間做出正確的預算。並且，開發軟體時碰到各種意想不到的問題是非常常見的。

侯世達定律其實道出了真諦：做事所花費的時間總是比你預期的要長，即使你在預期中已經考慮了侯世達定律。

7.先了解現有的程式碼

大多數的編碼都需要以某種方式改變現有的程式碼。即使是新功能，也需要適應現有的程式。所以，在你加進去新的內容前，首先需要了解當前的解決方案。否則，你一不小心就很有可能會打破現有的功能。這意味著，閱讀程式碼和編寫程式碼都是必要的技能。這也是為什麼看似微小的變化仍可能需要很長時間才能解決的原因之一——你首先必須瞭解上下文。

8.閱讀和執行

幸運的是，對於理解程式碼，我們有兩種互補的方法。你可以閱讀程式碼，也可以執行程式碼。執行程式碼的確是個非常棒的好方法。所以，請確保充分利用這兩種方法。

故障排除

9.bug總是難免的

我不喜歡那些宣稱軟體開發可以“一蹴而就”的高談闊論。不論你再怎麼費盡心機，bug總是難免的。最好能夠做成可以快速故障排除、修復bug和部署修復的系統。

10.解決故障報告

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

11.重現問題

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

12.修復已知錯誤，然後再看看有沒有遺漏的地方

有時候，可能同時存在著幾個不同的問題。它們之間的互相作用，可能會讓你毫無頭緒，束手無策。不要糾結於搞清楚發生了什麼，先去解決所有已知的問題，然後再看看還有什麼不對的地方。

13.沒有巧合

在測試和故障排除時，不要相信會出現什麼巧合。就像你改變了定時器的值，那麼就會改變系統重啟的頻率。所以一切都並非是巧合。新增新功能，另一個不相干的功能變慢了？這絕對不是巧合。相反，是你應該仔細調查的內容。

14.關聯時間戳

在故障排除時，事件的時間戳可以作為你的好幫手。尋找偶數增量。例如，如果系統重啟了，並且剛剛發出過一個3000毫秒左右的請求，那麼可能是觸發了某個定時器，才導致出現重啟的動作。

團隊合作

15.面對面的交流最有效

當我們需要討論如何解決問題時，那麼面對面的交流比視訊、打電話和電子郵件都要好。

16.橡皮鴨法

遇到你絞盡腦汁也解決不了的問題時，不妨找一個同事，然後將問題解釋給他們聽。很多時候，當你在敘述時，即使你的同事一言不發，你可能也會突然靈光乍現找到問題的關鍵。