機(jī)房收費(fèi)系統(tǒng)完成了已經(jīng)有很長一段時間了，本以為就此結(jié)束了。可是，前幾天突然要求對其進(jìn)行驗收了。
開始的時候，感覺驗收就驗收沒什么。可是，有小道消息稱，做的不好的有可能重構(gòu)。如果是因為當(dāng)初的設(shè)計思路或者是邏輯錯誤而重構(gòu)，那無話可說，必須要重構(gòu)。但是如果是因為一些注釋、UML圖、命名規(guī)范等而重構(gòu)，都會讓大家笑話。
于是，在前面人驗收的時候，后面的人都在討論驗收人員的側(cè)重點(diǎn)。然后大家在修改自己的收費(fèi)系統(tǒng)。
通過這次驗收，雖然我沒有被要求重構(gòu)，但是，在驗收過程中還是出現(xiàn)了很多的問題，驗收人員也給提出了很多的寶貴意見。
首先就是出現(xiàn)的問題。
命名不規(guī)范。尤其是參數(shù)的命名，當(dāng)初以為參數(shù)只是使用在某一個方法或者函數(shù)中，不會和其他的類、函數(shù)產(chǎn)生關(guān)系，不用太在意它的命名。可是，這種代碼只適合與自己看，其他人看你的代碼就會感覺不舒服，同時給人一種外行的感覺。
注釋不全。雖說對于類、方法和函數(shù)都做了注釋，但是，不是很完整。例如，所有的remarks都是空著的。通過驗收人員的講解，理解了它的作用，記錄版本號，編寫時間以及修改時間。還有就是，對于注釋的代碼，不要刪除，而應(yīng)該保留并完整寫明修改人，以及修改的時間。雖說是個人版的，但對于注釋，都是被刪除了。
文檔不全。當(dāng)時做收費(fèi)系統(tǒng)的時候，只寫了需求、概要、數(shù)據(jù)庫設(shè)計以及詳細(xì)設(shè)計文檔。其他的則沒有寫。當(dāng)初就是由于惰性的原因吧，感覺寫文檔太枯燥了，就急于編寫代碼了，當(dāng)系統(tǒng)實現(xiàn)之后，就以為系統(tǒng)實現(xiàn)了就行了，至于其他文檔就算了吧。
對UML圖理解不深。當(dāng)初在畫UML圖的時候，對用例圖理解的不是太深，以至于我的用例圖中的用例都是窗體。在驗收過程中，自己都不禁問自己，當(dāng)初是怎么想的呢？怎么會出現(xiàn)那種用例圖呢？
再說一些個別人出現(xiàn)的問題吧（也算是給自己提個醒）
文檔、數(shù)據(jù)庫沒了。在做完機(jī)房收費(fèi)系統(tǒng)到現(xiàn)在有很長的時間了，有的同學(xué)重裝了系統(tǒng)。有的沒有提前把數(shù)據(jù)庫中的數(shù)據(jù)備份，導(dǎo)致現(xiàn)在沒有了原先的數(shù)據(jù)。而文檔，有的是在第一遍的基礎(chǔ)上修改的，原先的也沒有備份。導(dǎo)致現(xiàn)在的文檔是合作版的時候，自己第三次修改的文檔，前兩次的文檔都沒了。
UML圖不知道哪一個是最新版本。有的同學(xué)UML圖畫了好幾遍，但是在文件保存的時候，沒有注意到命名，沒有表明版本號。以至于尋找的時候花費(fèi)了很長時間，有的甚至就找不到了。
應(yīng)該說，通過這次驗收，讓我們認(rèn)識到了當(dāng)初所做的系統(tǒng)存在著很大的不足。這次要求我們都要補(bǔ)全文檔、注釋，規(guī)范命名等等，讓我們長了一個記性。對我們來說沒有壞處。同時通過這次驗收，也讓我們認(rèn)識到，文件備份、管理、保存的重要性。在以后大家都會記住這次的驗收來提醒自己。