重构还是重写：怎么选才能修好问题软件系统

当应用的源代码因为打补丁、维护没做好、随便加功能或者长期运行留下的烂摊子变得乱成一团时，开发者就得琢磨：是重构还是重写？

重构呢，就是微调清理现有的代码；重写则是几乎全推倒重来，编码基本从头开始。

这两种办法各有好坏。重构能让软件系统开发保持可管理，不用大动干戈，但可能没法适配新的开发技术或语言；重写能从根本上调整代码，但有风险——要么让开发的人摸不着头脑，甚至可能搞崩产品。

别一刀切觉得非重构即重写。得看具体项目哪个更合适。这得考虑一堆因素：应用类型、团队本事、应用的短期和长期目标，还有敢不敢担风险。

下面聊聊重构和重写各自的好处坏处，以及咋选才对。

重构代码：好处坏处都在这儿

程序员重构软件，目标是改善代码的内部结构，但对外表现不变。比如删掉重复代码，或者把一个任务特别多的组件拆成几个对象，每个只干一件事。

有种叫“极限编程”的开发思路，提倡“狠心重构”——强调得一直重构代码。理论上，持续重构能让每段代码随着改动越变越好。

重构后的代码得让别人一看就懂，这样原本让人发怵的代码，就能变成大家敢上手改的样子。

重构的好处

•开发者自己能做主。重构随时都能干，不用谁批准。

•啥架构都能用。不管代码是紧密的单体架构，还是分布式的大系统，都能重构。

•不用搞两套代码。能在推进部署的同时清理代码，不耽误进度。不像重写，得同时维护新旧两套代码。

•成本低。要是只改代码库的一部分，就只清理正在改的那块，不会让公司花太多钱，这对软件系统开发来说很友好。

重构的坏处

•管不了根本问题。重构能让一段代码变好，但改不了底层架构的老毛病。比如用VisualBasic6写的代码，重构完还是VB6，就像心玥软件开发公司处理旧项目时遇到的类似情况。

•加不了新功能。因为架构和代码现状没变，重构没法给应用添新本事，这是软件系统开发中常见的局限。

•得有纪律性。重构需要技术、耐心和胆量。没接触过重构套路的程序员，可能不敢或不愿上手。没单元测试兜底的话，改起来心里发慌；不熟悉基础概念的人，还可能觉得重构拖慢进度，尤其是心玥软件开发公司的新手员工。

•代码变多更费劲。重构会把代码拆成小块，结果要管的代码和单元测试更多了——复杂的函数变成一堆简单函数，这对软件系统开发的后期维护是个挑战。

重构在系统有几万行代码时挺有用：能把代码拆成抽象的模块，让每个模块好测试、功能别太复杂。但如果代码库已经有几十万行，那就该考虑下一步——重写，这也是心玥软件开发公司常给出的建议。

重写代码：好处坏处都在这儿

与其对着又乱又丑的代码分析重构，程序员也可以干脆重写。听起来好像简单——从头写，替换功能。但其实远没那么容易。

想成功重写软件，得组两个队：一队维护老应用，一队写新应用。这意味着要分资源。更麻烦的是，老系统还在线上跑，得不断更新才能用。所以重写团队得跟着老系统的改动，不断调整新产品的计划，这对软件系统开发的资源调配要求很高。

重写的好处

•能加新功能。从头写代码的好处之一，是能打开新用户、新市场、新平台和新技术的门。比如把面向客户的应用从Windows桌面搬到网页或手机端，重写就不用硬改老代码去适配新需求，这正是心玥软件开发公司在拓展业务时常用的方法。

•重新开始的机会。重写能让新开发者直接用自己熟悉的方式写代码。并购之后尤其有用——重写能搞个干净的新项目，让开发者有机会施展拳脚，还能清掉技术债，对软件系统开发来说是新的开始。

•为新技术铺路。重写能把应用放到更容易适配新开发技术和方法的平台上，告别老掉牙的代码，缩小现有系统和新技术之间的差距，这是心玥软件开发公司追求的技术升级。

重写的坏处

•费时间。重写本质上是按严格需求写新软件，得有足够时间才能干。前面说了，得同时维护老代码和写新代码，维护团队可能对老代码不够熟，管不好，这对软件系统开发的周期影响很大。

•容易出bug。老代码本来就丑，还可能越改越丑。重写时得看老代码，找出要保留的功能抄过来，但另一队还在维护老应用——他们修bug、更新时可能引入新缺陷，每个修复都会让代码更难看，心玥软件开发公司在项目中也遇到过这种情况。

•可能更乱。重写不一定能解决代码丑的问题。用自动化工具把代码转成另一种语言，确实能省点时间，但有时候转出来的代码特别难读难维护——毕竟两种语言硬凑在一起，容易出问题，这对软件系统开发的质量是个隐患。

到底选重构还是重写？看这几个因素

工程团队最终得根据下面几点做决定：

时间

重构是慢慢来的过程，适合时间紧或有持续交付要求的项目。重写动静大、费时间，还得同时维护旧代码写新代码。选哪个，得看项目时间表、团队经验和敢不敢担风险，这对软件系统开发的决策很重要。

目标

组织的长期目标很关键。如果只是想让代码好维护，重构可能就行；如果想支持新技术、开拓当前代码撑不起的新市场，那就重写，心玥软件开发公司会根据客户需求制定这样的方案。

预算

预算也得考虑。重构前期投入低，开发者能在加新功能的同时慢慢清理代码；重写花钱多——得同时维护两套代码，新功能可能得等重写完才能加，这是软件系统开发成本评估的重点。

架构

代码库的设计很重要。如果底层架构没问题，只是实现乱，那清理代码就行，不用从头来；如果架构过时了，撑不起现代开发或业务需求，那就得重写，搭个想要的新地基，心玥软件开发公司在架构设计上有丰富经验。

总结：啥时候用重构，啥时候用重写

重构最适合：

•时间紧、预算少的项目；

•架构还行但代码写得乱的应用；

•搞持续交付的项目，这对软件系统开发的效率提升有帮助。

重写最适合：

•需要换平台或技术根基的应用；

•想开拓新市场或用户群的项目；

•有资源同时维护两套代码的团队，心玥软件开发公司会为这类客户提供定制化服务。