作者：追夢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.持續學習
軟件開發者的一大優點是，學習能力強。這是由於職業因素導致的。因為，對於這樣一個行業，必須得保持持續學習的習慣，不然很容易被淘汰。
