1
Zeami 2011-06-12 18:19:09 +08:00
也许是该放弃
|
3
xlmo 2011-06-12 18:54:24 +08:00
不是有bug的话就不要触碰不懂的那部分。
代码混乱可以用持续重构来改善。 新需求尽量自己写套新的,哪怕是有可能旧系统中已经有部分实现了。这个新的,不一定是一整套,也可以是局部的新系统。 没有人问,可以在掌握业务流程的基础上自己来推测代码功能,这个比较靠谱。 |
4
cashplk 2011-06-12 19:47:44 +08:00
没bug暂时不动。
慢慢重构,新需求参考旧代码独立做,以后废除老代码。 功能先从代码级别梳理,然后找相关的人询问推动变化。 对外的接口原则也差不多。 |
5
9hills 2011-06-12 19:50:34 +08:00
虽然没有写过大型系统的经验,但我的想法时这样的:
新的代码加入时不要直接和旧代码写到一起,还采取独立的模块或者子系统的办法,然后慢慢迁移。 有精力和时间的话还可以从外围开始剥离旧代码。。 不过我写的东西一个月后就想把它们全删掉重写。。虽然都不大,但就是难受阿,可以体会到lz的感受 |
6
sinxccc 2011-06-12 19:51:26 +08:00
梳理代码是个大工程⋯⋯
我的经验(C代码)是先从全局入手,大的流程图什么的看看能不能尝试画出来,然后把代码中自己的宏定义/typedef 还有数据结构和关系理清楚,最后再看代码。如果项目组中不止一个人的话可以分工,然后每天花1-2个小时去会议室把自己负责的代码流程讲给其他人听。 如果同时还要修改 bug 的话切记千万不要手痒重写代码,哪怕它原来又丑又脏,一行都不要。 |
7
walleve 2011-06-12 20:01:31 +08:00
不是bug就不要随意修改,除非遇到程序性能瓶颈之类的。。。
同时注意开始做文档和代码实现功能需求的梳理。 在必要的时候,快刀斩乱码! 该舍弃的舍弃,该备份的备份 同时开始做版本规划,这样可以为下一次交接做好准备。 |
8
newblue 2011-06-12 22:17:49 +08:00
建议:除非你那个东西完全烂掉了,必须重新写,不然还是继续保持下去。重构一个系统比重写一个系统可能要花的时间更多一点。
如果你的系统里面之前没有写好自动测试的代码的话,光靠一两个人来重构一个系统,那是一件很辛苦和漫长的事情,而且还不保证重构后运行会正常,还会带入新的bug。 |
9
yyfearth 2011-06-12 23:31:05 +08:00
其实大多公司里面都是这样的,而且完全没有或者很少有文档。
我们公司目前就这样。只要一个人走了,这个模块就没人知道了。 每个人手中的模块对于其他人来说就是一个黑盒,如果别人要他模块干嘛,他就开个接口。 |
10
sun019 2011-06-13 00:11:59 +08:00
首先不先不要扩展功能,停一下。
如果代码量不是很大,花1到2走重构,梳理代码也是值得的 |
11
sun019 2011-06-13 00:12:04 +08:00
首先不先不要扩展功能,停一下。
如果代码量不是很大,花1到2走重构,梳理代码也是值得的 |