Go語言中文網，致力於每日分享編碼知識，歡迎關注我，會有意想不到的收獲！

不知讀者是否也會時刻想: 我該怎麼寫這段代碼才優雅, 後期改起來方便?

努力思考卻還是得不到最佳答案, 煩躁等負面情緒不約而來。這便是在編程過程中的心智負擔。

這篇文章將從多個方面來簡化思考, 希望它能給努力思考的你帶來一點小靈感.

題外話: Golang哲學就是”少便是多”, 志在減少開發者的心智負擔. 不過再好的語言也敵不過”人”, 請接受Golang的風格 否則寫出PHPGo, JavaGo真是作繭自縛。

關於設計模式

java的23種設計模式? 再見.

不是說他們沒有作用，只是說它們太死板複雜，學習它們通常入不敷出。

對於編程還有很多需要注意的地方（下文），而不要只局限於設計模式。

我給出的建議是只需要理解一個大概，在平時編程中能用則用。

關於面向對象

Golang相比Java來說, 對”面向對象”這件事的支持是”不完整”的.

但話又說回來現在的”面向對象編程”漸漸被扭曲為了”面向類編程”（COP），而COP是複雜並難以理解的，COP有好處但要發揮出來並不容易。所以Golang決定拋棄所有不必要的概念以改善這個問題。

現在不必再理解 封裝(這個簡單到不需要理解), 多態, 繼承.

在golang中只需要理解兩個更實在的東西: 接口, 組合.

接口

Java 之父 James Gosling 在某次會議上有過這樣一次問答：

I once attended a Java user group meeting where James Gosling (Java’s inventor) was the featured speaker.

During the memorable Q&A session, someone asked him: 「If you could do Java over again, what would you change?」

「I’d leave out classes,」 he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.

大意是：

問：如果你重新做 Java，有什麼是你想改變的？

答：我會把類（class）丟掉。真正的問題不在於類本身，而在於基於做到的繼承（the extends relationship）。基於接口的繼承（the implements relationship）是更好的選擇，你應該在任何可能的時候避免使用做到繼承。

—- 摘自 Golang OOP、繼承、組合、接口 https://studygolang.com/articles/20972

在Golang中只需要記得一個東西: Interface(接口).

參見io.Reader接口就知道這種設計有多厲害.

讀文件是它, 讀網路請求也是它, 更騷的是 對於linux(Every thing is a file)來說用它就能操作近乎整個系統了.

簡單的說: 當某個功能(如去北京)有多種(或者以後可能有多種)做到方式(如坐火車/飛機/騎車)的時候, 用接口.

組合

組合理解起來並不複雜, 不過是一個語法糖, 就算沒有組合功能也毫不影響Go程序的運行.

如下代碼, 沒有組合換一種寫法即可.

// 組合
type L struct {
 sync.Mutex
}
// 這樣使用
L.Lock()
// 沒有組合
type L struct{
 l sync.Locker
}
// 這樣使用
L.l.Lock()

簡單的說: 組合能用則用，如果你不知道如何使用或者不用也並無大礙。

關於可維護性

“開閉原則”對我啟發很大.

原文是這樣:

伯特蘭·邁耶一般被認為是最早提出開閉原則這一術語的人，在他1988年發行的《面向對象軟件構造》中給出。這一想法認為一旦完成，一個類的做到只應該因錯誤而修改，新的或者改變的特性應該通過新建不同的類做到。新建的類可以通過繼承的方式來重用原類的代碼。衍生的子類可以或不可以擁有和原類相同的接口。

但其實我們在開發的時候並不是一直都在和對象打交道.

在我看來, “開閉原則”適用於平時寫的任何代碼.

完整理解”開閉原則”可能還是會造成心智負擔, 所以先打住, 只需要這樣:

• 一個函數只做一個功能(事情), 一旦這個功能開發完成, 這個函數應當”閉合”, 不應該再修改(bug除外).
• 當需要修改功能, 應當盡量將修改也寫成一個函數，盡早的進入分支判斷去調用新修改，而原代碼不變。

這便是 “對修改閉合, 對擴展開放”.

這里不得不在提及”面向函數編程”, 它的思想包括但不限於:

• 一個函數只做一個功能
• 函數無副作用

它正好利於修改, 利於寫出符合”開閉原則”的代碼.

關於錯誤處理

默認的errors包在對於多層的複雜應用是不夠的，這種情況下建議自行封裝，但別太追求完美 在項目中夠用就好。我們等待官方方案即可: https://github.com/golang/go/issues/29934

關於命名

restful能解決大部分命名問題.

你的代碼完全可以這樣無腦命名而不失優雅.

這樣的白話文真的很好命名與理解(根本不需要詞匯量).

並發

無腦Goroution, 80%的情況下都沒問題.

如果你實在擔心, 用channel的做下並發數量控制就好, 或者使用更完整的工具叫”協程池”, 他們的做到都不複雜.

第三方庫

得益於golang的開源和這幾年的蓬勃發展，golang的生態已經十分完善，所以很多情況下我們應該”面相github編程”，第三方提供的代碼已能滿足我們大多數需求。同時 選用一個受歡迎的第三方代碼庫通常比自己的更可靠，後續維護也省心很多。

關於編碼風格

最省心的行為是: 先跟隨團隊再提出意見

那麼省下來的時間和精力用來幹嘛？

1. 重構（自己的）老代碼。
2. 研究更高級的與語言弱相關的架構，如Devops/分布式/微服務。
3. 做到更多的產品或功能。

本文作者 bysir：https://www.jianshu.com/u/b3f7227e6640

‘,

>如何使用Golang進行無心智負擔的編程