PTT推薦

[心得] 線上系統再更新

看板Soft_Job標題[心得] 線上系統再更新作者
TonyQ
(得理饒人)
時間推噓 7 推:7 噓:0 →:23

剛好今天朋友聊到老系統怎麼翻新,
大家手上的系統有一天都會變老系統,
如果維護的不夠,可能就會變成被討厭的系統。

做人可以有被討厭的勇氣,系統被討厭就會被換新。


很多人說老系統換新很難,但我覺得還是有一些方法論的。

幾個我自己會處理的做法:

1. 找出最小故障單位

被稱之為系統的東西通常是多元件的,每個元件有各自的職責,
所以通常不可能是一次全部都有問題。

一般來說,一個老系統首先需要的是體檢,把常失火的地方找出來。

可能是一或多個。


2. 開始切出問題的邊界,凡是系統一定是有 input 跟 output 。

再來,仔細讀懂這一段的程式碼或行為,如果沒有程式碼,
那就記錄這一段足夠的input 跟 output 確認邏輯。


3. 建立測試環境

4. 拉出隔離層(中間疊 proxy 或改成透過網路存取等)


5. 局部替換邏輯(由 proxy 導部分流量檢查有無異常)。

6. 上線

7. 如果出問題,必須可還原回修改前的模式

=======

其實會難,通常是沒有切對結構,
或是沒找到 core issue 。

另外多數情況下未必是整個重寫,通常是局部的調整可以解決問題。


有一種情況是需要向舊相容,
這種時候介面會同時支援舊的,直到確定不再呼叫。

很多人會認為寫新的就不用管舊的介面,
結果上線一測東漏西漏死的亂七八糟。


總之,改老系統時,
保守的多做事多買多層保險才是先進。


改老系統的心法叫做移花接木,
強調的是模仿,與原本的功能行為越像越容易嫁接。


很多人總覺得重做功能就要東加西加,
功能連對照組都沒有,當然就會越做越難。


如果是為了加新功能,所以要重寫,
這其實不叫重寫,這叫槓上開花。

重寫是跟系統槓上,加新功能是讓腦袋開花。


一般調整系統都會需要明確目的,也能結構化確認問題,
往往是非常多細碎單元的組合,而不是一次萬里長征。



拍片也講求分段拍攝再後製剪接到位,
但重寫系統想要長鏡頭一鏡到底,這是高難度技巧。


總之系統重整,單純就是技能問題跟心態問題。

撇開耍屌、自以為是,認真的面對既有的程式跟需求。

尊重團隊已經做到的事情,
想著怎麼用新的方法完成,這些才是真正的目標。


多數的失敗,肇因於不尊重既有的邏輯,
貿然躁進調整,自然出事。

最可怕的是單行道的改版,
無法還原,一旦出事就大地震。

爬山要確保,寫程式也得有備案。


總之,尊敬既有的程式碼,與之共存,
並比既有的程式碼更理解既有的程式碼的目的。

這樣要重寫程式,很難失敗。
而且減少失敗次數,就是加速成功。




-----
Sent from JPTT on my Google Pixel 3 XL.

--

網頁上拉近距離的幫手 實現 GMail豐富應用的功臣

數也數不清的友善使用者體驗 這就是javascript

歡迎同好到 AJAX 板一同討論。

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.46.76 (臺灣)
PTT 網址

superpandal09/25 23:09我不看做法 我看的是要我做到底合不合理

superpandal09/25 23:10基本上找人進去不給高薪 不熟業務又要叫人短時間做出

superpandal09/25 23:10來本身就不合理

superpandal09/25 23:11合理的化技術層面好解決

superpandal09/25 23:11合理的話

x246libra09/26 02:51給高薪,短時間,不熟業務,可以做出來嗎?不確定樓上

x246libra09/26 02:51是薪水還是時間來判定是否合理

ldkrsi09/26 05:29老系統更新最難的不是上面覺得還能用就不要改嗎

ldkrsi09/26 05:30還有就是改到一半人手被源源不絕的急件借走

ldkrsi09/26 05:31然後就變成一個更難維護的樣子放在那邊

你這三點講的基本上跟是不是老系統翻修無關,而是通用的開發負面因素。

※ 編輯: TonyQ (61.231.75.160 臺灣), 09/26/2020 08:45:19

shooter55509/26 08:59最可怕的是各元件之間互相依賴太深 牽一髮動全身 改一

shooter55509/26 09:00個全部死

shooter55509/26 09:08然後就要排定一堆時間 來先把依賴的問題解決 再來改進

shooter55509/26 09:09其中一個元件 然後上層老闆就會失去耐心

這種情況應該避免動後面的資料結構,要試著在這前提底下進行。 只要新舊結構跟行為一致,就不用擔心需要大規模全換。 通常是有同時修改行為的野心才會出事。

※ 編輯: TonyQ (61.231.75.160 臺灣), 09/26/2020 09:48:47

WaterLengend09/26 10:00可以請問對於這種結構性的問題,平常除了專案實戰

WaterLengend09/26 10:00或開源專案能夠接觸之外,有其他的練習方法嗎?

開源專案接觸不到這種東西, 因為如果開源專案已經足夠多人用, 通常已經有自己的可靠性處理的策略, 你頂多是見習. 平常接些爛尾案對這些事情有幫助, 但抱著練功的心情就好. 不用刻意去接或以此為業~~

nini20009/26 11:10謝謝分享

※ 編輯: TonyQ (210.61.209.201 臺灣), 09/26/2020 12:44:37

WaterLengend09/26 12:54瞭解,感謝大大。不過根據您的經驗分享跟之前的經

WaterLengend09/26 12:54驗比較後,感覺起來都是將問題切分明確、最小化問題

WaterLengend09/26 12:54、以及挑選風險最低的方法實行將問題解決,而不是

WaterLengend09/26 12:54動不動就要炸掉重來,把時間跟資源花在刀口上

更明確點說, 我一貫的策略是判斷當下時間跟目標, 在風險能承擔的上線, 貼著風險承擔的邊緣走, 我做事情出包的機率不低, 但我都有把握出包的時候被收在安全範圍且迅速被解決. 這未必是風險最低的, 當然在論述時我會講得比較保守是因為冒險本來就需要判斷. 在正常狀況之下因為我對系統可承擔的風險比一般人高, 一方面多數情況下我對系統的熟悉跟經驗比別人多, 另一個角度是我比較敢動結構, 跟比較能清算動結構對應的風險. 所以在多數情況下, 我的改變相對於環境仍然是屬於激進跟大膽的, 但這個激進跟大膽的背後還是風險承擔跟計算. 主要的問題還是所有地方都一樣, 要能上得了線才是生存, 所以目標應該放在最安全的著陸, 而不是最大膽的登月計畫.

※ 編輯: TonyQ (210.61.209.201 臺灣), 09/26/2020 13:11:25

superpandal09/26 13:30不給高薪只是其中一個原因

superpandal09/26 13:32重申一次 在台灣好工作真的不多

superpandal09/26 14:15年薪百萬 沒過到一年自然沒百萬 多方考量意義在這

benqm30009/26 18:34對阿要你翻新,但是原本的工作還是一樣要照進度完成,

benqm30009/26 18:34然後薪水不變,歡迎來到寶島台灣。

這不就是一種工作嗎?

neo527709/26 18:35通常是沒有邊界,因為以前沒有切得很乾淨要換一個小東西

neo527709/26 18:35就要整個全部拆了

那就要先對原本的系統進行骨幹分切作業。

※ 編輯: TonyQ (223.137.36.198 臺灣), 09/26/2020 19:22:42 ※ 編輯: TonyQ (223.137.36.198 臺灣), 09/26/2020 19:29:34

michael0728n09/26 23:42可以很快rollback就沒啥大問題,最慘就浪費時間而已

viper970909/27 00:47推分享~以為這是基本+1