項目質(zhì)量控制：編碼階段

　　編碼主要還是受了設計的限制，我們的主要工作就只是在原有的結構上添加一些類(lèi)與方法，以及對原有的代碼進(jìn)行修改。前面也提到了，我們采用了比較保守的作法，沒(méi)有對代碼進(jìn)行重構，放任這種高耦合的代碼存在，導致我們在編碼過(guò)程中花費了不少精力和時(shí)間去理解它們，并在其中加上一兩條更加加深耦合度的代碼。其實(shí)到了編碼階段，很多問(wèn)題都糾纏到了一起，已經(jīng)分不清因果了。比較說(shuō)單元測試，首先我需要承認的一點(diǎn)就是沒(méi)有足夠的決心去做充分的單元測試，思想上也沒(méi)有做好充分的準備。除去主觀(guān)的因素之外，還有一點(diǎn)就是設計的結構不合理，很多的邏輯被處理在表示層中，數據處理則被加到了邏輯層中。沒(méi)有劃分出更多的接口供單元測試來(lái)驗證。但反過(guò)來(lái)說(shuō)，沒(méi)有單元測試用例的支持，也降低了我們想要進(jìn)行重構的決心。除了上述的問(wèn)題之外，還有一些細節的地方，如硬編碼，命名規則等都在一定程度上對代碼的質(zhì)量產(chǎn)生了影響。

　　改進(jìn)的辦法，一是從主觀(guān)上接受變化的現實(shí)，主動(dòng)的對代碼進(jìn)行改動(dòng)。單元測試一定要進(jìn)行，最好結合統計覆蓋率的工具一并進(jìn)行，這樣對于每個(gè)接口，都保證有充分多的測試用例來(lái)跑完盡可能多的路徑。在項目的質(zhì)量管理上面，要求還需要更加嚴格一些，一定要按照規范來(lái)進(jìn)行編碼。