Re: [請益] 這種情況要怎麼重構
※ 引述《vi000246 (Vi)》之銘言:
: 一個叫博客來,一個叫蝦皮好了
: B已經建好博客來商品列表頁面
: 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用
: 因為相似度很高,打算把頁面共用的邏輯抽出來
: 放到common lib
: 但是這時B也在開發中
: 如果我重構博客來頁面,他要把code merge回博客來時就要修很多衝突
: 這時我該做的是,直接複製博客來的邏輯,先把蝦皮商品列表建出來
: 等兩邊網站都完成,再來重構嗎?
: 因為現在程式成長幅度已經有點誇張了
: 單個檔一千行程式碼
: 我怕等兩邊都完成再重構,會花更多時間
其實我真的不懂為什麼要急著重構
有好處嗎?
一般而言,重構都是發生在農閒的時候
就是沒有新案子在趕,老闆又要想辦法把人力資源給排滿
以免被上面丟一坨賽過來的最好理由
那你急著重構就會遇到三個問題
1. 會不會影響到專案的時程
2. 會不會產生不預期的bug,或是到時候需求改變,搞死自己和對方
3. 農閒的時候沒理由打混
吃力不討好
真正好的做法是,雙方先把架構談好再來繼續做
不要想要自己一個人來自幹
另外
要重構一般的先決條件是要有一個完整的unit test來support
或是有一個願意做regression的QA來陪你
請問有達到這些條件了嗎?
By the way
我是同意邊寫邊重構這句話的人,但僅限於小地方修改
--
紫楓碎碎念
YouTube頻道:https://www.youtube.com/user/tbpfs
FB粉專:https://www.facebook.com/tbpfs2/
blog: http://tbpfs1.blogspot.com/
--
這案子已經是重構舊專案了 因此能預期這幾個頁面再成長
下去會一發不可收拾 想趁小病沒長大前先矯正好
現在只有一千行還有得救 等長到像舊專案那樣就改不動了
不斷創造新的工作機會XD
重構是隨時可做,他標題雖然是重構,但實際是 infra 模組的
邊界探索。在二方都還在飄移的好球帶摸索安全範圍,這反而
影響了開發速度,無法全心全意集中火力。
真的...農閒時候
16
1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1). 3. 假設改完會有衝突, 那表示你做的不是重構. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構. 5. 你要用他的 code , 跟你要整理重構, 是兩回事.15
我這篇寫的跟原原PO的狀況無關 ※ 引述《tbpfs ( )》之銘言: : 其實我真的不懂為什麼要急著重構 : 有好處嗎? : 一般而言,重構都是發生在農閒的時候2
如果專案有deadline的壓力建議是先各自發展以不相互影響為前提,最後再用剩餘時間開 一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人,沒有定義從系統 到功能的分工,導致代碼重工,而且缺乏溝通。 真的建議未來有機會在主導你還是要自己學會定義好工作,先學習不寫code就可以訂出功 能以及架構。我自己工作後常常遇到工程師很喜歡自幹,還沒開始就急著寫code,而不是26
首Po我現在遇到一個情況 同時跟其他人開發很相似的功能 舉例來說 我跟B同時開發兩個電商網站 一個叫博客來,一個叫蝦皮好了 B已經建好博客來商品列表頁面 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用
35
[討論] 重構跟kpi的考量假設以下情境 有個功能A、B都會用到相同邏輯,且有兩份重覆的code (沒有unit test保護,而且年久失修 要加入unit test會需要更多時程) 現在要加入C,也會用到相同邏輯 身為合格的工程師 應該會把ABC重覆的部份提取出來24
重構的幾個迷思覺得最近很多文章都有些不求甚解的問題,來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼,重寫舊的程式碼成自己爽的樣子,不一定是重構。 3. 重構是一種相對安全的工具型開發方法論, 但仍然有不少風險跟誘惑。20
Re: [討論] 所謂的開發強者是怎麼樣子的?^^^^^^^^^^^^^^^^^^^^^^ : 管理 1000+ servers、每年幫公司節省一百萬美金(?) machine cost : 1. 硬實力上 : 他很擅長在不同專案、codebases 中穿梭,幾天就能看穿並理解背後的邏輯和設計脈絡 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^17
Re: [討論] 重構之前要寫測試 不然不要重構這就是TAD, 一般做法是假設以前人做的是對的 拿以前的output當測資 避免以後的output跟預期結果不同 技術面的錯誤→沒有防呆/沒有釋放資源/overflow/沒有check 這應該不在討論範圍內, 也有客觀標準 行為與邏輯的部分才是有爭議的, 要嘛根本沒規格只有口傳13
Re: [討論] 重構跟kpi的考量感覺這個標題就是個假議題,你說不重構A、B因為Unit test來不及寫,那你新寫的C就不 用unit test了? 然後你又說三個code一模一樣,假設你幫C寫完unit test了,那你不就也把AB搞好了嗎? 再退一萬步來講,AB沒有unit test大家用的那麼爽你還硬要去動也只是吃飽太閒,不如 好好寫你C的unit test,寫完大家就用C就好啦2
Re: [請益] coding style差太多怎辦?重構取決於你對自己的程度有多自信 假設已經發現問題 也覺得自己有能力修改 試著跟主管溝通看看 說「在自己任務時程不耽誤的前提下 有路過看到程式碼就稍微整理一下」 若有得到主管或同事許可就下去改 沒把握自己可以改好的話 量力而為 先從小區塊開始改起