先加测试，然后重构，再继续后续开发。

数据库性能问题，升级硬件，用 Redis 等做缓存，冷热数据分离，表分区。拆分多个数据库和子系统。

对于新添加的代码，一定要写测试用例，在保证新代码质量的前提下再去动老代码，如果时间和人力不是很充足，不建议轻易去重构，尤其是没有单元测试的老代码，改起来有可能引入新的问题。如果老代码功能稳定，能不改就不改，不要因为看不顺眼去动老代码，把更多的精力放在改善性能，稳定性，安全性这些方面。

#2 楼 @kgen 赞，必须先加测试，熟悉功能，然后保证既有功能的前提下，增加或重构

#2 楼 @kgen 性能问题，非常感谢。

另外，大家都说先加测试来保证代码，有在项目中期加测试代码的实际这么干过的么，什么感受

是在说我们的项目乜。。。 一般的重构就是测试 + 重构，最好有个熟悉的同事一起结对编程，然后互相来个 code review。

#6 楼 @as181920

公司很多这样的项目，没有测试覆盖，产品童鞋每次都嚷嚷：每次测都有其它 bug 出来，一波未平一波又起。

没单元或者功能测试代码在后面支撑，没有人肉测试，咱也受不住了。

接下来，自己想试试从功能测试的开始，看看付出与收获是不是老板可以接受的。

这个楼盖起来

如果明天的新闻标题是：“重构期出现大 bug，公司损失过百万”，或：“重构期出现大 bug，公司年终奖被取消”，或：“重构期出现大 bug，开发组成员明日天台集合”，那就真要想想重构有没有必要了。。。

我就是在项目中期加测试的。前期开发大半年，为了开发速度完全没有任何测试，纯肉测……

加测试没必要一步到位（也不可能一步到位），你做什么功能，就把相关的测试补上，没改动的地方可以暂时不加。

另外如果新功能涉及到重构原有的老代码，一定要先写测试！测试最好由外而内写，没时间写完全部的，就写外部功能测试，并把各种 edge case 都加上。没 mock 没关系，构造真实数据没关系，测试慢点也没关系。重要的是保证结果正确。测试写完跑通了，然后再重构，分离耦合度高的代码，然后再重构测试代码，逐渐地由一个大的功能测试文件转成一个适当 mock 的功能测试，和若干个模块的单元测试。

老板/客户那边，如果碰到过加一个功能就 break 一些东西的黑历史，应该是很能说通的。否则就把实现功能加测试的时间评估成功能开发时间。至少在我看来测试代码也属于功能的一部分。

测试是影响设计的，如果代码结构设计也在持续修改，加的测试更多在集成阶段，model/controller 的测试性价比不高。

改变的方式有两种，一种重构，一种重写。

老代码老方式。

新代码把工程逻辑上拆分成几个小块，然后重写小工程（加测试，不限语言），逐步替代老程序。就不来点新的想象空间？

断断续续重构中。测试代码和 ci 几乎是我一个人在维护，一些同事不愿意写测试，