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

2023-03-13 17:04:02 +08:00
 voidmnwzp

去年 10 月份用 go 写了个 tcp 的推送 server ,现在想要维护下代码,添加一些功能,结果发现比较细节的代码居然看不懂了,可能是注释写的少了或者是当初写的太随意的原因,感觉很难看进去,虽然大致逻辑能把握住,但要想在基础上优化或者增加功能难免要在之前代码实现的细节处进行改动,但我现在实在是看不进去这些代码,在云里雾里的情况下贸然改动可能会导致之前的功能都会出 bug ,目前是很纠结到底是推倒重构还是硬着头皮看下去。。。 附地址:https://github.com/NullpointerW/golwpush

3440 次点击
所在节点    程序员
21 条回复
fzls
2023-03-13 17:46:29 +08:00
很正常哈哈,所以我现在写代码习惯把函数细分点,并把注释写的详细点,这样后面过了很久来维护的时候可以快速上手
8355
2023-03-13 17:57:44 +08:00
所以开源项目一定会写单元测试的原因就是在这里
第一是保证按照使用场景进行快速测试和代码调用链路梳理
第二是在更新或优化了代码之后可以快速验证全流程功能可用性
icyalala
2023-03-13 17:59:44 +08:00
正常正常~ 多写点注释方便自己以后看,多写些测试用例让以后改起来放心一些
自己的项目慢慢来就好
learningman
2023-03-13 18:00:59 +08:00
你这 commit message 写的
MossFox
2023-03-13 18:04:27 +08:00
换个姿势重写一遍。

……正经点说,可能一些设计模式相关的知识会值得了解一下。例如 Java 的那一堆设计模式里面,从啰嗦的内容里面可以提炼出一些挺精华的要点,比如通过合理的设计,可以做到新增特性时对代码的只增不改这种。

(不过我是没啥资格说这方面的事,自己的烂代码相隔半年就直接看不下去了,能跑的就让它接着跑,跑不动的我也不想动了)
sencat31
2023-03-13 18:06:28 +08:00
让 chatgpt 解释代码(
xuanyuanaosheng
2023-03-13 18:46:28 +08:00
大致看下,看不懂的部分重构
yaott2020
2023-03-13 19:05:18 +08:00
重构吧。。。
Mutoo
2023-03-13 19:15:24 +08:00
重构,出 2.0 ,加单元测试。
lshang
2023-03-13 19:33:58 +08:00
让 chatgpt 帮你解释,甚至它还能帮你优化或重构
opentrade
2023-03-13 19:47:10 +08:00
这么健忘?
quzard
2023-03-13 19:52:29 +08:00
让 chatgpt 帮你注释代码
zapper
2023-03-13 19:56:03 +08:00
我同意 2 楼说法
Executor
2023-03-13 20:11:42 +08:00
深有同感
我自己的小玩具基本都是一年一重构的, 基本就是一年后回顾项目时发现: 啊, 我之前写的都是些什么鬼东西……
ufo5260987423
2023-03-13 20:20:34 +08:00
哥们,我看了一下你的项目结构,大概……明白你是在哪里遇到困难了。
我用自己的项目 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
2023-03-13 20:27:02 +08:00
今天还有这个主题。对比你的,相映成趣。
《🥶🥶以后该用拼音首字母做数据表字段了,呵,摆烂谁不会啊》
https://v2ex.com/t/923650#reply13
wzzzx
2023-03-13 21:33:29 +08:00
@ufo5260987423 #15 太强了
ufo5260987423
2023-03-13 21:39:19 +08:00
@wzzzx #17 谢谢夸奖。
Bingchunmoli
2023-03-13 22:50:13 +08:00
我是仓库拿来学习 git 的分支弄乱的
voidmnwzp
2023-03-14 10:31:45 +08:00
@ufo5260987423 谢谢老哥耐心回复 在这里解释下你提出的几点:
关于 2 这个 srv 一开始的设计打算就是内置一个 http api 来提供使用者调用,而且 http 的是用 go 的标准库实现的也没必要引入了什么外部包了
3 、关于目录命名问题,protocol 下的代码主要负责对 tcp 数据流的封包和解包,我认为这和 protocol (协议)相关所以这样命名自认为没什么问题;关于目录架构问题,由于 go 规定每个文件夹只能有 1 个包名,所以为了区分各个文件的组织架构,只能通过文件夹区分,而且一开始的目标是完成基本的功能,一些包的功能模块只写了最基本的功能,所以导致一些目录下的代码文件只有一两个,去年写完这些功能后,打算以“连接数达到操作系统所支持的最高数的情况下能长时间稳定运行,并且保证并发性能”作为验收标准,最后经过一些测试,满负荷运行的情况下,单机的 qps 在 1000 左右,也算是达到了目标,后面因为想玩的 3a 出了就打游戏去了,搁置了没继续往下写,结果一搁置就快半年了。。。
4 、这个确实有问题,每次写完一大坨就想着保存,但总是涉及到了好几个模块的功能,自己也记不清了所以 commit 写的很敷衍,完全就是有了些完成度想“存个档”而已

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/923644

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX