关于维护老项目遇到的一个问题的思考

现在我在的项目组已经是一个很成熟的项目，该项目已经持续有好多年。

今天遇到的问题：

要修改某个项的默认滑杆值，但是找了半天依旧没有找到对应的默认滑杆值。找项目里的一个大佬也是找了将近一个小时才找到默认滑杆值的位置。

出现该问题的原因是因为该默认滑杆值已经维护过很多次，各种ab实验；并且每次的ab实验完成之后代码依旧留着（为了用户进退实验能够正常设置值）

通过一次又一次的ab实验之后，该滑杆值已经不知道放在哪里了（一两年前的了，由于时间太久了，都不知道谁熟悉这段代码）

 

对于该问题的思考：如何才能让代码变得更好维护？

1、定时的重构代码

2、对ab实验要有一定的取舍

对于老项目的看法是：能不改就不改。但是这个看法导致了现在项目的越来越难维护，需要越来越多的人力来维护这个项目。

 

以下是本人对于老项目的观点：

1、要实时重构，如《重构改善既有代码的设计》中说的：当在写代码的过程中遇到令自己难受的代码，最好的方法是看能否重构它

2、要定期重构，比如以一个月为限，一个月之后回过头来看一个月前自己写的代码是否有需要重构的地方。当有ab实验的时候，可以把ab实验删了（此时已经ab实验全量了。如果需要进退实验，有的用户可能还没有更新更新版本的进退实验，此时可以通过统计评估当前需要进退实验的用户比例，如果需要进退用户实验的人数很少的话则可以直接删掉ab实验否则该负责的人需要定时来检查人数，当人数的阀值低于某个数的时候就可以删掉）

3、当前发现ab实验、进退实验还有多个实验的叠加导致代码的复杂度直线上升，是否能够重构成更简单的框架

 

其实以上的第二点和第三点属于瞎扯淡：1、已经是老项目了，没人敢随便动框架；2、人力那么紧张，很难定期回过头去看自己写过的代码；即使牺牲一小部分的用户体验，产品那边的同学也不会愿意。（人家不会管你研发这边的人力成本）

所以最终更为合理的是第一点的：遇到它，能够重构就重构它