6
想要维护自己的开源项目，但发现读不下去难以维护
source link: https://www.v2ex.com/t/923644
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
去年 10 月份用 go 写了个 tcp 的推送 server ，现在想要维护下代码，添加一些功能，结果发现比较细节的代码居然看不懂了，可能是注释写的少了或者是当初写的太随意的原因，感觉很难看进去，虽然大致逻辑能把握住，但要想在基础上优化或者增加功能难免要在之前代码实现的细节处进行改动，但我现在实在是看不进去这些代码，在云里雾里的情况下贸然改动可能会导致之前的功能都会出 bug ，目前是很纠结到底是推倒重构还是硬着头皮看下去。。。 附地址:https://github.com/NullpointerW/golwpush
16 条回复 • 2023-03-13 20:27:02 +08:00
 |
fzls 3 小时 33 分钟前 很正常哈哈，所以我现在写代码习惯把函数细分点，并把注释写的详细点，这样后面过了很久来维护的时候可以快速上手
|
 |
8355 3 小时 21 分钟前 所以开源项目一定会写单元测试的原因就是在这里
第一是保证按照使用场景进行快速测试和代码调用链路梳理 第二是在更新或优化了代码之后可以快速验证全流程功能可用性 |
 |
icyalala 3 小时 19 分钟前 正常正常~ 多写点注释方便自己以后看，多写些测试用例让以后改起来放心一些
自己的项目慢慢来就好 |
 |
learningman 3 小时 18 分钟前 你这 commit message 写的
|
 |
MossFox 3 小时 15 分钟前 换个姿势重写一遍。
……正经点说，可能一些设计模式相关的知识会值得了解一下。例如 Java 的那一堆设计模式里面，从啰嗦的内容里面可以提炼出一些挺精华的要点，比如通过合理的设计，可以做到新增特性时对代码的只增不改这种。 （不过我是没啥资格说这方面的事，自己的烂代码相隔半年就直接看不下去了，能跑的就让它接着跑，跑不动的我也不想动了） |
 |
sencat31 3 小时 13 分钟前 让 chatgpt 解释代码（
|
 |
xuanyuanaosheng 2 小时 33 分钟前 大致看下，看不懂的部分重构
|
 |
yaott2020 2 小时 14 分钟前 via Android 重构吧。。。
|
 |
Mutoo 2 小时 4 分钟前 重构，出 2.0 ，加单元测试。
|
 |
lshang 1 小时 45 分钟前 让 chatgpt 帮你解释，甚至它还能帮你优化或重构
|
 |
opentrade 1 小时 32 分钟前 这么健忘？
|
 |
quzard 1 小时 27 分钟前 让 chatgpt 帮你注释代码
|
 |
zapper 1 小时 23 分钟前 我同意 2 楼说法
|
 |
Executor 1 小时 7 分钟前 深有同感
我自己的小玩具基本都是一年一重构的, 基本就是一年后回顾项目时发现: 啊, 我之前写的都是些什么鬼东西…… |
 |
ufo5260987423 58 分钟前 哥们，我看了一下你的项目结构，大概……明白你是在哪里遇到困难了。
我用自己的项目 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 。因为修正的都是无关紧要的问题。只有比较难的我才去稍微认真的写一下。 先评论这些，有什么问题和意见我们可以再交流。 |
1 |
ljrdxs 52 分钟前 |
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK