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