下面是我作為一名程式猿經過10幾年時間總結出的一些有關於軟體開發的經驗規則：
開發
1.從小事做起，然後再擴充套件
不管是建立一個新的系統，還是加入功能到現有的系統中，我總是從一個簡單到差點兒沒有不論什麼所需功能的版本號啟動，然後再一步一步地解決這個問題，直到愜意為止。我從來沒有妄想過可以一步登天。相反，我一邊開發一邊學習，同一時候新掌握的資訊還可以用於解決方式中。
我非常喜歡John Gall的這句話：“複雜系統總是源於簡單系統的演化。”
2.一次僅僅改變一件事
當我們在開發時。碰到測試失敗和功能無效的情況，假設你一次僅僅研究一個問題，那將會更easy找到問題的關鍵。換言之，就是使用短迭代。必須確保這個問題解決之後。再轉移到還有一個問題上。
這適用於向下提交。
假設在你加入新功能之前須要先重構程式碼。那麼先提交重構。然後再加入新的功能。
3.儘早地加入日誌記錄和錯誤處理
在開發新系統時，我做的第一件事就是加入日誌和錯誤處理，由於這兩者從一開始就很實用。假設系統不能照常工作。那麼你就須要知道程式中發生了什麼——這是日誌的作用。錯誤處理也是如此——錯誤和異常越早處理越好。
4.每一行新程式碼必須至少執行一次
在你真正完畢一個功能之前。你必須對它進行測試。不然，你怎麼知道它是不是依照你的想法在執行呢？通常情況下，最好的方法是通過自己主動測試。但並不是總是如此。只是。無論怎麼說，每一行新程式碼必須至少執行一次。
5.在總體測試之前先進行模組測試
先進行部分模組測試可以節省時間。
通常說來，我們在整合不同的模組時也會出現故障。比如模組之間的介面不匹配。可是假設我們可以信任各個元件的話，那麼跟蹤整合問題就會變得簡單得多。
6.全部事情所花費的時間總是比你預期的要長
特別是在程式設計中，即使一切進展順利，我們也非常難對功能所需的時間做出正確的預算。
而且。開發軟體時碰到各種意想不到的問題是非經常見的。
侯世達定律事實上道出了真諦：做事所花費的時間總是比你預期的要長，即使你在預期中已經考慮了侯世達定律。
7.先了解現有的程式碼
大多數的編碼都須要以某種方式改變現有的程式碼。即使是新功能，也須要適應現有的程式。
所以。在你加進去新的內容前，首先須要瞭解當前的解決方式。否則。你一不小心就非常有可能會打破現有的功能。這意味著。閱讀程式碼和編寫程式碼都是必要的技能。這也是為什麼看似微小的變化仍可能須要非常長時間才幹解決的原因之中的一個——你首先必須瞭解上下文。
8.閱讀和執行
幸運的是，對於理解程式碼，我們有兩種互補的方法。
你能夠閱讀程式碼，也能夠執行程式碼。執行程式碼的確是個很棒的好方法。
所以，請確保充分利用這兩種方法。
故障排除
9.bug總是難免的
我不喜歡那些宣稱軟體開發能夠“一蹴而就”的高談闊論。不論你再怎麼費盡心機，bug總是難免的。最好能夠做成能夠高速故障排除、修復bug和部署修復的系統。
10.解決故障報告
每一個開發者都應該花時間去處理來自客戶的故障報告，並修復bug。這能讓你更好地理解客戶的意圖，明確怎樣使用系統，知道排除故障的難易程度，瞭解系統的設計情況。這也是為自己的開發成果負責的好方法。
11.重現問題
修復bug的第一步就是重現問題。然後你得確保修復之後，問題可以徹徹底底地消失。
這樣一個簡單的規則可以確保你不會誤將非問題當作是問題，並確保解決方式真的可以奏效。
12.修復已知錯誤，然後再看看有沒有遺漏的地方
有時候，可能同一時候存在著幾個不同的問題。它們之間的互相作用。可能會讓你毫無頭緒，束手無策。不要糾結於搞清楚發生了什麼，先去解決全部已知的問題，然後再看看還有什麼不正確的地方。
13.沒有巧合
在測試和故障排除時。不要相信會出現什麼巧合。就像你改變了定時器的值。那麼就會改變系統重新啟動的頻率。所以一切都並不是是巧合。
加入新功能，還有一個不相干的功能變慢了？這絕對不是巧合。
相反，是你應該細緻調查的內容。
14.關聯時間戳
在故障排除時，事件的時間戳能夠作為你的好幫手。尋找偶數增量。比如，假設系統重新啟動了，而且剛剛發出過一個3000毫秒左右的請求。那麼可能是觸發了某個定時器，才導致出現重新啟動的動作。
團隊合作
15.面對面的交流最有效
當我們須要討論怎樣解決這個問題時，那麼面對面的交流比視訊、打電話和電子郵件都要好。
16.橡皮鴨法
遇到你絞盡腦汁也解決不了的問題時，最好還是找一個同事，然後將問題解釋給他們聽。
非常多時候，當你在敘述時，即使你的同事一言不發，你可能也會突然靈光乍現找到問題的關鍵。
17.問問題
閱讀和執行程式碼往往很有助於指出程式碼的目的和它的工作原理。可是假設你有機會諮詢那些更為了解的人（比如原來的程式猿）。那麼千萬不要錯過。
18.共享榮譽
不要貪圖榮譽，該是誰的就是誰的。比如：“Marcus想出了這個主意……”（假設真是他想的話）。而不要說“我們想出的……”。
其它
19.嘗試
假設你不知道某種程式語言功能的工作原理。那麼最好還是寫一個小程式來理解它是怎樣工作的。
這相同適用於測試你正在開發的系統。假設我將引數設定為-1，會發生什麼？當我在重新啟動系統時，假設服務當掉，會發生什麼？以此來研究它的工作原理。
20.帶著問題睡覺
假設你正在解決一個非常難的問題，那麼最好還是帶著問題睡覺。
有科學研究表明。這樣做盡管你表明上並沒有在主動思考，但你的潛意思卻這麼做了。其結果就是，第二天再去研究問題，解決方式已經呼之欲出了。
21.跳槽
不要害怕跳槽。和不同的人共事。開發不同的產品，感受不同的公司文化是很有意思的。
22.不斷學習
我們須要不斷地學習和了解軟體開發。你能夠嘗試不同的程式語言和工具，閱讀軟體開發的書籍，接受MOOC課程。相信我，量變才幹達到質的飛躍，這些小小的學習積累。終有一天會大大地提高你的知識和能力。
希望這些經驗能對大家實用。如有不當之處，敬請指正。