主要的問題可能就是體現在沒有對舊系統進行改進。舊系統本身有一些復雜的功能,邏輯關系也比較復雜,耦合度非常高。所以,在新需求來臨的時候,我們的第一反應就是盡量不去動原來的設計與代碼,保證原有系統功能不會發生變化。這一點就暴露出了我們沒有去擁抱變化的決心與膽量。雖然舊系統很復雜,但是我們不能去故意回避它。對于舊系統中設計的不合理的地方,應該主動大膽的去進行重構。其實重構的作用就是對不合理結構的進行改進,設計模式更是在設計結構的變化改進中才能體現它的價值。而這些東西,在我們的項目中都沒有應用.這可能跟我們的保守心理有關:只要不出問題,我們就不去動它,哪怕結構是多么的錯綜復雜。這種消極的觀念在當今的充滿變化的世界中是不太有前途的。項目經理要有足夠的決心去做,同時,也不要擔心去變化。當然,可能有人會說,時間緊怎么辦,其實這種付出對于項目的整體是只有好處沒有壞處的,因為結構合理會讓開發人員會更少的時間去理解代碼,減少代碼開發的復雜度,提高代碼編寫的質量。唯一需要考慮的就是如果改動的話,如何來保證這種變化對原有系統的功能不產生影響。這就需要有更多的測試,最好是單元測試來保證,這就是下面會談到的問題。
3、編碼階段
編碼主要還是受了設計的限制,我們的主要工作就只是在原有的結構上添加一些類與方法,以及對原有的代碼進行修改。前面也提到了,我們采用了比較保守的作法,沒有對代碼進行重構,放任這種高耦合的代碼存在,導致我們在編碼過程中花費了不少精力和時間去理解它們,并在其中加上一兩條更加加深耦合度的代碼。其實到了編碼階段,很多問題都糾纏到了一起,已經分不清因果了。比較說單元測試,首先我需要承認的一點就是沒有足夠的決心去做充分的單元測試,思想上也沒有做好充分的準備。除去主觀的因素之外,還有一點就是設計的結構不合理,很多的邏輯被處理在表示層中,數據處理則被加到了邏輯層中。沒有劃分出更多的接口供單元測試來驗證。但反過來說,沒有單元測試用例的支持,也降低了我們想要進行重構的決心。除了上述的問題之外,還有一些細節的地方,如硬編碼,命名規則等都在一定程度上對代碼的質量產生了影響。
改進的辦法,一是從主觀上接受變化的現實,主動的對代碼進行改動。單元測試一定要進行,最好結合統計覆蓋率的工具一并進行,這樣對于每個接口,都保證有充分多的測試用例來跑完盡可能多的路徑。在項目的質量管理上面,要求還需要更加嚴格一些,一定要按照規范來進行編碼。
4、測試階段
文章來源于領測軟件測試網 http://www.kjueaiud.com/