我從編程總結的 22 個經驗

編譯：伯樂在線/小謝

原文鏈接：我從編程總結的 22 個經驗

以下所列是我在這些年來軟體開發工作過程中受到的啟發，還有總結而來的好經驗。n

開發

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

12. 修復已知錯誤，然後再看看有沒有其他不對的地方

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

13. 沒有巧合

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

14. 關聯時間戳

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

合作

15. 面對面的交流最有效

當我們需要討論如何解決問題時，那麼面對面的交流比視頻、打電話和電子郵件都要好。我經常在與同事討論完後發現一個令人興奮的更好的方案。

16. 小黃鴨調試法

遇到你絞盡腦汁也解決不了的問題時，不妨找一個同事，然後將問題解釋給他們聽。很多時候，當你在敘述時，即使你的同事一言不發，你可能也會突然靈光乍現找到問題的關鍵。聽起來像魔法，但是這經常起作用。詳情看這篇文章：《小黃鴨調試法，每個程序員都要知道的》

17. 問問題

閱讀和運行代碼往往非常有助於指出代碼的目的和它的工作原理。但是如果你有機會諮詢那些更為了解的人（例如原來的程序員），那麼千萬不要錯過。繼續問他們具體的問題、後續的問題，這幾分鐘內給你的信息可能是你需要花費好幾天才能獲得的。

18. 共享榮譽

不要貪圖榮譽，該是誰的就是誰的。例如：「Marcus 想出了這個主意……」(如果真是他想的話)，而不要說「我們想出的……」。大膽的說出那些幫助過你或者貢獻過力量的人的名字。

其他

19. 動手去做

如果你不知道某種編程語言功能的工作原理，那麼不妨寫一個小程序來理解它是如何工作的。這同樣適用於測試你正在開發的系統。如果我將參數設置為-1，會發生什麼？當我在重啟系統時，如果服務當掉，會發生什麼？以此來研究它的工作原理。經常做這些會幫你發現bug，在此同時也會加深你的系統工作的了解。

20. 帶著問題睡覺

如果你正在解決一個很難的問題，那麼不妨帶著問題睡覺。有科學研究表明，這樣做雖然你表明上並沒有在主動思考，但你的潛意思卻這麼做了。其結果就是，第二天再去研究問題，解決方案已經呼之欲出了。

21. 改變/跳槽

不要害怕角色變化。和不同的人共事，開發不同的產品，感受不同的公司文化是非常有意思的。在我看來，太多的人只是被動地呆在同樣的地方年復一年的工作，只有在被迫的情況下才去改變。

22. 活到老學到老

軟體行業的一大魅力就是我們隨時有機會可以學到新的東西。你可以嘗試不同的編程語言和工具，閱讀軟體開發的書籍，接受MOOC課程。相信我，量變才能達到質的飛躍，這些小小的學習積累，終有一天會大大地提高你的知識和能力。

閱讀原文