公司项目越写越烂，想重构得不到支持，该走还是该留？

[ChoateYao]

在这家公司已经快两年了，从项目的开始就一直在。
进来很多同事也有很多同事离职，代码腐烂的气息越来越重。
期间提出很多建议，如写单元测试、重构代码、整理文档、统一代码风格。
但是基本上只是纸上谈兵，领导每次都给予团队人员不熟悉、每个人的代码风格都不一样等说法。
那我究竟是走还是留呢？每天过来上班看着任务列表就不想工作，实在是不想在这个项目上面写任何代码了。

[jun4rui]

我觉得不重构，还是有很多考量的。例如我这里现在一个项目也是稀烂的，超级烂啊，罄竹难书。

但是也没办法，上面首先根本不给你时间重构，而来原来很多地方开发的人早跳槽走了，没文档、代码一团糟、连缩进都爱写不写的看之前我都要先用编辑器重新格式化一遍才能开始看。公司头头又是业务出身根本不懂这些，你要是花大把大把的时间去重构，毫无经济效益，肯定不会同意的。

[myc0210]

能跑的马就是好马。重构的钱你出 你就可以重构了。有这功夫能多写几百个所谓的（腐烂模块）。老板绝逼愿意写几百个所谓的腐烂模块。

[lifechan]

这年头生存不宜，恐怕老板是想先搞出些花头有了新资本进入再考虑吧

[anoymoux]

没必要。。

[ianva]

lz 这个问题其实也是个人能力问题，
不只是领导支持不支持的问题，是你开始做起来了么？
有没有能力带领同事一起做这件事？
有没有能力，让其他人一起，在未来的代码中开始写测试，统一风格，而且不需要重构一个项目的情况下？

所有的小公司都会存在类似的问题，这东西不是有没有授权领导，而是你自己有没有这方面的能力，威望，并在一个项目上做好，还能推广

[ianva]

重构本身就不一定是一件好事，特别是在有很长历史而且需求就没有被持续整理和更新的情况下，再烂的代码也比你重构出来的项目靠谱。

[loading]

你重构就能写得比现在的好？

[fds]

我去的第一家公司的指标是在做新任务的时候有40%的时间可以用来重构旧代码。不过还是得先保证测试覆盖率达到一定程度再说，不然有些边边角角的问题会在上线后突然冒出来。

[vietor]

逐步重构，每次只重构非常小的部分，这样才能保证你的目的性。重起炉灶时非常不讨好的。

[michaelye1988]

我现在遇到和你一样的问题，在旧代码上面加新功能实在太痛苦了，因为项目太复杂，太庞大，我也没有重构一定能比旧代码好的把握，所以我打算自己重写一遍，上面也有人说了，按模块划分。我现在也是这样打算，不过这几天改老代码也有些好处，就是更熟悉项目了。

[Neveroldmilk]

跟着混吧，自己潜心研究新技术，碰上待遇更好的公司就跑路。

[Felldeadbird]

重构不是你想象那么简单。我现在作为管理，也不能一步到位。楼主自己好好想吧。

[Daizong]

对于已经上线工作的项目，不要因为看着不爽就重构。

[DiveIntoEyes]

BAT也只这样子的

[alexapollo]

BAT也都这样。。

[dryyun]

重构根本没有那么简单，除非迫不得已。

[fxxkgw]

真的没想象中那么容易啊 楼主！
我在的公司基本都是10年以上的，行业甚至放在国际都是前一二的，但是代码真的要多烂有多烂，一个函数几千行都很正常，但不可否认的是修修补补这么多年，还是挺稳定的。
大企业重构的风险太大，小企业根本不在乎这些，关键不在于公司代码多烂多好，而是你自己能从中学到的。

[tencoldays]

其实...代码重构、设计模式、测试驱动这些鸟事，都是做咨询的人或公司搞出来混口饭吃的，比如Martin Fowler和ThoughtWorks... 你什么时候听过Linus要重构linux代码了?

以前写Java的时候，把Martin Fowler当神一样。大家谈架构设计时候，如果不来几个设计模式，都不要意思说话，回头看看太傻逼了，哈哈。

[ruandao]

你自己的代码你控制不了吗?

每天分一点时间进行修炼

[fanpenghua]

危机＝机遇。 每当大叫干的时候，谁都没干。你觉得什么问题？