网站重构（重写）应该注意哪些？

Question

为了提高网站质量、用户体验、改进现有的弊端，要对网站重构，并且我们想把现有网站转移到Phalcon框架，很多东西还不是很清晰。想了解重构时需要注意哪些？

---

比如：

• 如何平滑的迁移数据库
• 如何不影响用户使用
• 如何提高重构效率
• 如何保障出问题了能尽量挽回
• 等等...

望有经验者指点！

Answer 1

谢邀。
因为个人经验不是很丰富，且并未参与过整个网站的重构项目，在平时的工作时只是做过部分功能上的重构，因此把自己的一些想法和经验说出来，希望能对小北有所帮助。

1.充分的测试

测试应该随着重构的步骤同步进行，不要等到重构快要结束然后 run 一大堆测试，因为这样很难保证测试充分，最好的办法是随着重构的步骤，一步步进行测试，这样可以将出错率尽可能地降低，看上去花了更多时间，实则是提高了效率。

2.保持行为单纯

重构就是重新构建现有代码，所以不要把新的功能混合到重构的过程中来，可能只是顺手一笔，但是我建议把重构的目的单纯化，即使发现那些功能上可以改进的，也可以记录下来，在重构完成后新建一个分支去做。

3.明确重构目的

重构都是带有目的性的，例如提高页面性能，缩减代码行数，缩减庞大的类或函数，提高代码的可读性等等。因此在重构前先把目的理清，在重构结束比较是否达到了要求，例如页面的性能提高了多少，代码行数缩减了多少。不要为了重构而重构，这样没有目的性的活动实际作用不大。

4.交流重构思路

这点得感谢我的老大 - Lucas，不仅每次都会 review 我重构后提交的代码，而且在我重构之前都会要求我把大致的思路讲一下，并给出我实质性的建议。我觉得这是个很好的团队习惯，因为重构不是个人行为，而是影响整个团队的操作，所以在进行较大重构前，应该跟团队其他成员深入交流，不要等到重构结束再去介绍，这样得花费更多的时间去解释，而且很可能效果不佳。

Answer 2

我觉得你列出来的所有问题，除了效率之外，解决方案都一样

灰度部署

至于怎么灰度部署，不外乎接入机nginx配置reload，如果业务有状态，可能还需要有写cookie然后让nginx根据cookie决定走不同的后端

嗯，关于数据库，因为不知道你的网站的业务模型，需要具体情况具体分析。最好的方案就是保持数据结构不变，先换技术框架。这样的好处是方便灰度，降低风险。等技术框架迁移干净了，再来考虑改数据结构

Answer 3

如何保障出问题了能尽量挽回

我觉得转移之前要先做大量的测试工作降低故障概率这是必须要做先做的，假设所谓的故障为转移后带来的一点不协调，可以先有目的性的让一部分用户去使用新的架构来降低出故障的概率，这样可能会造成数据的不同步，所以最好还是要再考虑有目的的转移某些用户的某些功能。当然转移时的数据备份，不用说了必须要做的。

如何提高重构效率

有人提到review，这个是很关键，主要是如果是个团队，每个人不可能什么地方都了解，所以还是要在重构的整个周期都要做review来保证这次的重构不会对现有的程序带来不必要的麻烦，但是重构的度要掌握好，什么是该做的什么是以后才能做的？

如何平滑的迁移数据库
如何不影响用户使用

这2点我认为应该是一起的，功能怎样都好，只要放上去了就应该经过了很多层关卡，但是数据库的过度不是一朝一夕可以完成的，而这个过程既要保证新的db对老db的支持，还要考虑他们的差异，迁移时造成的数据不同步等等……

那么怎样能够平滑的过度？我觉得还是先review，把所有的表格之间的关系理清，功能性的迁移table，迁移中的不同步，之后写程序来append吧。迁移的过程中要保持用户的体验，就可以结合上面提到的分用户分功能的转移到新的环境来处理请求。

当然最简单的办法就是不换db，或换相近的db，比如mysql和Maria。

---

看题主的意思，就是迁移中不能停服务器，其实如果能够停一下的话能好做很多。总之我的建议就是做之前要先看，而且不要因为工期的问题来赶时间，这样往往不会有好的效果。

Answer 4

http://blog.csdn.net/hitlion2008/article/details/8298552