經過十幾天的努力，合作的機房收費系統終於完工了，在這裏分享一下合作開發的經驗和收穫。
小崔，長海，楊元，大帥，還有我 我們一起合作開發機房收費系統，我負責系統架構設計，長海負責界面層，小崔負責業務邏輯層，楊元和大帥負責D層（有各自的分工）。
首先：數據庫的設計
這個階段收穫很大，先前自己設計的數據庫幾乎沒有用到主外鍵，感覺用主外鍵不僅容易出錯，而且再刪除數據庫中的數據的時候會錯誤百出。通過合作開發讓我找出了我的誤區。
1.主外鍵不是導致出錯主外鍵可以使各個表連接起來而不至於是零散的。
2.數據刪除只能是級聯刪除，，恰恰相反保護數據庫的安全性和一致性。
3.主外鍵有效地避免了數據庫的冗餘，可以通過主外鍵清楚地表達表與表的關係。
其次：開始了系統的架構和畫圖，寫文檔。
這個階段也是撞得頭破血流，最困惑的是文檔該如何寫？細化到什麼程度？每層應該收到什麼樣的文檔？
一邊摸索，一邊畫圖，圖畫完了，試着換位思考別人如何看懂我的圖？單憑方法的名字？自己的英文水平真是不敢恭維，最後把文檔以註釋的形式告終。在開發過程中才意識到文檔的不全面，不具體，使得開發人員開發過程中“寸步難行”，面對面的交流變得很頻繁。 最終一邊開發一邊補文檔，加上我們組員對我的寬容，不斷揣摩我的UML圖，真難爲他們了!現在回想起來可以說是以失敗告終。這裏總結幾點：
1.文檔的重要性，合作開發交流的依據。文檔的質量直接關係到開發人員的理解的正確性。
2.文檔的明確性，統一性。
1.明確性：層與層之間的接口（參數和返回值尤爲重要，這是開發人員的依據）
2.統一性：參數的類型（因爲採用實體類類型，需要詳細說明界面層需要傳入的具體參數，這樣無論怎樣設計界面都不會影響整個系統），返回值的形式和類型，命名規範，界面顯示數據的形式，錯誤處理的流程等，這樣層與層之間纔會避免衝突。
開發過程中：合作開發中沒有用工具生成代碼框架，覺得沒有代碼提示不習慣，容易出錯，一直在等，B層等D層，U層等B層，沒有保證按圖同步開發，這也是這次最大的遺憾。這讓我意識到：分層的另外一個意義，爲了分層而分層是練習，而團隊合作，各司其職，互不影響正不正是分層的價值所在。
通過這次合作開發，我們又一次體會三層的架構，運用設計模式，SVN服務器的使用，rose的網頁發佈。 不僅進一步熟悉了學過的知識，又學習了不少新的知識，有碰壁，更有收穫，更不缺乏快樂！
總結一下合作開發：
1.同步開發，只看文檔，UML圖，儘量減少面對面的交流
2.文檔要細化，編碼只是按照圖實現功能，圖和文檔不要讓人去猜，應該一目瞭然。
3.分工要明確，開發進度要有計劃，定期階段性驗收，這樣才能保證項目順利完成。
4.可以適當的做一個小demo,開發人員按照一個標準編碼，這樣保證思路的一致性。