🔧 阿川の電商水電行
如果你曾經打開過一個程式碼庫，然後立刻小聲嘀咕“哦不…”，那麼這篇文章就是為你準備的。
多年來，我與無數面臨系統遷移的開發人員進行過交流，他們提出的問題和遇到的挫折都如出一轍。我突然意識到：我們並非在與遺留系統本身作鬥爭，而是在與圍繞它的種種迷思作鬥爭。
昨天我在JS Poland 大會上發表了關於將舊前端遷移到現代工具的不同策略的演講。哇——真是精彩的一天！
感謝所有到場的朋友。我玩得很開心，也希望你們有所收穫（或至少喜歡我講的「古代程式碼考古」笑話😄）。
受演講後所有討論的啟發，我決定寫下關於遺留系統的最大誤解——我們作為開發人員經常重複的那些話，以至於它們聽起來像是普遍真理……即使它們並非如此。
讓我們來逐一揭穿它們👇
迷思一：“傳承意味著古老的或異域風情的。”
不。傳統科技不一定是指上世紀90年代那些神祕的、被遺忘的科技。
有時候，它只不過是……昨天的主流而已。
-
一個略微過時的Angular版本
-
一個包含大量類別元件的 React 程式碼庫
-
一個「仍然有效，所以不要動它」的 Webpack 3 配置
遺留問題並非指工具的年代久遠，而是指工具與當前環境的不符。當團隊、生態系統或業務發展到新的階段，而程式碼庫卻沒有相應更新時，該工具就變成了遺留工具。
迷思二：“歷史遺留問題是前任團隊的錯。”
這條總是讓我發笑。
你幾乎永遠不會知道你繼承的程式碼背後的全部故事：
-
或許這個計畫已經停滯了6年。
-
或許團隊缺乏足夠的經驗或時間來進行遷移。
-
或許唯一一個了解一切的人在 2018 年離開了公司。
（我們都認識那種人。）
指責別人很容易，理解事情的來龍去脈更難——但也更有效率。
迷思三：“遷移只是開發人員的執念。”
我希望如此😅
歷史遺留問題可能會在不知不覺中損害企業：
-
安全問題
-
效能問題
-
不斷上漲的維護成本
-
由於每個新功能都像是在拆除炸彈，所以交貨速度放緩。
遷移不是為了面子，而是為了風險管理。
迷思四：“大爆炸式重寫總是一種反模式。”
大爆炸式重寫劇本的名聲很差——通常是有充分理由的。
但有時它們是最便宜、最快捷的解決方案。
如果應用程式規模小、功能獨立且並非關鍵任務型應用，那麼可以進行徹底的重寫：
-
更簡單
-
更安全
-
更快
-
而且比耗時數年重構舊程式碼輕鬆得多。
並非每次遷移都需要像 Netflix 那樣的多階段大工程。
迷思五：“絞殺式編織法是唯一正確的編織方法。”
絞殺者遷移非常適合大型、複雜的應用程式。但它也存在一些缺點：
-
這需要時間（很多時間…）
-
你將面臨永無止境的遷移。
-
你的團隊需要同時掌握兩種技術。
-
新舊之間的界線可能會變得模糊不清。
它只是一種工具，而不是一種宗教。
有時候，絞殺者是完美的。
有時候，宇宙大爆炸是完美的。
有時候你需要一種混合型產品。
真正的技巧在於根據自身限制條件選擇合適的策略。
最後想說的
遺留系統並非失敗，它只是軟體自然生命週期的一部分。
任何程式碼庫最終都會變成遺留程式碼——包括你今天正在寫的這個 😉
重要的是要了解各種權衡取捨，選擇正確的遷移策略，並避免那些讓傳統系統看起來比實際情況更可怕的誤解。
原文出處：https://dev.to/sylwia-lask/5-myths-about-legacy-code-you-should-stop-believing-pi3
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
