? ? 合作開發算是暫告一段落了，算算從開始接到任務到完成居然過了近半個月，不過收獲也是不小的。
接到任務的第一天，大家做到一塊開始商量合作開發的事宜。制定了一下我們合作開發的Schedule，然后開始了我們的合作開發之路。待組長畫完用例圖，我們一起討論，一起敲定系統的具體用例，當然免不了有爭論的地方，不過也正是這些爭論讓我們更加深對信息管理系統的理解。用例定好了，開始一起攻克數據庫。根據用例，來設計數據庫，規范字段名稱，認真討論字段類型，按著“三范式”將一個個表確定下來。然后為表添加各種約束，主鍵、外鍵、Check約束、Unique約束、Default值、Identify自增值等，并建立的數據庫關系視圖。包圖一起確定了，然后開始分工，D層+Factory層+接口層1人，Entity層1人，B層+Facade層1人+組長，U層1人。
通過方才的分工可以看出，本次開發我們采用了三層架構，應用了抽象工廠模式+反射+配置文件和外觀模式。在我自己做的機房收費系統中沒有用到外觀模式，感覺在處理多表操作的時候（比如下機），只用B層的話就顯得有些力不從心了。所以我在第一次的機房收費系統總結的最后也提到了這個疑惑（http://blog.csdn.net/xiaoxian8023/article/details/7168878）。這次用外觀模式，雖然代碼又多了，不過思路卻比以前要清晰很多。外觀模式將B層繁多的類進行了封裝，對于U層而言，不需要了解那么多的細節，外觀模式為U層只提供了一個簡單的接口，U層其實都是那些粒度較粗的用例，只需要調用Facade層的方法即可，有Facade層來整理具體的邏輯，既滿足了U層的需要，也隱秘了數據。所以外觀模式這個“中介”對于我們來說還是很有幫助的。
當然我們也用到了策略模式，這個主要是用在下機結算時，根絕不同的卡類型，使用不同的計費方式。理解的比較淺。向七期的前輩請教，說其實刷卡上機和下機也是一種策略。當時沒怎么明白，不過現在有些理解了。上機和下機也是兩種不同的策略。刷卡時，要檢測卡的上機狀態，根絕上機狀態的不同，實現上機和下機兩種不同的策略。
這次有點遺憾的是觀察者模式。在處理強制下機操作時可以用到。將在線的全部加載到一個列表中，然后通過觸發強制下機操作，遍歷列表，使列表中的每一項都執行強制下機操作。是一個很好的方法，只可惜這次由于種種原因沒有加上，師哥遺憾。
不過這次的開發給我的感覺不像是同步開發。這次我們想自己動手敲代碼，沒有用UML圖來導出代碼框架，所以我們由下層寫出框架，然后提交，再由上層根據下層的代碼提示來寫，這樣一般不會出錯。不過想想，圖都給出來了，其實不用等著下層的提交框架也可以寫。一個好的設計，有完善的圖和文檔，我們完全可以根據這些來完成自己的工作。
本次合作開發給我最大的感覺就是一個合作才是軟件開發的正道。當然成功的合作，取決于項目的設計、分工的合理性及每個人對待自己任務的態度。項目設計的好壞可能直接影響到你的項目是否能夠完成。如何更加合理的分工，我感覺應該是每個人做自己擅長的那一部分，可靠性會增加很多。態度問題，每個成員都應該盡力盡快的完成自己的工作，不要因為你而使得整體項目計劃延遲。
有個問題想了半天，還是感覺說說比較好，我們有一部分成員把重點只放在了經歷合作開發，而項目本身有些馬虎了，感覺這樣不好。我覺得，雖然合作開發的主要目的是為了讓大家更好的理解三層，培養合作開發的意識和能力，但是，我們不能對于系統太過草率了。在我看來，每一個項目都是一個生命，生命不應該是殘缺的。對自己的任務完成度要求要高，這也是一種鍛煉，同時也是一種職業素質。
當然在合作開發過程中，也發現了自己要學的東西還很多。比如快速畫圖，數據庫表直接轉化為實體類和UML圖，SVN的熟練使用，Rose導出網頁版的圖等等技巧都是自己所需要鍛煉的。不怕不知道，就怕不知道，現在我已經知道了，剩下的就是去實踐。

總結

以上是生活随笔為你收集整理的谈谈我们的合作开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。