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

前言

这章我在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。在项目开发上我们见过很多类型的情况。重构的方式方法有很多种，因人因物（项目）而异，对项目作出合理的分析后再对其作出一部分细节的重构，日月累计最终成形。

总结

如果你正在做重构应考虑以下几点

• 成本
• 工期
• 代码的优雅与简洁
• 可扩展性等等
  为什么要重构？原有代码无法更好的扩展，代码可读性差无法在其基础上修改的等等原因。希望会对你提供重构质量有一定帮助。

致谢

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