烂架构的代码是如何最后变好的呢。

[hh3755]

不知道大家有没有这样的经历，你当前所做的项目的代码很乱，无架构可言，每天又会有源源不断的新需求过来，参与开发的人并不全是比较牛的人，所以还会补充进去一些烂代码。这样的代码最后如何能变好，或者怎么做才能让这样的代码变得更好。人很少，需求很多，代码比较烂。

[Keinez]

/t/92241

[Clarencep]

难道不是代码越来越烂，快要无法维护的时候，干脆起个2.0版本，重写一遍...
2.0也越来越烂，要无法维护了，老板终于下定决心搞代码质量，起个NG(next generation)版本，要狠抓代码质量...
NG版本依旧越来越烂, 干脆起个3.0版本继续重写吧...

[hh3755]

@Felldeadbird 对于第2点。关键是我们在不断的在原来的功能上加需求。越加越乱，不重构似乎已不可能。时间上的确很紧张。很多时候花了很多时间，结果新重构的功能比原来的功能不稳定还引来怀疑改动的价值。 对于第3，4点，公司只想把代码跑下去。重写一个新版本根本不是产品能提得出来的需求。也不会有那么多时间。也同意不是每个人愿意重构。

[hh3755]

@datou552211 是否有重构的经历可供参考。其实现在比较迷茫。

[mouhong]

重构，小步慢进。一般情况下不要想着重写，在很多时候，重写要么是写不完，要么是写完不见得比原来的好

[mouhong]

不过，你是项目负责人的角色么？要是，那或许可以先争取让上层认同重构的重要性，再通过一些制定一些规范让其它开发人员来遵循，定期做些 Code Review？要不是，那貌似就比较纠结了~

[hh3755]

@mouhong 也不算是，只是项目不大，搞着项目好乱，想看看大家一般都是怎么把它搞好的。交流学习一下。