如何使用Golang進行無心智負擔的編程？
關于設計模式
java的23種設計模式? 再見.
不是說他們沒有作用，只是說它們太死板復雜，學習它們通常入不敷出。
對于編程還有很多需要注意的地方（下文），而不要只局限于設計模式。
我給出的建議是只需要理解一個大概，在平時編程中能用則用。
關于面向對象
如何使用Golang進行無心智負擔的編程
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()
簡單的說: 組合能用則用，如果你不知道如何使用或者不用也并無大礙。
關于可維護性
如何使用Golang進行無心智負擔的編程
"開閉原則"對我啟發很大.
原文是這樣:
伯特蘭·邁耶一般被認為是最早提出開閉原則這一術語的人，在他1988年發行的《面向對象軟件構造》中給出。這一想法認為一旦完成，一個類的實現只應該因錯誤而修改，新的或者改變的特性應該通過新建不同的類實現。新建的類可以通過繼承的方式來重用原類的代碼。衍生的子類可以或不可以擁有和原類相同的接口。
但其實我們在開發的時候并不是一直都在和對象打交道.
在我看來, "開閉原則"適用于平時寫的任何代碼.
完整理解"開閉原則"可能還是會造成心智負擔, 所以先打住, 只需要這樣:
一個函數只做一個功能(事情), 一旦這個功能開發完成, 這個函數應當"閉合", 不應該再修改(bug除外).
當需要修改功能, 應當盡量將修改也寫成一個函數，盡早的進入分支判斷去調用新修改，而原代碼不變。
這便是 "對修改閉合, 對擴展開放".
這里不得不在提及"面向函數編程", 它的思想包括但不限于:
一個函數只做一個功能
函數無副作用
它正好利于修改, 利于寫出符合"開閉原則"的代碼.
關于錯誤處理
默認的errors包在對于多層的復雜應用是不夠的，這種情況下建議自行封裝，但別太追求完美 在項目中夠用就好。我們等待官方方案即可: https://github.com/golang/go/issues/29934
關于命名
restful能解決大部分命名問題.
你的代碼完全可以這樣無腦命名而不失優雅.
如何使用Golang進行無心智負擔的編程
這樣的白話文真的很好命名與理解(根本不需要詞匯量).
并發
無腦Goroution, 80%的情況下都沒問題.
如果你實在擔心, 用channel的做下并發數量控制就好, 或者使用更完整的工具叫"協程池", 他們的實現都不復雜.
第三方庫
得益于golang的開源和這幾年的蓬勃發展，golang的生態已經十分完善，所以很多情況下我們應該"面相github編程"，第三方提供的代碼已能滿足我們大多數需求。同時 選用一個受歡迎的第三方代碼庫通常比自己的更可靠，后續維護也省心很多。
關于編碼風格
最省心的行為是: 先跟隨團隊再提出意見
那么省下來的時間和精力用來干嘛？
重構（自己的）老代碼。
研究更高級的與語言弱相關的架構，如Devops/分布式/微服務。
實現更多的產品或功能
