有位名人说过,程序都有两面性,一是程序今天可以做什么,二是程序明天可以做什么。通常,我们只关心,准确地说,是老板只关心,程序今天能做什么。虽然老板口头上天天喊着关心程序员成长,程序质量最重要,但实际上还是进度最重要。
什么是重构
什么是重构呢?重构是对软件内部的结构性调整,在保持原有的功能的前提下,提高程序的可理解性,降低修改的成本,提升程序的运行性能。
让代码更容易理解
我们的程序,无论多么优秀的设计,往往随着我们不停的维护,代码总会变烂,特别是代码往往是不同人的维护,每个人的代码习惯,对业务的认识,对系统的理解都不一样,最重要的是,开发时间太赶了,导致代码越来越难以理解。
代码越多,就越来越难以理解,一个逻辑,可能散落在系统各个地方,我们常常把线上代码必成盗墓机关,稍有不慎,就会带来Bug。这是次要,为什么我们总在加班,因为很简单的功能,本来预估2个小时,后来写着写着才发现还要花18个小时来兼容其他逻辑问题。
发现原有的Bug
伟大的程序员,不是天生的。每一个程序员都会犯错误,也会留下埋得很深的Bug。重构,需要我们去深入梳理业务,深入了解每一行代码,对每一个代码中的“机关”做出假设,最后总能发现意想不到的Bug。
提高程序的运行速度与编译速度
我们的代码中,常常有一些烂代码,最常见的情况莫过于几个一些重复的函数,无关紧要的类,无关紧要的逻辑。举个简单的例子,我们写一个电商计算运费系统,去数据库里面查询了用户的地址,快递公司的信息,用户有没有相关卡券,最后却发现用户买的商品是虚拟产品,压根就不需要去计算运费!
架构师都是从重构开始的
这个其实才是最重要的,每一个架构师,都是从重构系统开始的!如果一个架构师没有重构过一个系统,那只能说他夸夸其谈,纸上谈兵。重构,对一个程序员的成长有多大?
何时开始重构,需要注意什么
重构,一般都在比较大的需求变更的时候,当然,我们要选择在时间比较富余,公司有其他资源支持的情况下。重构的时候,我们当然要先深入理解业务,知会相应的测试,自己编写测试用例。当然,我们能引入自动化测试那就更好了。如果经理支持,那是最好的情况,当然我一般都是先斩后奏,把需求做好的基础上,进行小规模的重构,完成后才向老板进行汇报。(这种还是要看老板而异,哈哈,只能说我运气好,遇到的老板都支持我折腾)
总结
重构,很多人很讨厌,大家都喜欢堆代码,追求完成功能。但其实,重构是对一个程序员最好的成长机会,是让你成为架构师最好的垫脚石,希望大家能够好好珍惜这个机会,学好相关的重构技巧,大胆尝试!(同名公众号,沙茶敏碎碎念)