浅谈重构造成的灾难性毁灭

前言

这章我在7月20号的时候就准备好了标题,在那之前有写过一篇重构的文章,这段时间一直在等重构造成的弊端。

庆幸的是至今也没挂掉。本章我们来聊聊重构造成的灾难性毁灭。

青铜

只要你确定你是一个真正的程序员,那当你接手一个新项目时,因为每个人的编码规范与风格不同,或者某块代码出现了问题,作为一名向上的程序员,总会想去重构这个项目更严重的都想重写一遍。例如下面的这类代码

$status = $_POST["status"]

switch status {
    case 
    ...
    break;
    case
    ...
    break;
    default:
    if(){
    ...
    }else if(){
    ...
    }else(){
    ...
    }
    break;
}

我知道当你看到这段代码内心是崩溃的,如果是名新人,在没有完全理解其结构作用的情况下,绝对不敢擅自动原有的代码,除非他想加班,那怎么办呢?只好在原有的代码上继续增加代码了。

$status = $_POST["status"]

switch status {
    case 
    ...
    break;
    case
    ...
    break;
    default:
    if(){
    ...
    }else if(){
    ...
    }else if(){
    ...
    }else (){
     // 新人写的
    }
    break;
}

这块聊的新人入职,一般是不敢动原有代码的。当然这不排除有胆量并且重构的也不错的新人。

白银

上面聊的与重构并无太大关系,但是必须存在的一段,用于表现程序员重构道路上的勇气。当你到白银差不多需要1-2年的时间,具体时间要个人处在的环境和自学能力。新人不敢动是因为他对语言的基础用法,类库,设计模式都没有特别了解,不敢擅自做动作也是比较聪明、保守的做法。

但到了白银就不一样了,我总结了程序员从入门到中级的心理变化,为什么只总结到中级?(PS:作者我自己都没有到高级)这是一个从谦虚到高傲在到什么都不会的过程。

看到这里即可明白重构造成的灾难性毁灭是在2-4年的时期发生的,那个阶段在技术不够扎实但还有一股子改变世界的劲头发生的问题。

例如积分系统(这里指新接手的项目),领导让你修改签到获得积分,如果在未全面了解代码结构与功能分布时,擅自修改那必然出现一场不可避免的灾难。一个简单的签到功能的模块复杂度不亚于一个普普通通的企业站。大致有如下模块组成

用户模块 -> 积分模块 -> 交易模块 -> 明细模块 

为什么说是必然?除非你在原有基础上改,那这样你又变回了青铜并且也不想那么做。在基础上重构可能当时不会出现问题。不断的有其他接手早晚回出问题。重构的灾难并非指的是一个人或某个人造成的,就如一个水杯,每个人看到都倒入一滴水,当溢出来时就发生了所谓的“灾难”

黄金

到这个段位后,很多人都变得聪明了,不在基础代码上修改,更不去所谓的重写。单独拿出一个文件写功能不就好了。事情还远没有那么简单。

就如上图那二货,认为自己可以,但最终Over。在项目开发上我们见过很多类型的情况。重构的方式方法有很多种,因人因物(项目)而异,对项目作出合理的分析后再对其作出一部分细节的重构,日月累计最终成形。

总结

如果你正在做重构应考虑以下几点
– 成本
– 工期
– 代码的优雅与简洁
– 可扩展性等等
为什么要重构?原有代码无法更好的扩展,代码可读性差无法在其基础上修改的等等原因。希望会对你提供重构质量有一定帮助。

致谢

感谢你看到这篇文章,希望可以帮到你,谢谢。

最后修改:9个月前
如果觉得我的文章对你有用,请随意赞赏

共有 0 条评论