作者ManGo1012 (ManGo)
看板Soft_Job
标题[讨论] 同一个程式码段落超过一人以上在修改
时间Mon Mar 20 13:22:01 2023
如题，好奇想问一下
基本上在有正常版控的条件下
这种情况是不是根本不该发生？
尤其是开发周期尚未结束，没有要交接
每个人负责的部分
最小单位应该直接用档案切开
一个档案只会有一个人在维护、push code
即使是超庞大Class
也应该尽量切成不同小Class
然後利用继承、封装、多型分工出去才对
因为我常遇到为了rebase
需要一定程度搬动到别人的code
可能就是往前往後个几行
或是在相同段落内插入几行自己的
这种情况是否就代表分工不明确、模组化没做好?
是否有甚麽情况是让这件事可以被接受的
还是这种情况本来就家常便饭
单纯我太龟毛而已XD
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.163.80.132 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1679289723.A.52D.html
1F：推 abccbaandy: 这就跟陨石开发一样阿，不应该，但大家都习惯了 03/20 13:24
2F：→ abccbaandy: 只要没天兵直接盖过去就好了 03/20 13:24
3F：→ loadingN: 自己解conflict啊 03/20 13:25
如果我解完我的conflict之後，让你写的某个function多了几行，就算功能不影响，但这件事不会怪怪的吗
4F：推 brucetu: 那些被你搬动的code就是比你早commit啊 那就是既有程式码 03/20 13:48
5F：→ brucetu: 了 三分钟前才commit进去的code 跟上个月写好commit进去 03/20 13:48
6F：→ brucetu: 的code有什麽分别吗 03/20 13:48
7F：→ acgotaku: 就很常见吧 谁晚进去 谁就rebase 测试写好不要影响对方 03/20 13:54
8F：→ y2468101216: 你说的就是svn的概念，就是因为不好用才慢慢改成 git 03/20 13:57
9F：→ y2468101216: 你能想像为了改一个档案等一个星期的痛苦吗？ 03/20 13:58
10F：推 leakleak: 很正常吧 站会聊一聊不就解决了 03/20 13:59
11F：推 WaterLengend: 那就代表那段逻辑还没完善而已啊 03/20 14:33
12F：推 as23041248: 为何会很常遇到呀，分工通常是每个人会开发不一样 c 03/20 14:45
13F：→ as23041248: omponent ，还是刚好都一直碰到共用的地方？ 03/20 14:45
目前算是模组化没切好，所以灰色地带太大了
14F：推 surimodo: 猜拳决定谁处理冲突 03/20 14:59
15F：→ touurtn: 单元测试覆盖到就会安心点 03/20 15:08
16F：→ leolarrel: 理论上然楼主说的算对,但现实上,跟你合作的人,程式码品 03/20 15:33
17F：→ leolarrel: 质就是无法预期.要是他又是你客户公司的正职RD,那你能 03/20 15:34
18F：→ leolarrel: 怎样? 跟你的客户PM抱怨说你们家谁谁谁写code很脏?? 03/20 15:35
19F：→ leolarrel: 或是你自己开公司当最高的甲方 03/20 15:35
20F：推 kurtsgm: 啊版控不就是要处理这件事的吗? 03/20 16:17
21F：推 quickey: 丢给chatgpt请他优化就好 03/20 16:38
22F：推 Petyr: 这不是很正常的事情吗 版控某方面也是预防被盖过去啊 03/20 17:38
23F：推 vi000246: 不正常耶 代表每个人负责的功能是互相影响的 03/20 17:55
24F：推 wulouise: 就没切好，档案改了又没查，你UT不给他过不给merge就好 03/20 18:27
25F：推 jej: 看起来怪怪的 这是大家都维护同一个branch的意思吗？ 03/20 18:35
26F：→ jej: 如果不同branch 就是给衰小的人merge 03/20 18:36
27F：→ jej: 本文中提到的rebase是指你们上到master很频繁吗？ 03/20 18:38
28F：推 happy8649: 开发专案照档案切负责范围？？？第一次听到，长见识了 03/20 19:17
我的意思不是这样XD
29F：推 gigayaya: 感觉你们该做的是切branch来最小化这个问题 03/20 19:29
30F：→ siriusu: 冲突很常见啊，尤其团队规模一大自然避不开 03/20 19:40
31F：→ answermangtr: 你要PR前本来就要rebase 跟是不是branch有啥关系 03/20 20:18
32F：→ answermangtr: 03/20 20:18
33F：推 Lipraxde: 版本控制让多人对同一段 code 贡献变得可能，冲突时解 03/20 20:28
34F：→ Lipraxde: conflict 很正常，而往往问题不是在 conflict，而是在 03/20 20:28
35F：→ Lipraxde: 有人 code 写太烂 03/20 20:28
其实我问的就是多人对同一段code贡献这件事，我总觉得怪怪的
36F：推 answermangtr: 会容易改到同一段code或同一个function是你们本身 03/20 20:28
37F：→ answermangtr: 架构上就有问题 没做好solid吧 03/20 20:28
38F：推 howardsun: 超正常啊，公司一个人只负责特定的程式码，会满危险的 03/20 21:44
39F：→ howardsun: ，没办法互相 cover 03/20 21:44
40F：→ wwndbk: vscode live share 03/20 22:48
41F：推 SHANGOYANYI: 你们的系统可能缺乏「架构」 03/20 22:59
42F：→ umum29: 正常 尤其有两三个长期专案在跑时 常会影响其他人 03/21 00:24
43F：→ umum29: 其实这也是CICD的精神 一但commit就要做integration test 03/21 00:29
44F：→ umum29: 就算模组切的在细 都有可能遇到多人开发conflict的状况 03/21 00:30
45F：→ blReader: 最小单位用档案切开 除非你们真的凑巧 他加栏位你修功能 03/21 00:44
46F：→ blReader: 不过这是理想的情境 专案频频发生冲突这并不正常 03/21 00:48
47F：→ blReader: 确实做到单一职责 切开之後别人的code多脏都不关你事 03/21 00:53
我也这麽觉得
48F：推 nayeonmywife: 请切开 03/21 02:22
49F：推 k798976869: 你自己不就有答案了 你有空帮忙切开封装啊 03/21 07:54
50F：推 abcf: 怎麽切都还是会有可能冲突，尤其是不同bug却改到相近的区块 03/21 08:21
51F：→ abcf: 上面说什麽模组切的好就不会的都是唬烂你的，讲谁都会讲。 03/21 08:22
我觉得就算是理想情况，当然实际不一定能做到完美
52F：推 devilkool: 一般情况不会一起写同一个函式吧？ 03/21 09:23
53F：→ yyc1217: 同时间不同人频繁改同一个段落确实很奇怪 也许可以用unit 03/21 11:07
54F：→ yyc1217: test确保执行成果符合预期 03/21 11:07
55F：推 hidog: conflict无法完全避免喔 03/21 11:34
目前看大家的回覆确实应该要切开，当然理想跟实际执行还是有差
但至少切乾净这个理念要有才对
※ 编辑: ManGo1012 (118.163.80.132 台湾), 03/21/2023 12:28:31
56F：推 internetms52: 你想一下开放封闭原则你就会发现他不符合，但碍於 03/21 12:38
57F：→ internetms52: 每个人现在都有新的功能要开发，我建议你们各自写 03/21 12:38
58F：→ internetms52: 一个扩充版本跟测试，以後找另一个人重构，除非你 03/21 12:38
59F：→ internetms52: 们有一个大神直接重构成很好的样子，不然一直改会 03/21 12:38
60F：→ internetms52: 很痛苦 03/21 12:38
61F：→ jej: 楼上 理想很丰满 现实和骨感 03/21 12:42
62F：→ jej: 是不想回家了的意思吗？ 03/21 12:42
63F：推 k798976869: 惯老板：浪费时间重构啥鸡巴 能赚钱吗 03/21 12:55
64F：推 xluds24805: 你动到别人可能在改的 code 时，就要有意识可能会 con 03/21 13:37
65F：→ xluds24805: flict。先跟对方确认没有相依，有的话就约定好一个顺 03/21 13:38
66F：→ xluds24805: 序，看是谁要先谁要後 03/21 13:38
67F：→ legnaleurc: 找一个人重构, 这种没考绩的屎缺谁要做 03/21 14:08
68F：→ blReader: 先写测试 有测试保护再谈重构 重构也不用特地请人写 03/21 15:20
69F：→ blReader: 重构是在有写测试保护的情境下 自己找时间或顺手重构 03/21 15:23
70F：推 s06yji3: 一般不太可能知道这个code同时有谁在改吧...... 03/21 19:24
71F：推 SHANGOYANYI: 如果跑敏捷 也可以在daily standup讲一下自己今天要 03/21 19:31
72F：→ SHANGOYANYI: 处理的ticket做沟通啦… 03/21 19:31
73F：→ jej: 楼上 多数的scrum master为了排除障碍 03/21 21:02
74F：→ jej: 短期见效 就是派衰小的人去merge阿XD 03/21 21:02
75F：→ jej: 他这个问题就有点像是工项拆解 03/21 21:10
76F：→ jej: 或是程式架构 03/21 21:10
77F：→ jej: 甚至到git branch的切割 03/21 21:10
78F：→ jej: 其中的某一项或是某几项有问题 03/21 21:10
79F：→ jej: 乍看之下应该是无法在立会後短期奏效的issue 03/21 21:10
80F：→ umum29: 负责merge的人真的衰 所以我们是每周不同人轮流merge 03/22 00:47
81F：→ superpandal: 版控又不能控需求还有工作分派和时程 03/22 01:07
82F：→ superpandal: 组件分开再组装稍微好点 不是一个一个ser 03/22 01:12
83F：→ superpandal: server 强迫别人写稍好的程式 03/22 01:13
84F：→ superpandal: 模组化 03/22 01:14
85F：→ acgotaku: 这跟元件,solid 哪有什麽关系,任务分配下去 共用到哪些 03/22 14:25
86F：→ acgotaku: 逻辑又不能控制 03/22 14:27
87F：→ acgotaku: 你确保封装边界不要更改,如要大改 要通知大家有相依的 03/22 14:29
88F：→ acgotaku: 先等你的发车在往下进行 如果有人比你急 你就晚点改 03/22 14:29
89F：→ superpandal: 功能本来就一环串一环 怎麽切看话事人功力 03/22 19:55
90F：→ superpandal: 力 我讲的不是solid 是专案内kiss 03/22 19:56
91F：→ superpandal: 统整的人再把它串起来功能就完成了 03/22 19:58
92F：→ superpandal: 就像shell只是调用方的角色 前面说的冲突 03/22 20:24
93F：→ superpandal: 的冲突多是一个人事情做太多会发生的 03/22 20:25
94F：→ superpandal: 其实也就是叫别人写lib 好处很多 03/22 20:31
95F：→ blReader: 相依於介面 改的人修内部逻辑 用的人DI介面 就不会冲突 03/22 23:28