之前接同事寫的部分
寫法和習慣甚麼的會有不一樣的地方
要花點時間才能看懂
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

都會先看過後再問喔 重點不是這次快不快 重點是如何維持長期團隊合作 而不查就問會毀掉你自身信用