浅谈重构

1.重构概念

在不改变软件的外部行为的基础上,改变软件内部的结构,使其更加易于阅读、易于维护和易于变更。——《重构 改善既有代码的设计》

说白了重构就是一系列的“等量变换”!

2.重构的风险

当我们遇到公司前人留下的烂代码时(很多时候我们也是留下“烂代码”的人),一般都是先开骂,其次就捉摸着干脆重做算了,一般都不愿意修改和重构,我们通常给出的理由是“代码太烂了,还不如重做”,这也就骗骗产品狗和老大罢了,真实的原因只有一个:里边埋坑太多,业务复杂,文档缺失,改坏了要承担后果。

所以重构有风险,重构需谨慎!

原则上如果你的老大不支持重构的话,你最好不要私自去做这件事,因为弄不好你改坏了就麻烦了,现在国内的互联网公司整天把事故什么的计入KPI,直接关系你的职业前程。

3.如何确保重构的成功

重构风险那么大,是不是说我们就不能做这件事了?如果我只是改了一个变量名,那应该不会有太大问题,还是有点不放心,那就干脆测试一下,事实证明本次重构百分百不会出什么幺蛾子。这就给了我们启示:“小步快跑” + “及时测试”,因为这样修改的代码量少,所用时间也少,每次只关注一个方面,从而极大地降低了重构的风险。如果你能遵从这个原则,重构就是So Easy的事情!

4.重构方法

初步重构,我们可以:添加注释、调整顺序、重命名变量、进行分段,再进一步我们可以:抽取方法、抽取类、抽取接口等等,运用一些典型的设计模式,修改一些不合理的数据结构,优化算法,运用一些语言新特性改写老的代码,进行并行和异步编程等等 ,方法不一而论,但并不是说都用上了就牛逼,能够在以后的实际工作中学着实践应用其中一些典型的方法就已经难能可贵了

5.保证代码质量

互联网行业业务发展迅速,需求过多,程序员为了赶工期往往“不择手段”实现功能,乱七八槽但是却实现了功能,心想以后有时间了再去重构,真实的调调是往往不了了之。再加上很多时候我们对代码又缺乏有效的CodeReview,烂代码就会越来越多,越到后面维护这些代码越苦逼。与其以后高风险地重构,不如从一开始就注重代码的质量,所以请一开始就以重构的思想写代码,做好CodeReview,从公司的层面来讲如果能从长远利益和维护成本角度来思考问题的话,就会明白代码质量的重要性,高质量的代码避免了大量的重构,降低了软件的风险和公司的成本,无形中增加了公司的收益!

时间: 2024-10-09 18:47:32

浅谈重构的相关文章

浅谈压缩感知(二十四):压缩感知重构算法之子空间追踪(SP)

主要内容: SP的算法流程 SP的MATLAB实现 一维信号的实验与结果 测量数M与重构成功概率关系的实验与结果 SP与CoSaMP的性能比较 一.SP的算法流程 压缩采样匹配追踪(CoSaMP)与子空间追踪(SP)几乎完全一样,因此算法流程也基本一致. SP与CoSaMP主要区别在于"Ineach iteration, in the SP algorithm, only K new candidates are added, while theCoSAMP algorithm adds 2K

重构机房收费系统—浅谈三层

重构机房基本完成了,期间三层重构完了,推翻之后,再重构七层(外观和工厂),再重构,来来回回用了一个月........ 重构机房从画图画到一半就废弃了,因为对三层不熟,之后,做完了,才敢重新拾起来画.画图先从包图开始,宏观上有个了解: (一)重构机房包图: 先前画包图的时候,跟师傅交流,结果被一个师姐给笑话了,因为我认为:它们各个层之间都是双向箭头的,后来才知道,箭头表示调用关系,B层只能被U层或外观调用,B层不能调用U层,所以不存在双向箭头,大家注意. 在我这次重构中是严格按照上面的图中来的.

浅谈代码重构与优化

浅谈代码重构与优化 前几天看到有一篇不错的文章减少该死的if-else嵌套,觉得写得很不错,整理了一下后准备在团队内部简单分享一下. 写在前面 大家在接手项目的时候,应该有遇到过下面这种结构的代码 if (true) { ..... if (true) { if (true) { .... if (true) { if (true) { ...... } } // do something } // do something if (true) { ......... } } // do som

图标字体化浅谈[转]

在做手机端Web App项目中,经常会遇到小图标在手机上显示比较模糊的问题,经过实践发现了一种比较好的解决方案,图标字体化.在微社区项目中,有很多小的Icon(图标),如分享.回复.赞.返回.话题.访问.箭头等,这些Icon(图标)一般都是纯色的.开始制作时考虑用双倍大小的Sprite图,通过CSS样式设置只显示二分之一尺寸,这样在Retina屏上显示的大小是正常的,一旦放大屏幕后图标又变得模糊不清,测试的效果不是很理想,后来又考虑多套图标适配方案.SVG矢量图等,都因为种种原因放弃掉了(如多套

浅谈移动前端的最佳实践(转)

前言 这几天,第三轮全站优化结束,测试项目在2G首屏载入速度取得了一些优化成绩,对比下来有10s左右的差距: 这次优化工作结束后,已经是第三次大规模折腾公司框架了,这里将一些自己知道的移动端的建议提出来分享下,希望对各位有用 文中有误请您提出,以免误人自误 技术选型 单页or多页 spa(single page application)也就是我们常常说的web应用程序webapp,被认为是业内的发展趋势,主要有两个优点: ① 用户体验好 ② 可以更好的降低服务器压力 但是单页有几个致命的缺点:

管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革

管理从砖瓦进化为人 --浅谈传统软件工程到敏捷软件开发之变革 前言 如果把软件开发过程比作修筑一座建筑的话,传统的软件工程方法对人的管理就像是把人化作一砖一瓦,秩序地堆砌,一层一层构建起摩天大厦. 显然地,人是不同于砖瓦那样的死物的.人作为一种复杂的动物,软件开发者会有喜怒哀乐,枯燥重复的工作内容会使他们提不起兴趣而缺乏激情:客户想法会随变动的现实而一天天有所转变,软件需求很难保持一成不变:开发者与测试者对于项目的认识会存在差异,而差异将导致效率的降低--因而传统的有些"反人类天性"的

浅谈数据库框架,见笑,请多指正

浅谈数据库框架,见笑,请多指正 http://weibo.com/p/1001603724746155003486 一友说"插件式存储又割裂了SQL引擎的完整逻辑...总体而言在现有框架下MySQL的优化器没有多大改进的价值". 我们且做个技术分析: 1 插件式框架,可以静态/动态加载组件,方便在同类不同属家的模块间切换,这种设计是良好的. 很多软件的设计都采用了"微内核+插件"这样的方式构筑了强大的应用.如Ecplise生态圈. 2 数据库范围内, MySQL的属

浅谈android架构设计

到目前为止,android开发在网络上或者社区上没有公认的或者统一的开发框架,好多框架都是基于对方法的封装.今天在这浅谈两年来对android开发的理解,主要是思想上的理解,希望对大家有帮助. 我认为android开发可以从两个方面去总结架构的设计,在这里对于实现只做陈述: 一,就是大多数人的设计思路,对方法的封装. 在这里我根据开发的习惯对工程进行包的设计: 1. http:网络请求方法封装.这里建议采用线程+Handler的模式,把Http 中get方法和post两种请求方式分开,对于正常的

浅谈商城活动设计

如题:浅谈商城活动设计 标题改成“浅谈商城活动的数据库设计”可能更加合理. 文章背景 为什么要吐槽,为什么要写这篇文章 本来我在弄大数据搜索,自己玩的不亦说乎,虽然感觉数据库设计不合理,但我可以数据清洗,弄到自己的搜索引擎里,自己随便玩,所以当时感觉在烂的数据库设计和我关系不大,只要我把数据清洗好,弄到自己的引擎里我的搜索正常,准确,问题不大.但忽然有一天老大跑来说ERP对接需要你来lead一下,然后一两个月带着捣乱的产品妹妹,和没有经验开发弟弟搞了ERP的简单对接,然后老大又说咱们商城库存总有