重构<1> --好好的项目,为什么要我一遍遍重写

唠嗑唠嗑

相信做过项目的朋友多多少少都会有一种经历,项目做到一半,从头再整理一遍,如果平时就写写函数接口的朋友应该是无缘体验啦。

当然,因人而异,有的人喜欢重构,有的人不喜欢。我写一个项目,一般会重头整理两三遍才最后提交,有些朋友那就是一遍过,个人有个人习惯吧,可能不喜欢重构的朋友觉得是在浪费时间吧。

那,没事儿,喜欢重构的朋友呢,下面的内容应该会有更多共鸣,不喜欢重构的朋友呢,希望通过这篇文章能对重构有所改观。

我也会分享一些我喜欢且习惯的重构方式,大头还是放在后续文章里。


统一定义:重构?是什么

对项目内部结构的一种调整,目的是在不改变成品可观察行为的前提下,使项目更加亲切,通俗易懂,高效。

喔,亲切排第一位,然后是通俗易懂,然后是高效。


为什么我喜欢重构?

首先那肯定得是重构使得项目更容易理解

怎么说更容易理解,大家心照不宣。

项目拿到手上,经过前期的立项、分析,分工之后,首先想的自然是赶紧实现功能吧,如果有哪位大神已经通篇规划之后再像填空一样填代码,我服。我目前还没有那么深厚的功底,所以当功能实现之后,我的项目就像是鸡啄米一样,混乱不堪但是暂时还是尽在掌握的。这时候就需要第一波重构了。

这一波重构啊,主要是拿着项目书,和团队再对接进度,然后把那鸡啄米一样的项目整理成那种豆腐块儿的样式,哪个功能,属于哪个类,哪些继承关系需要拓展,哪里需要换成虚函数,哪些公共部分需要独立出一个公用文件等等,最重要的是,注释该写的写全面。这次重构,就是将你手上那些“尽在掌握”的东西落实,省的过两天忘了点啥,那就凉凉了。

在整个项目功能完工时,还要进行一波重构,这波重构主要内容和第一次一样,不过我会把文件的排列方式改成我喜欢的风格,我会按照文件被使用的先后顺序对文件进行从上到下排列,这个山人自有方法。这样只要对整个项目的脉络清楚,就可以在最快的时间内找到那个文件,里面的那个特定函数,或者一堆函数。
因为,当工程文件多起来的时候,那也是真的多啊。

最后,还需要一波优化重构。

当我们在努力使得程序运转的时候,不会想到未来还会有人在看吧,现在还有朋友在看我的代码,我很庆幸我当时有将代码重构了好几遍。
当然,未来那个开发者多半是我们自己看自己的代码。。。。


重构提高编程速度!!

有的人可能不同意这一点啊,感觉像是在开玩笑,毕竟重构一次需要不少时间,这也不是开玩笑的。我一般,第一波重构要花个一两天,当然,我是个对自己有要求的人,所以我现在控制在一天。第二波重构也就花个半天,然后还能歇个半天,最后那波优化就比较久了。

但是,曾经一个亲身经历让我明白,重构所花费的时间都不算什么。那是我刚开始做项目时候的事情了,刚开始还好,代码之间的联系不多,写了几天之后,各个功能需要串在一起了,这时候麻烦来了。首先是函数接口不明朗,有的功能函数,单独的测试demo都好好的,但是一接起来就各种不适应出来,好不容易串起来了,又出现那种牵一发而动全身的状况,陷入泥潭之后,又发现有些细节的东西就忘了,不知道某些地方为什么要那样写,那样写的优势和意义在哪里?之前明明记得很清楚,这才几天咋就忘了。。。然后,然后···心照不宣,一把辛酸泪。

后面还是学不聪明,但是,栽了几次跟投就学聪明了。。。


重构帮助找到BUG

这个情况是比较少碰到啦,因为一些主流的bug存在的话测试都过不了哈哈,但是就怕有些隐患,测试的时候没测出来,重构的时候对整体,脉络的把控会有一定程度的加强,也就更加容易找出那些潜藏的bug,这是实在的,但是,看运气咯。


什么时候重构

什么时候重构上面也提到了一点,但是我还是要再说说,不然这篇短了点啊。

什么时候重构?什么时候想重构那就什么时候重构嘛。

事不过三

一般重构也不用重构很多次,三次差不多,做到中间的时候、做完的时候、优化的时候。
少了不好,多了确实浪费时间。

大改的时候重构

比方说要添加一些重要功能的时候,特别是那种后期会牵一发全身抖一抖的那种,这时候需要对项目又足够的把控的时候。


不行不行,手累,先到这儿吧,明天见。

©️2020 CSDN 皮肤主题: 撸撸猫 设计师:设计师小姐姐 返回首页