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

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

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

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

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

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

1，人的思惟不可能一样，大家都在尽量往一处想，但是总会有这样，那样的不同。

2，急于要完成功能，而不深入了解别人代码。研究别人代码不如重新开发快，这种思惟不好。

3，数据库冗余，这个我个人觉得必定会泛起的，一个项目做大，做强，一定是在不断的成长，成长过程中，数据库不可能是一成不变的。

4，缺少分块思惟，我觉得一个项目，就是良多功能独立的小块通过一定线串起来的，代码重构也就是把这些小块的重新组合，当然各个小块，在重构前后实现的功能会不一样，但它仍是为了实现一定的功能，只不外由旧变新而已。

上面的几点是我在开发项目过程实际碰到的，欢迎大家增补