看100篇架构设计的文章，不如干1次这个

程序，无论多么优秀的设计，往往随着我们不停的维护，代码总会变烂，特别是代码往往是不同人的维护，每个人的代码习惯，对业务的认识，对系统的理解都不一样，最重要的是，开发时间太赶了，导致代码越来越难以理解。

代码越多，就越来越难以理解，一个逻辑，可能散落在系统各个地方，我们常常把线上代码必成盗墓机关，稍有不慎，就会带来Bug。这是次要，为什么我们总在加班，因为很简单的功能，本来预估2个小时，后来写着写着才发现还要花18个小时来兼容其他逻辑问题。

发现原有的Bug

伟大的程序员，不是天生的。每一个程序员都会犯错误，也会留下埋得很深的Bug。重构，需要我们去深入梳理业务，深入了解每一行代码，对每一个代码中的“机关”做出假设，***总能发现意想不到的Bug。的代码中，常常有一些烂代码，最常见的情况莫过于几个一些重复的函数，无关紧要的类，无关紧要的逻辑。举个简单的例子，我们写一个电商计算运费系统，去数据库里面查询了用户的地址，快递公司的信息，用户有没有相关卡券，***却发现用户买的商品是虚拟产品，压根就不需要去计算运费！

架构师都是从重构开始的

这个其实才是最重要的，每一个架构师，都是从重构系统开始的！如果一个架构师没有重构过一个系统，那只能说他夸夸其谈，纸上谈兵。重构，对一个程序员的成长有多大？

• 对业务的代码非常熟悉，很快就能成长为骨干
• 重构的时候适合使用新技术，新框架，更有利于你的成长。
• 重构，又称高速上换轮胎，如何保证系统的稳定，是考验你真正实力的时候
• 重构的结果，必定会让你的上级对你刮目相看。
• 即便是重构出问题，损失的更多的还是老板，对于程序员，最多也只是丢掉饭碗。当然，出于职业道德，我们当然不能故意搞出问题。，一般都在比较大的需求变更的时候，当然，我们要选择在时间比较富余，公司有其他资源支持的情况下。重构的时候，我们当然要先深入理解业务，知会相应的测试，自己编写测试用例。当然，我们能引入自动化测试那就更好了。如果经理支持，那是***的情况，当然我一般都是先斩后奏，把需求做好的基础上，进行小规模的重构，完成后才向老板进行汇报。（这种还是要看老板而异，哈哈，只能说我运气好，遇到的老板都支持我折腾）

  总结

  重构，很多人很讨厌，大家都喜欢堆代码，追求完成功能。但其实，重构是对一个程序员***的成长机会，是让你成为架构师***的垫脚石，希望大家能
  

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!