关于梳理烂代码，大家有什么经验？

[darasion]

一个项目，面临这样的情况：

1、经历过很长很长时间的开发 --- 遗留的问题可能很多。
2、人走了一批又一批，来了一批又一批 --- 了解全部内情的旧人走了，新人只能跟着新进度奔命。
3、一边线上使用，一边线下开发 --- 不太可能重新做一套东西，各种适配接口已经盘根错节，还分属不同部门。
4、需要处理的许多数据和代码，已经不清楚来源和作用了 --- 好多好多年前的东西，写过代码的人走了，看过代码的人也走了，以前知道的人也都忘记是什么了。
5、不同的部门也都并非全部了解项目内情，面临以上同样的情况。 --- 并非一个人或一个团队的责任。

现在我面临的情况是，
要继续这个东西，必须梳理一下代码，否则接下来的代码就太难写了。
但是梳理的时候又遇到以上的情况，也找不到人问，问谁谁不知。

大家有没有处理类似情况的经验呢？

[Zeami]

也许是该放弃

[darasion]

@Zeami 不行，这个不是我所能决定。另外这样的东西往往实际正在使用，而且很重要，不是想放弃就可以放弃的。

[xlmo]

不是有bug的话就不要触碰不懂的那部分。
代码混乱可以用持续重构来改善。
新需求尽量自己写套新的，哪怕是有可能旧系统中已经有部分实现了。这个新的，不一定是一整套，也可以是局部的新系统。
没有人问，可以在掌握业务流程的基础上自己来推测代码功能，这个比较靠谱。

[cashplk]

没bug暂时不动。
慢慢重构，新需求参考旧代码独立做，以后废除老代码。
功能先从代码级别梳理，然后找相关的人询问推动变化。
对外的接口原则也差不多。

[9hills]

虽然没有写过大型系统的经验，但我的想法时这样的：

新的代码加入时不要直接和旧代码写到一起，还采取独立的模块或者子系统的办法，然后慢慢迁移。
有精力和时间的话还可以从外围开始剥离旧代码。。

不过我写的东西一个月后就想把它们全删掉重写。。虽然都不大，但就是难受阿，可以体会到lz的感受

[sinxccc]

梳理代码是个大工程⋯⋯

我的经验（C代码）是先从全局入手，大的流程图什么的看看能不能尝试画出来，然后把代码中自己的宏定义/typedef 还有数据结构和关系理清楚，最后再看代码。如果项目组中不止一个人的话可以分工，然后每天花1-2个小时去会议室把自己负责的代码流程讲给其他人听。

如果同时还要修改 bug 的话切记千万不要手痒重写代码，哪怕它原来又丑又脏，一行都不要。

[walleve]

不是bug就不要随意修改，除非遇到程序性能瓶颈之类的。。。
同时注意开始做文档和代码实现功能需求的梳理。

在必要的时候，快刀斩乱码！
该舍弃的舍弃，该备份的备份
同时开始做版本规划，这样可以为下一次交接做好准备。

[newblue]

建议：除非你那个东西完全烂掉了，必须重新写，不然还是继续保持下去。重构一个系统比重写一个系统可能要花的时间更多一点。

如果你的系统里面之前没有写好自动测试的代码的话，光靠一两个人来重构一个系统，那是一件很辛苦和漫长的事情，而且还不保证重构后运行会正常，还会带入新的bug。

[yyfearth]

其实大多公司里面都是这样的，而且完全没有或者很少有文档。
我们公司目前就这样。只要一个人走了，这个模块就没人知道了。
每个人手中的模块对于其他人来说就是一个黑盒，如果别人要他模块干嘛，他就开个接口。

[sun019]

首先不先不要扩展功能，停一下。
如果代码量不是很大，花1到2走重构，梳理代码也是值得的

[sun019]

首先不先不要扩展功能，停一下。
如果代码量不是很大，花1到2走重构，梳理代码也是值得的

[darasion]

@sun019 不可行。不是你想停下就停得下来的，你必须要配合别的团队。。