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

[hh3755]

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

[YouXia]

重构

[hh3755]

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

[loading]

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

[kn007]

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

[gongweixin]

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

[hh3755]

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

[hh3755]

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

[loading]

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

[hh3755]

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

[kn007]

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

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

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

[ZackYang]

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

[hh3755]

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

[hh3755]

@ZackYang 谢谢书籍上的推荐。

[initialdp]

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

[hahasong]

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

[datou552211]

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

[Felldeadbird]

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

[kn007]

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

[vietor]

逐步分拆独立模块

[hohoho]

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

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