想要维护自己的开源项目,但发现读不下去难以维护

查看 174|回复 16
lshang   
让 chatgpt 帮你解释,甚至它还能帮你优化或重构
opentrade   
这么健忘?
quzard   
让 chatgpt 帮你注释代码
zapper   
我同意 2 楼说法
Executor   
深有同感
我自己的小玩具基本都是一年一重构的, 基本就是一年后回顾项目时发现: 啊, 我之前写的都是些什么鬼东西……
ufo5260987423   
哥们,我看了一下你的项目结构,大概……明白你是在哪里遇到困难了。
我用自己的项目 scheme-langserver ( https://github.com/ufo5260987423/scheme-langserver )做基准,对你的项目进行一下评论,说的不一定对,请批判:
1 、对于任何来阅读你的代码的人(包括你自己)来说,你必须假设这是一个黑箱子,他们什么都不知道。那么,在这种情况下应该提供一个统一的出入口。对于 c 语言的代码来说,main 就必须要暴露在代码的根目录下的那个.c 文件里。这不是不可以做妥协,而是要尽力抓住这个原则,让人家尽快找到黑箱子的出入口;我不熟悉 go ,你大概率也不熟悉我用的 scheme ,但是我的根目录下面只有 run.ss 和 scheme-langserver.sls ,入口显而易见。你的则看不出来。
2 、代码的目标不清楚,似乎一开始是 tcp 推送的一个 server ,那为什么要有一个文件夹叫做 http 什么的?中间的需求变化了,当然就有问题了。我自己的建议是,利用好打包工具,分包去写。例如我的代码中用到了 match 宏,我是单独写了一个包( ufo-match )发布在 akku 上,然后自己随时取用。总之,对于某一个包,完成了最初预定的功能就尽量不要动,要动就肯定是大规模重构。
当然你会问:可是我并不能一开始就看清楚自己想要什么啊。
3 、这就需要你一开始就做好架构设计。什么是好的架构设计,就是架构的不同部分抽象程度足够高,功能重叠足够少。从你的目录结构来看,你这点做的不好。一个文件夹就代表了你抽象的一部分,这一部分下面就那么大猫小猫三两只。可想而知,文件夹命名没有给出足够的信息。
比如 protocol 下面是 pack 和 unpack 两个文件。protocol 是这个意思么?而且 pack 和 unpack 为什么不合并为一个文件呢?
persist ,全称大概是 persistent ?下面一个是 test 文件一个是 db——db 就是 persist 的全部么?
4 、commit message 要么不写,要么就好好写。你可以看到我的 commit 大部分都是 fix 。因为修正的都是无关紧要的问题。只有比较难的我才去稍微认真的写一下。
先评论这些,有什么问题和意见我们可以再交流。
ljrdxs   
今天还有这个主题。对比你的,相映成趣。
《🥶🥶以后该用拼音首字母做数据表字段了,呵,摆烂谁不会啊》
https:///t/923650#reply13
您需要登录后才可以回帖 登录 | 立即注册

返回顶部