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

看板Soft_Job作者 (Vi)時間3年前 (2020/06/24 17:56), 3年前編輯推噓26(27推 1噓 46→)
留言74則, 28人參與, 3年前最新討論串1/5 (看更多)
我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟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
推
06/24 18:05, 3年前 , 1F
複製過來refactor, 下一次對方可以考慮用你refactor的
06/24 18:05, 1F
→
06/24 18:09, 3年前 , 2F
先rebase他的囉
06/24 18:09, 2F
→
06/24 18:20, 3年前 , 3F
他放長假 等你重構完後再回來上班
06/24 18:20, 3F
推
06/24 18:27, 3年前 , 4F
開branch
06/24 18:27, 4F
→
06/24 18:30, 3年前 , 5F
你如果先重構最後他要解很多衝突最後可能會打架
06/24 18:30, 5F
推
06/24 18:38, 3年前 , 6F
重構後解完 conflict，可能又有一波重構要做
06/24 18:38, 6F
是啊 不管先重構還是後重構 這番功夫省不了的
推
06/24 18:38, 3年前 , 7F
為什麼已經做到這樣還要重構？
06/24 18:38, 7F
重覆的code太多了 大概兩個頁面有50%重覆 再加上我的頁面 以後要維護會花很多心力
→
06/24 18:39, 3年前 , 8F
你們不是抽出共用函式庫了嗎，怎麼依賴還那麼亂？
06/24 18:39, 8F
這只是比喻 實際情況是更小的功能重覆 不是專案層級
推
06/24 18:42, 3年前 , 9F
一千多行就在怕。我前個專案一個檔案三萬行。
06/24 18:42, 9F
推
06/24 18:46, 3年前 , 10F
先重構把檔案拆小，變小後要移也比較好移
06/24 18:46, 10F
推
06/24 18:46, 3年前 , 11F
三萬應該是html? 如果是JS就很恐怖了
06/24 18:46, 11F
推
06/24 19:37, 3年前 , 12F
先把抽共用的地方單獨開一個分支讓他merge
06/24 19:37, 12F
噓
06/24 19:41, 3年前 , 13F
找他討論很難嗎 沒共識就想偷偷來
06/24 19:41, 13F
推
06/24 19:46, 3年前 , 14F
先討論兩邊預計要改的地方，盡量先從你一定要用但他已經不
06/24 19:46, 14F
→
06/24 19:46, 3年前 , 15F
太會改的地方開始重構。每次改動盡量小且確保他的原功能沒
06/24 19:46, 15F
→
06/24 19:46, 3年前 , 16F
有問題。最後就是確實執行互相code review確保雙方認知沒有
06/24 19:46, 16F
→
06/24 19:46, 3年前 , 17F
落差。大概是這樣吧
06/24 19:46, 17F
→
06/24 19:48, 3年前 , 18F
最重要的是事前充分討論。很有可能討論完的結論是不需要重
06/24 19:48, 18F
→
06/24 19:48, 3年前 , 19F
構，或者重構的代價相比帶來的好處不合成本
06/24 19:48, 19F
謝謝L大 我應該會這樣做 先把我預計改的地方跟他說 如果他也要動到這部份 就先copy一份 不改原始的程式碼
→
06/24 20:07, 3年前 , 20F
應該是抽不乾淨吧？
06/24 20:07, 20F
→
06/24 20:08, 3年前 , 21F
你們的情況common已經沒意義了
06/24 20:08, 21F
※ 編輯: vi000246 (219.68.118.128 臺灣), 06/24/2020 20:36:11
推
06/24 20:42, 3年前 , 22F
只好使用魔法卡 “算了反正以後不是我維護”
06/24 20:42, 22F
→
06/24 20:42, 3年前 , 23F
使出反制陷阱 "就是你維護"
06/24 20:42, 23F
推
06/24 20:49, 3年前 , 24F
正常應該是你們要先討論好可以/需要共用的功能，再抽出來
06/24 20:49, 24F
→
06/24 20:49, 3年前 , 25F
作成lib，或是乾脆以對方的頁面為主開發common lib，你沒
06/24 20:49, 25F
→
06/24 20:49, 3年前 , 26F
有先溝通好就開始重構對方的東西，然後說應該要共用，就會
06/24 20:49, 26F
→
06/24 20:49, 3年前 , 27F
升級成政治問題。
06/24 20:49, 27F
→
06/24 21:25, 3年前 , 28F
我覺得還是時程太趕的關係 不然先討論好共用部份
06/24 21:25, 28F
推
06/24 21:25, 3年前 , 29F
題外話，單檔1000多行，應該很多職責不清，建議可以檢查哪
06/24 21:25, 29F
→
06/24 21:25, 3年前 , 30F
邊該抽出方法 介面 類別。
06/24 21:25, 30F
→
06/24 21:25, 3年前 , 31F
事先規劃好 就不會有現在的問題了
06/24 21:25, 31F
推
06/24 21:42, 3年前 , 32F
反正時程太趕，先擁抱技術債。上線後，營運後再做最後的決
06/24 21:42, 32F
→
06/24 21:42, 3年前 , 33F
定。沒銷量的那個銷毀 (這就是所謂的技術倒債) (逃走
06/24 21:42, 33F
推
06/24 21:46, 3年前 , 34F
先請一個架構師
06/24 21:46, 34F
推
06/24 22:10, 3年前 , 35F
2 phase啊 你先copy一份整理好 他先用原本的改一版 你們
06/24 22:10, 35F
→
06/24 22:10, 3年前 , 36F
之後再看誰要refactor他改過的那包based on你整理好的lib
06/24 22:10, 36F
推
06/24 22:28, 3年前 , 37F
時程不夠就已東西先完成優先吧，還是兩邊unittest都很完
06/24 22:28, 37F
→
06/24 22:28, 3年前 , 38F
整，refactor完不會破壞對方的邏輯？那就可以順便改
06/24 22:28, 38F
推
06/24 22:42, 3年前 , 39F
如果你要改的部分他也在改，其實不太建議直接在這塊抽commo
06/24 22:42, 39F
→
06/24 22:42, 3年前 , 40F
n lib，因為這代表可能 1. 程式碼沒有拆乾淨，應該先把模組
06/24 22:42, 40F
→
06/24 22:42, 3年前 , 41F
化做好 2. 需求還在變化，還不能確定到底有多高的可重用性
06/24 22:42, 41F
→
06/24 22:42, 3年前 , 42F
，直接各自發展可能會是更好的選項
06/24 22:42, 42F
→
06/24 23:17, 3年前 , 43F
同意樓上 目前只能稍微整理 讓日後修改不會太痛苦
06/24 23:17, 43F
→
06/24 23:17, 3年前 , 44F
是沒辨法一次做到好
06/24 23:17, 44F
推
06/24 23:20, 3年前 , 45F
如果因為時間不足從來就是假議題，因為每一個重要的專案一
06/24 23:20, 45F
→
06/24 23:20, 3年前 , 46F
定都有時程壓力
06/24 23:20, 46F
推
06/25 01:28, 3年前 , 47F
重構前先有測試計畫比較重要
06/25 01:28, 47F
推
06/25 09:58, 3年前 , 48F
release還重構，大概就吃飽太閒
06/25 09:58, 48F
推
06/25 10:04, 3年前 , 49F
如果b不願意抽出來 那也沒輒
06/25 10:04, 49F
推
06/25 13:58, 3年前 , 50F
你根他都沒時間想comm lib該長怎樣，找另一個人加
06/25 13:58, 50F
→
06/25 13:58, 3年前 , 51F
入,由他來決定要拉什麼出來，並一起討論需求
06/25 13:58, 51F
推
06/25 17:44, 3年前 , 52F
先把一個檔案一千行拆一拆再來講吧...
06/25 17:44, 52F
推
06/25 18:21, 3年前 , 53F
一個系統套在不同的專案上雖然可能有相同的目的 但
06/25 18:21, 53F
→
06/25 18:21, 3年前 , 54F
最終Ui跟核心、 資料庫會因為專案需求的關係有所變
06/25 18:21, 54F
→
06/25 18:21, 3年前 , 55F
化 你提早重構只能調整部分的比較不會有衝突的地方
06/25 18:21, 55F
→
06/25 18:21, 3年前 , 56F
你所想的不一定會更有效率
06/25 18:21, 56F
推
06/25 18:25, 3年前 , 57F
一千行算不算多 老實說長期維護五萬行以上的專案（
06/25 18:25, 57F
→
06/25 18:25, 3年前 , 58F
不算html/is) 而且都有拆分邏輯之類的情況下我不覺得
06/25 18:25, 58F
→
06/25 18:25, 3年前 , 59F
算多 應該說這也不是用幾行來認定 而且你搞不好行數
06/25 18:25, 59F
→
06/25 18:25, 3年前 , 60F
是虛胖的（如排版上大括號造成的）
06/25 18:25, 60F
→
06/25 18:26, 3年前 , 61F
我覺得你跟他應該是缺一個有共識的整理術
06/25 18:26, 61F
→
06/25 18:27, 3年前 , 62F
讓你在合併上常遇到衝突解不完 但是我覺得可能你一開
06/25 18:27, 62F
→
06/25 18:27, 3年前 , 63F
始就不應該就兩個專案去合併某些介面
06/25 18:27, 63F
推
06/25 18:29, 3年前 , 64F
我覺得你可以跟你朋友討論看看 分享一些作法看看會
06/25 18:29, 64F
→
06/25 18:29, 3年前 , 65F
不會讓兩人執行專案上變得更順
06/25 18:29, 65F
→
06/25 18:29, 3年前 , 66F
不要去做任何偷改或是強迫別人一定要接受你的作法
06/25 18:29, 66F
→
06/25 18:45, 3年前 , 67F
我還沒開始動工 只是預知道可能的問題先上來問問意見
06/25 18:45, 67F
→
06/25 18:45, 3年前 , 68F
我大概知道要怎麼做了 感謝大大回答
06/25 18:45, 68F
推
06/27 11:44, 3年前 , 69F
兩個菜鳥開發又沒有mentor 帶領就是會遇到這種鳥事。建議買
06/27 11:44, 69F
→
06/27 11:44, 3年前 , 70F
書系統性學習 網路上都是片段零碎觀念
06/27 11:44, 70F
→
06/28 16:32, 3年前 , 71F
代表common lib不夠common
06/28 16:32, 71F
→
06/28 16:33, 3年前 , 72F
只是在他的code裡加上你的code 這不叫common
06/28 16:33, 72F
→
06/28 16:38, 3年前 , 73F
可以自己先寫一份common的 再請B找時間整合你的
06/28 16:38, 73F
→
06/28 16:39, 3年前 , 74F
這樣才不會拖到兩個人的進度
06/28 16:39, 74F
‣ 更多 vi000246 的文章
文章代碼(AID): #1UyoCpLq (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 vi000246 的文章
文章代碼(AID): #1UyoCpLq (Soft_Job)