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

1，项目开端时，我们规则好一些代码标准，在必定的标准下进行开发，可是人的思维是不一样的，也便是说每个功用不同的人完结的逻辑或许会有这样那样的不同，导致了一些人不愿意去看他人代码，要改他人代码，首要要了解这个人其时是怎么想的，他的逻辑是怎么样的。所以有许多人的想法是有那看他人代码的时刻，我就从头做好了。这种想法不要有，看他人代码也能学到不少东西。假设都这样想，我想冗余代码会越来越多，后期重构会变的越来越困难。

2，做程序的一般换岗都比较频频，项目开端的时候，是5个人（项目开创人）开发的，等项目上线了，或许有人离职了。人手不够，公司招人。项目开创人呢，对新招的人，不太信认，怕修正原代码会导致上线的功用出问题，所以就出了新规则，最好不要修正上线过的程序，假设需求变化，最好从头写class或许是function，这样的话，代码会变的越来越多。或许会出现几个class都差不多，或许多个function的功用差不多。

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

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

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

1，人的思维不或许一样，我们都在尽量往一处想，可是总会有这样，那样的不同。

2，急于要完结功用，而不深入了解他人代码。研讨他人代码不如从头开发快，这种思维欠好。

3，数据库冗余，这个我个人觉得必然会出现的，一个项目做大，做强，必定是在不断的生长，生长过程中，数据库不或许是一成不变的。

4，短少分块思维，我觉得一个项目，便是许多功用独立的小块通过必定线串起来的，代码重构也便是把这些小块的从头组合，当然各个小块，在重构前后完结的功用会不一样，但它还是为了完结必定的功用，只不过由旧变新罢了。