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

很正常哈哈，所以我现在写代码习惯把函数细分点，并把注释写的详细点，这样后面过了很久来维护的时候可以快速上手

所以开源项目一定会写单元测试的原因就是在这里
第一是保证按照使用场景进行快速测试和代码调用链路梳理
第二是在更新或优化了代码之后可以快速验证全流程功能可用性

正常正常~ 多写点注释方便自己以后看，多写些测试用例让以后改起来放心一些
自己的项目慢慢来就好

你这 commit message 写的

换个姿势重写一遍。

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

（不过我是没啥资格说这方面的事，自己的烂代码相隔半年就直接看不下去了，能跑的就让它接着跑，跑不动的我也不想动了）

让 chatgpt 解释代码（

大致看下，看不懂的部分重构

重构吧。。。

重构，出 2.0 ，加单元测试。

让 chatgpt 帮你解释，甚至它还能帮你优化或重构

这么健忘？

让 chatgpt 帮你注释代码

我同意 2 楼说法

深有同感
我自己的小玩具基本都是一年一重构的, 基本就是一年后回顾项目时发现: 啊, 我之前写的都是些什么鬼东西……

哥们，我看了一下你的项目结构，大概……明白你是在哪里遇到困难了。
我用自己的项目 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 。因为修正的都是无关紧要的问题。只有比较难的我才去稍微认真的写一下。

先评论这些，有什么问题和意见我们可以再交流。

今天还有这个主题。对比你的，相映成趣。
《🥶🥶以后该用拼音首字母做数据表字段了，呵，摆烂谁不会啊》
https://v2ex.com/t/923650#reply13

@ufo5260987423 #15 太强了

@wzzzx #17 谢谢夸奖。

我是仓库拿来学习 git 的分支弄乱的

@ufo5260987423 谢谢老哥耐心回复 在这里解释下你提出的几点：
关于 2 这个 srv 一开始的设计打算就是内置一个 http api 来提供使用者调用，而且 http 的是用 go 的标准库实现的也没必要引入了什么外部包了
3 、关于目录命名问题，protocol 下的代码主要负责对 tcp 数据流的封包和解包，我认为这和 protocol （协议）相关所以这样命名自认为没什么问题；关于目录架构问题，由于 go 规定每个文件夹只能有 1 个包名，所以为了区分各个文件的组织架构，只能通过文件夹区分，而且一开始的目标是完成基本的功能，一些包的功能模块只写了最基本的功能，所以导致一些目录下的代码文件只有一两个，去年写完这些功能后，打算以“连接数达到操作系统所支持的最高数的情况下能长时间稳定运行，并且保证并发性能”作为验收标准，最后经过一些测试，满负荷运行的情况下，单机的 qps 在 1000 左右，也算是达到了目标，后面因为想玩的 3a 出了就打游戏去了，搁置了没继续往下写，结果一搁置就快半年了。。。
4 、这个确实有问题，每次写完一大坨就想着保存，但总是涉及到了好几个模块的功能，自己也记不清了所以 commit 写的很敷衍，完全就是有了些完成度想“存个档”而已

@voidmnwzp #20 感谢回复。
1.go 这个规定很正常啊，但是不能文件夹里面有文件夹，把结构弄的深一点嘛？因为我对 go 不熟悉（ 8 年前，那时候我还是本科看过一点点），所以就不再评论了。
2.关于目标。一般我们做开源尽量做人无我有，做一些自己遇到的特殊场景。你给自己设置的目标是一个 state-of-art 的场景。也就是说，场景是常见的（似乎是），但是要求太高，一般需要不断做工作打磨才能完成。所以你玩 3a 当然就任务完成的半吊子。而且，为了完成这种任务，不知道你是否采取了一些奇技淫巧——绝大多数情况下这些奇技淫巧是牺牲可读性的，这也就造成了你的现状：看不懂自己的代码。
3 、“总是涉及到好几个模块”这个涉及到本质问题：目标高但是完成度不高，自己又不太写文档和 commit ，功能耦合也高，性能 state-of-art 难度大。

建议：以后写这种项目，不要急于求成一下吃胖子，要把下层结构单个儿写出来做组合。不要怕上层整合不了，大不了重构嘛。你这又不是什么挣大钱的项目，应该有比 python 扔掉若干个大版本重构还要大的勇气 2333
你要觉得自己的项目是 jvm 那种，那倒是有人给你写注释和文档了 2333