iT邦幫忙

0

"重構"還是"砍掉重練"

小妹我目前手上的 Android 專案到我已經是經手的第三位工程師
每任工程師都是獨立開發及維護
目前專案是 Java 與 Kotlin 混血
個人覺得是該好好整頓一下整個專案
剛好公司針對這個專案有些新的UI改版
讓我進入到每個工程師都會遇到需要思考的問題
"重構專案" 還是要 "重寫專案" ??

Google了許多文章
許多文章都談到希望工程師要有良好的重構精神
不要動不動就砍掉重練
也有文章贊同重寫
"如果覺得重寫是好的,那就去做吧"

小妹我遇到的狀況如下:

  1. 註解少
  2. 前兩位工程師的風格不同
    呼叫 Server Api 各有一套方式
    • 第一位: Loader + HttpURLConnection
    • 第二位: Retrofit
  3. 命名沒有規則
  4. 第三方套件多
  5. 混血 Java 與 Kotlin

那我自己思考過後重寫有好有壞

優點:

  1. 可以更了解專案的功能
  2. 統一命名及呼叫 Server Api 的方式
  3. 邊寫邊新增註解
  4. 統一血統

缺點:

  1. 時程估算不易
  2. 如果不注意,前人踩過的雷可能會再踩一次

所以小妹有個疑問 想了解一下大家的經驗
如果遇到專案正處於以上狀態的話會如何選擇呢

重構
砍掉重練

哪一個呢??

看更多先前的討論...收起先前的討論...
weiclin iT邦高手 4 級 ‧ 2018-01-10 17:58:19 檢舉
重構, 除非 bug 多到動彈不得
你要思考的是開發時間,假如重構 時間 等於 重寫時間
哪我建議重寫會比較好,但是如果重寫大於 重構時間多久是你們能夠接受的
那我也是建議重寫會比較好,但是假如這各時間是有緊迫性的話,那時間短的那個顯然是比較能讓人接受的
weiclin iT邦高手 4 級 ‧ 2018-01-10 18:03:42 檢舉
你所列的優點, 重構也都有, 而你列的缺點, 還要再加上 3. 重寫的時間產能=0, 因為你在寫原本就有的東西, 4. 最後重寫出來的成果不見得就比原本的漂亮
lionlions iT邦新手 5 級 ‧ 2018-01-10 18:11:29 檢舉
34點有道理...
weiclin iT邦高手 4 級 ‧ 2018-01-10 18:18:21 檢舉
你不要把重構看成是修補原本的程式, 而是當成 "重寫一小部份功能", 一樣是重寫, 為什麼要堅持"一次全部重寫"?
lionlions iT邦新手 5 級 ‧ 2018-01-10 18:26:21 檢舉
那我有個小問題
就如同我上面提到的
前兩位工程師呼叫Server Api的方式不同
再加上我自己的一套就三套模式了
那我評估過後覺得其中B工程師的方式比較好
那我逐漸地將另一位A工程師和我自己的那套統一成B工程師的那套
這樣算是重構還是重寫呢??

這是我容易打結的一個地方
如果重構到最後跟之前的程式不一樣了
那這樣算重構還是重寫啊??
(打結中...)
weiclin iT邦高手 4 級 ‧ 2018-01-10 18:34:42 檢舉
重構就是小規模的重寫啊..重構的意思就是在不增加新功能的情況下改進程式以增加可維護性, 當然最好是有單元測試來保證功能正常不變
weiclin iT邦高手 4 級 ‧ 2018-01-10 18:37:44 檢舉
而且重構應該是軟體開發中自然的一環, 正常來說是寫完功能重構一下, 但舊專案你可以在寫新功能之前重構一下, 例如你要增加新的 api 功能, 那就趁機重構一下 api 的部份, 確認沒壞掉後再加入新功能, 這樣對你的工作進度也比較好交代
lionlions iT邦新手 5 級 ‧ 2018-01-10 18:39:23 檢舉
恩恩恩!!! (筆記)
weiclin iT邦高手 4 級 ‧ 2018-01-10 18:39:24 檢舉
如果說連重構(重寫一小部份)都做不好的話, 跟我說你全部重寫會變更好我是不信的...
你有一顆衝動的心就去重練吧哈~不過現有專案還是得維護你不覺得累的話(還要評估能力跟砍掉重練時間
話說如果那份專案大部分是自己寫到的或是已經很熟悉內部流程我才會強烈建議開版控重構就好寫壞了還可以回復
2
dog830228
iT邦研究生 4 級 ‧ 2018-01-11 09:06:39

依我個人重寫標準是,你接手的系統不能正常運作,常跳出Bug或問題

不然一般都是重構

如果目前系統可以重構,我有下面建議:
1.了解運作程式流程
2.把程式註解補上 (方便後續重構了解程式意圖)
3.把每段有涵義程式碼提取變成方法或類別 <---- 準備開始重構
4.測試重構前重構後執行結果是否一樣

PS:
1.如果會寫測試程式最好在第三前,先撰寫測試程式
2.重構時請勿進行程式開發,這會導致你錯亂

版主有提到

重構到最後跟之前的程式不一樣了

可以寫測試程式,來保證重構後不會壞掉

測試是重構的一條安全繩索,也是很重要的環節,請善用他

推薦有空可以去看看
重構:改善既有程式的設計 (二版)

0
做工仔人!
iT邦高手 1 級 ‧ 2018-01-11 09:51:16

樓主的問題,大概是每個寫程式的人會遇到的問題.
要"重構"或是"砍掉重練"個人認為:沒有一定的答案.要看你接手時的狀況.
但是程式功力的"長進"及"如何避免踩到前人所踩過的地雷":有一個重要的步驟:
就是先看"懂"前人的寫的程式.並思考他為什麼要這樣寫?並分析寫法的"優缺點" =>設法將前人的 knoWhow 轉換成自己的knowhow.

看到有"異常"時,與USER或其他同事聊聊天:去了解前人這樣寫的前因後果.=>避免踩地雷的方法之一

當你了解"全部"狀況後,其實答案就出來了.
全部重構/部份重構/全部砍掉重練 就心裡有底.
再來就是考量時間長短及眼前問題的急迫性來擬定計劃.

以樓主的說法:二位前人"呼叫Server Api的方式不同"再加上自己的方式就有三種.
=>代表樓主已經了解這三種的差異,再來就評估這三種的優缺點(說不定還會有第四種方式出現).
及安排修改方式的時程.

0
wwx
iT邦研究生 1 級 ‧ 2018-01-11 12:52:40

既然 "針對這個專案有些新的UI改版"

建議就先作這些新的部分吧!
難不成想要先把舊的功能都重作一次才能做新的部分嗎?

如果是新的部分在上下銜接的架構中有難度,
正好考驗是否有足夠的能力改寫而已...
新的部分都生不出來其他應該也不用想太多了

前兩任都能用各自的方式在系統上生出各自負責的功能,
現在,感覺好像有更好的方式來取代,即使心有大志,
應該也是先針對新的部分來作設計,
設計過程中順便想想怎麼釜底抽薪讓新的方式能去換掉舊的部分,
說真的,至少新的功能可以切割出來先做好才是,
之後新的功能真的有多優異,再去說服其他部分也作昇級,
相同的功能在汰換過程中,舊的可以作為新的對照,
確認是否都正常,比較是否更有效率更穩定...
不然走人的速度比開發的速度快應該是機率更大吧

0
JB
iT邦新手 5 級 ‧ 2018-01-17 18:10:52

不管決定重構或是打掉重練...最重要的一點是,
在開始做之前先和主管取得共識...

我要發表回答

立即登入回答