關於代碼設計的幾點思考

關注公衆號：xy的技術圈

這篇文章主要總結一下本身在平時編碼中遇到一些問題的思考。不少時候，代碼設計很難十全十美，咱們面對的每每是選擇題，如何在多個選擇之間權衡取捨，並非一件簡單的事情。

性能與可讀性

「性能」是一個優秀的程序員都會注意的點。在寫代碼的時候，咱們每每但願本身可以以最優的性能寫出知足需求的程序。可是有時候，一味的高性能可能會下降代碼的可讀性。

好比在數據庫字段設計的時候，有一個「年份」的字段，咱們都知道年份通常都是4位數，因而咱們使用了SMALLINT來做爲這個字段的類型。使用ORM映射到Java，就是short類型了。

熟悉Java語言的同窗應該知道，Java語言在設計數值的運算的時候，會隱式地把它轉換爲int類型，而int類型必需要顯式地強轉才能轉成short，因此形成了在代碼裏有很是多的(short)強轉，以下：

short year = repository.getYearById(id);
short nextYear = (short)(year + 1);
複製代碼

這樣的強轉其實並無多大的意義，下降的可讀性的同時，並無帶來多大的性能提高。

因此咱們在寫程序的時候，有時候須要在追求性能和代碼可讀性方面權衡，在可接受的性能下，儘可能讓代碼更加可讀。

通用性與過分設計

若是有多個地方用到相同的邏輯，咱們能夠考慮把它抽出去，封裝成一個私有方法甚至是一個類。咱們稱這段抽取後的代碼具備「通用性」，也稱爲「複用性」。

你們或多或少都瞭解過一些設計模式，事實上許多設計模式解決的問題正是代碼的「複用性」。代碼的複用性很重要，但有時候可能也會帶來複雜性的上升。尤爲是在抽取了一些額外的類以後，你的代碼就會多出不少xxBuilder, xxFactory, xxProxy之類的。更有甚者，直接是xxUtils, xxHelper等不明職責的類，裏面許多雜亂的方法。

公共的方法和類帶來的另外一個問題是，若是兩個業務同時用了這一段代碼，後來需求發生了更改，其中一個業務在這段代碼裏面的邏輯須要發生一些小的變化，那若是去改公共代碼，就會影響另外一個業務。

因此在「通用性」和「複雜性」之間怎麼權衡？答案就是「簡單設計」，不要「過分設計」。

在寫代碼的時候，儘可能讓代碼簡單，不爲了複用性去抽取不少的方法和類，只爲了可讀性去作必要的重構。只有到了必要的時候才抽取公共的方法或類，好比多個業務確實用到了同一段複雜邏輯，且大機率不會發生更改。

代碼是這樣，接口亦是這樣。不要由於考慮到「之後可能會用到」就去過分設計，到時候作到了那個功能再重構不遲。

至於具體怎樣去實施？我認爲沒有一個明確的準則，須要多寫代碼，多思考，多瞭解業務，才能敏銳地判斷是否須要抽取。

寫多少測試？

筆者平時項目上都是遵循的TDD流程，因此寫的測試還算比較多。在咱們項目上，儘可能是優先寫單元測試，而後集成測試只寫必要的happy-path，有些比較簡單的類甚至能夠不寫集成測試，好比controller層。先寫測試，再寫實現，測試驅動出實現代碼。

《重構》這本書裏面講到，寫測試不該該是一個固定的，死板的開發流程，咱們寫測試的時候，應該只寫必要的測試，只寫那些咱們沒有十足的信心的代碼的測試。

但這彷佛與TDD的「測試先行」的觀點有些相違背。若是咱們先寫測試，那怎麼能知道咱們的實現代碼長怎樣呢，又怎麼能知道咱們有沒有十足的信心呢？

其實在實際的項目開發中，測試想要100%覆蓋是十分困難的。尤爲是在「白名單」這種狀況下，咱們每每只能測出白名單內的參數是符合條件的，但不可能測完全部的白名單外的參數是不符合條件的。因此只能選一兩個去測試。

有時候想要先寫測試是十分困難的。好比咱們在實現的時候可能會依賴其它的類，因此咱們在測試的時候可能會去mock這個類，但在寫實現代碼的時候，發現這個類不合適，可能須要換成調用另外一個類。這個時候又回過頭來改測試，就顯得有些麻煩。因此有時候並不必定是徹底的測試先行，而是造成了一個環，測試-實現-重構。

總結

上面講到的是筆者對平常開發中遇到的一些問題的思考。其實有時候也得要根據實際狀況去考慮，在寫代碼的時候，須要考慮的東西不少，好比可讀性、可維護性、可擴展性、性能、測試等等。

編程是一項工程，如何把這件工程作好，就須要咱們掌握更多的知識。多研究一下別人是怎麼寫代碼的，它們有什麼優劣，看得多了，總結得多了，「經驗」天然就有了。

推薦書籍：

• 《重構》
• 《代碼整潔之道》
• 《Effective Java》
• 《設計模式》
• 《實現領域驅動設計》

認真寫文章，用心作分享。

我的網站：yasinshaw.com

公衆號：xy的技術圈