該不該重寫程式碼

在大型商業專案中,打掉重來是非常危險的行為。當然,如果你是在做實驗,想到新算法可以隨時重寫。如果你跳槽、或剛接手一個新專案,面對看上去異常混亂的舊程式碼,請冷靜下來,忍住打掉重寫的衝動,想想下面這些經驗之談。

Posted by Inside 硬塞的網路趨勢觀察 on Sunday, May 27, 2018

之前看了這篇文章

我覺得很多工程師都有自己的想法

但我想換個角度

如果以甲方的角度

甲方有現成的系統在運作

是不是應該重寫整個系統?

我有做過幾個這類的案子

有成功轉移上線的

也有失敗的

 

重寫的話

時間很長

營運端等不及

不重寫的話

手上的系統又問題一堆

感覺只是硬要延長使用壽命

 

比較建議的做法是

先評估這個現成的系統還想用多久

如果時間上不長 (例如一兩年)

那就可以重寫

反正舊的系統也用不久了

舊系統就盡量不要再改

有新的需求就往新系統開

不過這有一個但書

我遇過有客戶是

他花了大筆的錢 剛做好的系統

卻完全不能用

這就不適合這個狀況

這個狀況的前提是

舊系統的可用度算高

(起碼可以讓公司繼續營運)

 

如果你的系統問題不大

建議局部更新就好

柿子挑軟的吃

先找一些無關緊要的東西 讓團隊改改看

改上手 熟悉系統以後

再挑複雜的改

團隊也很重要

如果留不住人 異動頻繁

也不建議貿然的就改現成的系統

通常團隊的人事(維持)費用

會比開發系統的費用還高

這點也是考慮的因素之一

 

還有一個參考點是

可以多找一些真的有經驗的開發團隊聊聊看

因為每個團隊擅長的點都不一樣

我去年參與一個案子

這個公司的系統已經找過至少三四間公司

歷時兩三年

但是都沒弄好

每個團隊來 都改成自己想要 自己熟悉的模式

但是都不適合公司

(當然公司的主事者問題也很大)

反正最後還是搞砸了

多找些人聊 會有比較明確而且適合的答案