刚进一个项目组，原来的代码写得很烂，我该怎么办？

[hanks315]

有的地方已经不得不那样写了。我是跟着烂下去，图省事；还是要慢慢重构。

[saharabear]

给它重构,然后拍屁股走人.

[Js]

跟着烂下去

[dreampuf]

用哪儿改哪。

此外问题如下：

- 你确定他真的烂？烂在哪里，团队里的人怎么看？
- 你如何确保你不会给出烂的实现？团队里的人愿意接下并维护你的实现？
- 区分重写和重构，然后再向团队说明是否可接受其代价

[yimity]

我的代码也很烂，求指点啊。

[ceyes]

首先你要确定原来的代码能用不? 能稳定工作的话就不要自找麻烦了.
重构风险很大, 因为1.上司会认为你在用工作时间做没有意义的事情. 2.本来代码就很烂 重构当然很困难. 3.重构必然会带来 bug.
so ... 自己斟酌吧 当然最好的方案是 把情况反应给上司 他也觉得不重构 会毁掉项目 然后暂停进度 组织重构。 千万要注意其中的责任区分 必须把问题推给上司 别自己好心办了坏事。

[darasion]

那你就应该写更烂的来对付他们.

[summic]

在kpi层面算下投入与回报，如果无法全面重构，起码保证你继续写的代码不那么烂，甚至一点一点吞噬烂代码。

能赚钱的代码就不是烂代码

[walleve]

低头工作，好好写代码，然后干好自己的活，努力做好。。。拿到相应报酬。不要埋怨

[cubepeng]

不要尝试去重构，码农的职责就是让程序能正常运行，写的好看不管用！

[hanks315]

谢谢回复，基本了解了，我觉得自己是从重写开始，先确保自己的代码好维护

[bruce]

@hanks315 重新开始写不是一个成熟程序员的做法

[wenbinwu]

把自己新写的代码写好了先

[alexrezit]

看烂到什么程度. 如果已经烂到改一个功能都要读半天去理解作者的奇葩逻辑的话还是重写比较好.

[veggie]

没有冲动去重构的话，说明这个项目不够吸引你，也看不到未来，那就赶紧走人吧

[jkeylu]

保证自己的不烂就行，但是有时候你不得不烂，除非你能够在用新写代码的时间里同时重写你觉得烂的地方并同时也保证正确性，并承担一定风险，不然还是放弃吧，让它继续烂下去

[ewangke]

不理解什么是烂，能正确工作可以快速响应需求的代码绝不是烂代码。
不管你重构或重写，都是回归测试吧？成本是团队埋单。
团队>产品>代码，如果代码在你心中是第一位，我建议你调整一下看问题的角度。
建议楼主把问题暴露出来，大家一起想办法，做一个最佳决定。

[greatghoul]

你重构一下，然后走人。然后后面接手你工作的同学也来这里发一个同样内容的帖子。

[yun77op]

该项目还有生命力的话，”破窗理论“ 不要容忍糟糕代码，维护是开发过程中的例行事物，当然要写好测试，保证是可靠的

花多少时间去重构又是另一回事，一般情况下比如抽20%的时间重构，极端情况下上级或团队完全不认可的话就没办法了

[aurorawu]

要是刚参加工作的我绝对会自己重构，现在的我只会把自己的工作做好之余再去考虑这些。btw,你是怎么确定代码很烂的？代码写的“烂”的人多了去，你的标准是什么？程序跑起来没有影响就OK啦！

[diib]

bug几乎没有，效率又能满足需求，就不能称为烂代码。用心做好自己掌控范围内能做的，多看多想自己范围之外的，但是一定要少说。