※ 本文為 Knuckles 轉寄自 ptt.cc 更新時間: 2023-04-01 21:52:03
看板 Soft_Job
作者 標題 [討論] 同一個程式碼段落超過一人以上在修改
時間 Mon Mar 20 13:22:01 2023
如題，好奇想問一下
基本上在有正常版控的條件下
這種情況是不是根本不該發生？
尤其是開發周期尚未結束，沒有要交接
每個人負責的部分
最小單位應該直接用檔案切開
一個檔案只會有一個人在維護、push code
即使是超龐大Class
也應該儘量切成不同小Class
然後利用繼承、封裝、多型分工出去才對
因為我常遇到為了rebase
需要一定程度搬動到別人的code
可能就是往前往後個幾行
或是在相同段落內插入幾行自己的
這種情況是否就代表分工不明確、模組化沒做好?
是否有甚麼情況是讓這件事可以被接受的
還是這種情況本來就家常便飯
單純我太龜毛而已XD
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.80.132 (臺灣)
※ 作者: ManGo1012 2023-03-20 13:22:01
※ 文章代碼(AID): #1a5-rxKj (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1679289723.A.52D.html
推 : 這就跟隕石開發一樣阿，不應該，但大家都習慣了1F 03/20 13:24
→ : 只要沒天兵直接蓋過去就好了
→ : 只要沒天兵直接蓋過去就好了
→ : 自己解conflict啊3F 03/20 13:25
如果我解完我的conflict之後，讓你寫的某個function多了幾行，就算功能不影響，但這件事不會怪怪的嗎推 : 那些被你搬動的code就是比你早commit啊 那就是既有程式碼4F 03/20 13:48
→ : 了 三分鐘前才commit進去的code 跟上個月寫好commit進去
→ : 的code有什麼分別嗎
→ : 了 三分鐘前才commit進去的code 跟上個月寫好commit進去
→ : 的code有什麼分別嗎
→ : 就很常見吧 誰晚進去 誰就rebase 測試寫好不要影響對方7F 03/20 13:54
→ : 你說的就是svn的概念，就是因為不好用才慢慢改成 git8F 03/20 13:57
→ : 你能想像為了改一個檔案等一個星期的痛苦嗎？
→ : 你能想像為了改一個檔案等一個星期的痛苦嗎？
推 : 很正常吧 站會聊一聊不就解決了10F 03/20 13:59
推 : 那就代表那段邏輯還沒完善而已啊11F 03/20 14:33
推 : 為何會很常遇到呀，分工通常是每個人會開發不一樣 c12F 03/20 14:45
→ : omponent ，還是剛好都一直碰到共用的地方？
目前算是模組化沒切好，所以灰色地帶太大了→ : omponent ，還是剛好都一直碰到共用的地方？
推 : 猜拳決定誰處理衝突14F 03/20 14:59
→ : 單元測試覆蓋到就會安心點15F 03/20 15:08
→ : 理論上然樓主說的算對,但現實上,跟你合作的人,程式碼品16F 03/20 15:33
→ : 質就是無法預期.要是他又是你客戶公司的正職RD,那你能
→ : 怎樣? 跟你的客戶PM抱怨說你們家誰誰誰寫code很髒??
→ : 或是你自己開公司當最高的甲方
→ : 質就是無法預期.要是他又是你客戶公司的正職RD,那你能
→ : 怎樣? 跟你的客戶PM抱怨說你們家誰誰誰寫code很髒??
→ : 或是你自己開公司當最高的甲方
推 : 啊版控不就是要處理這件事的嗎?20F 03/20 16:17
推 : 丟給chatgpt請他優化就好21F 03/20 16:38
推 : 這不是很正常的事情嗎 版控某方面也是預防被蓋過去啊22F 03/20 17:38
推 : 不正常耶 代表每個人負責的功能是互相影響的23F 03/20 17:55
推 : 就沒切好，檔案改了又沒查，你UT不給他過不給merge就好24F 03/20 18:27
推 : 看起來怪怪的 這是大家都維護同一個branch的意思嗎？25F 03/20 18:35
→ : 如果不同branch 就是給衰小的人merge
→ : 本文中提到的rebase是指你們上到master很頻繁嗎？
→ : 如果不同branch 就是給衰小的人merge
→ : 本文中提到的rebase是指你們上到master很頻繁嗎？
推 : 開發專案照檔案切負責範圍？？？第一次聽到，長見識了28F 03/20 19:17
我的意思不是這樣XD推 : 感覺你們該做的是切branch來最小化這個問題29F 03/20 19:29
→ : 衝突很常見啊，尤其團隊規模一大自然避不開30F 03/20 19:40
→ : 你要PR前本來就要rebase 跟是不是branch有啥關係31F 03/20 20:18
→ :
→ :
推 : 版本控制讓多人對同一段 code 貢獻變得可能，衝突時解33F 03/20 20:28
→ : conflict 很正常，而往往問題不是在 conflict，而是在
→ : 有人 code 寫太爛
其實我問的就是多人對同一段code貢獻這件事，我總覺得怪怪的→ : conflict 很正常，而往往問題不是在 conflict，而是在
→ : 有人 code 寫太爛
推 : 會容易改到同一段code或同一個function是你們本身36F 03/20 20:28
→ : 架構上就有問題 沒做好solid吧
→ : 架構上就有問題 沒做好solid吧
推 : 超正常啊，公司一個人只負責特定的程式碼，會滿危險的38F 03/20 21:44
→ : ，沒辦法互相 cover
→ : ，沒辦法互相 cover
→ : vscode live share40F 03/20 22:48
推 : 你們的系統可能缺乏「架構」41F 03/20 22:59
→ : 正常 尤其有兩三個長期專案在跑時 常會影響其他人42F 03/21 00:24
→ : 其實這也是CICD的精神 一但commit就要做integration test
→ : 就算模組切的在細 都有可能遇到多人開發conflict的狀況
→ : 其實這也是CICD的精神 一但commit就要做integration test
→ : 就算模組切的在細 都有可能遇到多人開發conflict的狀況
→ : 最小單位用檔案切開 除非你們真的湊巧 他加欄位你修功能45F 03/21 00:44
→ : 不過這是理想的情境 專案頻頻發生衝突這並不正常
→ : 確實做到單一職責 切開之後別人的code多髒都不關你事
我也這麼覺得→ : 不過這是理想的情境 專案頻頻發生衝突這並不正常
→ : 確實做到單一職責 切開之後別人的code多髒都不關你事
推 : 請切開48F 03/21 02:22
推 : 你自己不就有答案了 你有空幫忙切開封裝啊49F 03/21 07:54
推 : 怎麼切都還是會有可能衝突，尤其是不同bug卻改到相近的區塊50F 03/21 08:21
→ : 上面說什麼模組切的好就不會的都是唬爛你的，講誰都會講。
我覺得就算是理想情況，當然實際不一定能做到完美→ : 上面說什麼模組切的好就不會的都是唬爛你的，講誰都會講。
推 : 一般情況不會一起寫同一個函式吧？52F 03/21 09:23
→ : 同時間不同人頻繁改同一個段落確實很奇怪 也許可以用unit53F 03/21 11:07
→ : test確保執行成果符合預期
→ : test確保執行成果符合預期
推 : conflict無法完全避免喔55F 03/21 11:34
目前看大家的回覆確實應該要切開，當然理想跟實際執行還是有差但至少切乾淨這個理念要有才對
※ 編輯: ManGo1012 (118.163.80.132 臺灣), 03/21/2023 12:28:31
推 : 你想一下開放封閉原則你就會發現他不符合，但礙於56F 03/21 12:38
→ : 每個人現在都有新的功能要開發，我建議你們各自寫
→ : 一個擴充版本跟測試，以後找另一個人重構，除非你
→ : 們有一個大神直接重構成很好的樣子，不然一直改會
→ : 很痛苦
→ : 每個人現在都有新的功能要開發，我建議你們各自寫
→ : 一個擴充版本跟測試，以後找另一個人重構，除非你
→ : 們有一個大神直接重構成很好的樣子，不然一直改會
→ : 很痛苦
→ : 樓上 理想很豐滿 現實和骨感61F 03/21 12:42
→ : 是不想回家了的意思嗎？
→ : 是不想回家了的意思嗎？
推 : 慣老闆：浪費時間重構啥雞巴 能賺錢嗎63F 03/21 12:55
推 : 你動到別人可能在改的 code 時，就要有意識可能會 con64F 03/21 13:37
→ : flict。先跟對方確認沒有相依，有的話就約定好一個順
→ : 序，看是誰要先誰要後
→ : flict。先跟對方確認沒有相依，有的話就約定好一個順
→ : 序，看是誰要先誰要後
→ : 找一個人重構, 這種沒考績的屎缺誰要做67F 03/21 14:08
→ : 先寫測試 有測試保護再談重構 重構也不用特地請人寫68F 03/21 15:20
→ : 重構是在有寫測試保護的情境下 自己找時間或順手重構
→ : 重構是在有寫測試保護的情境下 自己找時間或順手重構
推 : 一般不太可能知道這個code同時有誰在改吧......70F 03/21 19:24
推 : 如果跑敏捷 也可以在daily standup講一下自己今天要71F 03/21 19:31
→ : 處理的ticket做溝通啦…
→ : 處理的ticket做溝通啦…
→ : 樓上 多數的scrum master為了排除障礙73F 03/21 21:02
→ : 短期見效 就是派衰小的人去merge阿XD
→ : 他這個問題就有點像是工項拆解
→ : 或是程式架構
→ : 甚至到git branch的切割
→ : 其中的某一項或是某幾項有問題
→ : 乍看之下應該是無法在立會後短期奏效的issue
→ : 短期見效 就是派衰小的人去merge阿XD
→ : 他這個問題就有點像是工項拆解
→ : 或是程式架構
→ : 甚至到git branch的切割
→ : 其中的某一項或是某幾項有問題
→ : 乍看之下應該是無法在立會後短期奏效的issue
→ : 負責merge的人真的衰 所以我們是每週不同人輪流merge80F 03/22 00:47
→ : 版控又不能控需求還有工作分派和時程81F 03/22 01:07
→ : 組件分開再組裝稍微好點 不是一個一個ser
→ : server 強迫別人寫稍好的程式
→ : 模組化
→ : 組件分開再組裝稍微好點 不是一個一個ser
→ : server 強迫別人寫稍好的程式
→ : 模組化
→ : 這跟元件,solid 哪有什麼關係,任務分配下去 共用到哪些85F 03/22 14:25
→ : 邏輯又不能控制
→ : 你確保封裝邊界不要更改,如要大改 要通知大家有相依的
→ : 先等你的發車在往下進行 如果有人比你急 你就晚點改
→ : 邏輯又不能控制
→ : 你確保封裝邊界不要更改,如要大改 要通知大家有相依的
→ : 先等你的發車在往下進行 如果有人比你急 你就晚點改
→ : 功能本來就一環串一環 怎麼切看話事人功力89F 03/22 19:55
→ : 力 我講的不是solid 是專案內kiss
→ : 統整的人再把它串起來功能就完成了
→ : 就像shell只是調用方的角色 前面說的衝突
→ : 的衝突多是一個人事情做太多會發生的
→ : 其實也就是叫別人寫lib 好處很多
→ : 力 我講的不是solid 是專案內kiss
→ : 統整的人再把它串起來功能就完成了
→ : 就像shell只是調用方的角色 前面說的衝突
→ : 的衝突多是一個人事情做太多會發生的
→ : 其實也就是叫別人寫lib 好處很多
→ : 相依於介面 改的人修內部邏輯 用的人DI介面 就不會衝突95F 03/22 23:28
--
※ 看板: Soft_Job 文章推薦值: 0 目前人氣: 0 累積人氣: 25
作者 ManGo1012 的最新發文:
- 19F 4推
- 如題，好奇想問一下 基本上在有正常版控的條件下 這種情況是不是根本不該發生？ 尤其是開發周期尚未結束，沒有要交接 每個人負責的部分 最小單位應該直接用檔案切開 一個檔案只會有一個人在維護、push …95F 28推
→
guest
回列表(←)
分享