工作中會帶一些實習生或新人，大多缺乏經驗，項目調試是他們很頭疼的問題，代碼出了問題往往就束手無策了，很影響工作效率。其實代碼調試是有步驟可循的，代碼出了問題要做的第一件事情是定位問題，只有知道問題出在哪才能解決。
一個Java Web項目通常是由前端和后端組成的，請求是由前端發送給后臺代碼處理的，所以我們要做的第一件事情就是確定問題出在前端還是后端，先要保證前端發送給后端的請求參數是對的，有些同學在請求參數不對或者請求根本沒有到達后臺的情況下盲目地去檢查后臺代碼是不對的。
前臺請求通常通過form、超鏈接或ajax等方法提交給后臺，我們必須確定提交的鏈接是對的，然后是參數，提交的參數我們可以通過瀏覽器地址或者一些瀏覽器調試工具（例如火狐的firebug）得到。
如果請求鏈接是對的、參數也是對的，那就是后臺的問題了，后臺問題通常通過eclipse的debug工作調試，但有一種情況，就是開發中會運用一些mvc框架，例如struts2、spring
mvc等，我們在后臺某個地方加斷點根本就沒反應，這時候有個很簡單的方法，把斷點加到control層的代碼入口處，如果還沒反應，那就是框架配置問題了，要檢查配置對不對。
對象，你可以理解成一種具有屬性和行為的實體，它可向外部提供服務。而使用這個對象，可忽略其內部的細節，只需要知道使用這種服務時的“投入”、“產出”即可，因此，“高內聚、低耦合”是面向對象編程的基本思想。
略舉一例，平時我們工作中要刪除某條數據，一般不是真的delete掉，而是用一個status標識，status為-1表示刪除，你寫刪除接口時完全可以這么寫：
Class UserService{
private UserDao userDao;
public void deleteUser(User user){
user.setStatus(-1);
userDao.update(user);
}
}
這個邏輯其實執行的是更新操作，但接口名仍是deleteUser，因為它提供的確實是刪除“服務”，調用接口時我只需要知道我調用這個接口時會刪除對象，至于它怎么實現，我管不著。
Java中到處是指針引用，習慣了使用c語言指針的程序員往往會亂用指針，而破壞了面向對象的思想，比如，我要查詢某個用戶的密碼，有人可能會這么寫：
Class UserService{
private UserDao userDao;
public void queryUserPasswd(int id,User user){
String passwd=userdao.getUserPasswd(id)
User.setPasswd(passwd);
}
}
這種寫法在語法上沒什么問題，也能得到正確的值，但傳個user對象進來就有些不妥了，我要得到密碼，傳個用戶的密碼，只要給個id就可以把密碼返回給調用者了，干嘛要讓人再傳個對象進來？
作為一個項目經理，在工作過程中，確實會遇到令人哭笑不得的接口，就像上面那個刪除接口吧，有人會這么寫：
Class UserService{
public void deleteUser(UserDao userDao ,User user){
user.setStatus(-1);
userDao.update(user);
}
}
這接口寫得，讓人摸不著頭腦了，我刪除一個user對象，還要傳個userDao給你，意思是你為我提供服務，我還要給個工具給你，這說不通吧！
Java是純粹的面向對象語言，寫Java程序時要時刻記住，你在為別人提供服務，為別人提供服務就不應該提出過多的附加要求。這個問題在使用MVC模式分層思想的時候體現得更加嚴重。在使用MVC模式開發的時候，往往將整個項目分成幾層：action層、service層、數據庫處理層（dao層）等等，每一層往往由不同的程序員編寫，這時候要格外提醒自己在為別人提供服務。在一個新項目開始的時候往往會出現一個問題：在增加某條數據時，要對這條數據的字段進行驗證，不能為空或者長度過長等等，如果沒有驗證容易拋錯，在分層編寫接口時，開發人員經常想這個驗證應該在上層或者下層做吧，我這邊得到的數據是正確的，最后導致誰都沒做驗證。只要你記住了提供“服務”的思想，就不應該要求別人給你的數據是正確的，而是應該處理各種非正常問題，保證用戶給你的任何數據你都能給出相應的返回，當然，在實際的項目中項目經理可能規定數據驗證在service層做。