昨天晚上為止，合作開發的收費系統的uml建模圖，文件，**的規範化工作都已經完成了。
這次合作開發使我們的第一次合作開發，總是避免不了這樣那樣的問題。
首先，合作開發分工不清，組長那麼一說，組員那麼一聽，自己做什麼只知道的大概，造成工作量重複，主要是文件沒有寫好。
命名語義不清，組員不清楚這個方法到底是什麼意思，造成有的時候呼叫錯誤，對系統整體的把控不熟悉，在開發的過程中沒有理解專案組長的真正意思。
沒有及時討論，有自己的想法沒能說出來，每個人都有自己的想法，但是這是乙個團隊，有想法要提出來，不能自作主張，說改就改，造成其他成員工作量增加，甚至進行不下去。
多次刪除重建svn伺服器端的程式
主要原因有：
1.前期設計不好。（在所難免）
2.組員擅自更改介面，造成程式框架改變。
3.svn不會使，分工不明確，造成**衝突很多。
主要的一些技術問題：
2.dll修改密碼的時候傳參沒有傳username，只傳了新舊密碼，無法驗證原來密碼是否正確。
3.dll層分工不明確，誰都有dll層的**，基類寫重複了。造成工程**重複
4.dll工廠重寫帶來bll層的修改。
5.我在寫dal層時介面中突然多了乙個方法，可能是開始沒設計好，後來加上去的，重新實現介面，在寫加上的方法。
6.操作員上機記錄中缺少了乙個機房號字段，造成查詢功能不能實現。
縱觀一下這些問題，有一些問題是可以避免的，比如分工合作等等，及時討論等等，主要對自己的規範化還是不夠，文件不健全，造成了這些問題。
這次的合作開發，從中學到了很多東西，技術上的，還有管理上的。吃一塹，長一智。為開發以後的專案吸取教訓，努力做得更好。
整理iBATIS的一些重要點和一些常見問題的解決
1 ibatis配置 增加記錄時返回隨機生成的主鍵值 2.動態新增引數 3.關鍵字 和 的區別 乙個專案中在寫ibatis中的sql語句時，order by field 執行時總是報錯，後來上網查了查，才知道這裡不該用 而應該用 隨即查了下 與 的區別 總結如下 1.是把傳入的資料當作字串，如 fi...
開發中的一些規範
新建表 incid 自增id，當主鍵不是自增時，可加乙個自增id欄位用來排序 createtime 預設當前時間 createuser updatetime 建立時也需賦值 updateuser deleteflag bool 預設0 列表查新 多表查詢 需要多表查詢時，不要超過兩張表，需超過兩張表...
敏捷開發中的一些教訓和感悟
工作一年多了，所在的公司採用敏捷開發。作為小團隊裡一名普通的開發者，既體會到了敏捷的優點，也收穫了很多經驗教訓。在此記錄一下自己地感悟，如果有朝一日自己去領導乙個敏捷開發團隊，要盡量想辦法避免和解決這些問題。背景介紹 公司的開發進度是大概每5 7周發布乙個小版本，這裡面包括了1周的各種測試時間和1周...