hh3755

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

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

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

@ZackYang 谢谢书籍上的推荐。

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

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

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

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

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