《修改代碼的藝術》讀書筆記一

1、修改軟件的原由及其本質。

       修改軟件是任何一個開發人員所面對的問題，軟件是否容易修改，被修改後的軟件是否變得更好，是每個開發人員都知道必須關注可是在實際開發過程當中卻每每忽視的問題。有多少人在接手一個新項目時抱怨新項目的遺留代碼質量過低？又有多少人願意或者說有能力去將一個讓人崩潰的代碼逐步改善？    

　　假如你面對着一份只能考慮修改，不能考慮重寫的，可是混亂不堪的代碼，須要將其逐步改善，可能須要細緻的研究《修改代碼的藝術》這本書，它的目的就在於：但願可以將一個已經很是龐大並且混亂不堪的項目從現狀中擺脫出來，讓爲這個程序作開發的人員對開發感到安心，而不是擔心。    

　　這裏從書中列出的軟件修改的四個主要原由開始：  

　　　　1.添加新特性。  

　　　　2.修正bug。  

　　　　3.改善設計。  

　　　　4.優化資源使用。    

　　添加新特性和修正bug的含義不難理解，可是有時候由於對需求的理解不一樣，表面上看上去是修正bug的行爲實際對於開發人員來講確實添加一個新特性。關於這一點，這裏把這樣一種行爲劃分到添加新特性的範圍中，而不認爲是修正bug。    

　　改善設計指的是改變程序的結構，令軟件更加容易維護，一般也意味着，咱們但願改善設計的過程當中不該該改變程序的行爲。這種不改變程序行爲而改善設計的舉動稱爲重構。（書中指出重構背後的理念：若是咱們編寫測試確保現有行爲不變，並在重構的每一步中當心驗證其行爲的不變性，咱們就能夠在不改變程序行爲的前提下經過重構使其更具維護性）    

　　優化和重構相似，可是目的卻不一樣，重構的目標是程序的結構更容易維護，而優化的目標倒是針對程序所使用的資源，好比CPU時間和內存佔用等。    

　　通常而言，當對一個系統作修改以後，有三個方面可能會發生改變：結構、功能以及資源佔用。爲了把上述的bug修改和添加新特性區分出來，咱們把功能也分爲對舊有功能的修改和新功能。因而綜合起來，咱們能夠獲得一個表格：

	添加特性	修正bug	重構	優化
結構	改變	改變	改變	——
新功能	改變	——	——	——
功能	——	改變	——	——
資源使用	——	——	——	改變

　　固然，準確來講，前三種舉動也可能會致使資源使用的改變，可是因這三種狀況下資源使用的變化每每只是反作用，因此表中仍是列爲不變。    

　　在這全部的狀況裏面，有一點是很是重要的：咱們對程序的改動相比咱們但願保持的程序行爲相比，咱們但願保持的程序行爲要多得多。因此在對程序修改中，如何保證不致使不想改變的東西被改變，是重中之重。

2、修改中存在的問題

　　對大部分的開發人員來講，通常並不肯意對軟件進行修改。有了新的需求，須要添加新特性；有了bug，須要作修正；這樣的修改不得不作。可是改善設計提升維護性，大部分人是不肯意的作的。    

　　爲何會這樣？固然不是由於開發人員懶，那麼多的代碼都寫了，沒道理不肯意爲了之後維護方便，多寫一些。關鍵在於，咱們都擔憂只是爲了改善結構的修改行爲，對系統形成了嚴重的破壞。    

　　「避免修改」算是咱們對於已經跑在線上的程序的一種下降軟件問題的策略。「既然跑的好好的，那仍是別改了」。若是一個程序永遠不用改動，那或許這種策略有必定的可行性。可是，除非對於一個已死的項目，改動老是不可避免的。當團隊每次都以看上去最簡單的方式將新代碼添加到系統中，原有的方法、原有的類就會愈來愈龐大，修改的難度也會愈來愈大，最終形成質量不斷下滑。