如何继承糟糕的代码？

[Sherlockhlt]

接手了一个项目，现有代码感觉写得很混乱，很有推倒重写的冲动。。可是原来项目的负责人又不肯。。现在对项目完全没有继续写的欲望了。

[alexrezit]

一边先将就着改 bug, 与此同时另一边推倒重写, 一个模块一个模块替换到旧项目上去, 然后最后差不多的时候就整个 switch 到新项目.

[sdjl]

让负责人自己肯。。。

[xiaket]

@alexrezit 正解, 逐个模块地改善改进, 尽量减少升级过程中的烦恼.

[qiukun]

能隔离好就继续用吧

[haha1903]

@alexrezit
@xiaket
推倒重写是不对的，不停的 refactory，同时了解需求，能够完全理解这个项目的时候，你就不会想重写了，只会想把当前的项目变得更好。

[powerfj]

还有一个就是不要以为自己写的代码就是好代码，自己写代码的时候写完也找几个人评审一下看看，不然到别人那里你写的又是写的烂的代码

[alexrezit]

@haha1903 如果重写比修改更省时省力的话为什么不推倒重写呢?

[platoo]

吃过亏的人表示赞成 @haha1903，了解需求，不停的refactory是省时省力的方法。
且分享一例，当时接受了一个新模块，优化的时候觉得太烂了，一个功能的函数分拆到两个函数里面，导致大段功能重复代码。脑子一热，推倒重写！其实并不是很大的优化：将复用的代码提取，功能耦合的代码合并。结果测试的时候出现了bug，调试了两天。后来询问了周围所有接触过的这个模块的人。发现如果不分开的话，时序上面会紊乱。当时项目时间紧，就将就用了。我不幸中枪。所以，一定要在理解功能的基础上，透彻理解当时的项目背景什么的再修改啊！！

[darktiny]

最近也在困扰这个问题〜

[imom0]

15楼|prancer80|2012-10-30 03:32:00|只看此ID
回复|发信|转寄
给你说一个我同事的例子吧：
第一个阶段，天天骂祖宗。
第二个阶段，天天骂娘。
第三个阶段，天天骂写代码的SB。
第四个阶段，天天爆炸头，继续啃。
第五个阶段，天天跟老板要求换岗。
第六个阶段，继续啃。
第七个阶段，离职。

[ 在 creataaa 的大作中提到: ]
: 新人先后接手两个项目，都是公司积累了好几年的，都是几万行几乎无注释，都是逻辑很复杂、各种线程交错。。读得慢死了。。求经验。。。
--
FROM 213.55.76.*

[asoncheng]

只能说循序渐进，各个击破。
遇到的任何地方的代码都会遇到这样的情况，普遍现象。单独花时间重新写一遍，主管肯定觉得没经济价值，而在中国这样只看重当下经济回报急功近利的背景下，LZ还是好好学习，一点点来吧。

[haha1903]

@alexrezit 重写比修改省时省力，还要建立在系统所有的特性都完整，我虽然反对再来一版，但也觉得可以吧。
问题是，这两个前提是怎么确定的，不客气的说一句，大部分时候觉得重写省时省力的原因，是不想去弄原来“一团乱麻”的代码，说到底就是懒。可是，原来的代码你都不明白，你怎么保证系统可用并且功能完整。
所以，你首先要去了解旧系统，可能你非常了解旧系统之后，就不会再觉得重写一份省时省力了。
@Sherlockhlt @alexrezit
过来人给个建议吧，如果真的有足够的责任感，希望把事情做好。
那么建议分三步：

1. 给你要维护的功能补充一些自动化测试代码，无论是 UT 还是 ST
2. 慢慢看懂，并且按照自己的理解去 refactory 代码，第一步来保证你的 refactory 是正确的。（当然不能完全保证）
3. 重复前两步

[haha1903]

@platoo 支持一把，呵呵

[alexrezit]

@imom0 "在 xxx 的大作总提到" 怎么那么像我们学校 nforum 的风格...

[alexrezit]

@haha1903
如果你接手的项目里几乎所有的 bug 都是因为编写习惯不好而带来的, 肯定就会认为重写更省力.