我現在遇到一個情況 同時跟其他人開發很相似的功能
舉例來說 我跟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找時間整合你的這樣才不會拖到兩個人的進度