PTT職涯區 / Soft_Job (軟體人)

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

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