前搜狗搜索技术负责人郭昂指出:大多数重构可以避免
郭昂,前搜狗网页搜索效果负责人、前搜狗搜索广告算法负责人,现任职马可波罗采购搜索技术副总裁。他在自己博客中发表一篇文章谈重构,在微博上也引起不少反响。
郭昂,前搜狗网页搜索效果负责人、前搜狗搜索广告算法负责人,现任职 马可波罗采购搜索技术副总裁。他在自己的博客上写了一篇文章《 漫谈重构》,提到重构要解决的问题,以及自己的感受。
郭昂在前后两家公司的工作中,主持和经历十余次重构,涉及代码和架构。在他看来,如果不做重构,任代码随意膨胀,就会产生糟糕的架构,其恶劣影响包括:
首先是开发效率的降低,在糟糕架构下加进新功能,会受之前代码的影响,可能存在意想不到的改动点和问题点,开发和调试时间都会大大增加;其次是故障率的提升,在质量低下的代码中,总是容易藏着很多不易发现的坑,这些都会成为故障的隐患;同时,架构也会使得需求的完成大打折扣,使得设计好的目标,因为架构限制或者性能等原因,只能完成80%甚至更低。
接下来,他列出了重构要解决的各种问题:
- 结构糟糕:五千行以上的文件,三千行以上的函数,面对这样子的代码,对其进行修改和继续开发是件很艰难的事情。
- 安全隐患:很多代码,为了快速完成功能,对很多潜在安全风险置之不管,如内存管理、异常处理、模块接口等,迟早有一天会爆发。
- 性能问题:对于很多大型服务,性能高一点可以节省很多服务器费用。性能的核心问题大多在出代码上。
- 功能扩展:有的模块,开始设计时只是实现一些很基本的功能,而随着产品功能不断增强,需要进行重构以让其能够实现新赋予的任务。
- 协同开发:大系统需要多人一起开发,如果需要改同一个类甚至同一个函数,往往是冲突不断,而代码的整合往往也会存在更多问题。这时候需要很好的架构能够支持多人共同开发和修改。
- 模块调试:大系统中有很多子模块互相关联,假如某个模块的调试需要启动整个大系统,或者会受到其他模块稳定性的影响,效率非常低。通过重构建立调试层,或者开发调试工具是更好的选择。
- 模块复用:不同项目或模块重复开发相同功能子模块,在很多公司都很常见。将公共部分抽象出来,能够将这部分做得更好更精,从整体上,往往能大幅度提高开发效率和效果,往往也能优化算法性能。
- 算法使用不当:使用不恰当的数据结构或者相关算法,会使得性能或效果出现问题。这种情况,甚至要将原有的体系结构推倒重来,重新设计算法和数据结构,达到尽可能好的匹配效果。
- 承载规模不够:一些系统有其设计的容纳规模,例如瞬间访问量、同时在线人数,当超过一定量级时,很多时候并非简单通过加服务器能解决,有时需要重新设计架构。
接下来,他总结了自己重构经历的经验和感受,指出“第一道难关是如何过领导这道关”:
很多领导都要背着产品指标和任务,重构这种事情,在很多时候,有可能是“费力不讨好”的代名词,因为在大多情况,无法帮助领导完成指标。
他的建议是:
让重构与某些技术或产品指标挂钩,例如完成新产品、改进效果、提高性能等,相当于是重构伴随着其他改进搭帮上线,那么这种情况可以比较顺利的完成重构。
……
而如果单纯为了架构的合理性而去重构的话,就需要去说服领导,为什么原来的架构会降低开发效率,新做的架构能带来哪方面的提升。一定要让领导明白,这个能带来实实在在的长期收益,不管性能、效率、安全等都可以,而并非只是“看着不爽”而进行的重构。
在团队规模有保证的前提下,郭昂建议可以分工,一部分开发新架构,另一部分进行架构改进,保证长期目标和短期目标都可以落实:
值得注意的就是,不管从代码还是设计角度上来看,都要让现有做的事情能够复用,而不是新架构上线之后就会被废掉。
对于渐进式重构,郭昂建议:
以月为单位,快速的迭代,能够很快的看到效果,并且小规模投入使用。
对于重构中新架构的设计,郭昂指出:前瞻性、复用性、避免技术完美主义、避免使用过多未经广泛使用的前沿技术,这都应该注意。
他认为:重构的负责人非常重要。
作为重构时的负责人,一定要紧跟代码开发的过程,并随时进行指导,一般情况下,不要相信写出糟糕代码的人,经过略加指导就能写出漂亮代码了。……重构的工作一定要做细,迭代中的代码检查也是必不可少的。
在文章最后一部分,郭昂指出:
大多数的重构都是可以避免的,这需要从以下几个方面去提高。
良好的编码风格,好的习惯往往很难天然形成,更多是在工作中不断的老带新中耳濡目染练出来的。
初期的架构设计,也是非常重要。好的架构,对未来的开发以及发展,可以说是真真实实的“事半功倍”。
更重要的是,需要的是不断的提高程序员的自我修养,不仅仅是能力上的,还有态度上的。不要只想最初开发时省事,而不考虑若干时间后的事情。
郭昂文中有一句话可作总结:
不管怎样, 重构,一定不能是为了重构而重构,……最重要是找准其要解决的实际问题。
在相关微博评论中, 王东at搜狗认为:
1,重构的负责人很重要,有完美主义情结是加分项;
2,在架构更加合理的同时,效果至少不能变差,所以重构的过程中,最好多次review效果,而不是一气呵成;
3,重构任务分期进行,先改框架,抽象函数或类,再优化数据结构和算法,最后按代码规范拆分文件、函数和语句,增加必要的容错和注释
百度知识搜索部工程师 TroyCheng指出:
知道qb和search重构给我的感受亦是如此。有几点也是一直再强调的。重构或新模块第一版的结构设计,代码质量,程序员的自身修养,团队code review等。深有同感。
@万星很微薄说:
小重构可能每分钟都在做,中型重构在项目的某些阶段做,大型重构在产品的某些阶段做。
对此, 王志华在西二旗的回复是:
每分钟都做好重构基本以后不需要重构,持续局部优化会导致整体优化
郑柯 郑柯,实用的理想主义者,相信:每天改变一点点,这个世界会更好。