[請益] 這種情況要怎麼重構
我現在遇到一個情況 同時跟其他人開發很相似的功能
舉例來說 我跟B同時開發兩個電商網站
一個叫博客來，一個叫蝦皮好了
B已經建好博客來商品列表頁面
我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用
因為相似度很高，打算把頁面共用的邏輯抽出來
放到common lib
但是這時B也在開發中
如果我重構博客來頁面，他要把code merge回博客來時就要修很多衝突
這時我該做的是，直接複製博客來的邏輯，先把蝦皮商品列表建出來
等兩邊網站都完成，再來重構嗎?
因為現在程式成長幅度已經有點誇張了
單個檔一千行程式碼
我怕等兩邊都完成再重構，會花更多時間
現在就重構會造成merge衝突，而且兩邊開發進度也不一樣
他寫完的code我要用，就重構他的code
可能會重構到沒完沒了
遇到這種情況該怎麼辦呢?
想問有比較好的方法嗎
--
複製過來refactor, 下一次對方可以考慮用你refactor的
先rebase他的囉
他放長假 等你重構完後再回來上班
開branch
你如果先重構最後他要解很多衝突最後可能會打架
重構後解完 conflict，可能又有一波重構要做
是啊 不管先重構還是後重構 這番功夫省不了的
為什麼已經做到這樣還要重構？
重覆的code太多了 大概兩個頁面有50%重覆 再加上我的頁面 以後要維護會花很多心力
你們不是抽出共用函式庫了嗎，怎麼依賴還那麼亂？
這只是比喻 實際情況是更小的功能重覆 不是專案層級
一千多行就在怕。我前個專案一個檔案三萬行。
先重構把檔案拆小，變小後要移也比較好移
三萬應該是html? 如果是JS就很恐怖了
先把抽共用的地方單獨開一個分支讓他merge
找他討論很難嗎 沒共識就想偷偷來
先討論兩邊預計要改的地方，盡量先從你一定要用但他已經不
太會改的地方開始重構。每次改動盡量小且確保他的原功能沒
有問題。最後就是確實執行互相code review確保雙方認知沒有
落差。大概是這樣吧
最重要的是事前充分討論。很有可能討論完的結論是不需要重
構，或者重構的代價相比帶來的好處不合成本
謝謝L大 我應該會這樣做 先把我預計改的地方跟他說 如果他也要動到這部份 就先copy一份 不改原始的程式碼
應該是抽不乾淨吧？
你們的情況common已經沒意義了
只好使用魔法卡 “算了反正以後不是我維護”
使出反制陷阱 "就是你維護"
正常應該是你們要先討論好可以/需要共用的功能，再抽出來
作成lib，或是乾脆以對方的頁面為主開發common lib，你沒
有先溝通好就開始重構對方的東西，然後說應該要共用，就會
升級成政治問題。
我覺得還是時程太趕的關係 不然先討論好共用部份
題外話，單檔1000多行，應該很多職責不清，建議可以檢查哪
邊該抽出方法 介面 類別。
事先規劃好 就不會有現在的問題了
反正時程太趕，先擁抱技術債。上線後，營運後再做最後的決
定。沒銷量的那個銷毀 (這就是所謂的技術倒債) (逃走
先請一個架構師
2 phase啊 你先copy一份整理好 他先用原本的改一版 你們
之後再看誰要refactor他改過的那包based on你整理好的lib
時程不夠就已東西先完成優先吧，還是兩邊unittest都很完
整，refactor完不會破壞對方的邏輯？那就可以順便改
如果你要改的部分他也在改，其實不太建議直接在這塊抽commo
n lib，因為這代表可能 1. 程式碼沒有拆乾淨，應該先把模組
化做好 2. 需求還在變化，還不能確定到底有多高的可重用性
，直接各自發展可能會是更好的選項
同意樓上 目前只能稍微整理 讓日後修改不會太痛苦
是沒辨法一次做到好
如果因為時間不足從來就是假議題，因為每一個重要的專案一
定都有時程壓力
重構前先有測試計畫比較重要
release還重構，大概就吃飽太閒
如果b不願意抽出來 那也沒輒
你根他都沒時間想comm lib該長怎樣，找另一個人加
入,由他來決定要拉什麼出來，並一起討論需求
先把一個檔案一千行拆一拆再來講吧...
一個系統套在不同的專案上雖然可能有相同的目的 但
最終Ui跟核心、 資料庫會因為專案需求的關係有所變
化 你提早重構只能調整部分的比較不會有衝突的地方
你所想的不一定會更有效率
一千行算不算多 老實說長期維護五萬行以上的專案（
不算html/is) 而且都有拆分邏輯之類的情況下我不覺得
算多 應該說這也不是用幾行來認定 而且你搞不好行數
是虛胖的（如排版上大括號造成的）
我覺得你跟他應該是缺一個有共識的整理術
讓你在合併上常遇到衝突解不完 但是我覺得可能你一開
始就不應該就兩個專案去合併某些介面
我覺得你可以跟你朋友討論看看 分享一些作法看看會
不會讓兩人執行專案上變得更順
不要去做任何偷改或是強迫別人一定要接受你的作法
我還沒開始動工 只是預知道可能的問題先上來問問意見
我大概知道要怎麼做了 感謝大大回答
兩個菜鳥開發又沒有mentor 帶領就是會遇到這種鳥事。建議買
書系統性學習 網路上都是片段零碎觀念
代表common lib不夠common
只是在他的code裡加上你的code 這不叫common
可以自己先寫一份common的 再請B找時間整合你的
這樣才不會拖到兩個人的進度
3
其實我真的不懂為什麼要急著重構 有好處嗎? 一般而言，重構都是發生在農閒的時候 就是沒有新案子在趕，老闆又要想辦法把人力資源給排滿 以免被上面丟一坨賽過來的最好理由16
1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.15
我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言： : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言，重構都是發生在農閒的時候2
如果專案有deadline的壓力建議是先各自發展以不相互影響為前提，最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人，沒有定義從系統 到功能的分工，導致代碼重工，而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作，先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹，還沒開始就急著寫code，而不是
![Re: [請益] 這種情況要怎麼重構](https://yt3.ggpht.com/ytc/AMLnZu8OJyPPVMQ7ijoc9ewwrNysCZr1NWZr4Bwqeo5H_Fk=s900-c-k-c0x00ffffff-no-rj "Re: [請益] 這種情況要怎麼重構")
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯，且有兩份重覆的code (沒有unit test保護，而且年久失修 要加入unit test會需要更多時程) 現在要加入C，也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題，來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。 3. 重構是一種相對安全的工具型開發方法論， 但仍然有不少風險跟誘惑。20
Re: [討論] 所謂的開發強者是怎麼樣子的?^^^^^^^^^^^^^^^^^^^^^^ : 管理 1000+ servers、每年幫公司節省一百萬美金(?) machine cost : 1. 硬實力上 : 他很擅長在不同專案、codebases 中穿梭，幾天就能看穿並理解背後的邏輯和設計脈絡 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^18
[心得]以策略模式重構switch case或if (影片)最近在客戶那邊一起 pair 重構 legacy code， 碰到了一大段 if/else statement，用來判斷什麼時候該使用哪一種cache， 並依照不同 cache 的邏輯來決定回傳的內容。 發現還是有蠻多風氣比較封閉的公司對這類型的基本功跟處理不是很熟悉， 可能是對 code smell 不熟，對重構不熟，對 design pattern 不熟，對工具不熟。![[心得]以策略模式重構switch case或if (影片)](https://img.youtube.com/vi/zO-NnNC-xyg/mqdefault.jpg "[心得]以策略模式重構switch case或if (影片)")
17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳2
Re: [討論] 重構之前要寫測試 不然不要重構人生在世，吃飯跟拉屎都是要做的，應該沒有人會說， 要先吃飯不然別拉屎，還是先拉屎不然別吃飯。 改扣就是改扣，框個名字自稱叫重構， 是不是不知道，但即使是重構，本質還是改扣。 測試是為了改扣順利，不寫測試還是可以改扣。2
Re: [請益] coding style差太多怎辦?重構取決於你對自己的程度有多自信 假設已經發現問題 也覺得自己有能力修改 試著跟主管溝通看看 說「在自己任務時程不耽誤的前提下 有路過看到程式碼就稍微整理一下」 若有得到主管或同事許可就下去改 沒把握自己可以改好的話 量力而為 先從小區塊開始改起
![Re: [討論] 後端比前端工時更長嗎？](https://i.imgur.com/O5tUzAob.jpeg "Re: [討論] 後端比前端工時更長嗎？")