这是一个创建于 650 天前的主题，其中的信息可能已经有所发展或是发生改变。
去年 10 月份用 go 写了个 tcp 的推送 server ，现在想要维护下代码，添加一些功能，结果发现比较细节的代码居然看不懂了，可能是注释写的少了或者是当初写的太随意的原因，感觉很难看进去，虽然大致逻辑能把握住，但要想在基础上优化或者增加功能难免要在之前代码实现的细节处进行改动，但我现在实在是看不进去这些代码，在云里雾里的情况下贸然改动可能会导致之前的功能都会出 bug ，目前是很纠结到底是推倒重构还是硬着头皮看下去。。。 附地址:https://github.com/NullpointerW/golwpush
 |
1
fzls 2023-03-13 17:46:29 +08:00
很正常哈哈，所以我现在写代码习惯把函数细分点，并把注释写的详细点，这样后面过了很久来维护的时候可以快速上手
|
 |
2
8355 2023-03-13 17:57:44 +08:00  1
所以开源项目一定会写单元测试的原因就是在这里
第一是保证按照使用场景进行快速测试和代码调用链路梳理 第二是在更新或优化了代码之后可以快速验证全流程功能可用性 |
 |
3
icyalala 2023-03-13 17:59:44 +08:00
正常正常~ 多写点注释方便自己以后看，多写些测试用例让以后改起来放心一些
自己的项目慢慢来就好 |
 |
4
learningman 2023-03-13 18:00:59 +08:00
你这 commit message 写的
|
 |
5
MossFox 2023-03-13 18:04:27 +08:00
换个姿势重写一遍。
……正经点说，可能一些设计模式相关的知识会值得了解一下。例如 Java 的那一堆设计模式里面，从啰嗦的内容里面可以提炼出一些挺精华的要点，比如通过合理的设计，可以做到新增特性时对代码的只增不改这种。 （不过我是没啥资格说这方面的事，自己的烂代码相隔半年就直接看不下去了，能跑的就让它接着跑，跑不动的我也不想动了） |
 |
6
A8bM3D6FrJTw9l7Y 2023-03-13 18:06:28 +08:00
让 chatgpt 解释代码（
|
 |
7
xuanyuanaosheng 2023-03-13 18:46:28 +08:00
大致看下，看不懂的部分重构
|
 |
8
yaott2020 2023-03-13 19:05:18 +08:00 via Android
重构吧。。。
|
 |
9
Mutoo 2023-03-13 19:15:24 +08:00
重构，出 2.0 ，加单元测试。
|
 |
10
lshang 2023-03-13 19:33:58 +08:00
让 chatgpt 帮你解释，甚至它还能帮你优化或重构
|
 |
11
opentrade 2023-03-13 19:47:10 +08:00
这么健忘？
|
 |
12
quzard 2023-03-13 19:52:29 +08:00
让 chatgpt 帮你注释代码
|
 |
13
zapper 2023-03-13 19:56:03 +08:00
我同意 2 楼说法
|
 |
14
Executor 2023-03-13 20:11:42 +08:00
深有同感
我自己的小玩具基本都是一年一重构的, 基本就是一年后回顾项目时发现: 啊, 我之前写的都是些什么鬼东西…… |
 |
15
ufo5260987423 2023-03-13 20:20:34 +08:00 7
哥们，我看了一下你的项目结构，大概……明白你是在哪里遇到困难了。
我用自己的项目 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 。因为修正的都是无关紧要的问题。只有比较难的我才去稍微认真的写一下。 先评论这些，有什么问题和意见我们可以再交流。 |
 |
16
ljrdxs 2023-03-13 20:27:02 +08:00
|
 |
17
wzzzx 2023-03-13 21:33:29 +08:00
@ufo5260987423 #15 太强了
|
|
18
ufo5260987423 2023-03-13 21:39:19 +08:00
@wzzzx #17 谢谢夸奖。
|
 |
19
Bingchunmoli 2023-03-13 22:50:13 +08:00 via Android
我是仓库拿来学习 git 的分支弄乱的
|
 |
20
voidmnwzp OP @ufo5260987423 谢谢老哥耐心回复 在这里解释下你提出的几点：
关于 2 这个 srv 一开始的设计打算就是内置一个 http api 来提供使用者调用，而且 http 的是用 go 的标准库实现的也没必要引入了什么外部包了 3 、关于目录命名问题，protocol 下的代码主要负责对 tcp 数据流的封包和解包，我认为这和 protocol （协议）相关所以这样命名自认为没什么问题；关于目录架构问题，由于 go 规定每个文件夹只能有 1 个包名，所以为了区分各个文件的组织架构，只能通过文件夹区分，而且一开始的目标是完成基本的功能，一些包的功能模块只写了最基本的功能，所以导致一些目录下的代码文件只有一两个，去年写完这些功能后，打算以“连接数达到操作系统所支持的最高数的情况下能长时间稳定运行，并且保证并发性能”作为验收标准，最后经过一些测试，满负荷运行的情况下，单机的 qps 在 1000 左右，也算是达到了目标，后面因为想玩的 3a 出了就打游戏去了，搁置了没继续往下写，结果一搁置就快半年了。。。 4 、这个确实有问题，每次写完一大坨就想着保存，但总是涉及到了好几个模块的功能，自己也记不清了所以 commit 写的很敷衍，完全就是有了些完成度想“存个档”而已 |
|
21
ufo5260987423 2023-03-14 10:55:28 +08:00
@voidmnwzp #20 感谢回复。
1.go 这个规定很正常啊，但是不能文件夹里面有文件夹，把结构弄的深一点嘛？因为我对 go 不熟悉（ 8 年前，那时候我还是本科看过一点点），所以就不再评论了。 2.关于目标。一般我们做开源尽量做人无我有，做一些自己遇到的特殊场景。你给自己设置的目标是一个 state-of-art 的场景。也就是说，场景是常见的（似乎是），但是要求太高，一般需要不断做工作打磨才能完成。所以你玩 3a 当然就任务完成的半吊子。而且，为了完成这种任务，不知道你是否采取了一些奇技淫巧——绝大多数情况下这些奇技淫巧是牺牲可读性的，这也就造成了你的现状：看不懂自己的代码。 3 、“总是涉及到好几个模块”这个涉及到本质问题：目标高但是完成度不高，自己又不太写文档和 commit ，功能耦合也高，性能 state-of-art 难度大。 建议：以后写这种项目，不要急于求成一下吃胖子，要把下层结构单个儿写出来做组合。不要怕上层整合不了，大不了重构嘛。你这又不是什么挣大钱的项目，应该有比 python 扔掉若干个大版本重构还要大的勇气 2333 你要觉得自己的项目是 jvm 那种，那倒是有人给你写注释和文档了 2333 |
Select Language