看板
[ Soft_Job ]
討論串[請益] 這種情況要怎麼重構
共 5 篇文章
內容預覽:
我現在遇到一個情況 同時跟其他人開發很相似的功能. 舉例來說 我跟B同時開發兩個電商網站. 一個叫博客來，一個叫蝦皮好了. B已經建好博客來商品列表頁面. 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用. 因為相似度很高，打算把頁面共用的邏輯抽出來. 放到common lib. 但是這時B也在
(還有400個字)
內容預覽:
如果專案有deadline的壓力建議是先各自發展以不相互影響為前提，最後再用剩餘時間開一個分支做重構。其實這就是在規劃專案時沒有一個主要主導的設計人，沒有定義從系統到功能的分工，導致代碼重工，而且缺乏溝通。. 真的建議未來有機會在主導你還是要自己學會定義好工作，先學習不寫code就可以訂出功能以及架
(還有91個字)
內容預覽:
其實我真的不懂為什麼要急著重構. 有好處嗎?. 一般而言，重構都是發生在農閒的時候. 就是沒有新案子在趕，老闆又要想辦法把人力資源給排滿. 以免被上面丟一坨賽過來的最好理由. 那你急著重構就會遇到三個問題. 1. 會不會影響到專案的時程. 2. 會不會產生不預期的bug，或是到時候需求改變，搞死自己
(還有275個字)
內容預覽:
我這篇寫的跟原原PO的狀況無關. 重構有好處, 而且有不得不做的狀況. 我曾經遇到效能瓶頸,. 發現是在整個流程順序上只要重新調整並安插幾個預處理的階段就能大幅提升效能. 但原本的code就不是很clean, 隨便一個method破500行, 一個class有7、80個method. 有二十多個bo
(還有897個字)
內容預覽:
1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人.. 2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1).. 3. 假設改完會有衝突, 那表示你做的不是重構.. 4. 如果完成再重構會花更多時間, 那表示你做的不是重構.. 5. 你
(還有1965個字)