題我在后面也會提到。
需求分析階段出現(xiàn)的問題，解決的可操作性不是很大，更多的是從思想或經(jīng)驗上解決，而后面幾個階段出現(xiàn)的問題都相對具體一些。
2、設(shè)計階段
設(shè)計階段的問題相對比較明顯――結(jié)構(gòu)設(shè)計不合理，或者說還不夠。一個傳統(tǒng)的C/S結(jié)構(gòu)的系統(tǒng)，基本結(jié)構(gòu)我們采用了經(jīng)典的三層模型來劃分系統(tǒng)。由于是在舊有系統(tǒng)上的改進(jìn)，我們在盡量不改變原有系統(tǒng)的基礎(chǔ)上添加新的功能。
主要的問題可能就是體現(xiàn)在沒有對舊系統(tǒng)進(jìn)行改進(jìn)。舊系統(tǒng)本身有一些復(fù)雜的功能，邏輯關(guān)系也比較復(fù)雜，耦合度非常高。
所以，在新需求來臨的時候，我們的第一反應(yīng)就是盡量不去動原來的設(shè)計與代碼，保證原有系統(tǒng)功能不會發(fā)生變化。這一點就暴露出了我們沒有去擁抱變化的決心與膽量。雖然舊系統(tǒng)很復(fù)雜，但是我們不能去故意回避它。對于舊系統(tǒng)中設(shè)計的不合理的地方，應(yīng)該主動大膽的去進(jìn)行重構(gòu)。
其實重構(gòu)的作用就是對不合理結(jié)構(gòu)的進(jìn)行改進(jìn)，設(shè)計模式更是在設(shè)計結(jié)構(gòu)的變化改進(jìn)中才能體現(xiàn)它的價值。而這些東西，在我們的項目中都沒有應(yīng)用.這可能跟我們的保守心理有關(guān)：只要不出問題，我們就不去動它，哪怕結(jié)構(gòu)是多么的錯綜復(fù)雜。這種消極的觀念在當(dāng)今的充滿變化的世界中是不太有前途的。項目經(jīng)理要有足夠的決心去做，同時，也不要擔(dān)心去變化。
當(dāng)然，可能有人會說，時間緊怎么辦，其實這種付出對于項目的整體是只有好處沒有壞處的，因為結(jié)構(gòu)合理會讓開發(fā)人員會更少的時間去理解代碼，減少代碼開發(fā)的復(fù)雜度，提高代碼編寫的質(zhì)量。唯一需要考慮的就是如果改動的話，如何來保證這種變化對原有系統(tǒng)的功能不產(chǎn)生影響。這就需要有更多的測試，最好是單元測試來保證，這就是下面會談到的問題。
3、編碼階段
編碼主要還是受了設(shè)計的限制，我們的主要工作就只是在原有的結(jié)構(gòu)上添加一些類與方法，以及對原有的代碼進(jìn)行修改。前面也提到了，我們采用了比較保守的作法，沒有對代碼進(jìn)行重構(gòu)，放任這種高耦合的代碼存在，導(dǎo)致我們在編碼過程中花費了不少精力和時間去理解它們，并在其中加上一兩條更加加深耦合度的代碼。
其實到了編碼階段，很多問題都糾纏到了一起，已經(jīng)分不清因果了。比較說單元測試，首先我需要承認(rèn)的一點就是沒有足夠的決心去做充分的單元測試，思想上也沒有做好充分的準(zhǔn)備。除去主觀的因素之外，還有一點就是設(shè)計的結(jié)構(gòu)不合理，很多的邏輯被處理在表示層中，數(shù)據(jù)處理則被加到了邏輯層中。
沒有劃分出更多的接口供單元測試來驗證。但反過來說，沒有單元測試用例的支持，也降低了我們想要進(jìn)行重構(gòu)的決心。除了上述的問題之外，還有一些細(xì)節(jié)的地方，如硬編碼，命名規(guī)則等都在一定程度上對代碼的質(zhì)量產(chǎn)生了影響。
改進(jìn)的辦法，一是從主觀上接受變化的現(xiàn)實，主動的對代碼進(jìn)行改動。單元測試一定要進(jìn)行，最好結(jié)合統(tǒng)計覆蓋率的工具一并進(jìn)行，這樣對于每個接口，都保證有充分多的測試用例來跑完盡可能多的路徑。在項目的質(zhì)量管理上面，要求還需要更加嚴(yán)格一些，一定要按照規(guī)范來進(jìn)行編碼。
4、測試階段
代碼完成之后，測試的工作也隨之展開。但是由于成本的原因，我們并沒有再加入專業(yè)的測試人員來進(jìn)行，而只是用開發(fā)人員自己來進(jìn)行系統(tǒng)測試，讓開發(fā)人員互相測試別人實現(xiàn)的功能。由于開發(fā)人員與測試人員所需的專注點不同，造成了開發(fā)人員很多問題在測試中沒有被發(fā)現(xiàn)，缺乏測試的經(jīng)驗。
從另一個方面說，是開發(fā)人員不能夠及時的轉(zhuǎn)換自己的角色，而是還把自己定位在開發(fā)人員上面，更加關(guān)注的問題出在什么地方并立刻去解決它,而不是設(shè)法去發(fā)現(xiàn)隱藏的Bug。當(dāng)然，還有一些細(xì)節(jié)的地方，比如說測試都應(yīng)該是開發(fā)人員發(fā)布一個安裝包，然后單獨進(jìn)行測試，但有的時候為了圖省事，有的功能在調(diào)試狀態(tài)下發(fā)現(xiàn)通過了，在安裝包中就沒有再驗證，有時也會出現(xiàn)意想不到的情況發(fā)生。
這些問題都是在項目管理中暴露出來的，可以說是由于項目經(jīng)理對于質(zhì)量的要求還不高，有的時候為了片面追求成本與時間而忽視了質(zhì)量，從而造成了質(zhì)量的下降。
軟件的質(zhì)量可能就是被這一步步的失誤，錯誤，粗心等等影響了。算是個總結(jié)和教訓(xùn)吧，也希望大家能夠說出你的想法與意見，多多交流，共同進(jìn)步。