※ 引述《ManGo1012 (ManGo)》之銘言： : 如題，好奇想問一下 : 基本上在有正常版控的條件下 : 這種情況是不是根本不該發生？ : 尤其是開發周期尚未結束，沒有要交接 : 每個人負責的部分 : 最小單位應該直接用檔案切開 : 一個檔案只會有一個人在維護、push code 不一定，可能合理可能很 suck 要看規模、工作流程、有沒有人控場、默契 自己的經驗是分工做得好的地方通常會定義 ownership 「這塊 code 是拎北/拎母的，要改要先問」 積極的 owner 會對 code 要長成怎樣有明確的想法並前進 消極（但合格）的 owner 會讓 code...好好活著不要被亂改 甚至有時候不是明文規定，而是「啊，他對這段 code 最熟」 然後就自然演化成「他是 XX 系統扛壩子」 owner 的權限怎麼貫徹就到處都不一樣了 有的是如同你說的，只有特定人可以改某個檔案/repo 有的是同事可以亂發 PR / MR，但是只有 owner 可以 merge 這種就常常在解衝突，有時候頻率跟吃太陽餅掉屑差不多 一但有不只一人改同一堆 code，就會開始有知識的邊界的問題 怎麼知道哪段 code 在幹嘛，有什麼眉角，跟什麼外部系統有互動 又是哪個客戶提這種雞掰需求所以看起來雖然很怪但是不能改 在沒有明確定義 owner 的地方，這種事情會變成吵架的火種 （有定義的地方大概就會走一個「我要告老師(owner)啦哼哼哼」的路線...） 所以有類似制度的地方很多會做 code review，除了看同事 code 寫得如何 也很大成分是確保同事間知道彼此在做什麼，不用很熟，依稀有印象就可以了 「幹，這段 code 這麼鬼」 「我想起來了，有看過 MR，客戶A有這個雞掰需求...靠北這 MR 你發的耶」 「...幹我自己寫的自己忘了」 另外是 MR / PR 看多之後同事彼此的 code 會越來越像 之後改彼此的 code 會容易一點，這需要時間磨合就是 （但還是常看到因為「你這 code 寫好爛」而吵架的 軟體工程裡面最 suck 的終究是人類這個要素....） BTW，MR / PR 跟其他所有的同事互動一樣 會展現出誰是雞掰郎，誰是會把事情都整理好再交出去的好孩子 回過頭，你碰到的問題不是「很多人改同一段 code」 而是「ownership 不明確」 然後你就覺得「他國軍艦駛入我國領海，幹林老師」 只是也可能想像出各種讓「定義 owner」很麻煩的理由就是 事情只要扯到人跟業務就是各種 suck 而大部分的 code 是人為了業務寫的 suck \(^_^)/ suck \(^_^)/ suck : 即使是超龐大Class : 也應該儘量切成不同小Class : 然後利用繼承、封裝、多型分工出去才對 切小的好處 - 對腦袋比較輕鬆，一次不用載入這麼多 code - 權限設定比較容易 切小的壞處 - 想想 java 的 stacktrace 為什麼會這麼長一串 這也是程度問題就是... 一千行的 class 也許 suck 也許合理，要看狀況而定 一萬行的 class 基本上很 suck，不過能不能重構則是另一個問題（泣 另外對外面的人來說，這有點單一窗口 vs 跑好多窗口的差別 前提是介面設計合理不亂七八糟就是 -- 起來，不願做光棍的人們，把女孩的清純築成我們新的長城 蘿莉控們到了最危險的時候。每個人被迫著發出最後的吼聲。 起來！起來！起來！ 我們萬眾一心，往著女孩的裙底，前進！ 往著女孩的裙底，前進！前進！前進！進！ -- ※ 發信站: 批踢踢實業坊(ptt-web.org.tw), 來自: 218.166.77.235 (臺灣) ※ 文章網址: https://ptt-web.org.tw/Soft_Job/M.1679371712.A.067 ※ 編輯: GALINE (218.166.77.235 臺灣), 03/21/2023 12:17:14