專案寫完了，進行最後的測試，在此期間遇到的了各種問題，有些看似一樣的錯誤，可原因卻個不相同。大致分下，有一下幾種：
1、格式轉換錯誤
由於很多資料是從文字框中獲取的，是string型別，但我們的實體類屬性設定的是int或date等，那麼就需要轉換，但是像一串字母或漢字是不能轉為int型別，同樣格式不對的一串數字也不能轉為date型別，這就要我們去加資料判斷，有時我們疏忽了，就會造成這樣的錯誤
2、空值異常
這個情況，多是在持久層或業務層封裝的時候，沒有把相關的屬性封裝到物件中，當呼叫bean中的屬性，得到的就是null。
3、不包異常，但是相應的容器中不顯示內容，最常見的就是table列表
這是一般看兩個地方，首先，列印業務方法，是否能列印出來，如果不能，檢查相應的方法呼叫個sql語句是否正確；如果能列印出來，再看實現層的**是否寫對，比如是不是把相關的變數新增進去了等等
我的第一次專案需求調研
很幸運能在畢業的這一年參加一次專案需求調研與分析。以前在課本和大學的課堂上理解到需求分析是整個專案的基礎，需求分析的嚴謹直接決定專案能否驗收。在參加調研之前，也對這個專案所處行業進行了比較深入的了解，理解一些該行業的規則。需求調研開始的那天，因為抱著一顆想要完美自己的第一次需求調研的心，顯得比較緊張...
我的第一次專案需求調研
很幸運能在畢業的這一年參加一次專案需求調研與分析。以前在課本和大學的課堂上理解到需求分析是整個專案的基礎，需求分析的嚴謹直接決定專案能否驗收。在參加調研之前，也對這個專案所處行業進行了比較深入的了解，理解一些該行業的規則。需求調研開始的那天，因為抱著一顆想要完美自己的第一次需求調研的心，顯得比較緊張...
我的第一次專案管理 一次慘痛的教訓
最近總想發點時間寫些東西但抽不出時間，趁著放年假並且今天剛開完專案的年前回顧會議趕緊寫出來，其實挺不好意思講的，有點尷尬。由於公司逐步發展，專案越來越多，沒有人有時間來負責這個專案，我的老闆們可能看我比較順眼於是便讓我來負責這次的專案開發，於是我便莫名其妙的變成了專案負責人，一開始我是拒絕的，讓乙個...