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

※ 引述《vi000246 (Vi)》之銘言：
: 我現在遇到一個情況 同時跟其他人開發很相似的功能
: 舉例來說 我跟B同時開發兩個電商網站
: 一個叫博客來，一個叫蝦皮好了
: B已經建好博客來商品列表頁面
: 我也要建立蝦皮的商品列表 想把B建的博客來頁面拿來用
: 因為相似度很高，打算把頁面共用的邏輯抽出來
: 放到common lib
: 但是這時B也在開發中
: 如果我重構博客來頁面，他要把code merge回博客來時就要修很多衝突
: 這時我該做的是，直接複製博客來的邏輯，先把蝦皮商品列表建出來
: 等兩邊網站都完成，再來重構嗎?
: 因為現在程式成長幅度已經有點誇張了
: 單個檔一千行程式碼
: 我怕等兩邊都完成再重構，會花更多時間
: 現在就重構會造成merge衝突，而且兩邊開發進度也不一樣
: 他寫完的code我要用，就重構他的code
: 可能會重構到沒完沒了
: 遇到這種情況該怎麼辦呢?
: 想問有比較好的方法嗎

1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人.

2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1).

3. 假設改完會有衝突, 那表示你做的不是重構.

4. 如果完成再重構會花更多時間, 那表示你做的不是重構.

5. 你要用他的 code , 跟你要整理重構, 是兩回事.

所以你要先搞清楚你要做的事情, 是解決你的事情,
還是幫別人改(你未必有取得授權的) code.

你拿別人的東西, 改成自己能用的 common lib,
用自己的 common lib, 這樣基本上應該不至於被靠北.

但去動別人正在開發的東西, 說穿了, 你知道人家在幹嘛嗎?
你權責上能對人家時程負責嗎?

或說穿了, 你可以負起 fix conflict 的責任嗎?

另外有個版友說重構是農閒的事情,
其實重構是越忙的地方越需要, 因為會忙通常就是沒在重構,

但是這篇原文講得並不是重構,
而是在僭越職責的前提底下自作聰明改別人的程式碼.

厲害的人應該是會抽出正確的 common,
當A 跟B都做完的時候, 拿 common 套回去不會很久的.

會被開發拖著走的 common, 表示需求根本就還沒穩定到可以共同重構啊.

--
虛實之間的世界，反抗軍與啟蒙軍的交集
帶著 Android 去旅行、去發現

在身邊渾然不覺的 另一個世界。
全世界，都是我們的 足跡與遊樂場。
~ The world around you is not what it seems. ~ http://ingress.tw

--

假設從頭寫 A 的時間是 A1, 從頭寫 B 的時間是 B1, 正常情況下, 拿 A 直接改共用函式, 來寫 B 的時間應該是 B2 , 且 B2 < B1 . (如果不是這樣就不需要拿A改了). 假設 B2 寫完之後回去套 A 的時間式 A2 . 總開發時間是 A1+A2+B2 , 而這時間應該要小於 A1 + B1, 且 A2 應該極低. (不是極低表示你元件沒拆對) 在這前提下, 這才算是重構, 不然只是單純在重新開發元件而已.

我覺得你在談重構之前, 先好好重新組織你的問題再說...... 不然很難跟你討論你的明白. "重構" 會不會更花時間是能力跟權責問題, 不是溝通問題. 是不是很多人都沒看過 refactoring 該書啊？ 為什麼這麼多人把整併功能視為重構？ =_= 重構很單純的就是[安全的]把程式邏輯從 A 投影成 B，以一種不容易改壞的形式， 而兩套程式碼如果可以幸運地剛好重疊在一起，就可以被整併。 如果無法，那表示需要進行功能異動， 而這時候就不是重構，而是在進行元件化作業的功能異動。 到目前為止的討論，重構跟功能異動的兩頂帽子很顯然分不清楚啊. 這樣的前提底下來談重構是談身體健康還是來靈修的嗎?

"思考時間"為什麼不能作為基準. XDDD 另外, 重新寫出 A/B 都能用的元件是不是重構, 要取決於 A/B 的邏輯有沒有重疊, 你這前提沒弄清楚就談重構 AB , 基本上就已經是文不對題了. 後面都是零分好嗎? 如果我已經寫了上面兩段你都還是看不懂, 我覺得你要另尋高明了. 你要怎麼認知這件事情是你的自由, 但很顯然我們對重構的定義是不同的. 你如果對基礎假設有問題, 應該是先弄清楚基礎假設. 你怎麼知道 A跟B 一定有共用邏輯, 搞不好最後 A+B 會搞出個 C > A+B, 所以為什麼要假設 A+B 一定會有能夠重構的交集呢? 而如果是這樣, 又怎麼會是功能差不多呢? 太多吐槽點了, 就這樣吧.

你看不懂坦白說不是我的責任, 我還是寫給看得懂的人看就好. 我盡力了. XD