-
1 # 心向未知
-
2 # 月漫灣
如果長時間修不好，說明方向是錯誤的，還有一點很重要，自己是否理清了業務邏輯，如果邏輯不清，你不要繼續修改了。如果你的程式碼寫的很是複雜，不夠清晰明瞭，說明程式碼本身的邏輯就有問題，所以，建議你理清邏輯（業務邏輯，程式碼實現邏輯等），然後再繼續修改。
-
3 # 技術小兵
我覺得程式設計師的能力高低主要體現在對bug的控制上。好的程式設計師不僅自己很少寫bug，而且能夠將bug控制住，好的構架師則會在多人，或者大規模開發中用構架的手段將bug，或者將排查bug所需要的時間控制住，或者更直白的說就是將風險控制住。所以，如果你修改一個bug很長時間，只有兩種可能，一，你不知道問題在哪，修了或者說不知道根本問題在哪。往往修了一個bug，帶出一堆bug來，讓人崩潰。這時應該想想是不是對需求沒了解透，或者演算法錯誤了，總之要跳出當前的範圍，到更大的scope裡去找問題如演算法設計，構架設計。二，基礎知識不牢固，或者經驗不足，往往出現多執行緒死鎖，分散式環境下的時有時無的bug，新手往往無從下手，這時如果是這種情況應該儘快求助，快速止損，快速學習，而不是藏著掖著，永遠不要害怕求救，這樣可以快速積累經驗，快速成長。
-
4 # 大猿影視
首先你不要著急，你要分析你的業務場景，一般當問題出現的情況都是對業務不太瞭解造成的業務邏輯錯誤，還有一種就是本身程式碼的寫法有問題，這種應該好解決，因為這種會議可能會直接報錯，但是業務場景並不是那麼明顯的報錯，一些錯誤你需要去重新核對業務場景，與程式碼邏輯，並驗證資料庫儲存是否正確結合這些，慢慢地排查錯誤，慢慢地走一遍正常的業務邏輯流程你應該就會發現哪裡有問題？
-
5 # IT極客老兵
如果長時間修復不了bug，說實話，專案經理或者產品經理肯定對你有意見，你的績效可能會受到影響。
敲程式碼的，就是我們俗稱的碼農，平時工作再忙，也要勤於總結和學習，既要埋頭拉車，也要抬頭看路。
軟體行業，技術更新換代非常快，如果你不經常學習，很快就會落伍，就會出現你說的長時間修不好bug的情況，這就意味著你的技能跟不上了，需要更新。
不斷學習，才能更新技能。不斷總結，才能明白得失，揚長避短。
祝學習進步，工作順利！
-
6 # 我低端就改我名
1.穩定的重現bug。如果你不能穩定的重現它，說明你還不瞭解它，更別提修正它。
2.為這個bug寫單元測試，與其他的同類測試放一起。這些測試共同保證你的新程式碼不會帶來更多問題。
3.估算bug可能的模組，開啟或者新增執行時log。這些log將可以使你定位bug發生的具體模組。
4.在具體模組設定斷點，按行除錯。
-
7 # AI科技猿
感謝閱讀！
長時間修不好BUG，是有很多BUG，還是一直找不到一個BUG的原因？
不同情況得找不同應對方法！如果是一個BUG總是找不到問題，這個就說明你的除錯手段不夠豐富，沒有很好的利用好除錯工具！
我在工作中除錯，遇到程式碼級的BUG，透過“加斷點，跟蹤除錯”，的方法，基本都能找到問題原因。
但是定位BUG之後，修復才是關鍵點。如果不熟悉這段程式碼不要輕易改動程式碼，要分析清楚：
（1）這段程式碼是不是底層程式碼，被多處呼叫？如果這樣，修復要小心，考慮清楚所有呼叫的業務邏輯。不然，就是噩夢的開始，“摁下葫蘆起來瓢”！
（2）這段程式碼在業務邏輯中的位置，你的修復方式，會不會改變其他業務邏輯？如果這樣，又是一個巨大的BUG！
BUG的修復能力是程式設計師多少個996換來的！是付出多少汗水換來的！好多時候，出了BUG，經常見到大牛說“我猜這是某某模組的問題”，你會發現，大牛說的沒錯！
大牛真是猜的嗎！當然不是！
這是因為，大牛對該專案的業務邏輯爛熟於胸，對程式碼中的架構更是十分精通，遇到BUG，不用藉助工具除錯，短時間內就能分析出大概的位置！
這是大牛花了時間的研究業務和程式碼架構的結果！多數大牛都是公司加班最多的，大牛們在研究業務邏輯和程式碼架構！
總結所以，程式碼出現BUG，要想提高BUG的能力，就要花時間去熟悉專案業務邏輯，學習專案架構！
當我們看到一個人很牛的時候，這位大牛一定付出了巨大的心血！
-
8 # 一事無成即心安
這應該不太可能，除非前期架構規劃做錯了，但基本都有補救的方法。題主是不是說修補別人開發的軟體bug？那就得仔細全盤看了，至少得大概了原來開發人員的思路。
-
9 # 冰晶娃
遇到bug很正常，遇到當前情況解決不了的bug也很正常，可以採取其他方案代替，滿足業務需求，別死磕，除非是自我學習鑽研。
-
10 # 累的像狗還要繼續
程式設計師，bug人人都有，不管是初級還是高階的，區別在於bug的出現率和修復的效率問題。修復不好bug這是bug的定位問題。
開發前期要求
業務熟悉程度。一定要了解業務才能寫程式碼，不是說拿到需求就開始寫了，要在對業務的總體理解情況下做好規劃才能開始編碼。
bug定位
1.基於自己對業務瞭解程度和程式碼熟悉程度來確定bug出現在哪裡。這也是我一開始說業務熟悉程度和程式碼熟悉程度的關鍵原因。
2.掌握開發工具定位bug的技巧。前端可以用瀏覽器的除錯工具，後端可以用IDE的debug工具等。
bug修復
只要你真正定位出了bug，其實修復已經是相對簡單的了，但也不排除這個bug是系統開始設計的缺陷導致的，這種bug可能會導致功能或者系統的重構，這是致命的，所以一開始設計的時候一定要多下點功夫。還有一點就是，修復後一定要自測，就像上面說的，bug可能不斷的出現，這樣不僅浪費自己的時間也浪費測試人員的時間。
總結
總的來說bug是沒有修不好的，只是你不瞭解程式碼或者業務。當你覺得bug修不好的時候，回頭重新瞭解下業務和程式碼，說不定你就有思路了。同時也要求你多自測，多想想可能出現問題的情況。
回覆列表
建議多從源頭個細節去分析，並且一定要把程式碼模組化，及一個函式實現一個功能，不要貪多。同時注意查詢分析陣列，指標等，結構體定義等，檢視有沒有有沒有陣列越界，野指標的出現，記憶體的洩露，還有結構體位元組對齊等問題。同時也要藉助網上的力量，現在網上的各種資料都很多，不大清楚的可以百度一下。也可以向同事，大牛尋求幫助。一起探討，多個人一起總比一個要考慮更加全面些。