作者：追夢1819
原文：https://www.cnblogs.com/yanfei1819/p/14754210.html
版權宣告：本文為博主原創文章，轉載請附上博文連結！
楔子
本文是在在軟體開發中的一些經驗總結。有的看似很神奇，沒有科學依據，但是在使用時確確實實有效果。
本文目的，一為記錄，二為分享給後來者。
另，文中圖片源自網路，與內容無關，僅供娛樂，精髓在於文字。
正文
開發
1.由易及難，由小及大
無論是一個新專案還是一個二次開發的專案。我總是從一個最簡單的版本或者功能開始，然後逐步延伸，直達達到預期目的為止。
專案開始時無法詳細計劃所有事情。取而代之的是，我在學習的過程中學習了這些新發現的經驗教訓，並在後續方案中使用它們。形成一個螺旋上升的趨勢。
我喜歡約翰·加爾（John Gall）的話： “我們會發現，一個有效的複雜系統，總是從一個有效的簡單系統演變而來的。”
2.學會拆分
我們在開發時，某些測試失敗或某個功能失效時，如果僅更改一件事，發現問題就容易得多。換句話說，就是使用短迭代。
做一件事，確保它起作用，然後重複。這同樣適用於每次提交程式碼的場景。如果必須在新增新功能之前重構程式碼，請首先提交重構，然後（在新提交中）新增新功能。
3.儘早新增日誌記錄和錯誤處理
在開發新系統時，我要做的第一件事就是新增日誌記錄和錯誤處理，因為兩者從一開始就非常有用。
對於較大的功能或者系統，我們需要某種方式來了解程式中會發生什麼。也許它無法按預期執行時，但是一旦無法按預期執行，我們就必須能夠看到正在發生的事情。
錯誤處理也是如此，錯誤和異常也從一開始就發生，因此我們越早以系統的方式處理它們就越好。
4.所有新程式碼必須至少執行一次
在完成一項功能之前，我們必須對其進行測試（單元測試）。否則，如何知道它已經達到了預期？
通常，最好的方法是通過自動測試，但並非總是如此。但是無論如何，每行新程式碼都必須至少執行一次。
有時很難觸發正確的條件。但是，我們可以手動製造一些異常。例如，可以通過暫時拼寫錯誤的列名來檢查對資料庫呼叫的錯誤處理。或者，可以暫時將if語句反轉（“ if error”變為“ if not not”），以觸發很少發生的事情，只是確保程式碼已執行並且應執行應做的事情。
有時我會看到一些錯誤，這些錯誤表明開發人員永遠都不可能執行特定的程式碼行。審查時看起來不錯，但上線後仍然無法正常工作。
如果我們始終測試了每一行新寫的程式碼，則基本上可以避免上述問題。
5.整體測試元件
經過良好測試的元件可以節省時間。整合不同的元件時經常會出現問題，例如模組之間的介面不匹配或理解不正確。如果每個元件可以按照預期工作，那麼查詢整合問題將變得更加容易。
6.一切花費的時間比想象的要長
特別是在程式設計中。即使一切進展順利，也很難估計功能將花費多少時間。但是，在開發軟體時，遇到意外問題是很常見的：簡單的合併會導致細微的錯誤，升級框架意味著必須更改某些功能，或者API呼叫無法按預期進行。
我認為霍夫施塔特定律很有道理：即使考慮到霍夫施塔特定律，它也總是比您期望的更長。
7.首先了解現有程式碼
大多數編碼都需要以某種方式更改現有程式碼。即使它是一項新功能，也需要適配現有程式。並且，在將新內容放入其中之前，我們需要了解當前的解決方案。否則，可能會意外破壞某些現有功能。
這意味著閱讀程式碼是與編寫程式碼一樣必要的技能。這也是看似小的更改仍需要較長時間的原因的一部分-必須瞭解進行更改的環境。
8.閱讀並執行
閱讀並執行，幸運的是，有兩種互補的方法可以理解程式碼。可以閱讀程式碼，也可以執行程式碼。
在弄清楚程式碼的功能時，執行程式碼可能會提供很大的幫助。確保同時使用這兩種方法。
故障排除
9.總是會有bug
我不喜歡所謂“第一時間正確”的軟體開發方法。無論我們投入多少精力，總會有bug（bug的定義幾乎是：“我們沒有想到這一點”）。更好的方法是定位一個可以使我們快速解決問題，修復錯誤並部署修復程式的系統。
10.解決故障報告
每個開發人員都應將一部分時間花在處理客戶的故障報告和修復錯誤上。
它使我們可以更好地瞭解客戶真正需要什麼，如何使用系統，進行故障排除的難易程度以及系統的設計水平。這也是對自己的責任心的訓練。我們不要錯過這些好處。
11.重現問題
修復錯誤的第一步是重現問題。然後，請確保在新增修復程式後，問題就消失了。這個簡單的規則可確保我們不會以為某件事不是問題，並確保解決方案確實按照我們的方案去實現的。
12.修復已知的錯誤
修復完已知問題後，然後看看還剩下什麼問題。
有時我們會遇到一些其他問題。不同的bug可能相互影響，並引起奇怪的事情發生。不要嘗試解決在這些情況下會發生的情況，而是要解決所有已知問題，然後檢視仍然存在哪些現象。
13.假設沒有巧合
在進行測試和故障排除時，請不要相信巧合。我們更改了計時器，現在系統重新啟動的頻率更高。不是巧合。
新增了新功能，但不相關的功能變慢了嗎？不是巧合。而我們要做的事，要調研原因。
14.與時間戳相關
在進行故障排除時，請使用事件的時間戳作為輔助名稱。例如，如果系統重新啟動，並且在大約3000毫秒之前發出了請求，則可能是計時器觸發了導致重新啟動的操作。
合作
15.面對面辦公效率最高
在討論如何解決問題時，有面對面視訊，通話，聊天和電子郵件。不過我的經驗來講，面對面討論的方案和效率最好。
16.學會請教
當我們遇到困難時，應去找同事並向他們解釋問題。
很多時候，即使我們同事不回覆，但是在我們描述問題時，可能會意識到問題出在哪裡。聽起來像魔術，但經常會出奇的效果。
17.諮詢
讀程式碼和執行程式碼，通常對於弄清程式碼的功能和工作方式非常有用。但是，如果我們諮詢一個很厲害的人（也許是原始作者），也可以弄清楚我們的疑問。
18.分享他人對你的幫助
在討論問題或者業餘聊天時，儘量多提及別人對你幫助，包括給你解決問題的思路甚至靈感。
其他方面
19.試試看
如果不確定某個語言功能的工作方式，我們可以先編寫相同的Demo。測試正在開發的系統時也是如此。
如果將此引數設定為-1，會發生什麼？重新啟動系統後，如果該服務關閉，會發生什麼情況？探索它的工作原理–-隨便擺弄經常會發現錯誤，同時也加深了您對系統工作原理的理解。
20.在睡眠中"解決"問題
如果我們正在解決一個難題，且沒有任何思路時，我們可以好好睡一覺。這樣，即使沒有積極考慮問題，潛意識裡也可能可以解決該問題。有時候可以發現，第二天的思路比前一天更加開闊。
21.改變
不要害怕偶爾改變角色或工作。
與不同的人，不同的產品或不同的公司一起工作很令人興奮。
在我看來，太多的人年復一年地被動地呆在同一份工作中，只有在被迫離開時才改變。
22.持續學習
軟體開發者的一大優點是，學習能力強。這是由於職業因素導致的。因為，對於這樣一個行業，必須得保持持續學習的習慣，不然很容易被淘汰。
