许多程序员在工作中，经常会碰到公司前辈留下的烂代码，看之不爽，改之不悦，那到底改写还是重构呢？
曾咨询过一位资深HR，他说面试过许许多多的人，所有人都觉得前辈的代码有问题。
我们看前人的作业时，总会挑出带有缺点的一面，但是在当时，代码已经是很先进的了。
你是前辈的时候，同样会被嫌弃。
重构，彻底否定？
面对这一问题，有网友认为重构才是合适的，既然是烂代码，就该彻底否定，否则将贻害万年，重构要不了几天，作为一名架构师，有义务把一切混乱的东西重新弄整齐了......
做到完美，做到极致，是可以理解的与支持的，只是上面这位网友的做法太极端了，彻底否定未免过分了。
首先先弄清代码的业务，如果是核心业务，就需要考虑很多问题，如果不是，再合理计划如何重构。
重构是一项大工程，涉及测试和开发，需要协调进行，项目经理能够领队无疑是最好不过的。
也有人认为存在即合理，改写即可
该网友则似乎说得也有道理，如果业务已经稳定，不动代码。不了解的代码杂乱无章，不建议动。
代码重构的同时也需要承担风险，如果动已经稳定的代码，好的结果是完善代码，修复需要，皆大欢喜。若是日后出现bug，也没什么大不了的。最坏的结果莫过于把整个系统搞垮，风险很大。
看到一段烂代码，虽然可以正常进行，但整个项目一塌糊涂，无论从代码业务还是代码逻辑上都非常的乱。
原有的代码没人敢动，都是新增代码，都生怕改了某处代码会影响到其他业务流程，这就导致了代码强数量急速上升，质量急速下降。
我们遇到种情况时，该如何判断要不要重构呢？
OvO
看是否符合以下条件：
1、全面深层的分析和调研，不能一下子就要抛弃原有的一切；
2、应分析该代码是否影响项目的业务和性能质量，是否影响新功能业务的迭代；
3、领导是否准许和支持；
4、是否现在就要重构。
需要注意的事项：
1、绝对保障产品稳定性
2、尽量少惊动人力物力
3、分阶段的重构，懂得借力
4、避免步子迈的过大导致不可收场
重构不等于重写
清理逻辑，减少代码量，规范命名和结构、逐步解耦。
我们重构的目的是让后面的工作越来越轻松，不是把前辈已经实现的需求一下子加到自己的身上。
重构应该发生在弄清楚业务逻辑，且自己写完的代码也应该立即重构，保证代码的规范和整洁。
这是循序渐进的过程，不是推倒重来的过程。
正如网友所说的那般，技术的进步，迭代就是因为发现原有的缺陷，并能找到更好的方法来替代。这不仅仅是需不需要重构的问题，实质上是提供了机遇和责任。
来源：程序员大咖
网友评论