Re: [討論] 同一個程式碼段落超過一人以上在修改

※ 引述《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 跑好多窗口的差別
前提是介面設計合理不亂七八糟就是

--
起來，不願做光棍的人們，把女孩的清純築成我們新的長城
蘿莉控們到了最危險的時候。每個人被迫著發出最後的吼聲。
起來！起來！起來！
我們萬眾一心，往著女孩的裙底，前進！
往著女孩的裙底，前進！前進！前進！進！

--

對自己的 code 主張所有權通常是個好跡象 比較不會始亂終棄，也比較認同權力帶來的責任 不過你們公司該怎麼做比較順就不一定了 「誰管什麼東西」其實是個政治問題 - 某個 class / 檔案全部你管，你認同嗎？你同事跟主管認同嗎？ - 怎麼決定是哪幾個 class / 檔案？ - 其他人怎麼知道是哪幾個 class / 檔案？ - 所有該放進去的邏輯都由你來改，不管案子是不是你的，願意嗎？ - 或每次要改之前都先跟你說一聲？ - 如果其他人送 MR，你不會因為自己忙就都放個兩天再來看嗎？ - 怎麼執行？怎麼避免其他人 merge？（Gitlab / Github 都以 repo 切分） - 整個 repo 你管 - 你有辦法處理（或至少認識）整個 repo 的流通業務嗎？ - 處理 MR 速度能跟上同事寫 code 的速度嗎？ - 全部拆掉 - 要花多少人力多少時間 - 該拆成什麼形狀？誰決定？整合誰管？（對，又冒出個空 owner） - 如果業務在人之間流動，切的形狀要跟著改嗎？ - 或者...其他？ 最大的問題： - 能說服有決定權的人認同「解這題付出的成本，值得」嗎？ - 能說服業務在客戶 / stakeholder / 大老闆面前幫你坦嗎？ 軟體工程很大一部分其實是要處理人的問題 以人為主的問題其實就是政治問題 但寫 code 的人(包括我)又很都自覺討厭處理政治問題...

感謝... Orz