到今天為止,二十五天的開發計劃也就完畢了。因為一些意外情況,有一部分功能沒有完成。不過按照計劃,依然需要中斷一下。
整個系統的整體圖如下,我們組負責紅色部分:
因為這個項目相對來說比較龐大,所以劃分出來這麼六個模組,然後每個模組中再進行那個合作開發。
六個模組在功能是比較獨立的,除了一些必要的資料來源。採用的是同一個資料庫,在設計時需要考慮不同模組之間相互關聯的表。
因為是這樣一個比較大的合作項目,版本控制是必不可少的工具。這裡我們使用Svn來進資料列版本設定,伺服器使用VisualSvnServer來進行管理,用戶端為visual svn 和tortoise svn。
有了這些工具的支援,經過分組,各組確定自己的需求、功能。然後就開始了自己的開發之旅。
這樣分模組的優點是很明顯的,首先各群組成員只需瞭解自己負責模組的功能即可。也就是可以讓開發人員的注意力更加專註一些。這樣開發效率也會提高。並且還有一點就是這樣的模組設計可以使得在以後變更的時候不會造成牽一髮而動全身的局面出現。
上面說了整體的部分。然後再來說我們這一部分。
以前的幾篇文章也說過了,在開發線上考試系統之前,開發了一個題庫管理系統,所以這個模組也算是熟悉。不夠開發到後來其實也就使用了原先系統中的一個抽題的演算法。其他的也是新設計的,因為後來資料庫發生了變動。
我們組開發的時候也是採用分模組的方法來做的,以前的合作開發都是採用分層的方式來開發的。因為考慮到分層開發一般都是開發重複的內容,效率比較高,比如說我開發DAO層,那麼我只需要完成對資料庫的操作即可,這樣的話要使用的技術比較單一,開發速度比較快,但是有一個問題是所有的開發人員都需要瞭解所有需求,不然的話開發出來的DAO層和BLL層就不能完全覆蓋需求。這也就導致在後期頁面部分調用的時候就會出現沒有BLL的支援的現象。
這次分模組開發也會有一點問題就是各個模組之間會有交叉點,這裡也是系統關鍵的地方,因為這塊要是配合不好系統整體可能最後就跑不起來。這裡的解決辦法就是溝通,不斷的溝通(文檔)。讓合作者知道你需要調用它那塊的那些介面。
在開發過程中遇到的唯一的變動就是關於資料庫設計的改變,並且是在我負責的模組即將完成之後發生的變動。個人覺得之所以出現這種情況,是因為剛開始的時候沒有很詳細的討論資料庫的設計。
所以在最初設計的時候要讓所有的開發人員都能重視,並且發表自己的觀點。不要在以後開發中存在爭議,這實在是大忌。
關於我們負責的模組也就總結這些內容了。
現在回過頭來看總結,裡面很少涉及到技術細節。由此可見在某種情況下技術不是問題,問題是設計。把技術比作知識,那麼設計就是思想。雖然沒有提到技術,但是思想卻是通過技術體現的。相輔相成,但是也要抓住大頭兒。