文章背景：
今年七月份正式入職，公司主營ERP軟件，樓主所在的組主要負責二次開發，使用的語言是Java。
什么叫二次開發呢？ERP軟件的客戶都是企業。而這些企業之間的情況都有所不同，一套標准版本的企業資源管理系統必然難以百分之一百地滿足每一家公司的所有要求。所以，在客戶提出需求之后，程序員對系統進行增減修改，這就是二次開發。
另外，我們組還負責修復客戶報上來的各種漏洞。
學會如何添加新模塊新功能
為什么說從頭到尾只看代碼是不可行的？
基本上，財務系統跨越的年限都會有十幾二十年，代碼數千萬級別，更迭的版本多達十幾個，更重要的是，連一份設計說明文檔或者技術說明文檔都沒有。光看代碼，根本就不可能准確地知道每一個類都是做什么的用的，類里面的方法是如何被調用，數據時如何流轉處理的。
光靠猜，根本不可能猜出來。
熟悉代碼的一個好方法就是做一個簡單的新模塊
以一個最簡單的系統登錄界面為例子（見上圖），現在就來做一個練習：要求建立一個新的頁面，把“物流管理系統”六個字改為“人事管理系統”，把“賬號”改為“用戶名”，把“密碼”標簽和欄位去掉，用戶名正確即可直接登錄。
代碼都是現成了，直接新建相應的文件並且復制粘貼就行，再根據需求做更改。完成若干個這樣的練習之后，就可以了解每個標簽和欄位的作用，這是最快捷的方法。另外，我建議在看代碼的同時寫注釋，有助於鞏固記憶和加深理解。
復雜的功能要用到斷點
如果把需求改為添加一個並不簡單的功能呢？有的時候，我們可能不需要一個現成模塊的所有內容和功能，只是把其中一個功能移植到另外一個模塊當中去，顯然是不可以簡單粗暴地把所有的代碼都復制過去，可是我們又不知道這個功能設計到哪些代碼塊，要怎么辦呢？
這個時候，我們要用到斷點（Break Point）調試。
如何添加斷點，我這里就不贅述了，網上的教程一大把。如果有需要的話，我過幾天找幾篇好的綜合一下給大家貼出來。
在調試的過程中，可以很輕松知道哪些方法牽涉其中，一一標記即可。
談談如何debug
首先，你要確定這到底是不是一個bug
一天，網管小明被一個上網的客人叫過去，說自己的QQ被盜了，肯定是在網吧的電腦中病毒害的，要求他負責。小明面無表情地按了一下鍵盤上的Caps Lock（大寫鎖定），然后讓客人再輸一次密碼。然后，登陸成功。
上面舉的這個例子是常識性的問題，但是很多時候用戶犯的錯誤恰好是對系統的陌生，或者對業務知識的不熟悉。例如下面這么一個例子。前幾天接到這么一個bug:用戶要做一個付款單據，在付款單據頁面中卻讀取不到。
這時候，如果我對這一個業務知識點不熟悉，很可能會先去查數據庫，看是不是數據丟失了，或者是代碼的問題，某一個篩選條件設錯了。可當時我的第一反應就是，會不會他已經對該張欠款單做過付款單了？（ps:可以這么理解，一張欠款單已經做過了對應的付款單，意味着你們公司已經給對方付過錢了，不可能再付一次）
結果到他們的系統一看，果然如此。
在基本確定是一個漏洞之后，你最好能夠在本地系統中重視這個故障
因為用戶的系統都在使用當中，其中的數據也非常重要（分分鍾幾十萬上下，出了問題碼農搬十輩子磚都擔不起），所以沒辦法任意地在用戶的系統中做測試和驗證。所以，你做好能夠在本地系統中重視這個故障。
另外，在本地重視故障的過程中，你也會對這個故障發生的條件有一個更為全面的了解。例子：假設一天用戶過來跟你說，他有這么一個瞬間，看太陽是綠色的，你就向他詢問具體情況，以便重現。他告訴你說他昨天下午五點的抬頭以仰角四十五度看太陽是綠色的，而且之前還連續看了三個小時的島國愛情動作教育片。這個時候你就可以用同樣的條件一試。如果試成功了，說明條件基本完全，如果不成功，還可以繼續詢問客戶還是不是有其他的情況。
判斷可能的方向，利用BreakPoint逐步縮小范圍
在確定了客戶所報上來的故障基本情況之后其實基本就可以知道bug可能的方向。例如前幾天我接到了一個bug，說用戶一直在用一個功能，平時都沒事，知道周二那天下午突然就不行了。
查了相關的更新記錄，那天並沒有其他的同事對這個客戶的代碼進行更新，所以問題很有可能出現在數據庫。后來發現，果然是用戶做的一張單據的數量超過了系統限制，印發某個存儲過程發生錯誤。
如果是代碼方面的問題，我們可以用前面所講過的斷點測試逐步縮小可疑的范圍，找到問題所在。例如一個數據發生了錯誤，我們可以從跟數據庫交互的方法開始查看，直到最后顯示數據的方法為止。參數傳遞過程中，可能中間經歷了幾個十幾個，甚至幾十個的方法，使用半分法設置斷點就能夠快速地定位問題的所在。
做完整的測試，證明自己的修復方案是正確可行的
一般來說，如果被一個bug糾纏了好幾天，一旦找到了問題所在一定會高興得要死，恨不得從椅子上跳起來。可這個時候，程序員們在欣喜之余要保持足夠的冷靜，因為你並不一定找到全部的答案，甚至根本就沒有找到答案。
不止一次，我覺得我已經可以修復這個漏洞了，可當我以書面的形式提交修復方案的時候，總覺得不夠有說服力，老大看到之后肯定會有所質疑。所以又緩了緩，再想了想，發現自己離發現問題的根本原因還差得遠，更別提能夠給出一個合理的解決方法。
所以我建議大家必須要在修復bug之后做完整的測試，直到證明自己的修復方案的確是完完全全地解決了問題，並且沒有引入新的問題為止。
最后說幾句題外話
好久沒有寫技術博客了。
正式上班其實也不算很忙，港資企業（深圳分公司）本來就節奏不快，再加上又不是互聯網行業，加班幾乎也就是意思意思，基本六點左右就可以走人。不過再怎樣也沒有在學校里面這么閑，所以前陣子就光忙着應付公司的培訓，顧不上來博客園。最近總算開始適應了工作的方方面面，抽出空來寫這篇文章，給自己前三個月做一個工作總結。
我有一個公眾賬號“華工小y”，每天都會分享自己工作的點點滴滴，以及業余愛好的林林種種，感興趣的朋友可以關注一下。下面這條鏈接，是我前兩天寫的一篇文章，可以看一看。
（如果覺得這篇文章對你有幫助，可以輕輕點擊下方的“推薦”按鈕，同時也期待你的評論與樓主進行交流）