生活要斷捨離, 程式碼也要喔。
寫Go只要一支main.go就可以開始寫了, 想寫多長就寫多長, 要是埋頭苦幹不斷地寫下去, 一個專案要寫上幾萬行都是有可能的。
沒有斷捨離的程式碼就像一團亂的房間找不到一處落腳點, 不僅別人難以閱讀, 自己寫完之後要debug可能也要找半天, 更甚至, 或許寫完兩個月後自己也不認得當初的樣子了。
要想debug時還能保持優雅, 還是先試著幫它們分門別類吧!
從Hello World
一腳踏入程式語言之後, 如何將程式碼整理分類, 把邏輯歸納清楚, 通常都要參考幾個專案之後, 才會慢慢長出自己樣子, 而且這個樣子會隨著接觸的專案多了, 時間久了, 還會慢慢的改變喔。
按照這個模擬專案的規模跟需求, 我會先這樣分:
程式/資料夾 | 說明 |
---|---|
cmd.go | init連線 |
config.go | env config參數 |
env.example | env 範本 |
error.go | 錯誤處理 |
model/ | mysql/scylla 操作接口 |
pb/ | proto |
redis/ | redis 操作接口 |
main.go | 定義啟動行為 |
rpc.go | gRPC實作 |
這次的資料夾結構大概會是長這樣:
├── cmd.go
├── config.go
├── env.example
├── error.go
├── main.go
├── model
│ └── limit_setting.go
├── pb
│ ├── coconut.pb.go
│ └── coconut.proto
├── redis
│ └── limit.go
└── rpc.go
我習慣把搭配的工具收攏放在個別的資料夾裡, 像是 model/
負責mysql 或scylla操作、 redis/
就負責redis。這樣放的優點是如果model從scylla更換成mysql, 或是 redis從redigo改用go-redis, 我只要專注在調整資料夾底下的程式就好。pb/
放gRPC spec, error.go 集中存放error code可以方便找到錯誤代碼; rpc.go 放所有gRPC API接口...等等。
如果需求比較複雜的, 還可以分一個負責外接服務的資料夾, 或是共用func也可以整理到lib,專案的檔案結構會隨著專案而變化。每個專案的資料夾結構會依照使用到的工具跟設計的功能來調整, 所以每個專案都會有些不同。經過斷捨離分門別類之後的專案在需要查找問題時也比較能把範圍限縮出來,只是對於大型專案來說, 剛接手時要花一點時間先理清每個項目的職責。