我现在遇到一个情况 同时跟其他人开发很相似的功能
举例来说 我跟B同时开发两个电商网站
一个叫博客来，一个叫虾皮好了
B已经建好博客来商品列表页面
我也要建立虾皮的商品列表 想把B建的博客来页面拿来用
因为相似度很高，打算把页面共用的逻辑抽出来
放到common lib
但是这时B也在开发中
如果我重构博客来页面，他要把code merge回博客来时就要修很多冲突
这时我该做的是，直接复制博客来的逻辑，先把虾皮商品列表建出来
等两边网站都完成，再来重构吗?
因为现在程式成长幅度已经有点夸张了
单个档一千行程式码
我怕等两边都完成再重构，会花更多时间
现在就重构会造成merge冲突，而且两边开发进度也不一样
他写完的code我要用，就重构他的code
可能会重构到没完没了
遇到这种情况该怎么办呢?
想问有比较好的方法吗

复制过来refactor, 下一次对方可以考虑用你refactor的

先rebase他的囉

他放长假 等你重构完后再回来上班

开branch

你如果先重构最后他要解很多冲突最后可能会打架

重构后解完 conflict，可能又有一波重构要做

为什么已经做到这样还要重构？

你们不是抽出共用函式库了吗，怎么依赖还那么乱？

一千多行就在怕。我前个专案一个档案三万行。

先重构把档案拆小，变小后要移也比较好移

三万应该是html? 如果是JS就很恐怖了

先把抽共用的地方单独开一个分支让他merge

找他讨论很难吗 没共识就想偷偷来

先讨论两边预计要改的地方，尽量先从你一定要用但他已经不太会改的地方开始重构。每次改动尽量小且确保他的原功能没有问题。最后就是确实执行互相code review确保双方认知没有落差。大概是这样吧最重要的是事前充分讨论。很有可能讨论完的结论是不需要重构，或者重构的代价相比带来的好处不合成本

应该是抽不干净吧？你们的情况common已经没意义了

只好使用魔法卡 “算了反正以后不是我维护”

使出反制陷阱 "就是你维护"

正常应该是你们要先讨论好可以/需要共用的功能，再抽出来作成lib，或是干脆以对方的页面为主开发common lib，你没有先沟通好就开始重构对方的东西，然后说应该要共用，就会升级成政治问题。

我觉得还是时程太赶的关系 不然先讨论好共用部份

题外话，单档1000多行，应该很多职责不清，建议可以检查哪边该抽出方法 接口 类别。

反正时程太赶，先拥抱技术债。上线后，营运后再做最后的决定。没销量的那个销毁 (这就是所谓的技术倒债) (逃走

先请一个架构师

2 phase啊 你先copy一份整理好 他先用原本的改一版 你们之后再看谁要refactor他改过的那包based on你整理好的lib

时程不够就已东西先完成优先吧，还是两边unittest都很完整，refactor完不会破坏对方的逻辑？那就可以顺便改

如果你要改的部分他也在改，其实不太建议直接在这块抽common lib，因为这代表可能 1. 程式码没有拆干净，应该先把模组化做好 2. 需求还在变化，还不能确定到底有多高的可重用性，直接各自发展可能会是更好的选项

同意楼上 目前只能稍微整理 让日后修改不会太痛苦是没辨法一次做到好

如果因为时间不足从来就是假议题，因为每一个重要的专案一定都有时程压力

重构前先有测试计画比较重要

release还重构，大概就吃饱太闲如果b不愿意抽出来 那也没辄

你根他都没时间想comm lib该长怎样，找另一个人加入,由他来决定要拉什么出来，并一起讨论需求

先把一个档案一千行拆一拆再来讲吧...

一个系统套在不同的专案上虽然可能有相同的目的 但最终Ui跟核心、 数据库会因为专案需求的关系有所变化 你提早重构只能调整部分的比较不会有冲突的地方你所想的不一定会更有效率一千行算不算多 老实说长期维护五万行以上的专案（不算html/is) 而且都有拆分逻辑之类的情况下我不觉得算多 应该说这也不是用几行来认定 而且你搞不好行数是虚胖的（如排版上大括号造成的）我觉得你跟他应该是缺一个有共识的整理术让你在合并上常遇到冲突解不完 但是我觉得可能你一开始就不应该就两个专案去合并某些接口我觉得你可以跟你朋友讨论看看 分享一些作法看看会不会让两人执行专案上变得更顺不要去做任何偷改或是强迫别人一定要接受你的作法

我还没开始动工 只是预知道可能的问题先上来问问意见我大概知道要怎么做了 感谢大大回答

两个菜鸟开发又没有mentor 带领就是会遇到这种鸟事。建议买书系统性学习 网络上都是片段零碎观念

代表common lib不够common只是在他的code里加上你的code 这不叫common可以自己先写一份common的 再请B找时间整合你的这样才不会拖到两个人的进度