查看: 219|回复: 0

浅谈重构中踩过的坑

[复制链接]

该用户从未签到

发表于 2019-11-4 16:58:31 | 显示全部楼层 |阅读模式
文章首发于【博客园-陈树义】,点击跳转到原文浅谈重构中踩过的坑


近来重构了公司一个将近10年的核心功能模块,踩了不少坑。在做这个重构的时候好频频都觉得做不下去,好频频压力都非常大,心想着我该不会做着做着就退出编程届了吧。
不过还好,自己照旧对峙下来了,追念写这个项目标时候自己曾三次推翻重来,那种心路进程真的只有经历了才知道,真是煎熬。厥后追念起这一路踩过的坑,其实更多的是经验问题,而不是技能方面的问题。
关于心态

回顾做这个项目,我觉得心态问题是最告急的,技能问题倒是其次。为什么这么说呢?由于对于10余年的老功能模块来说,其中最复杂的其实是业务逻辑,而并非技能实现。所以对于老体系的重构,你首先需要将这十余年来积淀在该模块的业务逻辑梳理清楚,这自己就给了重构者一个无形的压力。再加上又是核心业务模块,少一点业务逻辑就会导致线上收入的淘汰,末了就是程序员祭天的悲凉运气。这一系列的背景,使得重构之时心理压力真的很大。
现在回头来看,对于重构项目,最好的方式照旧先仔细致细梳理清楚所有的业务逻辑,之后将其用思维导图画出来,这样你会对这十几年来的业务逻辑一清二楚。清楚了业务逻辑,对于你后面进行体系重新设计以及编码都是大有裨益的,以致是起决定性作用的一环。
说到心态这个话题,无论是做什么项目,即使是重构,也会涉及到排期问题。偶然候很大概你自己还没完全了解业务逻辑之时,上级就要你给出一个排期,这时候其实作为重构者是很为难的。对于这种情况,其实我建议照旧与上级做好充分的沟通,如果能延长给排期的时间是最好的。如果不能,那应该自动上报每天的进度,让上级知道你的进展。其实要你给出排期,不就是为了掌控进度吗。
当你给出排期后,很大概会出现了许多其时预估排期时没有出现的情况,这时候一样平常我们有两种选择:一种是急急遽忙草草处理了事,另一种则是稳放心态思索最好的解决方式。其实当你发觉另一种做法是更好的处理方式,但这种方式在现在排期下无法完成,这时候作为团体功能的开发重构人,你应该有自己的判断。即使是由于做了这件事情而延期,但只要你做的这件事情是对的,有利于体系拓展性和稳固性的,那照旧应该对峙自己的选择。我想,如果你由于正确的对峙而延期,我想公司并不会因此而责怪,只要你给出了自己的理由。最怕的是惶恐失措地写完一个东西,而这东西又漏洞百出。
所以偶然候觉得开发或重构一个体系真的是得抱着必死的刻意,这样才气有自己的对峙,而不会在上级的排期压力之下做堕落误的选择。特殊对于重构类的项目,如果没有一个从容的心态,那体系是肯定做欠好的。
关于本领

我觉得重构中的经验本领远告急于技能实力,由于一个经验可以让你淘汰很多不须要的麻烦。在说出我的心得之前,我想问一个问题:
在你重构的时候遇到一个问题,这个问题解决了会更好,但不解决也不会影响到此次项目标结果。请问,此时你是解决这个问题,照旧不解决好?
有些人会分析:这要看情况,如果我偶然间我会去解决,如果没偶然间,那我就会跳过它。一样平常会给出这种答案的人,都是理论上的巨人,行动上的矮子,基本可以断定没有经历过实战。由于其分析很符合马克思主义的辩证主义思想啊,这也确实没错。但这样的解决方式对于现实情况是不够有用的。
对于这种情况,我建议是不做。准确地说:对于任何不影响你告竣重构目标的事情,能不做就不做。由于你永久不知道这个坑到底有多深!在你并不知道坑有多深,而此时又有排期(追兵)在后面,这时候最聪明的做法就是不做。等你把必须做的做完了,你再回头来看看这个问题,如果你可以解决,那就尝试着解决。但如果此时你发现坑真的很深,你可以果断返回,这时你其实已经做完了事情,并不会有排期的压力了。这样的做法给自己留足了后路,自己可进可退,可攻可守。但如果你一开始就选择踩这个坑,那么大概你会让自己陷入泥潭。
所以建议大家在不清楚的情况下不做,不是叫大家办事懒惰。而是让大家明确自己的目标是什么,在资源(时间)有限的情况下把事情做成。
关于技能

技能是放末了的,由于我确实觉得技能在重构中并不是特殊告急。至少在我这次重构中,我基本上60%的工作都是由于我的心态或本领不足导致的重复劳动。我项目中重构涉及到的技能,我只用了不到10%的时间就完成了。回头想一想,真是觉得好凄凉。
重构中的技能其实更多的是使用设计模式将复杂的业务逻辑用简洁的代码呈现出来。简单点来说,就是用设计模式承载复杂的业务逻辑,尽大概使写出的代码简洁。
怎么样才是一个好的体系重构呢?其实有一句话说得特殊好:对拓睁开放,对修改封闭。意思就是说别人只能拓展你的代码,而不能修改你的代码。很多老体系为什么会越来越复杂?逻辑越来越多?缘故原由就是他写的代码允许别人进行修改。这么说大概会很抽象,我们举个例子说吧。
  1. if(type == apple){    //deal with apple } else if (type == banana){    //deal with banana} else if (type == ......){    //......}
复制代码
上面这段代码模拟的是对于水果剥皮的处理程序。如果是苹果,那么是一种拨皮方法;如果是香蕉,则是另一种剥皮方法。如果以后还需要处理其他水果,那么就会在后面加上很多 if else 语句,最终会让整个方法变得又臭又长。如果恰好这个水果中的不同品种有不同的剥皮方法,那么这里面又会有很多层嵌套。
可以看得出来,上面这样的代码并没有满足「对拓睁开放,对修改封闭」的原则。每次需要新增一种水果,都可以直接在原来的代码上进行修改。久而久之,整个代码块就会变得又臭又长。
如果我们对剥水果皮这件事情做一个抽象,剥苹果皮是一个详细的实现,剥香蕉皮是一个详细的实现,那么写出的代码会是这样的:
  1. public interface PeelOff {    void peelOff();}public class ApplePeelOff implement PeelOff{    void peelOff(){        //deal with apple    }}public class BananaPeelOff implement PeelOff{    void peelOff(){        //deal with banan    }}public class PeelOffFactory{    private Map map = new HashMap();    private init(){        //init all the Class that implements PeelOff interface       }}.....public static void main(){    String type = "apple";    PeelOff peelOff = PeelOffFactory.getPeelOff(type);  //get ApplePeelOff Class Instance.    peelOff.pealOff();}
复制代码
上面这种实现方式使得别人无法修改我们的代码,为什么?
由于当需要对西瓜剥皮的时候,他会发现他只能新增一个类实现 PeelOff 接口,而无法再原来的代码上修改。这样就实现了「对拓睁开放,对修改封闭」的原则。
其实上面这种设计模式是最基本的设计模式:抽象设计模式。对于各种复杂的业务情形,还有其他许多设计模式,例如:代理模式、装饰模式等等。但各种模式归根到底照旧考察你对业务的理解能力以及抽象能力,如果你对业务足够理解,你即使不知道某个设计模式,你也会写着写着写出这样一个设计模式。
总结

此时重构的经历让我觉得非常痛苦,但熬过来了就觉得没什么了。突然感叹道重构照旧很有本领性的,对于技能要求反而没有那么高。重构更多考验的是对业务的深入理解,对抽象思维的进一步运用。如果业务理解深入,有抽象的思维,那设计模式还可以一点点学出来。而如果反过来,则没有办法做下去。
重构何其苦,且做且前行。
文章首发于【博客园-陈树义】,点击跳转到原文浅谈重构中踩过的坑

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?用户注册

x

天涯海角也要找到Ni:浅谈重构中踩过的坑

相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表