代碼藝術 之 修改軟體

思維導圖 點擊圖片查看大圖 

  

介紹 我們平時在開發中遇到最多的不是開發新項目，而是對現有的項目進行修改和添加新特性。所以這次著重談談軟體修改。 目錄索引 #　　添加新特性，修正bug;#　　改善設計;#　　最佳化資源使用;#　　考慮危險性 添加新特性，修正bug 我們在平時維護現有系統的時候，我們不難發現 產品比較喜歡添加行為，而不是改變或移除原本他們所依賴的行為。 對於我們平時如何區分是修正bug還是添加新特性呢？這個是角度問題，是產品與技術人員的較量問題。比如：產品想把logo，從左邊移到右邊，而且還要在右邊移動。　　　那麼從產品的角度是修複bug，而從我們的角度是添加新特性。　　   產品從不管我們為此不得不從頭開始做一些新的工作的事實。——主觀看法的差異而已。

我們在平時一定要做到bug修正和添加新特性必須分開記錄和解決，這便於我們日後的維護。——一般我們公司是使用jira做這些記錄。

 

 

改善設計  改善設計的目的是改變既有軟體的結構和組織，以令其更易於維護。 改善設計我們不得不提重構，重構是不改變軟體行為的前提下改善其設計的舉動。我們要保證結構的改變不會影響既有的行為，這我們通常需要編寫測試代碼。——每一小步都小心驗證其行為不會改變。

  最佳化 最佳化與重構的區別是目的不同。對於重構來說，是為了易於維護而做的程式結構的調整。而對於最佳化來說，是為了提高效能（如時間或記憶體）。 

有兩個詞大家需要斟酌一下，“清理”和“整理”。清理有清除整理的意思，而“整理”沒有清除的意思。我們在重構或最佳化的時候，注意這兩個詞的區別。——為了與其他人溝通更加準確些。

 

 危險的修改 在我們需要作出修改並保持行為時，往往伴隨著相當大的風險。  思考方式：　　在我們修改代碼的時候，你腦子裡是否想到以下問題。——這也是希望大家在修改代碼的時候，自問一下。　　　　1、我要進行哪些修改？　　　　2、如何判斷已經正確的完成了修改？　　　　3、如何得知沒有破壞任何既有的行為？  傳統方法 我們經常使用的方式：當需求下來了，我們的第一反應是在現有的類或方法上添加和修改，而不是重建立個類或方法。這樣使用是因為費力少，更安全。而產生的後果是既有的類和方法越來越大，越來越難理解。而且我們不得不承認，我們對代碼會越來越生疏，以後再修改這個地方，從內心就會產生恐懼感，總懼怕這個地方再進行修改從而導致系統結構日益糟糕。  比較先進方法 1、努力的去做修改，做好文檔（主要是流程圖）、注釋。——我個人非常喜歡某個方法重寫，我的做法是看是不是能抽出類或者方法來，然後重寫方法。這樣做的目的（1）我更加瞭解系統。（2）能增強My Code編寫能力。2、僱傭更多員工，這樣我們就有更多的時間進行系統分析和仔細審查所有代碼。 

 總結 以上是對軟體修改整個過程的理解，若有誤，歡迎大家拍磚。 
參考文獻《修改代碼的藝術》  推薦