編碼階段,要成功,必須牢記一條:能做到少修改,不重做,力爭一次成功!!
在編碼階段,只要不是原則性的錯誤,盡量不要推倒前面所做的一切,重新做,畢竟以前做的時候也是考慮了方方面面的因素的,現(xiàn)在出現(xiàn)的問題只是在某方面考慮不周而已,一切都作廢,太浪費了。還有,要是數(shù)據(jù)庫字段已存在,除非萬不得已,千萬不要修改數(shù)據(jù)庫字段,能可添加字段。因為已經(jīng)存在的字段,很有可能已被軟件開發(fā)小組的其他成員在使用,不要因為你的修改而令其他人也要跟你做相應(yīng)的修改。后,軟件界面的修改要慎重,界面的修改很容易使你忽略修改相應(yīng)的內(nèi)容,造成軟件大問題沒有,小問題一大堆。
要想做到不修改,不重做,很不容易,要考慮的因素很多。
首先從軟件的角度來說吧:
對于專用軟件,很多時候,一般用戶對于軟件要完成哪些功能已經(jīng)有了一個比較清楚的輪廓,而且往往在開發(fā)合同中已經(jīng)大致地規(guī)定了。但是,開發(fā)合同上規(guī)定的只是一個大概的框架,用戶心目中的產(chǎn)品究竟是什么樣子,有時不要說開發(fā)人員不知道,連用戶本人也不知道。所以很多時候,都是到了開發(fā)工作的后期才發(fā)現(xiàn)開發(fā)人員的理解和用戶的要求有一些誤解,那么必然造成時間上的浪費。
對于通用軟件,很多時候是到了開發(fā)工作的后期才發(fā)現(xiàn)某方面的功能不足,或要添加新功能等等。
在小型軟件公司中,由于開發(fā)人員少,這樣意味著不同人員的程序之間交互、接口相對少一些。開發(fā)周期短意味著往往是同樣的幾個人從頭到尾負(fù)責(zé)一個項目。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭,討論一下基本的數(shù)據(jù)結(jié)構(gòu)、函數(shù)接口便分頭去做自己的工作了,沒有一份較正式的文檔。當(dāng)有的人會對討論出的接口、結(jié)構(gòu)理解有偏差(應(yīng)該承認(rèn)人是會犯錯誤的),一個誤解可能造成以后的返工。
其次從管理的角度來說吧:
1、 有效的團隊組織。
提高團隊組織的工作績效,提高組員的團隊精神。這非常有利團隊有效,有序的工作。有效的團隊建設(shè),這是管理的重要內(nèi)容。
2、 小組成員的溝通、協(xié)調(diào)。
溝通,也許在各行各業(yè)都已提到了一個相當(dāng)重要的位置。在一、二十年前,也許您會經(jīng)常聽到某位大俠單獨完成了某種創(chuàng)舉,成了人們崇拜的對象?桑@種大俠,已經(jīng)很難有生存空間了。取而代之的是,某軍團,又攻克了一座什么樣的寶壘。這樣,溝通,可以說已經(jīng)變得無比的重要。在軟件業(yè),溝通可以說是快速學(xué)習(xí)和掌握新知識,達到技術(shù)上的更高層次的佳途徑。 小組員的溝通,可以很好的加強團隊組織的凝聚力?赡芨玫淖岉椖苛夹缘倪M行。而培養(yǎng)這種氣氛,形成有效的溝通,這也是項目管理的基本內(nèi)容。協(xié)調(diào)幾個人的工作比自己完成一段編碼更重要。如果小組成員在協(xié)調(diào)上出了漏洞,可能導(dǎo)致很大的問題,所以項目負(fù)責(zé)人必須隨時監(jiān)控各開發(fā)人員的工作,包括內(nèi)容是否與要求發(fā)生偏差,進度是否滯后等等。
后從測試的角度來說吧。
傳統(tǒng)觀點認(rèn)為,測試是在編碼后的工作。其實,測試和編碼是兩個密不可分的階段,交叉進行的,測試在編碼后期進行的較多!主要有兩方面:
1、 不經(jīng)過單元測試而直接進入系統(tǒng)測試;
造成這一現(xiàn)象的原因是每個模塊相對比較簡單,但是為了測試一個模塊需要建立一些測試環(huán)境。例如,為了測試一個函數(shù)是否正確,應(yīng)該用一些測試數(shù)據(jù)去調(diào)用該函數(shù),需要編寫一些測試數(shù)據(jù)。但很多開發(fā)人員嫌麻煩,覺得反正其他模塊也很快出來了,直接用真正的數(shù)據(jù)來運行幾次行了。殊不知,一旦直接進入系統(tǒng)測試,發(fā)現(xiàn)運行結(jié)果不正確后需要一步步查找。不但耗費了大量的查找時間,而且后面的模塊已完成了,修改前面的模塊又會影響后面的模塊,使的修改的難度增加,修改后導(dǎo)致新的錯誤產(chǎn)生的概率增大,另外,每個人的潛意識都不想否定自己,這種情況下很難真正去修改。還有由于這種測試不完全,真正運行系統(tǒng),當(dāng)調(diào)用某模塊時,可能大部分時候都是正常數(shù)據(jù),極少出現(xiàn)邊界情況,可能某些邊界情況容易被忽視,很久之后才被發(fā)現(xiàn)。但是如果對每個模塊進行單元測試時都進行一下邊界測試,會很容易消除一些隱患。真可謂欲速則不達也!
2、 如果在項目人員配置中設(shè)置了專門的測試人員,編碼人員會認(rèn)為軟件所有的內(nèi)部測試工作全部應(yīng)該由測試人員完成。
眾所周知:軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“白盒法”對測試人員各方面素質(zhì)的種種要求,在進行程序測試時測試人員總是優(yōu)先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試;如果測試沒有通過,不得已這才考慮對程序代碼進行“白盒法”測試。顯然,這種對“白盒法”有意無意的“逃避”,對軟件的可靠性和穩(wěn)定性構(gòu)成了威脅,造成在編碼后期,甚至是在試運行或運行階段需要進行大量的修改。如何解決這個問題?一方面需要提高對測試人員的要求,另一方面也需要程序員完成部分的“白盒法”測試(實際上,程序員往往也是進行“白盒法”測試的佳人選)。
在代碼階段,除了要想做到不修改,不重做外,還需要對軟件的質(zhì)量進度等進行控制,必須做到以下幾點:
1、 定期召開項目工作會議,向項目開發(fā)人員及時了解項目進展情況及存在的主要問題。一旦發(fā)現(xiàn)問題,管 理人員應(yīng)迅速查明原因,盡快采取措施,爭取在盡可能小的范圍內(nèi)解決問題。
2、 在軟件開發(fā)過程中,請專家和用戶按照里程碑評審階段性的成果,判定開發(fā)進度 是否與軟件項目定義的里程碑保持一致,開始時間是否與計劃時間一致。
第四章 編碼后的管理
編碼完成后,是軟件實行試運行、運行階段,并生成相應(yīng)的版本,并進行相應(yīng)的備份。這個工作很重要,特別是版本生成備份,很容易出錯。筆者在曾經(jīng)犯過這樣的錯:給了老版本給用戶;把為甲做的版本給了用戶乙;備份時把以前有用的版本覆蓋了等等,不一而足。要避免犯這些錯誤,必須要在每次生成不同的版本或者備份時,都要建立相應(yīng)的文章。在文檔中,盡可能詳實地記錄本版本或備份的時間、目的,特別是和其他版本的不同之處。寫的越詳實,出錯的概率越小。