[心得] 線上系統再更新
剛好今天朋友聊到老系統怎麼翻新，
大家手上的系統有一天都會變老系統，
如果維護的不夠，可能就會變成被討厭的系統。
做人可以有被討厭的勇氣，系統被討厭就會被換新。
很多人說老系統換新很難，但我覺得還是有一些方法論的。
幾個我自己會處理的做法：
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豐富應用的功臣
數也數不清的友善使用者體驗 這就是ｊａｖａｓｃｒｉｐｔ
歡迎同好到 AJAX 板一同討論。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.140.46.76 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1601043823.A.4E9.html
→
09/25 23:09,
5年前
, 1F
09/25 23:09, 1F
→
09/25 23:10,
5年前
, 2F
09/25 23:10, 2F
→
09/25 23:10,
5年前
, 3F
09/25 23:10, 3F
→
09/25 23:11,
5年前
, 4F
09/25 23:11, 4F
→
09/25 23:11,
5年前
, 5F
09/25 23:11, 5F
推
09/26 02:51,
5年前
, 6F
09/26 02:51, 6F
→
09/26 02:51,
5年前
, 7F
09/26 02:51, 7F
推
09/26 05:29,
5年前
, 8F
09/26 05:29, 8F
→
09/26 05:30,
5年前
, 9F
09/26 05:30, 9F
→
09/26 05:31,
5年前
, 10F
09/26 05:31, 10F
你這三點講的基本上跟是不是老系統翻修無關，而是通用的開發負面因素。
※ 編輯: TonyQ (61.231.75.160 臺灣), 09/26/2020 08:45:19
→
09/26 08:59,
5年前
, 11F
09/26 08:59, 11F
→
09/26 09:00,
5年前
, 12F
09/26 09:00, 12F
→
09/26 09:08,
5年前
, 13F
09/26 09:08, 13F
→
09/26 09:09,
5年前
, 14F
09/26 09:09, 14F
這種情況應該避免動後面的資料結構，要試著在這前提底下進行。
只要新舊結構跟行為一致，就不用擔心需要大規模全換。
通常是有同時修改行為的野心才會出事。
※ 編輯: TonyQ (61.231.75.160 臺灣), 09/26/2020 09:48:47
推
09/26 10:00,
5年前
, 15F
09/26 10:00, 15F
→
09/26 10:00,
5年前
, 16F
09/26 10:00, 16F
開源專案接觸不到這種東西, 因為如果開源專案已經足夠多人用,
通常已經有自己的可靠性處理的策略, 你頂多是見習.
平常接些爛尾案對這些事情有幫助, 但抱著練功的心情就好.
不用刻意去接或以此為業~~
推
09/26 11:10,
5年前
, 17F
09/26 11:10, 17F
※ 編輯: TonyQ (210.61.209.201 臺灣), 09/26/2020 12:44:37
推
09/26 12:54,
5年前
, 18F
09/26 12:54, 18F
→
09/26 12:54,
5年前
, 19F
09/26 12:54, 19F
→
09/26 12:54,
5年前
, 20F
09/26 12:54, 20F
→
09/26 12:54,
5年前
, 21F
09/26 12:54, 21F
更明確點說, 我一貫的策略是判斷當下時間跟目標,
在風險能承擔的上線, 貼著風險承擔的邊緣走, 我做事情出包的機率不低,
但我都有把握出包的時候被收在安全範圍且迅速被解決.
這未必是風險最低的, 當然在論述時我會講得比較保守是因為冒險本來就需要判斷.
在正常狀況之下因為我對系統可承擔的風險比一般人高,
一方面多數情況下我對系統的熟悉跟經驗比別人多,
另一個角度是我比較敢動結構, 跟比較能清算動結構對應的風險.
所以在多數情況下, 我的改變相對於環境仍然是屬於激進跟大膽的,
但這個激進跟大膽的背後還是風險承擔跟計算.
主要的問題還是所有地方都一樣, 要能上得了線才是生存,
所以目標應該放在最安全的著陸, 而不是最大膽的登月計畫.
※ 編輯: TonyQ (210.61.209.201 臺灣), 09/26/2020 13:11:25
→
09/26 13:30,
5年前
, 22F
09/26 13:30, 22F
→
09/26 13:32,
5年前
, 23F
09/26 13:32, 23F
→
09/26 14:15,
5年前
, 24F
09/26 14:15, 24F
→
09/26 18:34,
5年前
, 25F
09/26 18:34, 25F
→
09/26 18:34,
5年前
, 26F
09/26 18:34, 26F
這不就是一種工作嗎？
推
09/26 18:35,
5年前
, 27F
09/26 18:35, 27F
→
09/26 18:35,
5年前
, 28F
09/26 18:35, 28F
那就要先對原本的系統進行骨幹分切作業。
※ 編輯: TonyQ (223.137.36.198 臺灣), 09/26/2020 19:22:42
※ 編輯: TonyQ (223.137.36.198 臺灣), 09/26/2020 19:29:34
推
09/26 23:42,
5年前
, 29F
09/26 23:42, 29F
→
09/27 00:47,
5年前
, 30F
09/27 00:47, 30F
Soft_Job 近期熱門文章
28
62
PTT職涯區 即時熱門文章
84
155