前言

程式存在失控風險，請反覆測試，

使用 IDE 提供的功能，

透徹地閱讀你的程式碼，

做到心中有數。

看不懂別人的程式碼

看不懂非常不解，不懂只是暫時的，

既然都有原始碼了，

還愁看不懂嗎？

程式語言的那些語法、關鍵字拋開不說，

重要的是解決了什麼問題，

怎麼解決的，

為什麼這樣寫？

丟擲異常

如果除錯程式過程中，

丟擲了異常，

那麼先恭喜你，

你離看懂這個方法已經非常接近了。

寫程式怕的是“丟擲異常”，

最怕的是測試不丟擲異常，

上線丟擲異常。

沒有一個錯誤資訊支援，

幾乎想破腦袋也很難分析出來龍去脈。

正確認識 Bug

程式設計寫程式碼，固然非常重要，

考驗的是一個程式設計師抽象業務功能，

分析邏輯，並使用方法實現的能力。

然而，

我們並不能保證，敲寫的程式碼“絕無Bug”。

要知道，

Bug 是神一般的存在，

只要你深入地剖析，

總能對一些方法進行繞過，

從而達到你提權、取資料、改資料的目的。

Bug 暫時沒發現，

僅僅是合適的條件被觸發而已。

掌握高超而全面的除錯技巧

能寫程式，非常好；

如何將你的程式除錯透過，

且在出現異常的時候，

能夠使用巧妙的方法，

將問題復現，

這是很了不起的事情。

一旦重現了 Bug，

相當於你的狙擊步槍，

已然瞄準了獵物，

剩下的，一擊必中。

寫在最後

俗話說：“書讀百遍其義自見”。

程式碼也一樣，

就想查賬一樣，

事無鉅細，親自上陣，

拿出繡花針的功夫，

反覆閱讀，不厭其煩。

大膽修改，勇於改錯，

除錯錯誤，追溯流程。

相信你不久就會對程式的功能

爛熟於胸。

對了，記得把梳理的過程用文件記錄，

這樣初期的時候，

你不用每次都要痛苦地重來一次。

1.於產品，業務確定業務流程

2.使用重構大法

3.抓包找入口點，資料輸入和輸出結構，斷點除錯跟蹤流程

4.梳理流程圖，文件化

首先拿到原需求文件，有文件最好；若系統迭代很多次了，經多人之手的話，可能文件保留也不完整了，那就實際操作一下系統，不時地向老員工吸收一下經驗，熟悉業務後再開發

第一個問題

自己寫的程式碼，過兩三個月再看都需要理理才能看的懂，更別說別人看自己的程式碼了。

這時，就體現出技術文件的重要性了，看一下你所開發的專案之前有沒有技術文件，如果有就順著技術文件往下看，只要捋清楚程式的執行流程，再看就簡單些了；如果沒有，就問問之前開發這個專案的人還在不在，不在了就問問經手了這個專案的人，如果都不在了，那就自己苦逼的一點點捋吧，多花點時間。

第二個問題

功能寫出來了不知道原理，這個是很多程式設計師都會經歷的吧。很多操作，比如crud，也不用自己知道底層原理，只要能操作成功就行了。

如果題主想要弄清楚原理，花的時間就要很多了。題主可以多問問同事，多找找資料，多看語言經典書籍，多去技術網站逛逛，比如說著名的stack，國內的csdn和部落格園等等，看多了實踐多了就會有自己的理解了。

第一點按照頁面把流程走一遍就行，沒必要非得把別人程式碼都扣的請清楚楚沒意義的事，太浪費時間。如果是二次開發跟相關業務熟悉下就行，新增的功能，看功能點在哪，是和需要和之前程式碼有關係，沒關係就直接擼，有關係，就理清這條線再擼。