以下是我作為一名
程式設計師經過10幾年時間總結出的一些有關於軟體開發的經驗規則：
無論是建立乙個新的系統，還是新增功能到現有的系統中，我總是從乙個簡單到幾乎沒有任何所需功能的版本啟動，然後再一步一步地解決問題，直到滿意為止。我從來沒有妄想過能夠一步登天。相反，我一邊開發一邊學習，同時新掌握的資訊還可以用於解決方案中。
我很喜歡john gall的這句話：「複雜系統總是源於簡單系統的演化。」
當我們在開發時，碰到測試失敗和功能無效的情況，如果你一次只研究乙個問題，那將會更容易找到問題的關鍵。換言之，就是使用短迭代。必須確保這個問題解決之後，再轉移到另乙個問題上。這適用於向下提交。如果在你新增新功能之前需要先重構**，那麼先提交重構，然後再新增新的功能。
在開發新系統時，我做的第一件事就是新增日誌和錯誤處理，因為這兩者從一開始就非常有用。如果系統不能照常工作，那麼你就需要知道程式中發生了什麼——這是日誌的作用。錯誤處理也是如此——錯誤和異常越早處理越好。
在你真正完成乙個功能之前，你必須對它進行測試。不然，你怎麼知道它是不是按照你的想法在執行呢？通常情況下，最好的方法是通過自動測試，但並非總是如此。不過，不管怎麼說，每一行新**必須至少執行一次。
先進行部分模組測試可以節省時間。通常說來，我們在整合不同的模組時也會出現問題，例如模組之間的介面不匹配。但是如果我們能夠信任各個元件的話，那麼跟蹤整合問題就會變得簡單得多。
特別是在程式設計中，即使一切進展順利，我們也很難對功能所需的時間做出正確的預算。並且，開發軟體時碰到各種意想不到的問題是非常常見的。
侯世達定律其實道出了真諦：做事所花費的時間總是比你預期的要長，即使你在預期中已經考慮了侯世達定律。
大多數的編碼都需要以某種方式改變現有的**。即使是新功能，也需要適應現有的程式。所以，在你加進去新的內容前，首先需要了解當前的解決方案。否則，你一不小心就很有可能會打破現有的功能。這意味著，閱讀**和編寫**都是必要的技能。這也是為什麼看似微小的變化仍可能需要很長時間才能解決的原因之一——你首先必須了解上下文。
幸運的是，對於理解**，我們有兩種互補的方法。你可以閱讀**，也可以執行**。執行**的確是個非常棒的好方法。所以，請確保充分利用這兩種方法。
每個開發人員都應該花時間去處理來自客戶的故障報告，並修復bug。這能讓你更好地理解客戶的意圖，明白如何使用系統，知道排除故障的難易程度，了解系統的設計情況。這也是為自己的開發成果負責的好方法。
修復bug的第一步就是重現問題。然後你得確保修復之後，問題能夠徹徹底底地消失。這樣乙個簡單的規則可以確保你不會誤將非問題當作是問題，並確保解決方案真的能夠奏效。
有時候，可能同時存在著幾個不同的問題。它們之間的互相作用，可能會讓你毫無頭緒，束手無策。不要糾結於搞清楚發生了什麼，先去解決所有已知的問題，然後再看看還有什麼不對的地方。
在測試和故障排除時，不要相信會出現什麼巧合。就像你改變了定時器的值，那麼就會改變系統重啟的頻率。所以一切都並非是巧合。新增新功能，另乙個不相干的功能變慢了？這絕對不是巧合。相反，是你應該仔細調查的內容。
在故障排除時，事件的時間戳可以作為你的好幫手。尋找偶數增量。例如，如果系統重啟了，並且剛剛發出過乙個3000毫秒左右的請求，那麼可能是觸發了某個定時器，才導致出現重啟的動作。
遇到你絞盡腦汁也解決不了的問題時，不妨找乙個同事，然後將問題解釋給他們聽。很多時候，當你在敘述時，即使你的同事一言不發，你可能也會突然靈光乍現找到問題的關鍵。
完整內容點此檢視
敏捷經驗教訓， 開發總結！
敏捷的過程改進方法 從經驗教訓中學習 敏捷方法開發總結的點評記錄 敏捷的過程改進方法 從經驗教訓中學習 每次去客戶現場做 差距分析或者執行檢查 總是習慣於找他們的缺點，但是每次也總能從客戶那裡發現他們的優點，時間久了，慢慢地對缺陷麻木了，審醜疲勞了，只有發現他們的優點時，我才會精神一振，心情愉快。今...
上位機開發經驗教訓總結
20191118更新程式，程式調整為使用狀態機的方式實現 public void circlemain endregion region 資料採集及變數對映 var result modbusplc.readdiscrete 0 7 if result.issuccess endregion reg...
10 年程式設計師總結的20 條經驗教訓
開發那點經驗 說說 1.從小事做起，然後再擴充套件 無論是建立乙個新的系統，還是新增功能到現有的系統中，我總是從乙個簡單到幾乎沒有任何所需功能的版本啟動，然後再一步一步地解決問題，直到滿意為止。我從來沒有妄想過能夠一步登天。相反，我一邊開發一邊學習，同時新掌握的資訊還可以用於解決方案中。我很喜歡jo...