代碼優化隨想

這不是一篇技術文章，只是最近作代碼重構的一些心得和想法。

要有堅決的目標

從某種程度上來講，重構是件費力不討好的事，尤爲是在業務驅動的團隊，畢竟重構並不能帶來直接、可量化的收益。

業務只看到功能能不能跑，不會管用什麼姿式跑。不少時候也會發現，你的同事簡簡單單堆砌代碼被表揚高效作的多，得到好的回報，而你只能默默前行，若是沒有明確和堅決的目標，極可能就半途而廢了，而半途而廢甚至不如不作，至少不作你還知道這是對的。

重構的目標必定要符合行業主流規範，如MVC，組件化，服務化，可重用。代碼必定要高效、簡單易懂，這點很重要，技術人總有一種炫技的衝動，寫出只有本身能看懂的代碼並不能收穫同行者。

清晰的計劃

用嘴寫代碼老是不可行的，要想達到目標，少不了一個清晰的落地計劃。就像作任何事情同樣，總會遇到阻礙，有不少的需求須要處理，會被打擾，在沒有可見的成果以前，也不會獲得支持，畢竟在線業務，穩定大於一切。

從見效最快的地方作起，若是優化一個緩存結構，能夠提高60%的性能，那應該果斷把它作了。

從局部作起，拆一棟房子不敢，拆一個窗戶還能樓塌了？

若是無可奈何須要試錯，從邊緣業務開始嘗試，並要考慮充分回滾方案，可在線調整配置的方式是風險相對較少的。

持續的作，慢慢的就會有成果，大膽的分享這些成果和經驗，這時再去作更大的嘗試，就會有一些支持了。

重構老是有風險的，要接受這個現實

毋庸質疑，重構必定會有風險，否則也輪不到你作。咱們能夠，也必定會犯錯誤，須要接受這個現實，只有這樣，才能理解如何下降這些錯誤帶來的影響。

要坦誠，出錯了不要掩飾，一次掩飾過去並不能消除別人對你的懷疑，但必定會給人不可信任的印象，下次就會失去試錯的資格。

不要盲目自信，尤爲是汲外部調用不少的邏輯，在確保徹底搞清楚邏輯以前，不要亂動，調研清楚。

要藉助工具，代碼老是比人可靠。完善的單元測試，自動化測試，總能覆蓋你想不到的點，得到意想不到的收穫。

幸運女神不會一再眷顧，你必須本身尋求突破。

原文摘自個人公衆號，有增刪。