思維導圖
點擊圖片查看大圖
介紹
我們平時在開發中遇到最多的不是開發新項目，而是對現有的項目進行修改和添加新特性。所以這次着重談談軟件修改。
目錄索引
# 添加新特性，修正bug;
#
改善設計;
#
優化資源使用;
#
考慮危險性
我們在平時維護現有系統的時候，我們不難發現
產品比較喜歡添加行為，而不是改變或移除原本他們所依賴的行為。
對於我們平時如何區分是修正bug還是添加新特性呢？這個是角度問題，是產品與技術人員的較量問題。
比如：產品想把logo，從左邊移到右邊，而且還要在右邊移動。
那么從產品的角度是修復bug，而從我們的角度是添加新特性。
產品從不管我們為此不得不從頭開始做一些新的工作的事實。——主觀看法的差異而已。
我們在平時一定要做到bug修正和添加新特性必須分開記錄和解決，這便於我們日后的維護。——一般我們公司是使用jira做這些記錄。
改善設計的目的是改變既有軟件的結構和組織，以令其更易於維護。
改善設計我們不得不提重構，重構是不改變軟件行為的前提下改善其設計的舉動。我們要保證結構的改變不會影響既有的行為，這我們通常需要編寫測試代碼。——每一小步都小心驗證其行為不會改變。
優化與重構的區別是目的不同。對於重構來說，是為了易於維護而做的程序結構的調整。而對於優化來說，是為了提高性能（如時間或內存）。
有兩個詞大家需要斟酌一下，“清理”和“整理”。清理有清除整理的意思，而“整理”沒有清除的意思。我們在重構或優化的時候，注意這兩個詞的區別。——為了與其他人溝通更加准確些。
在我們需要作出修改並保持行為時，往往伴隨着相當大的風險。
思考方式：
在我們修改代碼的時候，你腦子里是否想到以下問題。——這也是希望大家在修改代碼的時候，自問一下。
1、我要進行哪些修改？
2、如何判斷已經正確的完成了修改？
3、如何得知沒有破壞任何既有的行為？
傳統方法
我們經常使用的方式：當需求下來了，我們的第一反應是在現有的類或方法上添加和修改，而不是重新建個類或方法。
這樣使用是因為費力少，更安全。
而產生的后果是既有的類和方法越來越大，越來越難理解。而且我們不得不承認，我們對代碼會越來越生疏，以后再修改這個地方，從內心就會產生恐懼感，總懼怕這個地方再進行修改從而導致系統結構日益糟糕。
比較先進方法
1、努力的去做修改，做好文檔（主要是流程圖）、注釋。——我個人非常喜歡某個方法重寫，我的做法是看是不是能抽出類或者方法來，然后重寫方法。這樣做的目的（1）我更加了解系統。（2）能增強我的代碼編寫能力。
2、雇佣更多員工，這樣我們就有更多的時間進行系統分析和仔細審查所有代碼。
總結
以上是對軟件修改整個過程的理解，若有誤，歡迎大家拍磚。
參考文獻《修改代碼的藝術》
推薦
