Legacy Code是什麼?
我想可能很多人會在遊戲裡面看到Legacy，
不論是好裝備，還是遺產，
對於許多人來說都是能收獲東西，
但這個在程式碼中，
不是如此的東西，

每一間公司的程式員，
往往會更新著。
就如同忒修斯之船一般，
人員主管甚至框架技術都漸漸被換掉，
而一些程式碼也隨著當前技術人員的認識，
逐漸越來越難以理解，
這就是Legacy Code。

可能有些人有著一定的基礎，
這時候就會開始著手準備

但在此之前先讓我們來談談好處，
任何一件事情都有著兩面性。

最顯而易見的好處就是穩定，
就像筆者在OCP所說的，
只要確保硬體沒問題的狀況，
那麼軟體不論多久都能一直存續。

這種消極的做法，
但也往往是應對方法之一。

但這種作法也會越來越容易孳生Legacy Code，
可以看到我們在程式碼中要求，
往往都會要求一個最大的目的，
穩定。

那麼如何在保持穩定的狀況，
進行積極一點的作法呢？

那麼最為常見的做法就是重構（Refactoring），
Refactoring最主要的就為兩種要求，
1、保持功能不變，Refactoring過程中不改變程式碼的外部行為，
也就是不會讓client察覺正在重構。

2、改進程式碼結構，使其更好理解與維護。

在這邊筆者要特別強調一點，
Refactoring是不能跟優化畫上等號的。

在筆者與一些人交談的時候，
有一部分人會把這兩個畫上等號，
但其實這是不對的。

有時候Refactoring並不會造成效能提升，
甚至有可能讓效能降低，
Refactoring的目的是保持穩定的同時，
提升閱讀以利於後續進行維護修改與擴充。

Refactoring的這個行為，
甚至在絕大部分時間，
是在進行一項業務順手作的。

而這隨手做的詳細，
就是我們這次要探討的。

例如常見的名稱混淆，
如有時候會看到GetXXXDetailList
名稱上會難以認知是明細跟清單兩個混淆在一起，
這是顯著的無法認知具體要做什麼。

而在c#中，
有一個功能叫做IsPostBack，
這對於判斷是否第一次近來非常有用，
有前輩會把IsPostBack重命名為其他變數，再拿來使用，但這個做法不太好，
因為這違反了LSP的後製條件不應被削弱的理念，
雖然效果上並無差別，但以變數名稱解讀上，功能容易被削弱。

這是筆者最常做的事情，
而說道這裡，
我們要切回標題一下，
這一篇文章圍繞著筆者過去所被問過的所有題目而誕生。

那麼筆者被問這個回答是這麼回答的呢?
在曾經筆者被詢問的情況是這樣的。

面試官問筆者：
會特地安排時間重構嗎?

筆者有點疑惑地說不會，都順手作。

為什麼呢?
因為就以前面的例子來說，
筆者就常常在日常工作中進行少量的重構，
而很顯然的筆者所說的重構（Refactoring）會是什麼狀況。

在於一些狀況可能要特別的去理解當前的情勢，
筆者複盤後，
覺得在許多狀況下回應過於單調。

當然引導是面試官的責任，
但展現也會是面試的一環。

基於此，
筆者可能現在會這樣回答，

筆者所認為的重構（Refactoring），
是在不改變外部的行為下所進行的，
並且也不會去特地安排時間去做這個行為，
接著請面試官解說他所說的情況是發生什麼狀況，
針對他的回答進行解讀。

當然這是筆者的認知，
Refactoring不是優化，
目的是利於後續作業。

就像筆者之前曾說過，
軟體不像現實中的東西，
那麼不論多久都能一直存續，
所以它的好處就是穩定，
只要不動就沒事情。

---推薦各位去看
推薦各位去看，筆者所說的內容並沒有像這位前輩一樣簡潔，
目的行為結果描述得很明確，
筆者遇到的狀況也只是其中幾種，
真心推薦大家去看

筆記：重構 — Chapter 1 & 2：第一個範例 & 重構原則
https://medium.com/%E5%BE%8C%E7%AB%AF%E6%96%B0%E6%89%8B%E6%9D%91/%E7%AD%86%E8%A8%98-%E9%87%8D%E6%A7%8B-chapter-1-2-%E7%AC%AC%E4%B8%80%E5%80%8B%E7%AF%84%E4%BE%8B-%E9%87%8D%E6%A7%8B%E5%8E%9F%E5%89%87-ca57a6d40f42