合作專案開發到現在也算是該告一段落了。上午有除錯了乙個小時，改了其中的不足的地方。
說起這個專案真是有種失敗的感覺。這幾天也是鬱悶壞了。
前面已經總結一次了。不過沒有總結到最後。
從最初的修改設計，一直開發完
bll層。一切都是預想的那樣，雖然一開始拿到我的設計方案時大家有了不同的意見，該改進的地方也都做了改進，動了不小的「手術」。但是整體上來說還是按照我最初設計的架構來進行的。不過到最後開發介面層的時候問題就全部暴露了，那就是我最初的設計並沒有完全滿足使用者的需求，不過這也不能算是令人頭疼，因為少幾個功能可以補上。但是令我頭疼的是介面層在開發完了之後進行除錯，竟然每個窗體都要進行修改，也就是說整個介面層就是乙個錯誤。（很鬱悶。。。）
我思來想去，總結了一下原因：
首先是我在最初設計時沒有考慮完整，沒有對專案總體的結構，內部的詳細關係進行乙個很詳細的描述。這導致在介面層在做的時候對一些事情不是很清楚。
其次是我沒有對他們進行嚴格的要求，我是指在整個專案中每個人的編寫**的規範，補充文件的規範。
再有就是沒有整體感，沒有責任感。可能也是因為這是在學習，並不是真正的專案。大家都急於完工，各自負責各自的部分，完成之後就感覺沒事了。這點我覺得尤其可以體現在介面的開發上，或許不應該交給兩個人來開發，這樣會造成混亂。並且介面層的開發壓力較大，因為大家都完事了，就剩下介面了，著急是難免的。還有就是責任感，就是要對自己的**負責，要清楚明白的知道自己的**要表達什麼意思。其實都是基本素質的問題。要不然總會在一些小事上犯錯。
看了一本《領域驅動設計》精簡版的書，講的是在做專案之前，首先要找到需求，也是書中所謂的要多和領域專家（也就是客戶）交流，這樣才能形成完整的需求，有了完整的需求才能夠進行設計。我在看這本書時想到我們現在做的這個專案，之所以失敗，就是因為我個人在最初的設計時沒有將需求完整的囊括進設計裡，也就是說沒有用需求來驅動設計。就像我們常說的要文件驅動開發一樣，沒有文件固然也可以進行開發，但是沒有文件就像是沒有指導一樣，你不知道那個模組應該怎樣對外提供介面，哪個模組應該呼叫哪個模組。
因此也就是最初設計的不完善，最後導致了後期在將完成時問題百出。
這幾天也開始看《程式設計師的修煉之道》，裡面剛開始就講了一節「**讓貓吃了」，就是說不要給自己做出來的不完善的東西找藉口，如果真的要找的話，不如說是**讓貓給吃了。這也是乙個程式設計師必備的素質吧，
be honestly
，be
responsibly
個人感覺現在應該從一些經典著作中看看前人是如何應對這些問題的。
對於專案來說，設計是失敗了。不過對於學習來說還算是成功了吧。因為成功的犯下了錯。這個經歷是彌足珍貴的。
謹記吧！！！
合作開發機房收費系統小結
這次合作機房收費系統有很大收穫，最大的感觸就是交流很重要。首先說一下收穫 1.學會了svn的基本使用 2.了解了合作開發的基本流程 3.使用rose畫圖比之前更規範 4.用rose生成詳細的開發文件 5.學會了使用sqlhelper 6.對設計模式有了進一步理解 策略加簡單工廠模式，外觀模式，抽象工...
機房合作開發總結
合作開發之前的準備階段 我們詳細了解了 svn的使用 ea的使用 對於svn雖然在去年的暑假中就有所了解和使用 但相對於這次的使用 發現先前對 svn的認識是有所偏激的 是版本控制管理軟體 它可以解決以下的問題 開發人員合作的問題,了解檔案的修改檔案 make 時版本的問題 完整編譯 多個人修改同乙...
首次合作開發 收穫總結 收費系統
我們共分兩隊，每隊六個人，胡陽帶一組，學宇帶一組。到今天，我們六個人合作開發的收費系統出爐了，這個系統是建立在我們對這個系統需求深厚了解的基礎上開發的，剛剛按照mvc三層架構開發完自己的第二版收費系統，馬上就投入到合作開發的隊伍中來了，在這次活動中，胡陽事先做好了系統架構分析，寫了乙個詳細的時序圖，...