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