day 8 - 程序码也要断舍离

生活要断舍离, 程序码也要喔。

写Go只要一支main.go就可以开始写了, 想写多长就写多长, 要是埋头苦干不断地写下去, 一个专案要写上几万行都是有可能的。
没有断舍离的程序码就像一团乱的房间找不到一处落脚点, 不仅别人难以阅读, 自己写完之後要debug可能也要找半天, 更甚至, 或许写完两个月後自己也不认得当初的样子了。
要想debug时还能保持优雅, 还是先试着帮它们分门别类吧!

从Hello World一脚踏入程序语言之後, 如何将程序码整理分类, 把逻辑归纳清楚, 通常都要参考几个专案之後, 才会慢慢长出自己样子, 而且这个样子会随着接触的专案多了, 时间久了, 还会慢慢的改变喔。

按照这个模拟专案的规模跟需求, 我会先这样分：

这次的资料夹结构大概会是长这样：

├── 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,专案的档案结构会随着专案而变化。每个专案的资料夹结构会依照使用到的工具跟设计的功能来调整, 所以每个专案都会有些不同。经过断舍离分门别类之後的专案在需要查找问题时也比较能把范围限缩出来,只是对於大型专案来说, 刚接手时要花一点时间先理清每个项目的职责。