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