三、 經(jīng)驗(yàn)與教訓(xùn)
從項(xiàng)目規(guī)模中可以看出,該項(xiàng)目的時(shí)間還是比較緊張的;另外一方面,項(xiàng)目交付是在合同規(guī)定日期之前完成,而且通過(guò)了所有的功能測(cè)試。從一定意義上的講,項(xiàng)目的開發(fā)是取得了一定的成功的。
3.1 經(jīng)驗(yàn)
![]()
在項(xiàng)目開發(fā)前,項(xiàng)目開發(fā)商已經(jīng)通過(guò)其它項(xiàng)目,實(shí)施了以XP為代表的靈敏軟件開發(fā)方法的部分最佳實(shí)踐,并取得了很大的成功。因此,在該項(xiàng)目的執(zhí)行過(guò)程中,項(xiàng)目開發(fā)商繼續(xù)采用了XP的部分實(shí)踐以及其它軟件開發(fā)方法中的推薦做法[1][2]:
每日晨會(huì):在項(xiàng)目實(shí)施過(guò)程中,天天早晨開發(fā)小組都要參加一個(gè)持續(xù)15分鐘左右的會(huì)議,由項(xiàng)目經(jīng)理主持,聽取每個(gè)成員的進(jìn)度,并根據(jù)進(jìn)展情況,對(duì)于進(jìn)度和資源進(jìn)行調(diào)整。
由于會(huì)議是天天進(jìn)行的,PM很輕易從中獲得真實(shí)的項(xiàng)目情況-"掀開地毯下面的東西"[4],從而對(duì)風(fēng)險(xiǎn)有了較好的控制。
交叉審核:項(xiàng)目組在最初的時(shí)候原本是想采取"成對(duì)編程"的實(shí)踐,但是沒(méi)有獲得物理和治理上的支持,因此,只能采取交叉審核的方式進(jìn)行。
需求獲取:由PM和一名對(duì)于原有系統(tǒng)較熟悉的開發(fā)人員進(jìn)行需求獲取和SRS (Software Requirement Specification) 的撰寫。技術(shù)經(jīng)理和其它開發(fā)人員進(jìn)行需求的審核。
分析與設(shè)計(jì):由一名開發(fā)人員進(jìn)行系統(tǒng)框架的設(shè)計(jì),其它人員進(jìn)行審核;在系統(tǒng)框架設(shè)計(jì)進(jìn)行過(guò)程中,由于系統(tǒng)去除訂單處理以外的其它部分比較獨(dú)立,因此,將其它模塊分配給開發(fā)人員,而將核心部分交與技術(shù)經(jīng)理進(jìn)行分析與設(shè)計(jì)。開發(fā)人員在每個(gè)迭代周期內(nèi),都會(huì)在分析與設(shè)計(jì)做完后,每2人一組進(jìn)行審核。
編碼:天天下班前,2人一組,對(duì)對(duì)方的代碼進(jìn)行Review,發(fā)現(xiàn)問(wèn)題及時(shí)解決。代碼Review的時(shí)候,語(yǔ)法與規(guī)則的檢查,通過(guò)Check Style的工具進(jìn)行;開發(fā)人員將審查的重點(diǎn)放在功能實(shí)現(xiàn)與性能優(yōu)化等方面。
測(cè)試:在需求文檔形成以后,2個(gè)測(cè)試人員分布編寫分配模塊的Test Case;而在具體測(cè)試的時(shí)候,兩人交叉測(cè)試對(duì)方的模塊和更新文檔。
在系統(tǒng)開發(fā)Verification的各個(gè)階段,都有Check List,具體的信息請(qǐng)查看參考文獻(xiàn)[3]。
測(cè)試先行:測(cè)試在軟件開發(fā)中的重要作用已經(jīng)得到了越來(lái)越多的重視,但是,由于習(xí)慣勢(shì)力的影響和對(duì)于"Test-Driven Development"的不熟悉,開發(fā)小組并沒(méi)有實(shí)施完全意義上的測(cè)試先行。
對(duì)于系統(tǒng)框架的核心類設(shè)計(jì)過(guò)程中,項(xiàng)目小組采取了TDD的方式進(jìn)行開發(fā)。在后續(xù)的系統(tǒng)開發(fā)中,每個(gè)開發(fā)人員在進(jìn)行開發(fā)前,首先要完成一個(gè)功能測(cè)試 ( Function Test ) 列表,將要完成的Use Case中的主要業(yè)務(wù)邏輯以及關(guān)聯(lián)邏輯都要羅列出來(lái),在提交測(cè)試人員進(jìn)行集成測(cè)試之前,開發(fā)人員需要保證完成Function List中的所有選項(xiàng)。
在每個(gè)開發(fā)人員的模塊完成并通過(guò)個(gè)人的功能測(cè)試后,測(cè)試人員進(jìn)行集成測(cè)試,同時(shí)編寫測(cè)試腳本,并通過(guò)自動(dòng)測(cè)試工具 (Rational Robot) 進(jìn)行記錄。天天下班之前,測(cè)試人員會(huì)啟動(dòng)測(cè)試工具,進(jìn)行回歸測(cè)試。在第二天向PM和技術(shù)經(jīng)理提交測(cè)試報(bào)告并將Bug提交至Bug Trace系統(tǒng)(Rational Clear Quest),由PM進(jìn)行Bug的分發(fā)。每個(gè)開發(fā)人員需要在下一個(gè)迭代周期完成前,修正前一個(gè)迭代內(nèi)分配的Bug。
持續(xù)集成:在測(cè)試先行的基礎(chǔ)上,開發(fā)一組平均天天都會(huì)進(jìn)行已經(jīng)完成模塊與以后系統(tǒng)的集成。集成由專門的人員,在開發(fā)人員將已經(jīng)通過(guò)功能測(cè)試的
源碼Check in到源碼控制系統(tǒng) (ClearCase) 中以后進(jìn)行,在部署應(yīng)用結(jié)束以后,通知測(cè)試人員進(jìn)行集成測(cè)試。
小步發(fā)布:項(xiàng)目有專門的測(cè)試與發(fā)布服務(wù)器,天天都有集成的系統(tǒng)在運(yùn)行和接受測(cè)試。由于沒(méi)有現(xiàn)場(chǎng)客戶,對(duì)于已經(jīng)發(fā)布的系統(tǒng),是由"客戶領(lǐng)域?qū)<?(這個(gè)項(xiàng)目是由Business Development人員來(lái)充當(dāng)這個(gè)角色)來(lái)進(jìn)行審查的。他對(duì)于系統(tǒng)的意見和發(fā)現(xiàn)的問(wèn)題,在經(jīng)過(guò)PM和技術(shù)經(jīng)理審核后,進(jìn)入ClearQuest,分配給開發(fā)人員進(jìn)行修改。
由于項(xiàng)目一開始就注重組織內(nèi)部以及與客戶的溝通和交流,同時(shí)采用了很多靈敏軟件開發(fā)過(guò)程的實(shí)踐,項(xiàng)目如期交付使用。
3.2 教訓(xùn)
項(xiàng)目在交付以后,最初的兩個(gè)訂貨季節(jié)沒(méi)有出現(xiàn)功能與性能上的問(wèn)題。但是,由于合同中有數(shù)據(jù)遷移的條款,在項(xiàng)目交付2月后,項(xiàng)目開發(fā)商將舊應(yīng)用系統(tǒng)中的數(shù)據(jù)導(dǎo)入新系統(tǒng)以后,在下一個(gè)大的訂貨季節(jié)中,持續(xù)的出現(xiàn)性能上的問(wèn)題。在代碼修改和硬件環(huán)境提高以后,系統(tǒng)性能目前獲得了一定的改善。
從項(xiàng)目驗(yàn)收日期的日益推遲中,我們可以看出,該項(xiàng)目還是有很多地方做的不夠,例如:
系統(tǒng)二次開發(fā)效應(yīng):"第二個(gè)系統(tǒng)效應(yīng)"是Brooks在《人月神話》中提出的一個(gè)普遍的問(wèn)題,一般而言,第二個(gè)系統(tǒng)會(huì)傾向于過(guò)分設(shè)計(jì)[4]。
對(duì)于這個(gè)項(xiàng)目而言,沒(méi)有犯這個(gè)錯(cuò)誤,卻發(fā)生了另外一種情況:舊系統(tǒng)中,對(duì)于訂單信息以及產(chǎn)品信息的展示,不管是多是少(系統(tǒng)頁(yè)面最多顯示上千條記錄),都是在一個(gè)頁(yè)面中顯示。這對(duì)于沒(méi)有明顯的層次結(jié)構(gòu),直接在Script中調(diào)用數(shù)據(jù)庫(kù)記錄的PHP來(lái)說(shuō),性能還是可以接受的。但是,新系統(tǒng)的設(shè)計(jì)中客戶提出考慮系統(tǒng)用戶習(xí)慣一致性的問(wèn)題,就照搬了舊系統(tǒng)的頁(yè)面設(shè)計(jì);同時(shí),在架構(gòu)設(shè)計(jì)上,對(duì)于這種頁(yè)面顯示大量數(shù)據(jù)的情況,也沒(méi)有給予充分的考慮,為后來(lái)的性能問(wèn)題,埋下了伏筆。
教訓(xùn)一:沒(méi)有考慮新平臺(tái)的影響,照搬舊系統(tǒng)的功能以及頁(yè)面設(shè)計(jì)。
非功能性需求:項(xiàng)目合同中主要描述的是系統(tǒng)功能性的需求,而沒(méi)有非功能性需求的規(guī)定;同時(shí),在需求獲取解決,也沒(méi)有明確的了解系統(tǒng)的性能指標(biāo)等非功能性需求。主要原因在于項(xiàng)目開發(fā)商之前沒(méi)有大規(guī)模業(yè)務(wù)系統(tǒng)開發(fā)的經(jīng)驗(yàn),對(duì)于非功能性需求沒(méi)有足夠的重視;同時(shí),在測(cè)試階段,也沒(méi)有對(duì)于系統(tǒng)負(fù)載和性能做過(guò)測(cè)試。
因此,在項(xiàng)目交付以后,由于舊系統(tǒng)數(shù)據(jù)遷移后,數(shù)據(jù)量有了很大的增長(zhǎng),同時(shí),在秋季的定購(gòu)高峰中,有大量的并發(fā)用戶訪問(wèn),出現(xiàn)了下列問(wèn)題:
數(shù)據(jù)庫(kù)死鎖;
大量數(shù)據(jù)計(jì)算與顯示頁(yè)面速度很慢,頁(yè)面要經(jīng)過(guò)5~10分鐘才能夠完全顯示;
上述兩種情況在少量負(fù)載的單元測(cè)試和集成測(cè)試中是不可能出現(xiàn)的。
教訓(xùn)二:對(duì)于企業(yè)應(yīng)用系統(tǒng),尤其是業(yè)務(wù)系統(tǒng),沒(méi)有切實(shí)注重負(fù)載、性能等非功能性需求。
效率與設(shè)計(jì):在J2EE中,已經(jīng)成功的運(yùn)用了很多設(shè)計(jì)模式的思想,為系統(tǒng)的開發(fā)提供了一個(gè)很好框架。但是,在項(xiàng)目的架構(gòu)設(shè)計(jì)中,除了考慮可維護(hù)性、可復(fù)用性等問(wèn)題以外,還要考慮代碼執(zhí)行效率的問(wèn)題[5]。
隨著計(jì)算機(jī)硬件技術(shù)的發(fā)展,"莫爾定律"被一再的驗(yàn)證,系統(tǒng)硬件的價(jià)格逐漸降低。對(duì)于很多使用J2EE架構(gòu)或者
java技術(shù)的項(xiàng)目來(lái)說(shuō),解決性能與效率問(wèn)題的解決方案就是增加硬件方面的投入。而實(shí)際上,軟件開發(fā)過(guò)程中優(yōu)劣算法之間的差距是靠硬件的投入平衡不了的。
該項(xiàng)目在系統(tǒng)維護(hù)期間,對(duì)代碼進(jìn)行走查,修改了很多對(duì)于性能有影響的語(yǔ)句;同時(shí),在框架設(shè)計(jì)中,尤其是數(shù)據(jù)庫(kù)操作方法,利用Cache原理,從一定程度上解決了性能的問(wèn)題。
教訓(xùn)三:系統(tǒng)框架設(shè)計(jì)只考慮面向?qū)ο蠛涂删S護(hù)性,沒(méi)有在完美的設(shè)計(jì)與高效率的代碼之間做出權(quán)衡。
數(shù)據(jù)庫(kù)設(shè)計(jì):JAVA是純粹的面向?qū)ο笳Z(yǔ)言,利用J2EE開發(fā)的項(xiàng)目,也強(qiáng)調(diào)首先進(jìn)行OOAD的分析,首先有對(duì)象,然后再有數(shù)據(jù)庫(kù)的設(shè)計(jì)。DBA在項(xiàng)目中的作用,已經(jīng)遠(yuǎn)遠(yuǎn)沒(méi)有傳統(tǒng)的結(jié)構(gòu)性編程中重要。而實(shí)際情況卻是遠(yuǎn)非如此:大部分的業(yè)務(wù)系統(tǒng),假如要對(duì)系統(tǒng)的性能做出優(yōu)化,對(duì)數(shù)據(jù)庫(kù)層或者SQL語(yǔ)句進(jìn)行優(yōu)化是要害的步驟之一。
對(duì)于這個(gè)PRM系統(tǒng),在數(shù)據(jù)庫(kù)的設(shè)計(jì)上并沒(méi)有經(jīng)過(guò)DBA的審查就開始進(jìn)行開發(fā);而在性能問(wèn)題出現(xiàn)以后,客戶增加了512M的內(nèi)存,也沒(méi)有請(qǐng)求DBA對(duì)Oracle的參數(shù)做相應(yīng)的調(diào)整,造成了很大的資源浪費(fèi)。
在項(xiàng)目維護(hù)過(guò)程中,依靠DBA的幫助,開發(fā)商對(duì)于數(shù)據(jù)庫(kù)系統(tǒng)參數(shù)、索引、
存儲(chǔ)過(guò)程和SQL語(yǔ)句都做了一定的調(diào)整,這對(duì)于系統(tǒng)性能的提高起了很大的作用。
教訓(xùn)四:在面向?qū)ο蟮能浖到y(tǒng)構(gòu)建中,忽視數(shù)據(jù)庫(kù)設(shè)計(jì)以及DBA的重要作用。
客戶參與:在傳統(tǒng)的軟件開發(fā)過(guò)程中,一般情況下,客戶在簽訂合同后,項(xiàng)目交付前是很少有機(jī)會(huì)看到系統(tǒng)的,這樣就造成了系統(tǒng)交付后,客戶抱怨很多的情況;而在以XP為代表的靈敏軟件開發(fā)方法中,強(qiáng)化了客戶在軟件開發(fā)中的重要作用,XP更是提出了"現(xiàn)場(chǎng)客戶"的實(shí)踐,將客戶作為項(xiàng)目小組的一員,客戶對(duì)于項(xiàng)目的發(fā)布計(jì)劃、內(nèi)容和優(yōu)先級(jí)等方面有絕對(duì)的控制權(quán)。
對(duì)于這個(gè)PRM項(xiàng)目,由于客戶的原因,不可能采取"現(xiàn)場(chǎng)客戶"的實(shí)踐,但是,開發(fā)商的BD對(duì)于該客戶十分熟悉,完全可以作為客戶代表參與到項(xiàng)目中來(lái),因此,開發(fā)商將客戶經(jīng)理作為項(xiàng)目組的一員。
實(shí)際情況是:開發(fā)過(guò)程中,客戶經(jīng)理由于業(yè)務(wù)拓展的原因,并沒(méi)有在項(xiàng)目上分配多少時(shí)間進(jìn)行審查;而客戶在交付前也沒(méi)有花費(fèi)很多的時(shí)間研究系統(tǒng),也沒(méi)有提交很多的反饋報(bào)告。在系統(tǒng)交付出現(xiàn)性能等問(wèn)題后,客戶經(jīng)理與開發(fā)人員一起對(duì)于系統(tǒng)需求進(jìn)行審查,提出了很多有參考性的意見。假如從一開始,就強(qiáng)化"現(xiàn)場(chǎng)客戶"的最佳實(shí)踐,就可以很早發(fā)現(xiàn)問(wèn)題。
教訓(xùn)五:客戶或者客戶經(jīng)理對(duì)于項(xiàng)目的參與力度不夠。
四、 結(jié)論
在基于J2EE的企業(yè)應(yīng)用項(xiàng)目開發(fā)中,要注重以下問(wèn)題:
權(quán)衡系統(tǒng)設(shè)計(jì)與性能指標(biāo),關(guān)注非功能性需求;
采取靈敏軟件開發(fā)過(guò)程,關(guān)注人(客戶和開發(fā)人員)在項(xiàng)目實(shí)施中的重要作用,假如可以的話,聯(lián)合實(shí)施XP的所有實(shí)踐;進(jìn)入討論組討論。