在我之前"優雅代碼"的文章中我提到了函數大小規定的問題，

寫出優雅簡明代碼的論題集 -- Csharp(C#)篇[1]

寫出優雅簡明代碼的論題集 -- Csharp(C#)篇[2]

在這篇文章中我還想更詳細的談談為什么好的代碼必然不會有大的函數，-- 寫小的函數不是我們的目的，但是為了使你的代碼可讀性強，你開始花時間重構它們，然后，你發現函數開始縮小，類開始縮小。最后你會發現這才是你想要的代碼--就像是一本更貼切用戶需求的文檔。

一個函數只做一件事

一個函數應該只做一件事，這樣不但你能夠更好的命名你的函數，理解和閱讀代碼也變得更加的容易。如果你遇到一個特殊的情況不得不打破這個原則，可以停下來，思考一下是不是你對這個“特殊情況”的理解還不夠。函數應該很精確的執行一件事并且只執行這一件事。

鮑勃大叔在他的《Clean Code》里面提到這一點，還有一些其他關于代碼甚至是架構方面的書也提到過。

在讀到這個觀點之前，我發現自己做重構的時候會不知不覺的朝這個方向走；知道這個觀點之后，開始把它當作一種習慣 -- 當然，我承認自己寫得很多代碼都沒有滿足這個要求，因為知道離行道還是有一段距離。

但是如果你想讓自己或別人在維護代碼的時候輕松一點，你就應該嘗試著盡量做好，然后想辦法說服你的同事做好。

類的單一職責原則（Single Responsibility Principle）

類也會變得越來越小 -- 這也不是你的目的，但是當你遵守面向對象類設計的原則的時候，類就開始變小。我們希望實現類的高內聚、低耦合。當你要修改類時，你應該只有一個理由，也就是說類應該只有一個責任。

單一職責原則是一個非常重要的概念。可能很多人像我一樣一開始會懼怕一大推的小類--覺得會讓項目變得更加的難以理解--對于這樣的情況，我想說你先嘗試一下，看看結果如何？尤其當我們擁有強大的Visual Studio來管理類視圖的時候，這樣的嘗試應該不是一種冒險。

一個前提：要有單元測試

寫出“整潔”代碼的一個前提是要有單元測試？你可能會覺得我跑題了。但是我發現如果沒有建立起單元測試，我們就沒有勇氣不斷的修改我們的代碼，甚至沒有辦法睡好覺。好的，我可以改一下小標題：睡好覺的前提：要有單元測試。

“變小”的代價

通常人進入改變模式的步驟是：聽到一個新的概念->懷疑->執行->后悔->再堅持->接受或者回到原始狀態。那么函數和類變小的代價是什么呢？我自己的經歷和體會是：

對于已有代碼沒有時間進行重構--非常可以理解，那么當需求發生變化的時候，當我要改變這些已有代碼的時候，我就開始朝這個方向重構它們--讓它們比我“來”之前更“干凈”。

對于新的代碼，在編寫的過程中不斷的重構--你沒有辦法一開始就讓你的代碼完美。當你寫了幾個小時后，你發現自己代碼并不漂亮，沒有關系，不要懷疑自己的能力，花時間進行重構，因為整潔的代碼都是在重構中完成的。

未完待繼...

轉貼請注明: