淺談關於代碼重構與優化的問題

關於代碼重構與優化的問題，在做前端開發的時候也時常會遇見，在這段時間裡面，可能是對自我要求比較高，不僅僅是項目能完成，功能正常使用這一層面上。還儘力的研究怎麼寫出優雅的代碼，性能更好，維護性更強的代碼，通俗一點就是重構。本文是我一個小記錄，在此分享一下例子也簡單，深入複雜的例子等以後有適合的實例再進行寫作分享。

首先需要明白什麼是重構？其實，重構不是重寫。重構大概的意思是在不影響項目的功能使用前提下，使用一系列的重構方式，改變項目的內部結構。提高項目內部的可讀性，可維護性。無論是什麼項目，都有一個從簡單到複雜的一個迭代過程。在這個過程裡面，在不影響項目的使用情況下，需要不斷的對代碼進行優化，保持或者增加代碼的可讀性，可維護性。這樣一來，就可以避免在團隊協作開發上需要大量的溝通，交流。才能加入項目的開發中。

為什麼需要重構？就像衣服髒了就洗，破了就補，不合穿就扔。尚學堂?百戰程序員陳老師指出隨著業務需求的不斷增加，變更，捨棄，項目的代碼也難免會出現瑕疵，這就會影響代碼的可讀性，可維護性，甚至影響項目的性能。而重構的目的，就是為了解決這些瑕疵，保證代碼質量和性能。但是前提是不能影響項目的使用。

至於重構的原因，自己總結了一下，大概有以下幾點：

函數邏輯結構混亂，或因為沒注釋原因，連原代碼寫作者都很難理清當中的邏輯。

函數無擴展性可言，遇到新的變化，不能靈活的處理。

因為對象強耦合或者業務邏輯的原因，導致業務邏輯的代碼巨大，維護的時候排查困難。

重複代碼太多，沒有復用性。

隨著技術的發展，代碼可能也需要使用新特性進行修改。

隨著學習的深入，對於以前的代碼，是否有著更好的一個解決方案。

因為代碼的寫法，雖然功能正常使用，但是性能消耗較多，需要換方案進行優化

那麼何時需要重構呢？在合適的時間，在合適的事情。在我的理解中，重構可以說是貫穿整一個項目的開發和維護周期，可以當作重構就是開發的一部分。通俗講，在開發的任何時候，只要看到代碼有彆扭，激發了強迫症，就可以考慮重構了。只是，重構之前先參考下面幾點。

首先，重構是需要花時間去做的一件事。花的時間可能比之前的開發時間還要多。

其次，重構是為了把代碼優化，前提是不能影響項目的使用。

最後，重構的難度大小不一，可能只是稍微改動，可能難度比之前開發還要難。

基於上面的幾點，需要大家去評估是否要進行重構。評估的指標，可以參考下面幾點

數量: 需要重構的代碼是否過多。

質量: 可讀性，可維護性，代碼邏輯複雜度，等問題，對代碼的質量影響是否到了一個難以忍受的地步。

時間: 是否有充裕的時間進行重構和測試。

效果: 如果重構了代碼，得到哪些改善，比如代碼質量提高了，性能提升了，更好的支持後續功能等。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！