代码优化随想

这不是一篇技术文章，只是最近作代码重构的一些心得和想法。

要有坚决的目标

从某种程度上来讲，重构是件费力不讨好的事，尤为是在业务驱动的团队，毕竟重构并不能带来直接、可量化的收益。

业务只看到功能能不能跑，不会管用什么姿式跑。不少时候也会发现，你的同事简简单单堆砌代码被表扬高效作的多，得到好的回报，而你只能默默前行，若是没有明确和坚决的目标，极可能就半途而废了，而半途而废甚至不如不作，至少不作你还知道这是对的。

重构的目标必定要符合行业主流规范，如MVC，组件化，服务化，可重用。代码必定要高效、简单易懂，这点很重要，技术人总有一种炫技的冲动，写出只有本身能看懂的代码并不能收获同行者。

清晰的计划

用嘴写代码老是不可行的，要想达到目标，少不了一个清晰的落地计划。就像作任何事情同样，总会遇到阻碍，有不少的需求须要处理，会被打扰，在没有可见的成果以前，也不会获得支持，毕竟在线业务，稳定大于一切。

从见效最快的地方作起，若是优化一个缓存结构，能够提高60%的性能，那应该果断把它作了。

从局部作起，拆一栋房子不敢，拆一个窗户还能楼塌了？

若是无可奈何须要试错，从边缘业务开始尝试，并要考虑充分回滚方案，可在线调整配置的方式是风险相对较少的。

持续的作，慢慢的就会有成果，大胆的分享这些成果和经验，这时再去作更大的尝试，就会有一些支持了。

重构老是有风险的，要接受这个现实

毋庸质疑，重构必定会有风险，否则也轮不到你作。咱们能够，也必定会犯错误，须要接受这个现实，只有这样，才能理解如何下降这些错误带来的影响。

要坦诚，出错了不要掩饰，一次掩饰过去并不能消除别人对你的怀疑，但必定会给人不可信任的印象，下次就会失去试错的资格。

不要盲目自信，尤为是汲外部调用不少的逻辑，在确保彻底搞清楚逻辑以前，不要乱动，调研清楚。

要借助工具，代码老是比人可靠。完善的单元测试，自动化测试，总能覆盖你想不到的点，得到意想不到的收获。

幸运女神不会一再眷顾，你必须本身寻求突破。

原文摘自个人公众号，有增删。