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

重构

@YouXia 人少，需求多。是要抽出一个人来做专门重构吗。如何解决项目进度和重构本身挤占时间的冲突呢。重构如何做呢。专门设计还是调整当前的东西以满足需求，有何准则，或书推荐。

跑起来再说，等你们人走差不多了，项目不能看，自然就“重构”了…

没有规划是很sb的，以后很难改，牵一发而动全身。。。
没有规划就如 @loading 所说的，等你们走光了， 这个项目就可以重构了。。。

逐步优化，每个新需求多估点时间，每次把周边的优化下，全部重构在公司里不现实

@kn007 项目刚开始的时候什么情况都有可能发生。我现在接手的项目就有这个问题。重写？有没经验分享。

@gongweixin 我也觉得可以这样。但是每次新需求，并不是所有人（有新手）都愿意去动哪些容易产生问题的东西，比如重构，一般是怎么处理这种情况的呢。另外遵循怎么样的准则，重构能做得比较好呢。

@hh3755 在一个跑起来的项目面前，首先业务逻辑应该是很清晰的，安排一个最高水平的重构就行！

@loading 设计架构弄不好就弄巧成拙，大家都是如何提高自己的架构设计水平的呢。目前我只知道*重构*那本书。想顺便把大家的重构水平也提高一下。

@hh3755 如果你确实有时间，而且这个项目老板也不想投入金钱去重构新的。。。
看下你这个项目，尽量先把这个项目按功能模块化（简单说就是函数汇集），然后看下模块里函数是不是有重复的东西，去掉，有些东西只能顺藤摸瓜，才能搞好。全部弄好后，集成起来就是烂尾的代码了。

最好一个方向，就是选好个项目的核心，围绕那个核心来模块化。

就像核心交换机、路由器、无线控制器、防火墙、一堆二层交换机、一堆AP。肯定要以核心交换机为主，其他为辅，来配置规则。

<<代码大全2>>, <<重构>>, <<PoEAA>>, <<设计模式>>

@kn007 谢谢中肯的建议。我也渐渐发现某些东西在原来尚能满足需求，但是源源不断的新的需求进来之后，让原来的架构渐渐的运行起来有些吃力，进而慢慢变成一个大问题。但是需求进来的时候时间往往是不可控的。大家都不能等你把架构改了再做需求。如果是盲目的直接调整架构是有益的。比如觉得哪点就好，需要调整就直接调整。问题就是说 架构哪些，怎么判断哪些需要被架构。

@ZackYang 谢谢书籍上的推荐。

从来没有见过这种情况下代码最后会变好。

并不能变好，有一天你受不了走人的时候，这事就算完了

赶紧重构，要不然恶性循环，甚至影响产品质量

我给楼主一些建议：
1.先明确目前项目是否公司核心。核心项目不是你说重构就重构的，
2.核心项目如何重构？最好就是在开发某些大功能时，偷偷加入自己的设想架构。但是未必凑效。我就试过这样做，而且很快就失败了。因为该改动的需求流产了，我做的重构也没了。
3.是否有相同的新项目开发。老板可能会让你使用现有的程序直接修改过去。把握这个时机，强烈向老板推荐重构或者自己有权利进行重构。 我现在就是走这样的路线。在新项目用新架构，待新项目成熟了，就淘汰掉旧项目的旧架构，使用新架构。
4.旧项目如何处理？有一个过渡期，楼主可能需要投入第一时间进行维护的。所以做好觉悟吧。
这玩意其实吃力不讨好，因为整个团队里面，不是每个人都有重构的思想。

@Felldeadbird 这种处理方式好，哈哈，也挺无奈的

逐步分拆独立模块

也遇到了楼主的问题。公司的 iOS app 找的外包，我接手时看了代码都快哭了。新需求很多，没人没时间重构，领导关心的是功能，跟老大提出来老大也很无奈，完全推倒重写是不可能的。

能做的就是边加新功能边力所能及地修改重构原来的，这个过程好蛋疼。到现在也重写了近三分之一啦，希望最近的需求忙完能稍微空闲些，至少把tm的那一坨storyboard都删了！

/t/92241

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

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

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

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

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

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