[請益] 這種情況要怎麼重構

[vi000246 (Vi)]

我現在遇到一個情況 同時跟其他人開發很相似的功能

舉例來說 我跟B同時開發兩個電商網站

一個叫博客來，一個叫蝦皮好了

B已經建好博客來商品列表頁面

我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用

因為相似度很高，打算把頁面共用的邏輯抽出來

放到common lib

但是這時B也在開發中

如果我重構博客來頁面，他要把code merge回博客來時就要修很多衝突

這時我該做的是，直接複製博客來的邏輯，先把蝦皮商品列表建出來

等兩邊網站都完成，再來重構嗎?

因為現在程式成長幅度已經有點誇張了

單個檔一千行程式碼

我怕等兩邊都完成再重構，會花更多時間

現在就重構會造成merge衝突，而且兩邊開發進度也不一樣

他寫完的code我要用，就重構他的code

可能會重構到沒完沒了

遇到這種情況該怎麼辦呢?

想問有比較好的方法嗎


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 210.64.53.88 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1592992563.A.574.html
推 wulouise: 複製過來refactor, 下一次對方可以考慮用你refactor的
→ neo5277: 先rebase他的囉
→ csieflyman: 他放長假 等你重構完後再回來上班
推 aria0520: 開branch
→ MOONY135: 你如果先重構最後他要解很多衝突最後可能會打架
推 alihue: 重構後解完 conflict，可能又有一波重構要做
是啊 不管先重構還是後重構 這番功夫省不了的
推 s06yji3: 為什麼已經做到這樣還要重構？
重覆的code太多了 大概兩個頁面有50%重覆
再加上我的頁面 以後要維護會花很多心力
→ laputaflutin: 你們不是抽出共用函式庫了嗎，怎麼依賴還那麼亂？
這只是比喻 實際情況是更小的功能重覆 不是專案層級
推 NDark: 一千多行就在怕。我前個專案一個檔案三萬行。
推 ronny1020: 先重構把檔案拆小，變小後要移也比較好移
推 content71: 三萬應該是html? 如果是JS就很恐怖了
推 supernow: 先把抽共用的地方單獨開一個分支讓他merge
噓 Murasaki0110: 找他討論很難嗎 沒共識就想偷偷來
推 LeoSW: 先討論兩邊預計要改的地方，盡量先從你一定要用但他已經不
→ LeoSW: 太會改的地方開始重構。每次改動盡量小且確保他的原功能沒
→ LeoSW: 有問題。最後就是確實執行互相code review確保雙方認知沒有
→ LeoSW: 落差。大概是這樣吧
→ LeoSW: 最重要的是事前充分討論。很有可能討論完的結論是不需要重
→ LeoSW: 構，或者重構的代價相比帶來的好處不合成本
謝謝L大 我應該會這樣做
先把我預計改的地方跟他說 如果他也要動到這部份 就先copy一份
不改原始的程式碼
→ leo5916267: 應該是抽不乾淨吧？
→ leo5916267: 你們的情況common已經沒意義了
※ 編輯: vi000246 (219.68.118.128 臺灣), 06/24/2020 20:36:11
推 TAKADO: 只好使用魔法卡 “算了反正以後不是我維護”
→ vi000246: 使出反制陷阱 "就是你維護"
推 TAKADO: 正常應該是你們要先討論好可以/需要共用的功能，再抽出來
→ TAKADO: 作成lib，或是乾脆以對方的頁面為主開發common lib，你沒
→ TAKADO: 有先溝通好就開始重構對方的東西，然後說應該要共用，就會
→ TAKADO: 升級成政治問題。
→ vi000246: 我覺得還是時程太趕的關係 不然先討論好共用部份
推 APTON: 題外話，單檔1000多行，應該很多職責不清，建議可以檢查哪
→ APTON: 邊該抽出方法 介面 類別。
→ vi000246: 事先規劃好 就不會有現在的問題了
推 qrtt1: 反正時程太趕，先擁抱技術債。上線後，營運後再做最後的決
→ qrtt1: 定。沒銷量的那個銷毀 (這就是所謂的技術倒債) (逃走
推 Masakiad: 先請一個架構師
推 GGFACE: 2 phase啊 你先copy一份整理好 他先用原本的改一版 你們
→ GGFACE: 之後再看誰要refactor他改過的那包based on你整理好的lib
推 wulouise: 時程不夠就已東西先完成優先吧，還是兩邊unittest都很完
→ wulouise: 整，refactor完不會破壞對方的邏輯？那就可以順便改
推 LeoSW: 如果你要改的部分他也在改，其實不太建議直接在這塊抽commo
→ LeoSW: n lib，因為這代表可能 1. 程式碼沒有拆乾淨，應該先把模組
→ LeoSW: 化做好 2. 需求還在變化，還不能確定到底有多高的可重用性
→ LeoSW: ，直接各自發展可能會是更好的選項
→ vi000246: 同意樓上 目前只能稍微整理 讓日後修改不會太痛苦
→ vi000246: 是沒辨法一次做到好
推 APTON: 如果因為時間不足從來就是假議題，因為每一個重要的專案一
→ APTON: 定都有時程壓力
推 bjj: 重構前先有測試計畫比較重要
推 Csongs: release還重構，大概就吃飽太閒
推 Csongs: 如果b不願意抽出來 那也沒輒
推 internetms52: 你根他都沒時間想comm lib該長怎樣，找另一個人加
→ internetms52: 入,由他來決定要拉什麼出來，並一起討論需求
推 Ghamu: 先把一個檔案一千行拆一拆再來講吧...
推 guanting886: 一個系統套在不同的專案上雖然可能有相同的目的 但
→ guanting886: 最終Ui跟核心、 資料庫會因為專案需求的關係有所變
→ guanting886: 化 你提早重構只能調整部分的比較不會有衝突的地方
→ guanting886:  你所想的不一定會更有效率
推 guanting886: 一千行算不算多 老實說長期維護五萬行以上的專案（
→ guanting886: 不算html/is) 而且都有拆分邏輯之類的情況下我不覺得
→ guanting886: 算多 應該說這也不是用幾行來認定 而且你搞不好行數
→ guanting886: 是虛胖的（如排版上大括號造成的）
→ guanting886: 我覺得你跟他應該是缺一個有共識的整理術
→ guanting886: 讓你在合併上常遇到衝突解不完 但是我覺得可能你一開
→ guanting886: 始就不應該就兩個專案去合併某些介面
推 guanting886: 我覺得你可以跟你朋友討論看看 分享一些作法看看會
→ guanting886: 不會讓兩人執行專案上變得更順
→ guanting886: 不要去做任何偷改或是強迫別人一定要接受你的作法
→ vi000246: 我還沒開始動工 只是預知道可能的問題先上來問問意見
→ vi000246: 我大概知道要怎麼做了 感謝大大回答
推 zased: 兩個菜鳥開發又沒有mentor 帶領就是會遇到這種鳥事。建議買
→ zased: 書系統性學習 網路上都是片段零碎觀念
→ yourinfo: 代表common lib不夠common
→ yourinfo: 只是在他的code裡加上你的code 這不叫common
→ yourinfo: 可以自己先寫一份common的 再請B找時間整合你的
→ yourinfo: 這樣才不會拖到兩個人的進度