談談咱們的合做開發

    合做開發算是暫告一段落了，算算從開始接到任務到完成竟然過了近半個月，不過收穫也是不小的。

    接到任務的第一天，你們作到一塊開始商量合做開發的事宜。制定了一下咱們合做開發的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導出網頁版的圖等等技巧都是本身所須要鍛鍊的。不怕不知道，就怕不知道，如今我已經知道了，剩下的就是去實踐。

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。