具体如下：

代码维护，重构是件很令人不爽的一件事。以下几种情况，会让代码维护和重构变得很困难。

1. 项目开始时，大家规定好一些代码规范，在一定的规范下进行开发，但是人的思想是不一样的，也就是说每个功能不同的人实现的逻辑可能会有这样那样的不同，导致了一些人不愿意去看别人代码，要改别人代码，首先要了解这个人当时是怎么想的，他的逻辑是怎么样的。所以有很多人的想法是有那看别人代码的时间，我就重新做好了。这种想法不要有，看别人代码也能学到不少东西。如果都这样想，我想冗余代码会越来越多，后期重构会变的越来越困难。

2. 做程序的一般跳槽都比较频繁，项目开始的时候，是5个人（项目创始人）开发的，等项目上线了，可能有人离职了。人手不够，公司招人。项目创始人呢，对新招的人，不太信认，怕修改原代码会导致上线的功能出问题，所以就出了新规定，最好不要修改上线过的程序，如果需求变动，最好重新写class或者是function，这样的话，代码会变的越来越多。可能会出现几个class都差不多，或者多个function的功能差不多。

3. 数据库冗余字段，冗余表过多，也会让代码维护变的十分困难。因为功能优化，或者新需求，导致原有表结构根本不能满足新需求，这个时候，就会去表里添加字段，或者挂接另一个表，长期以往，数据库变的很臃肿，数据库一大，代码肯定就不用说了，程序都是围绕着数据来的，冗余字段，冗余表都要维护的，不然数据就不统一了。必要的冗余可以减少数据库查询，如果过多，只会事得其返。所以在修改数据库时更要考虑清楚，考虑将来数据库和代码要重构的情况。

4. 个人原因是最主要的原因，首先要有分块思想，也可以说是oop思想，这种思想是在实战中养成的，这个是要一定时间的。不要为了急着去实现功能而忽视了整体考虑。假如来了一个新需要，我会首先考虑怎么实现这个需求，有了思路后，我也不会急着去开发这个功能，我还会在考虑这个功能模块，会不会用在其他地方？如果其他地方用，怎么样让其他地方用着更方便。我会让所以调用这个功能模块的地方，接口只有一个。然后我才会着手去开发。还有一点，不要相信需求定下来就不会变了，不会的。人的想法很多，开发代码的时候，这一点也要考虑进去，所以统一的接口在需求变动时，我只要修改一个地方，其他地方都可以改掉。如果这样考虑了，前期开发时，时间会多一点，但是后期维护就快很多。

小结一下，有了上面4点，重构数据库，重构代码将是必然的

1. 人的思想不可能一样，大家都在尽量往一处想，但是总会有这样，那样的不同。
2. 急于要完成功能，而不深入了解别人代码。研究别人代码不如重新开发快，这种思想不好。
3. 数据库冗余，这个我个人觉得必然会出现的，一个项目做大，做强，一定是在不断的成长，成长过程中，数据库不可能是一成不变的。
4. 缺少分块思想，我觉得一个项目，就是很多功能独立的小块通过一定线串起来的，代码重构也就是把这些小块的重新组合，当然各个小块，在重构前后实现的功能会不一样，但它还是为了实现一定的功能，只不过由旧变新而已。