之前接同事写的部分
写法和习惯什么的会有不一样的地方
要花点时间才能看懂
trace到某个程度才能理解设计目的
但比起真的设计架构或算法之类的
单纯是理解别人当初想要表达什么
在这种时候会倾向直接问吗？
还是 Git 翻一下找点线索
这种不太需要讨论
回想一下就出来的问题，是不是直接问比较快？
但有时候问好像会被骂说“啊怎么不先翻 Git”
结果变成 Git 找不到之前不太敢问
但有时候改动真的很少
一整包里面只改个 func
但又怕改了整包爆掉只好整个看一遍
明明只是改个 func 还要看一堆东西
是我太菜还是吗
各位大神平常都怎么做？

有可能整包爆掉的改动我不认为叫“只是”改个func

func 里面一堆副作用一堆参数要改之类的，也不至于整包爆掉啦，但其他地方就会失效，少改个属性就会有功能冲突这种

copilot

客气点直接问

设停损点找个 15 分钟找不到就问，不然找太久一样会被说没产出问的时候表明你找过了什么，思路是什么，上别人知道你有先做功课即可

嗯 太菜

依照高内聚低耦合的标准,FUNC会造成的影响应只侷限于内部

15分钟这个停损点不错，看来我之前停损点设太高了。但有时候怕的是“以为懂了但有漏掉”，只好再多看一下无限Loop

除非团队的Git规范执行很好，不然应该看文件再问人

git blame git log 先看看吧。如果 commit 没乱下log 有好好写的话

都出社会了应对进退自己学 别上来问启智问题

设时间限制是一条，另一个是让人知道你已经读过什么了

你的问题根本不是要不要看git。要了解程式码，或把关程式码品质的方法还很多。但根源是你们互相不爽彼此而已。帮别人看一下程式，10分钟没那么难。

不是自己写的程式不要想全懂，请根据自己的目的性缩小到自己需要看的区块即可

看不懂问人是最快，不过如果被嫌大概问的是蠢问题

如前面推文，建议你先自行研究一小时，还是卡关再问人问问题时，告诉对方你做了哪些调研、目前阶段理解到哪切忌伸手牌，接你问题的人通常心里会有个评断是你的学习心态到哪，再决定他要怎么方式应对你看最新的就好，个人觉得看旧代码帮助不大。题外话，与时俱进，AI工具在现今大码农时代一定要善用掌握

丢 gpt 问

原PO要先有自己的立场，例如说这段code我觉得功能是XXX，但我没有把握，所以想问学长这段code实际的功能

先翻一下再问 最好不要什么都没看过没翻就伸手就跟发文不爬文一样低耦合是理想 现实是意大利面

git 只是查出什么时候改、为什么改而已吧不过有功能刚加进去都会写功能起源

直接问gpt

爱乱骂的同事真的很烦

读git是要看他的心路历程和历史脉络吗, 我们都是找战犯才会去看git XD

你看过再问阿==...

读git==找战犯+1

除了要做功课，发问前先想好要怎么描述你的问题。一个问题只解决一件事，一股脑把问题丢出来，只会让被问的人搞不清楚你的问题。也要先根据你的假设准备延伸话题，才能更进一步讨论。另外也要看同事是那种人，遇到19楼那种就看git就好XD

直接问

千万不要直接问"我不懂"

改个func整包爆掉？所有完全没有UT吗？是我就直接问啊XD

1.看文件 2.看注解 3.问GPT 4.赶紧问人 绝对没有看Git记录这项

或许只是焦虑问题，可以试着先处理情绪，才有办法综观怎么做

直接问

说这段写得很烂 叫他过来解释

我会先看啦，很重要的东西会问

设停损点+1

你都到处翻了，加减判断一下 codebase 的水准吧，不过逻辑怪怪的那种 code 追的再深都...只是在浪费精力

先看15-30分钟 超过就问

那种动一下别的地方莫名失效啊、冲突啊的 code，UT、IT该抓出来啦，抓不出来那就是当初就没好好规划好好写的，就换个方式请其他擅长的同事帮忙处理，然后自己去找看的懂的地方改，找对的位子坐

本来就要先看过吧 不然你要怎么问问题 之后你也才有机会懂这块最后变专家啊...

不要遇到问题就想问别人 这是坏习惯工作上最讨厌这种把自己工作推给别人的同事如果思考程式码对你而言很痛苦 那你可能不适合这个职业

有可能整包爆掉的改动我不认为叫“只是”改个func

func 里面一堆副作用一堆参数要改之类的，也不至于整包爆掉啦，但其他地方就会失效，少改个属性就会有功能冲突这种

copilot

客气点直接问

设停损点找个 15 分钟找不到就问，不然找太久一样会被说没产出问的时候表明你找过了什么，思路是什么，上别人知道你有先做功课即可

嗯 太菜

依照高内聚低耦合的标准,FUNC会造成的影响应只侷限于内部

15分钟这个停损点不错，看来我之前停损点设太高了。但有时候怕的是“以为懂了但有漏掉”，只好再多看一下无限Loop

除非团队的Git规范执行很好，不然应该看文件再问人

git blame git log 先看看吧。如果 commit 没乱下log 有好好写的话

都出社会了应对进退自己学 别上来问启智问题

设时间限制是一条，另一个是让人知道你已经读过什么了

你的问题根本不是要不要看git。要了解程式码，或把关程式码品质的方法还很多。但根源是你们互相不爽彼此而已。帮别人看一下程式，10分钟没那么难。

不是自己写的程式不要想全懂，请根据自己的目的性缩小到自己需要看的区块即可

看不懂问人是最快，不过如果被嫌大概问的是蠢问题

如前面推文，建议你先自行研究一小时，还是卡关再问人问问题时，告诉对方你做了哪些调研、目前阶段理解到哪切忌伸手牌，接你问题的人通常心里会有个评断是你的学习心态到哪，再决定他要怎么方式应对你看最新的就好，个人觉得看旧代码帮助不大。题外话，与时俱进，AI工具在现今大码农时代一定要善用掌握

丢 gpt 问

原PO要先有自己的立场，例如说这段code我觉得功能是XXX，但我没有把握，所以想问学长这段code实际的功能

先翻一下再问 最好不要什么都没看过没翻就伸手就跟发文不爬文一样低耦合是理想 现实是意大利面

git 只是查出什么时候改、为什么改而已吧不过有功能刚加进去都会写功能起源

直接问gpt

爱乱骂的同事真的很烦

读git是要看他的心路历程和历史脉络吗, 我们都是找战犯才会去看git XD

你看过再问阿==...

读git==找战犯+1

除了要做功课，发问前先想好要怎么描述你的问题。一个问题只解决一件事，一股脑把问题丢出来，只会让被问的人搞不清楚你的问题。也要先根据你的假设准备延伸话题，才能更进一步讨论。另外也要看同事是那种人，遇到19楼那种就看git就好XD

直接问

千万不要直接问"我不懂"

改个func整包爆掉？所有完全没有UT吗？是我就直接问啊XD

1.看文件 2.看注解 3.问GPT 4.赶紧问人 绝对没有看Git记录这项

或许只是焦虑问题，可以试着先处理情绪，才有办法综观怎么做

直接问

说这段写得很烂 叫他过来解释

我会先看啦，很重要的东西会问

设停损点+1

你都到处翻了，加减判断一下 codebase 的水准吧，不过逻辑怪怪的那种 code 追的再深都...只是在浪费精力

先看15-30分钟 超过就问

那种动一下别的地方莫名失效啊、冲突啊的 code，UT、IT该抓出来啦，抓不出来那就是当初就没好好规划好好写的，就换个方式请其他擅长的同事帮忙处理，然后自己去找看的懂的地方改，找对的位子坐

本来就要先看过吧 不然你要怎么问问题 之后你也才有机会懂这块最后变专家啊...

不要遇到问题就想问别人 这是坏习惯工作上最讨厌这种把自己工作推给别人的同事如果思考程式码对你而言很痛苦 那你可能不适合这个职业

可以问，但是要先自己吸收内化过，不能只是当个伸手牌

重要的工作就直接问，其他的就看完再问。如果对方连重要的工作都不愿意直接回答，那可以考虑一下是只有这个人是这样,还是整个职场环境都这样.

先看过再问，直接问是有扣打的，遇过那种每次有问题都直接问的，明明对话纪录都找得到，或者git有其他地方也在用却来问怎么用的真的会疯掉，做事一直中断就饱了

公司程式不问怎么知道？ 很多都是技术债搞出来的甚至用法都有问题，反正能动就没人管

有些鸡巴同事就算你有认真思考再问他还是态度很差这几楼有几个看起来就是那种同事

https://reurl.cc/lQjl1Y 第八点。都廿几年的老文了(烟

直接问 工作上印度人文件都不看 直接开会问满问爽脸皮厚真的是无敌 亚洲人太爱面子

傻逼会跟你说生成式AI，但我会跟你说就是天份跟经验而已

推87F 中肯

问ai

都会先看过后再问喔 重点不是这次快不快 重点是如何维持长期团队合作 而不查就问会毁掉你自身信用