前言
这章我在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。在项目开发上我们见过很多类型的情况。重构的方式方法有很多种，因人因物（项目）而异，对项目作出合理的分析后再对其作出一部分细节的重构，日月累计最终成形。
总结
如果你正在做重构应考虑以下几点
- 成本
- 工期
- 代码的优雅与简洁
- 可扩展性等等
为什么要重构？原有代码无法更好的扩展，代码可读性差无法在其基础上修改的等等原因。希望会对你提供重构质量有一定帮助。
致谢
感谢你看到这篇文章，希望可以帮到你，谢谢。