跳至主要內容
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?

4563博客

全新的繁體中文 WordPress 網站
  • 首頁
  • 想知道现在还有多少人用 print 调试 debug?
未分類
2020 年 11 月 19 日

想知道现在还有多少人用 print 调试 debug?

想知道现在还有多少人用 print 调试 debug?

資深大佬 : keepwalk2020 3

在 IDE 功能日益强大的今天,还有多少人在用 print 调试程序?
大佬有話說 (100)

  • 資深大佬 : loadingimg

    我

  • 資深大佬 : anjianshi

    我

  • 資深大佬 : loading

    我
    后端 print
    前端 console.log

  • 資深大佬 : hendyzone

    我

  • 資深大佬 : zqx

    新手喜欢用 log,运行完了看输出。
    高手单步调试

  • 資深大佬 : levelworm

    一开始 print,解决不了的单步。

  • 資深大佬 : Jirajine

    解释型语言的调试器都可以 eval 任意表达式,编译型语言很多就不行,那就还是需要 print 。

  • 資深大佬 : ConradG

    我
    IDE 再强大,也没法在测试环境用

  • 資深大佬 : ciaoly

    打日志找 bug 不是很正常吗?

  • 資深大佬 : laminux29

    开发环境、临时测试环境、正式环境,这三种环境,测试使用的工具与方法,肯定会有不同。

    但无论如何,用 print 之类的来 debug,是有点不专业。

  • 資深大佬 : opensail

    用啊,fprintf,qdebug()啥的

  • 資深大佬 : unixeno

    生产环境你也打不上断点
    微服务下,一个请求调 100 个服务的那种,不靠 print 你也没法调

  • 資深大佬 : jdhao

    高手用几个 print 大概就能找到问题所在,然后尽力复现就行了。。。

  • 資深大佬 : heiheidewo

    多线程时你去单步试下?

  • 資深大佬 : salife

    用 log 替换 print 吧,编程规范里面不知道有没有准用 print

  • 資深大佬 : lkhao1231

    dev 直接 remote debug
    非 dev 的测试环境 查 log

  • 資深大佬 : wty

    最近搞 nrf52832,协议栈不允许暂停,敢打断点程序就直接崩给你看,,,,快搞吐了。

  • 資深大佬 : anguiao

    @salife 编程规范也只能管提交上去的代码,自己本地怎么调试,还真管不着。

  • 資深大佬 : est

    IDE 就能重现的 bug 也好意思叫 bug ?

  • 資深大佬 : DoctorCat

    print 一堆 fuck,分分钟迅速解决掉问题

  • 資深大佬 : binux

    @zqx 真正的高手都用 print,因为他们知道在哪打 log

  • 資深大佬 : msg7086

    生产环境上没办法单步 debug,除了打 log 没别的办法。
    本机一般用不上单步,打打 log,甚至有时候写个 test case 就能调通了。

  • 資深大佬 : yh6788

    我,很灵活啊。

  • 資深大佬 : ysmood

    成长阶段一般都是 print 到 break point 再到 print,不过高阶的 print 已经和最开始时的很不一样了。比如某个断点一次运行会被调用几百次且难以写条件断点时 log 很可能是更效率的 debug 方式,再比联调分布式布式系统也难以用断点, 典型的项目可以看 open tracing 。

    我个人感觉只有调试非常简单的东西断点才会用断点。栈深点的算法用断点对普通人来说心智负担都很大,可能都会用动画级别的 log 来辅助大脑理解了。

  • 資深大佬 : Mutoo

    现在前端调试器除了有 breakpoing 还有 conditional breakpoint 和 logpoint,后者是 print+breakpoint 的杂交。还可以直接在代码里加 debugger; 进行断点。

  • 資深大佬 : raaaaaar

    都部署到环境上去后,上是怎么 print 的? log 设计好,不比 print 好多了

  • 資深大佬 : waruqi

    一直都是 print,已经快 10 年没用 ide 调过了

  • 資深大佬 : Mithril

    条件断点有多卡你试过么。。。分分钟给你把 bug 卡没了。。。。
    多线程来回跑的时候全靠 print 多条关键路径来还原场景,这种情况下要么 print,要么写好 if 再往里面写点垃圾代码打断点,本质上还是 print

  • 資深大佬 : yjxjn

    @salife 肯定不能用啊,sonarlint 以及 spotbugs 写了 print 都要警告的。

  • 資深大佬 : Nich0la5

    这么多人用 print ?按规范不应该用 logger 吗

  • 資深大佬 : Mithril

    @yjxjn 用来 debug 的代码又不会提交上去,跟 lint 有啥关系。
    @Nich0la5 debug 用的,又不是在产品上挂 print 。而且有的 logger 会有缓存,多线程情况下并不一定能保证输出的 log 顺序是正确的。

  • 資深大佬 : Nich0la5

    @Mithril 使用 logger 可以把线程信息写进去,一次封装好后面就不愁了,debug 完把日志级别一改就完事。
    而且大型项目都有统一的 logger 定向位置,用 print 是拿不到日志的

  • 資深大佬 : IgniteWhite

    我……主要是菜

  • 資深大佬 : Mithril

    @Nich0la5 说的不是同一个事。debug 用的 log 肯定是有的,我们说的是你在发现 bug 以后,本机调试过程中使用 print 而不是 IDE 本身的 debuger 。
    而且当你想要看到多个线程的代码在某一段时间的执行是如何互相影响时,光是记录线程 ID 是没什么用的。你还要保证这些线程的 logger 共用缓冲,然后 logger 没准就在里面加了个锁,到时候你的线程状态和出 bug 的时候就不一样了。
    当然你可以靠时间去排个序,不过这么折腾为啥不直接加个 print ?

  • 資深大佬 : Hconk

    一般来讲能用 IDE 调试的 bug 就尽量用 IDE 的 breakpoint, condition breakpoint, 包括尽可能用 vsc 的 remote ssh 调试, 但是在分布式集群上的程序 bug,没办法直接上 IDE 去调试,最后还是先 log 一些日志,如果能定位到问题就直接解决,如果遇到比较麻烦的 bug 还是会想办法在 IDE 下复现调试。

  • 資深大佬 : MOETAN0

    我,在循环中观察变化,print/日志是最顺手的

  • 資深大佬 : RickyC

    php 用 print_r()

  • 資深大佬 : phpxiaowangzi

    前端 console.log 后端 var_dump

  • 資深大佬 : bear2000

    没有断点调试的情况下就用 print

  • 資深大佬 : radiocontroller

    没有人比我更懂 print !

  • 資深大佬 : edk24

    后端 trace(),js 偶尔 trace

  • 資深大佬 : annielong

    log 有时候记录太多了,不好查,还是 print 简单明了

  • 資深大佬 : weyou

    同样经历 print->断点调试->print 的阶段,前两个阶段在学校完成的,工作以后就没再用过断点调试。另外 log 和 print,对于我来说这两者没有本质区别,没啥好争论的。

  • 資深大佬 : Molita

    用 python 话 用 pdb trace,挺好用的

  • 資深大佬 : czdpzc

    让我想到这个图
    https://sm.ms/image/eU8a7fPcBT49Rr3

  • 資深大佬 : dcty

    有时候一断点,bug 它就不出现了。

  • 資深大佬 : onice

    我就是啊。

  • 資深大佬 : wlfeng

    一般本地开发用 debug,部署到服务器上就看 log,所以写代码的时候怎么打 log 也是很讲究的

  • 資深大佬 : S0on

    我

  • 資深大佬 : northisland

    不得已情况下,会这么干。。。

    经常是接手一块老功能,大概是 java 或 python 调 c++的动态库。。。

    写个类似的测试用例(输入正反序列化一下)的时间,可能改动都实现 8 回了。

    但是有条件还是 ide 香。

  • 資深大佬 : Winrey

    我我我! [举手

    可以试试 Sentry 其实

  • 資深大佬 : northisland

    都是实现需求,print + LOG 硬莽,还是 ide 见招拆招,都差不多。

  • 資深大佬 : sidegem

    比起 ide 的调试功能,我觉得 print 更好用点

  • 資深大佬 : hikkikuma1991

    我。。。我都是写分布式程序的,几千台机器上调试除了看 log 没有别的好办法= =

  • 資深大佬 : newmlp

    @Nich0la5 不都是一回事么

  • 資深大佬 : Lawskiy

    debug ros node ? 我觉得还是 print 简单点

  • 資深大佬 : lychs1998

    怎么方便怎么来。

  • 資深大佬 : itskingname

    给你讲,我老师,在 macOS 上面安装 Windows,然后在 Windows 里面跑 Visual Studio 运行 VB,他调试的时候,用 dialogbox,用报警对话框来显示变量的值。比 print 可牛逼多了。[狗头]

  • 資深大佬 : xloger

    我我我,Android 开发,用 Debug 跑一次增量大概第一次三四分钟,之后一分钟吧,直接运行十秒不到,换你你选哪个…

  • 資深大佬 : Deepseafish

    是时候祭出这张图了 想知道现在还有多少人用 print 调试 debug?

  • 資深大佬 : Rekkles

    连 debug 都能区分优越感 想知道现在还有多少人用 print 调试 debug?

  • 資深大佬 : wangyzj

    我!

  • 資深大佬 : redtea

    java 用 print 有性能问题,不知道 python 有没有。

  • 資深大佬 : THESDZ

    手段而已

  • 資深大佬 : aneostart173

    print 调试不可替代。

  • 資深大佬 : faceRollingKB

    不如调查一下,有多少人完全不用 print 或者 console.log ,不知道一只手能不能数的过来

  • 資深大佬 : est

    @redtea 经典问题

    https://stackoverflow.com/questions/918359/my-python-program-executes-faster-than-my-java-version-of-the-same-program-what

  • 資深大佬 : est

    好像贴错了。反正记得有个问题是 python 的 print 带了 buffer,java 的没带。然后每次调用就很浪费。

  • 資深大佬 : nuk

    一般在 gdb 里 print,加 print 重新编译要太久太久,而且太多比较难复现。
    比如。。在很偶然的情况下。。我们自己实现的 map 的 hash 值居然会算错。

  • 資深大佬 : vipppppp

    代码有很多异步或者回调的时候,打断点也不一定比 print 来的有效

  • 資深大佬 : goodboy95

    单步调试用起来爽,但正式环境下还是要 print,不要问为什么不搞远程调试,问就是正式服要求高安全性。

  • 資深大佬 : reus

    所有涉及超时的程序都不能打断点,只能靠打印信息,这是本质问题,工具再强大,也改变不了客观规律

  • 資深大佬 : yolee599

    用自己写的 log 工具,可以自定义 level,可以用一句宏定义关闭

  • 資深大佬 : crclz

    我觉得两种都得会。

  • 資深大佬 : crclz

    Don’t underestimate the value of printf().
    —- stanford cs140 课程

    http://web.stanford.edu/~ouster/cgi-bin/cs140-spring20/pintos/pintos_10.html

  • 資深大佬 : darknoll

    @zqx 说反了

  • 資深大佬 : iFollow

    本人调驱动只会 printk ……

  • 資深大佬 : paoqi2048

    我用 print 还有 log

  • 資深大佬 : dbow

    现在遇到的 bug, 都很奇特, 时有时无, 复现困难, 只能用 print

  • 資深大佬 : killeder

    嵌入式,printf 是最常用的调试手段

  • 資深大佬 : DoUSeeMe

  • 資深大佬 : across

    看到这种问题,我只觉得论坛平均技术水平断崖式下跌····

    你能想象电子行业的人出来问:还在人拿锤子修理机械么?

  • 資深大佬 : Felldeadbird

    一直用 print 啊。虽然知道有更好的工具。但是习惯了,很难改。

    其次,生产环境我一样 print 。 不过我会上一些参数来调试。不影响正常业务运作。

  • 資深大佬 : iSecret

    不,我写的程序没有 BUG 。(狗

  • 資深大佬 : cholerae

    内核和驱动调试不用 printk 怎么整,很麻烦的

  • 資深大佬 : walsh

    高手都是徒手看 dump(狗头)

  • 資深大佬 : shpkng

    我

  • 資深大佬 : acmore

    Print 和 Debugger 都是工具和手段,怎么快怎么来,通过二分迭代 + Print 就能迅速定位的还要走单步调试就略显迂腐了,一般在 Context 比较庞大的情况下用 Debugger 效果才会更加显著。

  • 資深大佬 : sr0miao

    me

  • 資深大佬 : lzyliangzheyu

    上仿真器(逃

  • 資深大佬 : sockpuppet9527

    我,除非没有 printf/dump 只能用 gdb 🙂

  • 資深大佬 : SomeoneElseChild

    单纯不想按 F9

  • 資深大佬 : paloalto

    昨天,有俩个年轻同事来找我,说:马老师,线上网页打不开,发生甚末事了?
    我一看!哦,原来是线上环境有 bug 。
    传统 debug 讲究的是接化发,我“啪”就发出一串 print,很快啊!我全部防出去,防出去了啊。防出去以后,自然是,传统 debug,点到为止。
    这个 bug 不讲码德,来,骗,来,偷袭,我 30 多岁的,老码农。这好吗?这不好!
    我劝,这个 bug,耗子尾汁,好好反思。以后不要再犯这样的聪明,小聪明。
    编程开发,要以和为贵,要讲码德,不要搞,窝里斗。谢谢朋友们!

  • 資深大佬 : lhx6538665

    递归 循环 这种断点已经很难用了
    鼠标移动事件 断点根本不能用
    一切需要精确时间的操作,使用断点就是错误的做法

  • 資深大佬 : sampeng

    只有无奈的情况才单点。。。print 是最好的调试方式。。。。你单点调试一轮,我已经解三 bug 了

  • 資深大佬 : Macv1994

    前端 console.log()
    后端 print
    手动滑稽

  • 資深大佬 : richzhu

    我

  • 資深大佬 : VeryCB

    我

  • 資深大佬 : tu9oh0st

    我

  • 資深大佬 : ezleeinfo

    你提这个问题有没有想过,用什么是解决什么问题的吗?解决问题就行了,没必要把程序员似的优越感弄出来。

文章導覽

上一篇文章
下一篇文章

AD

其他操作

  • 登入
  • 訂閱網站內容的資訊提供
  • 訂閱留言的資訊提供
  • WordPress.org 台灣繁體中文

51la

4563博客

全新的繁體中文 WordPress 網站
返回頂端
本站採用 WordPress 建置 | 佈景主題採用 GretaThemes 所設計的 Memory
4563博客
  • Hostloc 空間訪問刷分
  • 售賣場
  • 廣告位
  • 賣站?
在這裡新增小工具