不懂就问,同事写后台不会用断点也不学…每次调接口都要好久,怎么劝劝啊…

• 資深大佬 : linauror

  这感觉也不是不会打断点的问题，还是能力问题，对程序熟的话，打 log 一般也能很快定位到问题了

• 資深大佬 : Vegetable

  本人后台开发，前端说改个东西要两天，但我感觉撑死 2 小时，怎么破？- 知乎
  https://www.zhihu.com/question/375396826

  哈哈哈开玩笑。不用断点的人多的是，真的，远比你想象的多。但是疯狂 log.Println 也是不应该的，不然日志的 TRACE DEBUG 时拿来干啥的？这的确算是个人风（水）格（平）问题。
  如果你不是 Leader，最好别多管，犯不上。闭嘴不是最好的选择，但绝对不是最差的…

• 資深大佬 : eGlhb2Jhb2Jhbw

  上的说的都没错，不过他同事说的是”用不了”，这就是不会还懒得学的说辞罢了。

• 資深大佬 : paulee

  你去看看他怎么调试，你要是看懂了并且能告诉他哪里有问题，说明他有问题，要是没看懂，学就是了

• 資深大佬 : sonyxperia

  告诉他领导啊

• 資深大佬 : whusnoopy

  我觉得问题不在同事会不会用断点，而是调试太慢

  而主的观点是会合理用断点明显会加速调试过程，这个见仁见智吧，如果对方能继续不用断点也能把调试效率拉上来，那就随他去，不然你让他学会用断点，也未必会加快调试过程

  立场说明：前 ACM/ICPC 选手，比赛时三个人一台机器不可能让你单步调的，多输出中间结果打印下来在纸上去调试；工作后写 C++ 服务端，启个环境没有 80G 内存启不来的那种，还是期望思路清晰一次过，不然也还是依赖打印日志，单步是永远不可能单步的，gdb 最多去看看 core 文件的现场

• 資深大佬 : lancelock

  我之前一直想用 vim 写代码，但是因为不好调试都放弃了，反正我是佩服只用 log 或者 gdb 的人

• 資深大佬 : yousabuk

  我也不用断点，没啥问题啊，看现象 + 日志也能大概定位问题所在。

  调的满的可能原因：
  1，慢性子人，没办法；
  2，能力有些差，没办法；
  3，主小瞧了后端的复杂度，自认为 10 分钟的事；

• 資深大佬 : CoderGeek

  要么水平不到位要么懒 提高效率少浪费双方时间

• 資深大佬 : nicevar

  确实是这样, 写后台不会调试的大有人在, 有的已经工作了很多年了, 都是靠日志, 日志固然很方便, 但是有些时候断个点很快就能解决问题, 日志看了大半天还没找到原因, 告诉他们断点调试, 大多数还是很乐意的, 觉得相见恨晚

• 資深大佬 : rockyou12

  明显是能力不行啊……，goland 打端点和其它语言没啥区别，就是不知道学啊。不要说 log 比端点调试快，用哪个和会不会是两个问题

• 資深大佬 : nicevar

  @yousabuk 有些场景断点调试要比看日志快得多

• 資深大佬 : jackrelative

  go 确实可以断点，但是靠断点调试是非常不合理的。同样，影响他人调试进度也是非常错误的。

  正确的姿势是：
  写测试用例，单元测试覆盖到位。自测 OK 了再联调。

  结论：题主和题主提到的同事都是错误的。

• 資深大佬 : yousabuk

  @nicevar
  就是在有些场景才偶尔用断点，平时喜欢 log，很顺手。
  一般情况下在写代码的时候程序流程怎么走心里就已经有数（少数情况下的时候会跑飞），没那么多使用断点调试的场景。

• 資深大佬 : wellsc

  为啥啊，我就喜欢用 print 调试程序，也没影响进度啥的，调试慢可能是别的问题，不是调试工具的问题啊

• 資深大佬 : comwrg

  叫他写自动化测试就没那么多逼事了

• 資深大佬 : newtype0092

  我也是 log 选手，主要是正常情况下逻辑写的清晰点只要知道一段逻辑的入口参数、变量，中间的运行过程完全能想来，只要 CPU 不出错基本是不会有意外的，只要把关键的变量打印出来看看符不符合预期，很快就能定位问题。
  断点、单步等操作比较麻烦，一般只是在看一个新的框架、不熟悉的底层代码的时候才用，自己写的代码还要专门断点太墨迹了。

  既然你觉得 10min 能解决的问题，最好直接自己上，不是开玩笑，很多后端都会点简单的前端，小问题有时候前端没空就自己上手改了，前端完全可以学点后端的东西，也能让你对整个流程更了解，开阔思路，下次他再这么墨迹直接改完甩他脸上。

• 資深大佬 : drackzy

  熟练了不是打几个断点，看看改改接口就调完了吗

• 資深大佬 : yousabuk

  后端调试的慢，那么主为啥非要等后端呢？
  可以继续开发其他的功能模块嘛。
  前端给后端搭好，后端慢就自己看去就可以了。

• 資深大佬 : stevenkang

  需求群里面，或者领导群里面回复：

  前端已开发完毕，等待后端联调。

  第二天：
  前端已开发完毕，等待后端联调。

  最后你看着急的是他，继续不听劝，还是你？

• 資深大佬 : jackrelative

  另外多说一点，为何 go 靠断点调试是非常不合理的。

  go 开发 100%都会涉及多线程，非常多的问题不断点跑大量压测都有时候很难碰到，何况断点吭哧吭哧慢慢倒腾。断点调试可能一辈子都无法找到问题。我很少看到后端开发断点调试。

  还是得靠自测和测试单元，代码和框架机制要简单。

• 資深大佬 : newtype0092

  @nicevar #12 绝大部分场景相反吧。而且对线上的疑难杂症或者多个系统交互的场景也不可能让你断点停下来啊，就算是测试环境，不可能整个环境为你一个人停下来，别人没法玩了。

• 資深大佬 : nicevar

  @newtype0092 断点的场景肯定少, 有谁跑去线上环境去断点的, 再说很多公司连线上环境都不让普通开发去操作, 断点基本上都是在本机操作, 测试环境都很少用

• 資深大佬 : wingoo

  个人不建议断点, 良好的测试 + log / trace 才是正经做法

• 資深大佬 : nicebird

  重点是这人太菜，调试太慢。

• 資深大佬 : maomaomao001

  不要跟他连调啊, 让他用 postman 之类的测好了, 你再去接

• 資深大佬 : yukiloh

  老师没教好，我以前大项目也用不来断点，后来看千峰的李为民的整会了

• 資深大佬 : areless

  web 后端 log 比断点好。慢是另外原因。

• 資深大佬 : Yoock

  如果有很多 rpc 调用，本地根本调试不了的

• 資深大佬 : Dbin

  怎么劝？你又不给别人开工资，还是跟上面反馈一下比较好。

• 資深大佬 : zachlhb

  说实话我也不喜欢用断点，直接 print 出来感觉更快些

• 資深大佬 : chihiro2014

  断点从来不是调试的正确姿势，并且也不是看源码的正确姿势。
  打日志才是，如果连自己业务都不清楚，那就很蛋疼

• 資深大佬 : qq1340691923

  用 log 合理 最好是先让他写单元测试，postman 测过了没问题了 联调时再 log 打印 不过日志等级要设置成 debug

• 資深大佬 : darknoll

  用啥断点啊，小白才用断点，牛逼的都是看 log

• 資深大佬 : taxiaohaohhh

  @Vegetable 遇到这种谁行谁上，但凡影响我进度的，无论前后端我都是自己搞定，小公司我可以为所欲为

• 資深大佬 : spritewdx

  很多拿线上环境来说断点和 log 优劣,线上环境合理的 log 日志是必不可少的,但跟调试使用 log 还是 debug 模式并没有什么关联
  建议:让后端自行测试,通过后再进行联调.

• 資深大佬 : mrdemonson

  不用断点，还当啥程序员呀；断点是调试程序的，日志维护程序的

• 資深大佬 : ershisi

  断点不是最重要的啊，解决问题能力是最重要的。自测都不测的吗？

• 資深大佬 : crackhopper

  我也喜欢用调试器。不过周围大家都是 log 调试。调试器依赖编译开关，尤其是一个服务有大量上下游依赖的时候，项目的配置都有点搞不明白，自己改一下增加 debug 版本还是有点困难的。log 就非常容易了，另外仔细观察 log 也可以很快定位到问题，定位不到说明需要增加 log，这种也是好的，尤其是排查线上的 bug 根本不可能用断点，log 记录的是否充分就很关键了。
  整体，我首选 log 调试，其次选择调试器。

• 資深大佬 : hankai17

  块链的 go 刚培训出来的吧

• 資深大佬 : crackhopper

  线上 bug 那块不能用调试器，我说的有点绝对了。如果有数据记录，可以数据重放；或者配合一些快照工具，可以从崩溃前调取程序快照，也许还是可以用断点的。但总之线上 bug 用调试器断点定位，还是太困难了。成本高。

• 資深大佬 : darksword21

  我就是 log 选手。感觉断点很麻烦很难去。。

• 資深大佬 : liaokylin2v

  其实很多写了好多年代码的程序员都不会断点，比如 php 程序员。

• 資深大佬 : xiangyuecn

  自我主观认为
  开发环境：
  log+断点 >> 仅断点
  log+断点 >> 仅 log
  断点 ≠ log

  生产环境：
  断点几乎不适用，只剩 log，通过开关控制输出级别

• 資深大佬 : chisj

  大部分情况下，log 比断点科学多了

• 資深大佬 : superchijinpeng

  优秀的代码是不需要断点的

• 資深大佬 : yeyu123

  print 大法好..谁用谁知道, 很多时候断点并没有 log 速度快

• 資深大佬 : Blacate

  log 大法好。。

• 資深大佬 : kuaner

  你写前端当然用断点很爽,他后端真不如打 log

• 資深大佬 : Sharuru

  不用劝，每个人都有自己的方式去做一件事情，可能别人有一套自己顺手的 debug 流程呢。

  反正 deadline 会给出答案（ doge

• 資深大佬 : ccraohng

  自己写的逻辑没理清，无头苍蝇乱飞。或者水平有限

• 資深大佬 : soki

  目测 + log

• 資深大佬 : jrtzxh020

  我们的后端跟离谱。一边写逻辑一边联调，一个接口调半天不通。每次领导说写好功能没有，就说已经写好了，在和前端调试。。。给他虐哭了

• 資深大佬 : KingHL

  我是后台开发，工作了五年，换了三家公司，极少见用断点调试的。

• 資深大佬 : aladdindingding

  你应该没见过每一行 log 把变量都打印出来的

• 資深大佬 : ddoocc

  断点只适合调很小很小的工程。

• 資深大佬 : cokyhe

  我用断点也是和同事学的，Go 语言，如果能知道问题大概出在哪，一般用 log，实在不知道咋出现的诡异 bug，才会用断点去咔咔咔

• 資深大佬 : ChangQin

  有种可能，你同事用的是 mac，然后没装 xcode-commend-tool 之类的东西，我之前没装一调试也崩溃，后来一弄就好来了，不过就跟前面老哥说的，打 log 都够了 – –

• 資深大佬 : collery

  我能说我现在这家公司，所有环境都没开端口么。 问就是不给开 。。 看代码真的密密麻麻的日志

• 資深大佬 : libotony

  主可以重点放在他效率低，至于他所使用的方法可以不去关心。一直以来都有个疑问，很多人都重度依赖“联调”，我认为他们对“代码写好了”是有误解的。当然有些特殊情况是需要联调的（防杠布丁）

• 資深大佬 : Navee

  主可以发点资料给他学一学
  在工作中，你这位同事绝对不是最后一个和你的认知差距很远的同行

• 資深大佬 : gp1136612050

  确实我也觉得是能力问题。有时候出问题，测试把场景或者现象一描述，我就能定位到是哪里出问题。有时候都不用 log 或者断点就直接改改完自测就好了。当然说的是改自己的东西。

• 資深大佬 : qwerthhusn

  请求接口后，Chrome F12 Network 找到请求 右击 Copy，Copy as cURL 复制出 curl 请求命令，然后可以重复在命令行调用
  发过去，让其自己去调，然后就可以安心划水了，全程不需要参与

• 資深大佬 : latteczy

  不用断点+1 。
  实际工作中能让你通过断点 /打 log 去调试的问题应该比较少，一般遇到问题通过 review 代码就能看出来。

• 資深大佬 : mengzhuo

  离了 Goland 我看你怎么断点，现网有问题怎么断点，会用个把工具就叽叽歪歪在网上声讨别人？
  而不是帮他搞一搞？提升团队能力？

• 資深大佬 : paoqi2048

  IDE 断点还好，命令行断点挺麻烦的

• 資深大佬 : xuzhzzz

  我们也是 kratos，我们不会是同事吧

• 資深大佬 : wentaoliang

  为啥不能用 log 。我反而觉得断掉调试效率不高。只有遇到复杂逻辑或者疑难问题才打断点

• 資深大佬 : zhouwei520

  debug 不是自测的么？联调看日志就行

• 資深大佬 : zhouwei520

  不都是联调才开始写代码么，手动滑稽

• 資深大佬 : amimo

  调试器可以让你在不修改代码,不重启应用的情况下,在任意位置打印 Log,这调试效率不更高么?

• 資深大佬 : 0x11901

  感觉还是编译 /执行的速度太快了的原因……我以前特别喜欢写 log，后来遇到了项目编译一次 20+分钟之后，我不仅断点要打 20 个，甚至 debugger 附加二进制调试……符号表……逆向……还不简简单单……

• 資深大佬 : newmlp

  断点只能解决一时的问题，只要日志加好以后出问题解决会方便很多，也许人家正忙着加日志呢，没空和你 debug

• 資深大佬 : gamexg

  断点的确快速简单，不过日志比较适合长期使用。

  选择哪个看个具体情况了，
  如果你同事打算尽量增加齐全的日志，方便以后再出问题时解决问题，那么这也是一种选择。

• 資深大佬 : csl1995

  C++选手
  开发阶段：
  log 直观清楚，可以解决一些比较明显的问题
  log 弄不清楚问题原因，用 GDB 兜底
  上了生产：
  生产的介质是不会给你开-g 的，所以只有日志
  出了问题基本就是根据日志分析复现问题

• 資深大佬 : lechain

  举个上提到的，生产介质不支持的情景例子

  如果做 turnkey 方案，客户平台遇到问题，只有靠印 log 怎么办？断点调试的场景比较局限，虽然定位问题比较快

  只能说各有优缺点，不能一棍子打死…

• 資深大佬 : xmge

  @sonyxperia 兄弟，同事是统一战线，永远不要站错队。

• 資深大佬 : greenlantern

  怕是用了断点能墨迹成三天

• 資深大佬 : yousabuk

  @0x11901
  对，各项成本综合最优方案，我编译 FPGA 程序 3 小时，敢随便编译吗？修改一下编译一下，两下还不得下班了嘛。就得完善仿真，各种仿真测试，最后再编译。
  碰到其他运行太方便了的程序，就可虑的少了，反正有啥问题跑起来就看到了，就懒得思考那么多了。

• 資深大佬 : 0987363

  以前用 c/c++的时候倒是离不开断点，主要还是指针越界问题。现在 go 的指针越界都能直接报错了，搭配上合理的 log，定位问题非常简单，完全不需要断点

• 資深大佬 : souths

  说实话，不熟悉才会调试的慢，马虎、觉得复杂更是因为不熟悉

• 資深大佬 : siteshen

  建议明确前后端的界限，前端只是把后端当个黑盒子使用，做前端的只能「建议」后端怎么做（反之亦然）。

  前端遇到问题，只需要告诉后端某个请求有问题，并提供 curl 命令、预期结果和实际结果。

  至于后端是用断点、log 、买个啄木鸟还是拍电脑，都与前端无关。

• 資深大佬 : 12tall

  单元测试不行吗

• 資深大佬 : p1gd0g

  有没有 requestID ？有没有定义错误码？有没有输出错误堆栈？

• 資深大佬 : sm0king

  后端 bug 不都是前端改的么？

• 資深大佬 : laball

  IDEA 就可以直接调试啊，VS Code 应该也可以。
  懒癌发作嘛？

• 資深大佬 : zichen

  如果接口文档定义的够清晰，前后端都照着接口开发，哪儿用的着花很长时间调试？好多开发问题，其实归根结底是设计问题。