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

不然一般都是重構

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

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

版主有提到

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

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

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

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

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

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

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

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

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

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

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

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

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