修復bug有哪些更快的技術？做好這6點就夠了
你有沒有想過為什麼有時修復錯誤似乎比它應該花費更長的時間？當你終於找到問題時，事實證明你所需要的只是一個小小的改變。然而，花了很多時間才能找到正在發生的事情。這種情況比我想象的更頻繁。
另一方面，當您編寫程式碼並進行測試並且無法正常工作時，修復錯誤非常快。你跳回編輯器，掀起一行程式碼，問題就解決了。
為什麼即使問題很簡單，有時修復錯誤也需要很多工作，有時候，修復問題的速度很快 - 甚至可能很難解決問題？我們可以從易於修復的錯誤中學到一些東西，這樣我們可以花更少的時間來修復bug嗎？
讓我們來談談這個問題，看看我們可以用什麼方法來解決這個問題，並且因為很難找到錯誤而停止拔頭髮。
典型的錯誤修復過程
為了確定在修復錯誤時花了這麼長時間，我們先來看看修復錯誤所涉及的步驟。
首先，我們需要了解這個問題。這意味著我們需要知道出了什麼問題，在哪裡，以及應該發生什麼。
接下來，我們需要重現這個bug。一個典型的案例可能是我們需要進入我們正在處理的應用程式並點選一些事情來看看會發生什麼。
然後，我們需要弄清楚程式碼的哪個部分導致了問題。我們通常可以通過使用除錯工具來啟動它 - 例如使用Chrome的偵錯程式在我們重現問題的頁面上逐步執行程式碼。
一旦我們找到導致問題的程式碼片段，我們就需要確定根本原因。根據問題的複雜性，這種困難可能會有很大的不同。
在確定了根本原因後，我們終於可以修復該錯誤了。
最後，我們需要確保錯誤實際修復。這通常是通過嘗試再次重現它來完成的。
嗯，我想我們已經開始在這裡看到一個問題了。修復bug本身只有六分之一！
但在我們得出結論之前，讓我們更詳細地看一下這些步驟。然後，我們可以看到每個步驟中的內容需要花費時間，並找到使它們更快的方法。
第1步：瞭解問題
錯誤修復過程的第一步是理解問題。我們需要收集足夠的資訊，以便我們知道發生了什麼，以及應該發生什麼。
這個步驟花費很長時間的最大貢獻者是可怕的，糟糕的錯誤報告。
使用者從不提供好的錯誤報告。這是生活中無可否認的事實。
我可能會誇大一點，但我確信你已經比你想要的更頻繁地聽到“它不起作用”的字樣。
“X不起作用，它需要在昨天修復！”
然後你繼續問一些問題，希望你能從記者那裡收集一些比“它不起作用”更有用的資訊。
當然，有時當行星和恆星正確對齊時，你會得到一個好的錯誤報告。您可以清楚地瞭解出現了什麼問題，重現它的精確步驟，甚至可以獲得有關使用者使用的瀏覽器和作業系統的資訊！那時候你可以直接進入第2步並開始修復bug。
但在最糟糕的情況下，你只會對發生的事情有一個模糊的概念，這意味著在第2步中需要付出更多的努力。
第2步：重現錯誤
如果您在步驟1中獲得了良好的錯誤報告，則此部分可以很容易。您可以按照錯誤報告中的步驟操作，然後立即重現錯誤。太棒了！現在，您可以繼續查詢損壞的程式碼。
可悲的是，這一步往往不是那麼順利。
由於模糊的錯誤報告，這一步往往涉及很多猜測。
也許使用者使用的是Firefox，或者他們使用的是Chrome。在點選此按鈕之前，他們不確定他們做了什麼。我想知道我是否應該隨意按下按鈕並希望最好？
有時，在嘗試重現問題後，您必須反覆執行步驟1和步驟2，而不會產生任何結果。希望您可以從使用者那裡獲得更多資訊，然後再試一次。
在這一點上很清楚，為了加快步驟1和2，我們需要收集儘可能多的資訊。我們掌握的資訊越多，理解和重現問題就越容易。
第3步：找到有問題的程式碼片段
一旦我們再現了這個bug，我們就需要找到導致問題的程式碼的特定部分。
此步驟的難度各不相同，主要取決於兩個因素：
您擁有的程式碼量
您熟悉程式碼庫
（在較小程度上，您對除錯工具的瞭解）
程式碼量會影響這一點，因為每行程式碼都會增加可能的錯誤數量。值得慶幸的是，熟悉程式碼庫可以顯著縮小範圍。
找到問題通常從採取有根據的猜測開始。
“好吧，這就是問題，這就是我可以重現它的方式，所以我認為問題出現在程式碼的Y部分”
您對程式碼庫的熟悉程度越高，您的猜測就越好。這使您可以縮小需要檢視的程式碼量，可能需要大量調整。
“好吧，我最近在處理函式Z，它有與此相關的程式碼。我最好先檢查一下。“
根據問題的型別，您還可以使用除錯工具來幫助您更輕鬆地找到有問題的程式碼。
“是的，當我點選它時會出現錯誤。我將在事件處理程式中設定一個斷點並從那裡開始。“
在此過程的這一步，最大的時間匯是找到問題發生的確切位置。它可能是行為不當的功能，使用者的不良价值或任何數量的東西，您需要在繼續之前找到問題的根源。
第4步：確定根本原因
這可能是這個過程中最重要的一步，但它經常被完全跳過！
由於感知時間限制，或者僅僅因為經驗不足的開發人員可能不知道他們應該這樣做，它可能會被跳過。無論哪種方式，跳過此步驟通常意味著您的程式碼慢慢開始填充hacks和kludges。
注意，我說感覺時間限制。通常你可能會感到有壓力要快速修復。
“只需快速修復，客戶就在等待。你以後可以做好工作。“
因此，您可以使用一些程式碼來修復損壞的程式碼並跳過根本原因。當然，你很可能永遠無法妥善修復它，因為總有一些東西需要完成。
但快速修復快速修復的結果與使用膠帶修復漏水管道相同。即使在芬蘭，我們稱膠帶為“耶穌膠帶”，因為它具有修復任何東西的神奇能力，在某些時候膠帶修復開始洩漏，你需要再使用一些膠帶。不久之後，你手上就會有一個巨大的混亂，你必須把它全部撕下來。
最後，您需要花費更多時間來修復快速修復，而不是花費更多時間來完成正確的工作。
但我離題了。
確定根本原因意味著您需要找到錯誤的真正來源。讓我給你舉個例子。
假設您網站上的某些價值顯示不正確。您可以通過更改顯示程式碼來解決此問題，但更多時候，顯示症狀的程式碼不是根本原因。
如果您更深入地研究問題，您可能會發現資料庫中的資料也是錯誤的。進一步深入研究，您會發現儲存該值的程式碼已被破壞。這是問題的根本原因。您找到的原始程式碼只是在其他地方顯示問題的症狀。
如果您只是修復了症狀，那麼真正的問題就會存在。它將繼續在將來引起問題，同時你不斷修復更多的症狀。
與查詢症狀不同，此步驟不需要太多猜測。你有一個起點，從那裡你可以追溯到根本原因，所以你不需要猜測。
儘管如此，這一步可能非常耗時，因為您經常需要在幾個級別上深入研究程式碼。多長時間在很大程度上取決於根本原因與症狀相比的位置 - 有時它們甚至可能是相同的，但如示例所示，它可能會降低幾個等級。
第5步：修復錯誤
最後我們可以解決這個問題。我們已經複製了這個錯誤，找到了症狀發生的地方並找到了根本原因。
在完成所有工作之後，這一步通常是相當微不足道的。我們有關於出了什麼問題，應該發生什麼以及出現什麼症狀的資訊。錯誤通常不需要大的修改來修復，因此實現部分往往很快。
第6步：確保錯誤得到修復
作為這個過程的最後一步，我們需要確保錯誤被徹底掩蓋。
這可以通過重複您之前重現問題的步驟來完成。
偶爾這個bug仍然會重現。在這種情況下，您通常需要返回步驟4或5並從那裡繼續。
如果對軟體測試、介面測試、自動化測試、效能測試、LR指令碼開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
這個過程有什麼問題？
現在我們已經查看了錯誤修復過程中的每個步驟，我們可以確定這些關鍵難點：
缺乏有關該問題的資訊：錯誤報告通常缺少重要資訊，這使得很難理解問題並重現問題。我們擁有的資訊越少，花費的時間就越多。
猜測：我們經常需要進行一些猜測。我們沒有解決問題所需的所有資訊，也沒有辦法在程式碼中查明問題。因此我們需要猜測，這本質上是容易出錯的
時間限制的壓力：我們經常需要快速修復錯誤，因為使用者和客戶以及業務依賴於軟體的工作。反過來，這可能會使得不能正確分析問題，這會導致更多的錯誤和問題。
所有這些都有助於減緩錯誤修復並使其成為一個繁瑣的過程。我們編寫程式碼來修復bug的部分很少是最大的時間下沉！
但是，儘管如此，有時我們可以非常快速地修復錯誤。這通常發生在我們新增新功能和處理全新程式碼時。
為什麼是這樣？
如果我們在考慮使用全新程式碼時的典型情況，我們通常會非常熟悉我們剛才寫的內容。在這種情況下發現錯誤的人通常與編寫程式碼的人相同。
這幾乎完全消除了猜測！
我們知道我們剛寫的程式碼
我們經常以小的漸進步驟測試我們的程式碼，因此可能導致錯誤的程式碼更少
因此，修復錯誤是一件輕而易舉的事。通常情況下，您只需將alt-tab返回到編輯器，立即發現問題並進行更快的修復，而不是說“它不起作用”。
收集更好的資訊
我們可以有把握地說，缺乏資訊和由此產生的猜測是導致修復bug變慢的最大因素。
我們可以做些什麼來改善這種情況？
讓我們首先看一下我們可以做些什麼來從使用者那裡獲取更多資訊並進入錯誤報告。邁出這一步的第一步是向用戶詢問一些具體問題。這有助於指導使用者為我們提供更有效地解決問題所需的資訊。
以下是您可以使用的一些問題。我不記得我第一次看到這些，但我傾向於自己使用這種格式並且效果很好。
問題的簡短描述
發生了什麼？
應該發生什麼呢？
如何重現這個問題？
第一個並不是絕對必要的，但是如果您使用像JIRA這樣的工具，因為您需要該問題的名稱，這將非常有用。第二個是相當明顯的，第三個對於理解使用者期望發生的事情非常有用。雖然你可以自己解決這個問題，但最好事先了解一下 - 特別是有時它可能不是技術問題，而只是混亂的結果。
第四點可能是最重要的，但使用者並不總是知道如何填補這一點。如果可能的話，最好給他們一個小樣本，如你想要它填充，如“1。我在第X頁2.我點選按鈕Y 3.我輸入值Z“。
特別是對於Web應用程式有用的其他資訊是使用者的瀏覽器和作業系統。根據使用者的不同，他們可能並不總是知道這一點，因此能夠自動收集這些資訊可能很有價值。為此，您可以考慮整合Usersnap等服務，這有助於將更多資料收集到錯誤報告中。
在指令碼錯誤的情況下，具有堆疊跟蹤通常也是有用的，儘管具有良好的再現步驟，您也應該能夠自己獲得它。像Loggly這樣的工具可用於自動收集有關錯誤的資訊（即使在客戶端JavaScript程式碼中），這樣您就可以更好地瞭解發生的情況。
這些步驟是改進流程的良好起點。但是他們並沒有真正解決所有問題。例如，無論您嘗試多少，使用者都可以並且將繼續傳送令人困惑的錯誤報告。
我知道。我反覆告訴使用者他們需要包含重現問題的步驟，或者我們不能做任何事情，而且我仍然不斷得到可怕的“它不起作用”的錯誤報告。
“Jani，X破了修復它”
啊。
那麼還有什麼我們可以做到這一點並不依賴於那些挑剔的使用者呢？
記錄執行時資訊
記錄經常被忽視作為一種工具。也許這樣做缺乏好的庫，或缺乏使用日誌輸出的好工具 - 因為讓我們面對它，誰想通過手工查詢特定事件來瀏覽一個巨大的日誌檔案？但是正確完成並使用好的工具，日誌可以提供有價值的資訊。
大多數開發人員僅將日誌記錄用作臨時措施。很容易將一堆`console.log'打入我們的程式碼只是為了看看發生了什麼 - 我做了很多。
但是當我說伐木時，我不只是談論除錯日誌或錯誤日誌。我正在談論一般的登入 - 關於程式碼中發生了什麼，正在傳送什麼輸入等的資訊。
以更系統的方式登入需要一些工作。我們需要注意包括登入我們的程式碼，我們需要確保記錄可能有用的資訊。那麼這有助於加快bug的修復速度呢？
有時，如果沒有使用者告訴我們，可能會出現問題。自動程序在沒有記錄的情況下基本上是不透明的，你永遠不會知道出了什麼問題。
如果您有良好的日誌，他們可以幫助您更快地找到問題。根據您記錄的內容和方式，他們可以指出問題的一般方向，甚至提供更具體的資訊，例如向您顯示哪些值是錯誤的。
特別是在自動化流程的情況下，日誌記錄很重要。除非您有日誌，否則通常無法跟蹤此類程序中發生的情況。日誌應該足夠詳細，以便讓我們對發生的事情有一個合理的瞭解。
使用這樣的日誌有助於通過向我們提供更多有用資訊來減少猜測工作量。
儘管我喜歡將Java變得糟糕，但日誌記錄是他們做得很好的一件事。它有許多庫和已建立的日誌實踐。如果您遇到過Java應用程式的問題，您可能會檢視日誌甚至增加日誌詳細程度。他們中的許多人輸出了大量的日誌。
記錄有用的是什麼？對於每個應用程式來說，擁有日誌或記錄所有內容並不是絕對必要的，但這裡有一些例子：
記錄個人請求。例如，如果您使用過Apache或Nginx，它們都有一個日誌檔案，該檔案為伺服器執行的每個請求獲取一行，以及有關它的資訊。僅此資訊不一定有用，但如果您為每個請求記錄多條資訊，這可能是首先記錄的好資訊。
記錄流程或事務中的步驟。我們假設您的使用者可以上傳圖片，但您可以調整圖片大小。您可以記錄流程中的每個步驟，例如“上傳的影象”，“調整影象大小”等。
記錄與外部工具/服務的互動。訪問資料庫，API或在我們的影象大小調整示例中，如果您呼叫ImageMagick等工具來執行某些操作。
根據您查詢日誌的有用程度，實現啟用/禁用某些型別的日誌或基於每個使用者啟用/禁用日誌的方法也是一個好主意。
更快地發現錯誤
到目前為止我們所看到的所有這些措施都沒有解決我們的關鍵問題。錯誤報告和日誌雖然有用，但只會在事後提供更多資訊。
還記得我們如何找到快速修復的錯誤之間的重要區別，以及需要很長時間才能修復的錯誤是我們檢測問題的時間。
每當我們積極處理一段程式碼並在開發過程中發現錯誤時，它們的修復速度要快得多。我們對程式碼有了全新的記憶，我們已經掌握了所有資訊，因此我們不需要進行其他必要的考古。
到目前為止，這些都沒有任何幫助，即使這是花費多少時間的最大貢獻者之一。
我們怎樣才能更快地發現更多的錯誤，甚至在我們的開發過程中？
顯然，我們可以聘請二十多位QA專家來用顯微鏡進行更改。然而，對於大多數團隊而言，這並不是很實用，即使使用質量保證流程，也可能需要一些時間來發現問題，此時我們已經轉向了其他方面，所以它無濟於事。
在開發過程中可以幫助我們發現錯誤的是測試自動化。
我們可以在開發機器上執行自動化測試
即使在小程式碼更改後，單元測試套件也可以快速自動執行
精心設計的測試可為我們提供有關問題的準確資訊
測試自動化是一個更加現實的目標。它不需要大量的前期投資：您可以逐步開始使用它，並且每一步都可以獲得越來越多的好處。
單元測試如何加速bug修復？
每當我們更改程式碼時，我們都會冒險引入錯誤。但是，如果我們新新增的程式碼存在錯誤，我們通常會輕鬆地發現並修復它們。
新新增或更改的程式碼很容易修復，因為我們已經掌握了它 - 我們只是花時間研究它！這意味著可以輕鬆找到並修復其中的任何問題，因為我們不需要開始挖掘程式碼來找到它。我們仍然可以記住事情的發展方向。
因此，我們可以同意，我們越早發現錯誤，就越容易修復。