这是一个创建于 1689 天前的主题，其中的信息可能已经有所发展或是发生改变。
同事用 Go 写后台,我写前端,我俩联调时,我发现同事一直用 log 不用断点,我好奇就问了下为啥不用断点.同事说 Go 用不了断点,他写区块链时也用的 log 调试...但明显 GoLand 能用断点....每次调接口都磨磨唧唧的,10min 的事儿能给您墨迹一上午,就疯狂 log.....怎么劝也不听....现在后台框架用的是 b 站的 Kratos...
第 1 条附言 · 2020-05-13 10:50:29 +08:00
看了大家的评论,我发现有一些背景我没说太清楚.
- 这个项目是个从 0 到 1 的小项目,真的不大,目前在开发阶段.用 Go 开发也是因为同事之前写区块链会 Go,不用新接触一门语言所以就用了...
- 我用 Java 写过后台,项目不大但基本啥的都能搞定,所以"10min的事儿"不是我的臆测,因为改同样的东西在 Java 中估计就需要 1~2min.
- 关于用 log 还是断点.当然各有各的好处,每个有每个的使用场景.但对于我们现在来说,重点是调试的效率太低.同事这边 log 打印是真打印不明白,真不如直接上断点一行一行看.不是说谁好谁不好,就我们目前这个阶段,断点比 log 效率高.
- 我这边最后打算顺从我的同事了...就闲暇时看看 Go 回头多帮帮忙,也算是自我提高了....
 |
1
linauror 2020-05-13 09:51:02 +08:00  6
这感觉也不是不会打断点的问题，还是能力问题，对程序熟的话，打 log 一般也能很快定位到问题了
|
 |
2
Vegetable 2020-05-13 09:54:15 +08:00 4
本人后台开发，前端说改个东西要两天，但我感觉撑死 2 小时，怎么破？- 知乎
https://www.zhihu.com/question/375396826 哈哈哈开玩笑。不用断点的人多的是，真的，远比你想象的多。但是疯狂 log.Println 也是不应该的，不然日志的 TRACE DEBUG 时拿来干啥的？这的确算是个人风（水）格（平）问题。 如果你不是 Leader，最好别多管，犯不上。闭嘴不是最好的选择，但绝对不是最差的... |
 |
3
eGlhb2Jhb2Jhbw 2020-05-13 09:56:34 +08:00 1
楼上的说的都没错，不过他同事说的是"用不了"，这就是不会还懒得学的说辞罢了。
|
 |
4
paulee 2020-05-13 09:57:05 +08:00
你去看看他怎么调试，你要是看懂了并且能告诉他哪里有问题，说明他有问题，要是没看懂，学就是了
|
 |
5
sonyxperia 2020-05-13 09:58:13 +08:00
告诉他领导啊
|
 |
6
whusnoopy 2020-05-13 10:11:53 +08:00 4
我觉得问题不在同事会不会用断点，而是调试太慢
而楼主的观点是会合理用断点明显会加速调试过程，这个见仁见智吧，如果对方能继续不用断点也能把调试效率拉上来，那就随他去，不然你让他学会用断点，也未必会加快调试过程 立场说明：前 ACM/ICPC 选手，比赛时三个人一台机器不可能让你单步调的，多输出中间结果打印下来在纸上去调试；工作后写 C++ 服务端，启个环境没有 80G 内存启不来的那种，还是期望思路清晰一次过，不然也还是依赖打印日志，单步是永远不可能单步的，gdb 最多去看看 core 文件的现场 |
 |
7
lancelock 2020-05-13 10:16:22 +08:00
我之前一直想用 vim 写代码，但是因为不好调试都放弃了，反正我是佩服只用 log 或者 gdb 的人
|
 |
8
yousabuk 2020-05-13 10:17:09 +08:00
我也不用断点，没啥问题啊，看现象 + 日志也能大概定位问题所在。
调的满的可能原因： 1，慢性子人，没办法； 2，能力有些差，没办法； 3，楼主小瞧了后端的复杂度，自认为 10 分钟的事； |
 |
9
CoderGeek 2020-05-13 10:17:29 +08:00
要么水平不到位要么懒 提高效率少浪费双方时间
|
 |
10
nicevar 2020-05-13 10:18:24 +08:00
确实是这样, 写后台不会调试的大有人在, 有的已经工作了很多年了, 都是靠日志, 日志固然很方便, 但是有些时候断个点很快就能解决问题, 日志看了大半天还没找到原因, 告诉他们断点调试, 大多数还是很乐意的, 觉得相见恨晚
|
 |
11
rockyou12 2020-05-13 10:18:52 +08:00
明显是能力不行啊……，goland 打端点和其它语言没啥区别，就是不知道学啊。不要说 log 比端点调试快，用哪个和会不会是两个问题
|
 |
13
djoiwhud 2020-05-13 10:24:07 +08:00 3
go 确实可以断点，但是靠断点调试是非常不合理的。同样，影响他人调试进度也是非常错误的。
正确的姿势是： 写测试用例，单元测试覆盖到位。自测 OK 了再联调。 结论：题主和题主提到的同事都是错误的。 |
|
14
yousabuk 2020-05-13 10:24:17 +08:00
|
 |
15
wellsc 2020-05-13 10:25:41 +08:00 via Android
为啥啊，我就喜欢用 print 调试程序，也没影响进度啥的，调试慢可能是别的问题，不是调试工具的问题啊
|
 |
16
comwrg 2020-05-13 10:26:03 +08:00 via iPhone
叫他写自动化测试就没那么多逼事了
|
 |
17
newtype0092 2020-05-13 10:26:22 +08:00
我也是 log 选手，主要是正常情况下逻辑写的清晰点只要知道一段逻辑的入口参数、变量，中间的运行过程完全能想来，只要 CPU 不出错基本是不会有意外的，只要把关键的变量打印出来看看符不符合预期，很快就能定位问题。
断点、单步等操作比较麻烦，一般只是在看一个新的框架、不熟悉的底层代码的时候才用，自己写的代码还要专门断点太墨迹了。 既然你觉得 10min 能解决的问题，最好直接自己上，不是开玩笑，很多后端都会点简单的前端，小问题有时候前端没空就自己上手改了，前端完全可以学点后端的东西，也能让你对整个流程更了解，开阔思路，下次他再这么墨迹直接改完甩他脸上。 |
 |
18
drackzy 2020-05-13 10:26:47 +08:00
熟练了不是打几个断点，看看改改接口就调完了吗
|
|
19
yousabuk 2020-05-13 10:28:30 +08:00
后端调试的慢，那么楼主为啥非要等后端呢？
可以继续开发其他的功能模块嘛。 前端给后端搭好，后端慢就自己看去就可以了。 |
 |
20
stevenkang 2020-05-13 10:28:35 +08:00
需求群里面，或者领导群里面回复：
前端已开发完毕，等待后端联调。 第二天： 前端已开发完毕，等待后端联调。 最后你看着急的是他，继续不听劝，还是你？ |
|
21
djoiwhud 2020-05-13 10:31:11 +08:00 4
另外多说一点，为何 go 靠断点调试是非常不合理的。
go 开发 100%都会涉及多线程，非常多的问题不断点跑大量压测都有时候很难碰到，何况断点吭哧吭哧慢慢倒腾。断点调试可能一辈子都无法找到问题。我很少看到后端开发断点调试。 还是得靠自测和测试单元，代码和框架机制要简单。 |
|
22
newtype0092 2020-05-13 10:33:33 +08:00
@nicevar #12 绝大部分场景相反吧。而且对线上的疑难杂症或者多个系统交互的场景也不可能让你断点停下来啊，就算是测试环境，不可能整个环境为你一个人停下来，别人没法玩了。
|
|
23
nicevar 2020-05-13 10:38:36 +08:00
@newtype0092 断点的场景肯定少, 有谁跑去线上环境去断点的, 再说很多公司连线上环境都不让普通开发去操作, 断点基本上都是在本机操作, 测试环境都很少用
|
 |
24
wingoo 2020-05-13 10:42:30 +08:00
个人不建议断点, 良好的测试 + log / trace 才是正经做法
|
 |
25
nicebird 2020-05-13 10:53:15 +08:00
重点是这人太菜，调试太慢。
|
 |
26
maomaomao001 2020-05-13 10:55:07 +08:00
不要跟他连调啊, 让他用 postman 之类的测好了, 你再去接
|
 |
27
yukiloh 2020-05-13 10:55:23 +08:00 via Android
老师没教好，我以前大项目也用不来断点，后来看千峰的李为民的整会了
|
 |
28
areless 2020-05-13 11:00:59 +08:00 via Android
web 后端 log 比断点好。慢是另外原因。
|
 |
29
Yoock 2020-05-13 11:02:19 +08:00 via iPhone
如果有很多 rpc 调用，本地根本调试不了的
|
 |
30
Dbin 2020-05-13 11:06:21 +08:00
怎么劝？你又不给别人开工资，还是跟上面反馈一下比较好。
|
 |
31
zachlhb 2020-05-13 11:08:49 +08:00 via Android
说实话我也不喜欢用断点，直接 print 出来感觉更快些
|
 |
32
chihiro2014 2020-05-13 11:08:54 +08:00
断点从来不是调试的正确姿势，并且也不是看源码的正确姿势。
打日志才是，如果连自己业务都不清楚，那就很蛋疼 |
 |
33
qq1340691923 2020-05-13 11:12:32 +08:00
用 log 合理 最好是先让他写单元测试，postman 测过了没问题了 联调时再 log 打印 不过日志等级要设置成 debug
|
 |
34
darknoll 2020-05-13 11:17:32 +08:00
用啥断点啊，小白才用断点，牛逼的都是看 log
|
 |
35
taxiaohaohhh 2020-05-13 11:19:45 +08:00
@Vegetable 遇到这种谁行谁上，但凡影响我进度的，无论前后端我都是自己搞定，小公司我可以为所欲为
|
 |
36
spritewdx 2020-05-13 11:20:16 +08:00
很多拿线上环境来说断点和 log 优劣,线上环境合理的 log 日志是必不可少的,但跟调试使用 log 还是 debug 模式并没有什么关联
建议:让后端自行测试,通过后再进行联调. |
 |
37
mrdemonson 2020-05-13 11:24:54 +08:00
不用断点，还当啥程序员呀；断点是调试程序的，日志维护程序的
|
 |
38
ershisi 2020-05-13 11:30:04 +08:00
断点不是最重要的啊，解决问题能力是最重要的。自测都不测的吗？
|
 |
39
crackhopper 2020-05-13 11:37:07 +08:00
我也喜欢用调试器。不过周围大家都是 log 调试。调试器依赖编译开关，尤其是一个服务有大量上下游依赖的时候，项目的配置都有点搞不明白，自己改一下增加 debug 版本还是有点困难的。log 就非常容易了，另外仔细观察 log 也可以很快定位到问题，定位不到说明需要增加 log，这种也是好的，尤其是排查线上的 bug 根本不可能用断点，log 记录的是否充分就很关键了。
整体，我首选 log 调试，其次选择调试器。 |
 |
40
hankai17 2020-05-13 11:37:25 +08:00
块链的 go 刚培训出来的吧
|
|
41
crackhopper 2020-05-13 11:38:54 +08:00
线上 bug 那块不能用调试器，我说的有点绝对了。如果有数据记录，可以数据重放；或者配合一些快照工具，可以从崩溃前调取程序快照，也许还是可以用断点的。但总之线上 bug 用调试器断点定位，还是太困难了。成本高。
|
 |
42
darksword21 2020-05-13 11:38:56 +08:00 via iPhone
我就是 log 选手。感觉断点很麻烦很难去。。
|
 |
43
liaokylin2v 2020-05-13 11:39:08 +08:00 via Android
其实很多写了好多年代码的程序员都不会断点，比如 php 程序员。
|
 |
44
xiangyuecn 2020-05-13 11:45:30 +08:00
自我主观认为
开发环境： log+断点 >> 仅断点 log+断点 >> 仅 log 断点 ≠ log 生产环境： 断点几乎不适用，只剩 log，通过开关控制输出级别 |
 |
45
chisj 2020-05-13 11:47:05 +08:00
大部分情况下，log 比断点科学多了
|
 |
46
superchijinpeng 2020-05-13 11:52:17 +08:00 via iPhone
优秀的代码是不需要断点的
|
 |
47
yeyu123 2020-05-13 11:52:37 +08:00
print 大法好..谁用谁知道, 很多时候断点并没有 log 速度快
|
 |
48
Blacate 2020-05-13 11:56:32 +08:00
log 大法好。。
|
 |
49
kuaner 2020-05-13 11:57:34 +08:00
你写前端当然用断点很爽,他后端真不如打 log
|
 |
50
Sharuru 2020-05-13 11:58:47 +08:00 via Android
不用劝，每个人都有自己的方式去做一件事情，可能别人有一套自己顺手的 debug 流程呢。
反正 deadline 会给出答案（ doge |
 |
51
ccraohng 2020-05-13 12:20:44 +08:00 via Android
自己写的逻辑没理清，无头苍蝇乱飞。或者水平有限
|
 |
52
soki 2020-05-13 13:59:28 +08:00
目测 + log 🐶
|
 |
53
jrtzxh020 2020-05-13 14:00:56 +08:00
我们的后端跟离谱。一边写逻辑一边联调，一个接口调半天不通。每次领导说写好功能没有，就说已经写好了，在和前端调试。。。给他虐哭了
|
 |
54
KingHL 2020-05-13 14:02:02 +08:00
我是后台开发，工作了五年，换了三家公司，极少见用断点调试的。
|
 |
55
aladdindingding 2020-05-13 14:02:48 +08:00
你应该没见过每一行 log 把变量都打印出来的
|
 |
56
ddoocc 2020-05-13 14:08:43 +08:00
断点只适合调很小很小的工程。
|
 |
57
cokyhe 2020-05-13 14:16:39 +08:00
我用断点也是和同事学的，Go 语言，如果能知道问题大概出在哪，一般用 log，实在不知道咋出现的诡异 bug，才会用断点去咔咔咔
|
 |
58
ChangQin 2020-05-13 15:03:13 +08:00
有种可能，你同事用的是 mac，然后没装 xcode-commend-tool 之类的东西，我之前没装一调试也崩溃，后来一弄就好来了，不过就跟前面老哥说的，打 log 都够了 - -
|
 |
59
collery 2020-05-13 15:20:14 +08:00
我能说我现在这家公司，所有环境都没开端口么。 问就是不给开 。。 看代码真的密密麻麻的日志
|
 |
60
libotony 2020-05-13 15:20:35 +08:00
楼主可以重点放在他效率低，至于他所使用的方法可以不去关心。一直以来都有个疑问，很多人都重度依赖“联调”，我认为他们对“代码写好了”是有误解的。当然有些特殊情况是需要联调的（防杠布丁）
|
 |
61
Navee 2020-05-13 15:30:17 +08:00
楼主可以发点资料给他学一学
在工作中，你这位同事绝对不是最后一个和你的认知差距很远的同行 |
 |
62
gp1136612050 2020-05-13 15:33:07 +08:00
确实我也觉得是能力问题。有时候出问题，测试把场景或者现象一描述，我就能定位到是哪里出问题。有时候都不用 log 或者断点就直接改改完自测就好了。当然说的是改自己的东西。
|
 |
63
qwerthhusn 2020-05-13 15:52:41 +08:00
请求接口后，Chrome F12 Network 找到请求 右击 Copy，Copy as cURL 复制出 curl 请求命令，然后可以重复在命令行调用
发过去，让其自己去调，然后就可以安心划水了，全程不需要参与 |
 |
64
latteczy 2020-05-13 17:09:13 +08:00
不用断点+1 。
实际工作中能让你通过断点 /打 log 去调试的问题应该比较少，一般遇到问题通过 review 代码就能看出来。 |
 |
65
mengzhuo 2020-05-13 17:22:37 +08:00
离了 Goland 我看你怎么断点，现网有问题怎么断点，会用个把工具就叽叽歪歪在网上声讨别人？
而不是帮他搞一搞？提升团队能力？ |
 |
66
paoqi2048 2020-05-13 17:34:33 +08:00
IDE 断点还好，命令行断点挺麻烦的😑
|
 |
67
xuzhzzz 2020-05-13 17:37:30 +08:00
我们也是 kratos，我们不会是同事吧
|
 |
68
wentaoliang 2020-05-13 18:22:08 +08:00 via iPhone
为啥不能用 log 。我反而觉得断掉调试效率不高。只有遇到复杂逻辑或者疑难问题才打断点
|
 |
69
zhouwei520 2020-05-13 18:28:28 +08:00
debug 不是自测的么？联调看日志就行
|
|
70
zhouwei520 2020-05-13 18:30:28 +08:00
不都是联调才开始写代码么，手动滑稽
|
 |
71
amimo 2020-05-13 18:43:15 +08:00
调试器可以让你在不修改代码,不重启应用的情况下,在任意位置打印 Log,这调试效率不更高么?
|
 |
72
0x11901 2020-05-13 20:01:09 +08:00
感觉还是编译 /执行的速度太快了的原因……我以前特别喜欢写 log，后来遇到了项目编译一次 20+分钟之后，我不仅断点要打 20 个，甚至 debugger 附加二进制调试……符号表……逆向……还不简简单单……
|
 |
73
newmlp 2020-05-13 20:33:40 +08:00
断点只能解决一时的问题，只要日志加好以后出问题解决会方便很多，也许人家正忙着加日志呢，没空和你 debug
|
 |
74
gamexg 2020-05-13 20:43:27 +08:00
断点的确快速简单，不过日志比较适合长期使用。
选择哪个看个具体情况了， 如果你同事打算尽量增加齐全的日志，方便以后再出问题时解决问题，那么这也是一种选择。 |
 |
75
csl1995 2020-05-13 20:45:05 +08:00
C++选手
开发阶段： log 直观清楚，可以解决一些比较明显的问题 log 弄不清楚问题原因，用 GDB 兜底 上了生产： 生产的介质是不会给你开-g 的，所以只有日志 出了问题基本就是根据日志分析复现问题 |
 |
76
lechain 2020-05-13 21:51:28 +08:00 via Android
举个楼上提到的，生产介质不支持的情景例子
如果做 turnkey 方案，客户平台遇到问题，只有靠印 log 怎么办？断点调试的场景比较局限，虽然定位问题比较快 只能说各有优缺点，不能一棍子打死… |
 |
77
xmge 2020-05-13 22:09:58 +08:00
@sonyxperia 兄弟，同事是统一战线，永远不要站错队。
|
 |
78
greenlantern 2020-05-13 22:33:34 +08:00 via Android
怕是用了断点能墨迹成三天
|
|
79
yousabuk 2020-05-13 22:49:21 +08:00
@0x11901
对，各项成本综合最优方案，我编译 FPGA 程序 3 小时，敢随便编译吗？修改一下编译一下，两下还不得下班了嘛。就得完善仿真，各种仿真测试，最后再编译。 碰到其他运行太方便了的程序，就可虑的少了，反正有啥问题跑起来就看到了，就懒得思考那么多了。 |
 |
80
0987363 2020-05-13 23:40:41 +08:00 via Android
以前用 c/c++的时候倒是离不开断点，主要还是指针越界问题。现在 go 的指针越界都能直接报错了，搭配上合理的 log，定位问题非常简单，完全不需要断点
|
 |
81
souths 2020-05-14 00:07:51 +08:00
说实话，不熟悉才会调试的慢，马虎、觉得复杂更是因为不熟悉
|
 |
82
siteshen 2020-05-14 02:57:24 +08:00 2
建议明确前后端的界限，前端只是把后端当个黑盒子使用，做前端的只能「建议」后端怎么做（反之亦然）。
前端遇到问题，只需要告诉后端某个请求有问题，并提供 curl 命令、预期结果和实际结果。 至于后端是用断点、log 、买个啄木鸟还是拍电脑，都与前端无关。 |
 |
83
12tall 2020-05-14 09:07:59 +08:00
单元测试不行吗
|
 |
84
p1gd0g 2020-05-14 09:09:44 +08:00
有没有 requestID ？有没有定义错误码？有没有输出错误堆栈？
|
 |
85
sm0king 2020-05-14 09:38:56 +08:00
后端 bug 不都是前端改的么？
|
 |
86
laball 2020-05-14 12:52:57 +08:00
IDEA 就可以直接调试啊，VS Code 应该也可以。
懒癌发作嘛？ |
 |
87
zichen 2020-05-14 13:43:40 +08:00
如果接口文档定义的够清晰，前后端都照着接口开发，哪儿用的着花很长时间调试？好多开发问题，其实归根结底是设计问题。
|
 |
88
potatowish 2021-01-07 21:34:54 +08:00 via iPhone
关键的地方 log 一下，调试的时候基本就能看出问题了，也便于线上定位问题 。个人觉得断点不够爽快
|
Select Language