在我第一次進入主產品開發後，把代碼從 Github 上面 pull 下來。
「這是什麼鬼東西？」
結構混亂，大量覆寫的 class 各處都是，以及很可怕的巢狀 ID。
view 的部分也有些地方非常雜亂……。看來 legacy code 跟 refactor 永遠都在進行式。
對於日新月異的前端來說，要接觸一個新技術、框架並不是太困難的事。但困難點在於如何在現有的大型專案中做取捨，我們常常會有其他考量。例如團隊的接受度、team leader、其他政治因素等等而無法輕易地將新框架套用在目前的專案上。
這個系列的文章主要會分享如何在既有的專案中小心地進行重構。希望對各位有些幫助。
目前遇到的問題
HTML 的架構混亂肥大，許多 util class 四散各處，在 CSS 中更可以看到大量的覆寫 class。雖然聽說之前已經有整理過了，但顯然這個房間還充滿許多灰塵。
我認為前端常常遇到的 smell 問題有：
- 復用性不足：儘管已經採用 React，但仍有許多高耦合的 component。而且其中還夾雜著 flux 與 redux 兩種不同的 library
- 大量混雜業務邏輯的代碼（如 API ability 的判斷等），不僅要實際去了解業務流程外，還要知道檔案放在哪，必要時可能還要去看後端的程式碼
- HTML 的撰寫不夠語義化，充斥太多
util class及atomic class，後面接手的人比較難搞懂這行 view 裡頭所要表達的東西。 - CSS 檔案的撰寫不夠模組化。有太多混雜的模組都放在同一隻檔案中，查找非常不方便。
- 大量的覆寫 class 造成上版時有很多意外的狀況發生。
沒有統一的規範跟撰寫方式，很快代碼就會往指數性的肥大邁進。
身為一個前端工程師，經驗還稍嫌不足的我來說，雖然目前正在孤軍奮戰中，但其實還能做一些事。有問題對我來說是一件非常值得興奮的事，至少對我來說，那是一個可以捲起袖子來做事的大好機會。
解法
那麼，到底該怎麼做呢？我認為可以從以下幾點開始下手
- 著手撰寫
styleguide，讓自己與之後的前端團隊快速上手，並且有一定的準則可以遵守 - 技術選型：自動化工具、code quality 工具、選擇與淘汰
- test 框架：前端代碼大部分都還沒寫 test，未來等架構穩定的時候希望可以趕快補上。
- 讓重構變得簡單
- 讓 comment 及 doc 變成習慣： comment 的 doc 永遠是工程師的好朋友！
- 提交代碼的規範
本系列的文章主要會著重在重構的部分，最後一篇會再跟大家分享文件應該寫些什麼，以及前端如何提交代碼及發送 pull request 給 code reviewer。
目前已經大致撰寫了 styguide 的架構，下一步是逐漸重整 CSS 的架構以及拆分 HTML 組件。
這不是一朝一夕就能完成的東西，甚至就某種角度來看會拖延到專案的進度。有點像是默默付出的工作吧…！畢竟在原有的專案中做改變本來就有較大的阻力。
何時應該重構
隨時重構，不要為了重構而重構。再來可以參考三次法則)
- 上版的時候對現有的 HTML 及 CSS 重構，或者對應的 component
- 寫新的 js 模組時重構，順便撰寫 Comment 及文件
- 送 pull request 的時候：不過要確定自己有寫上詳細的 comment 及 doc，才能提高 code reviewer 的 review 意願，而 senior 總是能更快看出代碼裡面的問題。
我們常常對一些既有代碼的架構感到心癢，或者很想要趕快重構。但在 workaround 的情況下，有時重構的成本是非常大的。
何時不應該重構
其實比起重構來說，更重要的應該是拿捏不應該重構的程度。身為工程師或多或少都會對別人的代碼嗤之以鼻，恨不得趕快把 code 清掉。
但，既然 code 有某種程度的肥大，代表他或多或少解決了問題。而且重構是需要成本的。就算是以目前的開發來說，通常也是先著重於將功能實作後，在有限度地作小幅度的調整以及逐漸補齊文件及註解。對於重構來說，最重要的是 consistency。s
- 目前的解法雖然不漂亮，但確實解決問題的時候。
- 目前的代碼重複率還不高的時候
- 重構的成本太大，甚至影響到系統本身的時候。
保持心平氣和
重構的時候記得控制自己的情緒。我們很可能一不小心就在咒罵代碼或前任，然後在情緒上頭反而過度重構，造成更多的問題也說不定。
代碼的存在是有歷史的
有可能是進度太趕、有可能是政治因素、又或者當時的技術還沒到位。但可以確定的是，情緒化完全無法解決問題。
Talk is cheap. Show me the code.
下一篇，我會開始分享一些重構的技巧。
Final Word
最後還是要聲明一下，這篇文章雖然會著重在一些重構的技巧上，但其實從 legacy code 中尋找出口的方法不只是重構而已。希望大家不要過往矯正，一看到髒 code 就急著捲起袖子重構。退一步評估一下成本跟重構的價值再做決定。