[討論] 不確定的地方要看 Git 還是直接問？
之前接同事寫的部分
寫法和習慣甚麼的會有不一樣的地方
要花點時間才能看懂
trace到某個程度才能理解設計目的
但比起真的設計架構或演算法之類的
單純是理解別人當初想要表達甚麼
在這種時候會傾向直接問嗎？
還是 Git 翻一下找點線索
這種不太需要討論
回想一下就出來的問題，是不是直接問比較快？
但有時候問好像會被罵說「啊怎麼不先翻 Git」
結果變成 Git 找不到之前不太敢問
但有時候改動真的很少
一整包裡面只改個 func
但又怕改了整包爆掉只好整個看一遍
明明只是改個 func 還要看一堆東西
是我太菜還是嗎
各位大神平常都怎麼做？
-----
Sent from JPTT on my Google Pixel 7 Pro.
--
有可能整包爆掉的改動我不認為叫“只是”改個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
39
Re: [討論] 資工系畢業不會git很扯嗎我也是資工畢業der，第一份工作在趨勢研替三年，沒用過git都在用p4v 第二份在M社做Skype for Business，還是沒用到git，後來轉組到Teams，終於有git惹， 但用了不到半年就轉到G社，又回到沒git的環境惹。 現在在另一間FANNG，依然沒有用git。 會不會git，很重要嗎？QQ24
Re: [討論] 資工系畢業不會git很扯嗎說到這個git吼 我有經驗啦 想當初 我在台灣幹第一份工作的時候 也是不會git阿 然後R team裡面有一個台科大還是北科大資工的 都30幾歲了講話還很嗆 我說我沒用過git 他說: 蛤 你們學校沒教喔? 台清交是教甚麼的? 媽的 嗆成這樣 我就去學了git 阿就是版本控制而已啊23
Re: [討論] 靠submit紀錄來除錯是一個不好的習慣嗎^^^^^^^^^^^^^^^^^^^^ 有一種狀況是這樣 軟體架構設計不良,高耦合,導致原本要做A功能,卻影響到B功能, 但不好追是哪一行程式造成問題. (開發經驗久的人應該都遇過這種情形) 這種時候我們會需要追是從哪個版本開始壞掉3X
Re: [討論] 靠submit紀錄來除錯是一個不好的習慣嗎^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 程式會造成"軟體架構設計不良,高耦合,導致原本要做A功能,卻影響到B功能," 大部份是git造成的 不知道吧？那這樣算不算"無知"？ 想看看git branch來merge去是不是都是一坨屎在那branch來merge去9
[請益] git rebase的問題各位好 本人在近來在公司需要將專案中某個pull request的commit統合成一個 下圖為pull request，本公司用的是bitbucket 我看了一些網路教學和youtube，仍然想不出解法。我的做法如下：![[請益] git rebase的問題](https://img.youtube.com/vi/8j0H6urZ-bU/mqdefault.jpg "[請益] git rebase的問題")
9
Re: [請益] 大型Git版本庫的備份或替代方案: : 用法跟 git 很類似，但是就是拿來備份大的檔案。 : 更精確的說是 snapshot 檔案，每個版本類似 git 的 commit : : 有支援，可以參考![Re: [請益] 大型Git版本庫的備份或替代方案](https://git-lfs.github.com/images/facebook-promo.png "Re: [請益] 大型Git版本庫的備份或替代方案")
9
[問卦] git commit是不是能紀錄工作狀態？如題 4這樣的 因為小弟時間感很差 常常會好幾天的記憶都混在一起 所以對於工作進度沒什麼概念 有時候覺得自己每天都在混，拖很久才把工作完成8
[問卦] git要怎麼用才高端？本肥文組菜雞工程師啦 只會git push, git pull 但我看同事各種花式操作指令 Git到底要怎麼用才顯得高端？ --6
Re: [討論] 靠submit紀錄來除錯是一個不好的習慣嗎我覺得抓bug要看經驗 不同情境有不同的使用方式 像是從git log抓bug，使用git blame指令 是俗稱的抓戰犯 通常用在追踨bug追到一段code4
[請益] GitLab備份還原後資料總大小不一致請教一下版上前輩 因為VM作業系統為 ubuntu 18.04，需要升級以提升安全（買ESM就可以升級嗎？) 因此打算將VM上的 GitLab 服務改在新的一台 ubuntu 22.04 VM上面跑 但是將 GitLab CE 15.10.1製作的備份還原到另一台VM後， 發現 git-data/repositories 資料夾的大小少了20G左右