PTT評價

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

看板Soft_Job標題[討論] 同一個程式碼段落超過一人以上在修改作者
ManGo1012
(ManGo)
時間推噓28 推:28 噓:0 →:67

如題,好奇想問一下
基本上在有正常版控的條件下
這種情況是不是根本不該發生?
尤其是開發周期尚未結束,沒有要交接

每個人負責的部分
最小單位應該直接用檔案切開
一個檔案只會有一個人在維護、push code
即使是超龐大Class
也應該儘量切成不同小Class
然後利用繼承、封裝、多型分工出去才對

因為我常遇到為了rebase
需要一定程度搬動到別人的code
可能就是往前往後個幾行
或是在相同段落內插入幾行自己的
這種情況是否就代表分工不明確、模組化沒做好?

是否有甚麼情況是讓這件事可以被接受的
還是這種情況本來就家常便飯
單純我太龜毛而已XD

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.80.132 (臺灣)
PTT 網址

abccbaandy03/20 13:24這就跟隕石開發一樣阿,不應該,但大家都習慣了

abccbaandy03/20 13:24只要沒天兵直接蓋過去就好了

loadingN03/20 13:25自己解conflict啊

如果我解完我的conflict之後,讓你寫的某個function多了幾行,就算功能不影響,但這件事不會怪怪的嗎

brucetu03/20 13:48那些被你搬動的code就是比你早commit啊 那就是既有程式碼

brucetu03/20 13:48了 三分鐘前才commit進去的code 跟上個月寫好commit進去

brucetu03/20 13:48的code有什麼分別嗎

acgotaku03/20 13:54就很常見吧 誰晚進去 誰就rebase 測試寫好不要影響對方

y246810121603/20 13:57你說的就是svn的概念,就是因為不好用才慢慢改成 git

y246810121603/20 13:58你能想像為了改一個檔案等一個星期的痛苦嗎?

leakleak03/20 13:59很正常吧 站會聊一聊不就解決了

WaterLengend03/20 14:33那就代表那段邏輯還沒完善而已啊

as2304124803/20 14:45為何會很常遇到呀,分工通常是每個人會開發不一樣 c

as2304124803/20 14:45omponent ,還是剛好都一直碰到共用的地方?

目前算是模組化沒切好,所以灰色地帶太大了

surimodo03/20 14:59猜拳決定誰處理衝突

touurtn03/20 15:08單元測試覆蓋到就會安心點

leolarrel03/20 15:33理論上然樓主說的算對,但現實上,跟你合作的人,程式碼品

leolarrel03/20 15:34質就是無法預期.要是他又是你客戶公司的正職RD,那你能

leolarrel03/20 15:35怎樣? 跟你的客戶PM抱怨說你們家誰誰誰寫code很髒??

leolarrel03/20 15:35或是你自己開公司當最高的甲方

kurtsgm03/20 16:17啊版控不就是要處理這件事的嗎?

quickey03/20 16:38丟給chatgpt請他優化就好

Petyr03/20 17:38這不是很正常的事情嗎 版控某方面也是預防被蓋過去啊

vi00024603/20 17:55不正常耶 代表每個人負責的功能是互相影響的

wulouise03/20 18:27就沒切好,檔案改了又沒查,你UT不給他過不給merge就好

jej03/20 18:35看起來怪怪的 這是大家都維護同一個branch的意思嗎?

jej03/20 18:36如果不同branch 就是給衰小的人merge

jej03/20 18:38本文中提到的rebase是指你們上到master很頻繁嗎?

happy864903/20 19:17開發專案照檔案切負責範圍???第一次聽到,長見識了

我的意思不是這樣XD

gigayaya03/20 19:29感覺你們該做的是切branch來最小化這個問題

siriusu03/20 19:40衝突很常見啊,尤其團隊規模一大自然避不開

answermangtr03/20 20:18你要PR前本來就要rebase 跟是不是branch有啥關係

answermangtr03/20 20:18

Lipraxde03/20 20:28版本控制讓多人對同一段 code 貢獻變得可能,衝突時解

Lipraxde03/20 20:28conflict 很正常,而往往問題不是在 conflict,而是在

Lipraxde03/20 20:28有人 code 寫太爛

其實我問的就是多人對同一段code貢獻這件事,我總覺得怪怪的

answermangtr03/20 20:28會容易改到同一段code或同一個function是你們本身

answermangtr03/20 20:28架構上就有問題 沒做好solid吧

howardsun03/20 21:44超正常啊,公司一個人只負責特定的程式碼,會滿危險的

howardsun03/20 21:44,沒辦法互相 cover

wwndbk03/20 22:48vscode live share

SHANGOYANYI03/20 22:59你們的系統可能缺乏「架構」

umum2903/21 00:24正常 尤其有兩三個長期專案在跑時 常會影響其他人

umum2903/21 00:29其實這也是CICD的精神 一但commit就要做integration test

umum2903/21 00:30就算模組切的在細 都有可能遇到多人開發conflict的狀況

blReader03/21 00:44最小單位用檔案切開 除非你們真的湊巧 他加欄位你修功能

blReader03/21 00:48不過這是理想的情境 專案頻頻發生衝突這並不正常

blReader03/21 00:53確實做到單一職責 切開之後別人的code多髒都不關你事

我也這麼覺得

nayeonmywife03/21 02:22請切開

k79897686903/21 07:54你自己不就有答案了 你有空幫忙切開封裝啊

abcf03/21 08:21怎麼切都還是會有可能衝突,尤其是不同bug卻改到相近的區塊

abcf03/21 08:22上面說什麼模組切的好就不會的都是唬爛你的,講誰都會講。

我覺得就算是理想情況,當然實際不一定能做到完美

devilkool03/21 09:23一般情況不會一起寫同一個函式吧?

yyc121703/21 11:07同時間不同人頻繁改同一個段落確實很奇怪 也許可以用unit

yyc121703/21 11:07 test確保執行成果符合預期

hidog03/21 11:34conflict無法完全避免喔

目前看大家的回覆確實應該要切開,當然理想跟實際執行還是有差 但至少切乾淨這個理念要有才對

※ 編輯: ManGo1012 (118.163.80.132 臺灣), 03/21/2023 12:28:31

internetms5203/21 12:38你想一下開放封閉原則你就會發現他不符合,但礙於

internetms5203/21 12:38每個人現在都有新的功能要開發,我建議你們各自寫

internetms5203/21 12:38一個擴充版本跟測試,以後找另一個人重構,除非你

internetms5203/21 12:38們有一個大神直接重構成很好的樣子,不然一直改會

internetms5203/21 12:38很痛苦

jej03/21 12:42樓上 理想很豐滿 現實和骨感

jej03/21 12:42是不想回家了的意思嗎?

k79897686903/21 12:55慣老闆:浪費時間重構啥雞巴 能賺錢嗎

xluds2480503/21 13:37你動到別人可能在改的 code 時,就要有意識可能會 con

xluds2480503/21 13:38flict。先跟對方確認沒有相依,有的話就約定好一個順

xluds2480503/21 13:38序,看是誰要先誰要後

legnaleurc03/21 14:08找一個人重構, 這種沒考績的屎缺誰要做

blReader03/21 15:20先寫測試 有測試保護再談重構 重構也不用特地請人寫

blReader03/21 15:23重構是在有寫測試保護的情境下 自己找時間或順手重構

s06yji303/21 19:24一般不太可能知道這個code同時有誰在改吧......

SHANGOYANYI03/21 19:31如果跑敏捷 也可以在daily standup講一下自己今天要

SHANGOYANYI03/21 19:31處理的ticket做溝通啦…

jej03/21 21:02樓上 多數的scrum master為了排除障礙

jej03/21 21:02短期見效 就是派衰小的人去merge阿XD

jej03/21 21:10他這個問題就有點像是工項拆解

jej03/21 21:10或是程式架構

jej03/21 21:10甚至到git branch的切割

jej03/21 21:10其中的某一項或是某幾項有問題

jej03/21 21:10乍看之下應該是無法在立會後短期奏效的issue

umum2903/22 00:47負責merge的人真的衰 所以我們是每週不同人輪流merge

superpandal03/22 01:07版控又不能控需求還有工作分派和時程

superpandal03/22 01:12組件分開再組裝稍微好點 不是一個一個ser

superpandal03/22 01:13server 強迫別人寫稍好的程式

superpandal03/22 01:14模組化

acgotaku03/22 14:25這跟元件,solid 哪有什麼關係,任務分配下去 共用到哪些

acgotaku03/22 14:27邏輯又不能控制

acgotaku03/22 14:29你確保封裝邊界不要更改,如要大改 要通知大家有相依的

acgotaku03/22 14:29先等你的發車在往下進行 如果有人比你急 你就晚點改

superpandal03/22 19:55功能本來就一環串一環 怎麼切看話事人功力

superpandal03/22 19:56力 我講的不是solid 是專案內kiss

superpandal03/22 19:58統整的人再把它串起來功能就完成了

superpandal03/22 20:24就像shell只是調用方的角色 前面說的衝突

superpandal03/22 20:25的衝突多是一個人事情做太多會發生的

superpandal03/22 20:31其實也就是叫別人寫lib 好處很多

blReader03/22 23:28相依於介面 改的人修內部邏輯 用的人DI介面 就不會衝突