改bug是程式設計師工作的一部分，如果只是以湊合的心態去對待工作或生活，那麼一生也只能是“湊合”而已。心態決定一切！

不是，修改bug是個大工程量的操作。

先從業務流程上確認修改是否會導致新的bug出現，再從技術上考慮修改是否符合專案開發規範、符合設計規範，進一步考慮程式碼是否優美，是否可以進一步精簡乃至重構。

程式設計師應該對程式碼質量和效能有著苛刻、極致的要求，實現功能只是一方面，還要考慮程式碼的可維護性、健壯性、耦合性等等。 最低的要求，如果出bug都不用心認真對待的話，就不及格了，千萬不能草草了事，這樣長期下去害的只是自己

即使純軟體，找bug也非常難，即使版本定稿後，經過有關部門嚴格測試通過後，由於可能實驗室條件下沒能滿足bug的觸發條件，故短時間內可能難以捕捉。

故在軟體設計上，要減少bug生成的編寫程式碼習慣，這樣可以大大降低bug的出現。

總之，沒有任何程式設計師可以牛逼地說他的程式沒有bug，否則程式為何不斷升級？

對外人好聽的是升級，實際上我們找到了新的bug！

因為一個新版本的誕生就意味著一個新bug將要崛起！

下圖是本人十數年前編寫和在網上流傳的，版本不知升級多少次了，雖然現在非常穩定，但肯定有bug沒被啟用！

個人感覺肯定不是湊合就行。出現bug，去分析bug的問題所在，找出bug，及時認真的解決，同樣也是個人能力的一種體現。個人認為，作為一個合格的開發者，程式碼的能力是一部分，發現問題，解決問題的能力也是很重要的一部分。如果一遇到bug，只是草草了事，那麼，肯定避免不了會再次出現問題，甚至會引發其他的問題，這樣會更加浪費時間和精力。同樣，出現問題不認真對待，解決也是對自己對公司的一種不負責任。長期下來對自己對公司都沒有好處。所以個人認為，出現bug，不僅要認真去對待解決，更要做好問題的記錄，把解決方案寫成文件或者發一篇問題部落格，這樣如果以後出現相似問題更容易解決，而且長此以往自己的技術，開發效率也會大大提升。

不應該，但時常發生。

應該做的是：發現了bug，應該找到其根源，將其根除。

實際上：

剛開始，基礎程式碼質量較高時，湊合改改，往往就此奏效了，不少人也就這樣處理，問題短時間不再出現，軟體開發進入下一步

隨著開發的進展，出現了更多的bug。如果再多湊合幾次，程式碼質量就越來越差

有的軟體，就此交付了，bug可能還寫在操作指南上，湊合用

有的軟體，陷入泥潭之中，湊合改掉一個bug，又發現更多的bug，改了又改

湊合改bug的老司機開了又開，終於翻車了

曾經用過的帶著bug交付的某稅務軟體，不能改密碼，一改就崩潰。諸如此類，低質量軟體不少。

實際上，被湊合改掉（其實是躲避掉）的bug還是很多的。但要想成為一個有價值的程式設計師，不想產生那麼多爛程式碼，就儘量別幹這種事。

當然不是，既然是BUG，就一定存在語法（拼寫）錯誤或者邏輯錯誤。

語法錯誤簡單，細心查詢總能找到，而且修正後就一勞永逸了。

邏輯錯誤就比較麻煩，它又分為實現邏輯錯誤和功能邏輯錯誤，實現邏輯錯誤是開發人員對業務實現演算法的錯誤，主要是由於開發人員開發經驗不足或者對業務理解不透徹造成的，這類錯誤通常需要有經驗的開發人員協助排查；而功能邏輯錯誤則通常是需求不清導致的，解決方案是和客戶重新溝通需求，明確需求再重新定義業務功能。所有這些bug，原則上都應該梳理程式碼，清晰流程，然後徹底的修正。

但現實總是很骨幹，實際中大多數複雜系統，特別是老舊的複雜系統，已經沒有人能梳理業務，也沒有人能全域性掌控程式碼，而且也沒有成本去梳理整個系統（通常成本更低的方案是推倒重來）。而這時候最好的處理方法就是補丁摞補丁，能湊合就行了。

作為一個工作多年的程式設計師，我來聊一聊關於 bug 的問題吧！

我個人一直在堅持信奉一句話：程式設計不息，Bug 不止。為什麼這麼說呢？

關於程式設計師和 bug 之間的關係

關於程式設計師和 bug 之間的關係，我是這麼看的。作為程式設計師，自程式設計伊始，Bug 就會如影隨形，因為它就是你的影子。Bug 就是軟體的影子，和軟體就是與生俱來的，是不可逃脫的好 CP，有著難捨難分的好感情。Bug 無處不在，對於程式設計師的酷愛，超越程式猿的老婆，它對於軟體的痴迷，比程式猿還要厲害，即使再牛逼的程式猿也逃脫不了 Bug 的魔掌。

其實，程式設計是一套極其複雜的流程，有著各種邏輯關係，只要有邏輯關係以及各種流程的地方，就可能存在 bug 。這其實是不可避免的。你在生活中遇到的各種問題，就像是程式設計中遇到的bug。因為，有些問題，大家都是不可預見。你不可能在今天的某一件事，就會成為未來生活中的麻煩，是一樣的道理。

遇到 Bug 時，你的反應是什麼？

遇到 Bug 時，每個程式設計師由於性格不同，反應也不一樣，看看你屬於哪種？

理性的程式設計師會說：這個 Bug 能復現嗎？

自負型：這不可能，在我這是好好的。

經驗型：不應該，以前沒這個問題啊？

幻想型：可能是資料有問題。

無辜型：我好都好長時間沒碰這塊程式碼了，怎麼可能！

樂觀型：只需要改一行程式碼，不會影響其它程式的。

實踐型：你重啟一下服務試試。

其實，從內心來講，每個程式設計師都不希望遇見bug，所以遇見bug時就會有各種各樣的反應，他們的反應就顯示出了當時他們的心理。

那程式設計師改 bug，湊合能行嗎？

我們不可否認，在工作中有相當一部分的程式設計師，都是遇到 bug ，哪裡報錯，就改哪裡。這就相當於發洪水了，哪裡發洪水，就堵哪裡！這在一定程度上，在當時，可能確實解決問題了。

比如：程式設計師報錯了，報了一個空指標異常，導致程式崩潰，那估計得有相當一部分的程式設計師，不會去思考背後為什麼報空指標，其他地方有沒有同樣的問題！而大部分程式設計師可能只加一個非空的判斷就過去了。這就是湊合改 bug ，只解決了當時的一個問題，其實，並沒有挖掘背後深層次出現 bug 的原因。那如何減少程式碼中的 Bug 呢？

說了這麼多廢話，主題不就是想說，如何減少程式碼中的 Bug 嗎？其實我這個人比較矯情，比起如何減少程式碼中的 Bug？我更喜歡吐槽。

每個團隊制定一個程式碼規範，同一個專案，同一個規範。

熟悉功能需求，找到合適的功能框架。

編碼之前，一定要先理清需求，將業務轉化成功能點。根據功能點分模組，寫方法。

編碼過程中，一定要嚴謹的進行業務邏輯處理，比如：丟擲的異常要處理，在 for 迴圈中，儘量不要頻繁 new 物件等。 程式碼邏輯要清晰。

做好程式碼審查，Code Review 。不要懶於程式碼審查。

其實還是那句話，說起來容易，做起來難啊！就跟寫註釋一樣，寫一句註釋能有多難，大部分程式設計師都懶於寫註釋，到最後，時間長了，自己都看不懂自己寫的是什麼玩意了。我相信大家都知道程式設計師討厭的四件事，那就是：寫註釋、寫文件、別人不寫註釋、別人不寫文件。

如何挖掘 bug 背後的終極大 boss 呢？

我們都知道，沒有完美的程式，是程式就會存在 Bug，而且 Bug 只是程式錯誤的表象，只是一種症狀，我們修復後還應該探究更深層的原因。更要學會思考，尋求 Bug 出現的本質，究其根本，總結經驗，才能防患於未然，避免 Bug 重複出現。

既然要學會思考，那麼當 Bug 出現時，我們第一時間當然是去修改它，修復它。其次就該我們思考了，這時候就得問問自己，最起碼得問三個問題：

我在其他地方犯了同樣的錯誤嗎？

修了這個 bug 會引起什麼其他連鎖反應或者會按下葫蘆浮起瓢嗎？

怎樣預防這種 Bug 再次出現？

只有把這三個問題考慮清楚了，我們才不會重複犯錯，才會讓自己寫的程式碼質量更高，程式更穩定。第一個問題是根據某一個 Bug 提前找到可能會發生的，與他類似的 Bug ，提前預防和解決。第二個問題是思考一下，解決了這個 Bug 會不會引起其他問題？我們都知道程式的嚴謹性和邏輯性，通常是牽一髮而動全一身。所以這個問題很重要。第三個問題：查詢 Bug 真因，總結記錄，預防再次出現。

我相信大家在解決問題和 Bug 的時候，通常不會思考這三個問題，大家往往只會出現一個 Bug ，就解決一個 Bug ，對於沒有出現的或者即將出現的不會提前預防和解決。這不僅僅是缺乏思考的一種表現，更是一種懶惰的行為。

最後，我用一句非常文人墨客的話來結束這個問題的回答吧！

程式設計不息，Bug 不止，在天願作比翼鳥，在地願為連理枝。天長地久有時盡，此恨綿綿無絕期。Bug 對你如此深情，如此愛你，你怎麼能拒絕？這就是我們程式設計師程式設計工作中的必要需求。

當然不行啊

贈送大家一首程式設計師之歌：

十年生死兩茫茫，寫程式，到天亮。千行程式碼，BUG何處藏。縱使上線又怎樣，朝令改，夕斷腸。Leader每天新想法，天天改，日日忙。相顧無言，唯有淚千行。每晚燈火闌珊處，程式設計師，加班狂。

對於普通的程式設計師來說，可能無法做到一次編寫沒有bug的程式，但是要儘量減少bug的數量。大部分bug的起因都是對業務邏輯的抽象不準確，對業務程式碼的具象不嚴謹。　　

一、提升自身的能力素養，減少自己與他人麻煩　　

1、理清真正需求　　

經驗稍淺的程式設計師經常在收到任務需求的時候，很少動腦思考任務需求，而是直接按照需求去做。而有經驗的程式設計師多半是拿到需求的時候，會站位思考這個需求是否是真正需要，功能開發是否真的有用，然後跟團隊進行溝通分析，達成一致的任務需求。

所以，這也就是為什麼，很多程式設計師剛寫完幾千行程式碼，然後被要求重新寫，這種崩潰的感受，誰也都不願意接受的啊。　　

2、明確每個細節　　

瞭解真正需求之後，就是梳理實現這個目的需求中的各個細節是否合理，對於細節需求描述模糊或者存在歧義的地方，可以和團隊或者客戶進行溝通，在專案開發之前將細節敲定下來。　　

如果是任務需求是開發的方向，那麼細節末枝則是整個開發專案的枝幹，每一個枝幹的需求都可能影響到真正的需求，如果一個小部分沒理清楚，那麼可能整個專案的走向都會出現差錯。　　

3、規範自身，專注練習　　

程式設計師自身也存在著一些致命缺點，而這些缺點都需要認真去對待與克服。比如說對待其他程式設計師寫的程式碼時，都是帶著一種挑剔和學習的態度，但一旦對待自己的程式碼，就認為自己寫的程式碼都是正確的；所以，應該端正態度，一視同仁。

雖然說難以接受自己會寫有bug的程式碼，但是為了那一點點自尊和不拖後腿的覺悟，不如多花點時間專注練習，來保證程式碼的質量，畢竟技術在於實踐。　　

4、建立bug庫　　

年少讀書那會兒，我們經常會寫錯某個漢字，以及常錯的習題，一般老師都會教我們學會建立錯題本。程式設計也是一樣，為了防止在程式設計方面不在同一個地方，摔倒兩次的原則，也可以建立bug庫，將每一次自己程式出現的bug案例，都記錄到bug庫裡，檢查程式碼的時候，逐一對照，確保不會再犯錯。　　

二、團隊協作，減少重大錯誤和弱智bug　　

在開發大量的解決方案時，我們也會遇到相同的問題，比如智慧手環方案和智慧手錶方案，其功能是差不多的，甚至可以說部分程式碼可以替代使用的，bug則可能因為先前解決過而沒有出現。　　

工作不是單打獨鬥，團隊寫作也很重要，前期的技術方案和設計評審、程式碼審查，能夠減少一些重大的錯誤和弱智bug。

程式設計師們遇到bug不要煩躁，要保持心態平和的狀態。因為每個人都不可能一次性完美地完成任務，每個人都需要慢慢完善，程式碼也一樣。同時也祝願程式設計師們——千行程式碼過，bug不沾身！

湊合是不行的。bug必定存在的，預防bug的最佳實踐是寫程式碼時就要有預見性，經驗很重要，寫程式碼的經驗，規範化，還有平時除錯的經驗，除錯得多了，自然知道怎麼找根源，修復多了，才知道什麼叫牽一髮而動全身從而找準修改點。這沒有定式可言，道可倒，非常道，靠自己領悟了。