文件的对应关系不能乱

　　这里涉及到从branch到main的intergration，你在branch上把一个文件移动了并做了修改，而在main上同样有人做了修改，做intergration的时候，你很容易丢失别人在main上的修改，因为其对应关系并没有被建立起来，也无从merge了。我想不同的SCM工具应该都提供了解决方案的，比如perforce可以在其branchspec中来说明其对应关系。

　　重构的方法

　　工作期间拜读过《重构----改善既有代码的设计》，上面讲了许多不错的改善设计的方法与步骤，但是基本没用上。因为关于设计，我们对哪种情况，如何修改之前都已做了研究并有了方案，而那些步骤感觉稍显罗嗦，不是很适用。VisualAssist提供了个重构的模块，在一般规模的代码里用用还可以，但是对于有很多个solution的代码无能为力了。况且这些只是涉及到源代码的重构，我们还有工程/DLL的重构。

　　我们采取的方法是：针对不同的情况，写perl脚本来自动化一些任务。举个简单点的例子：我修改了一个方法的名字，脚本会搜索所有的代码，自动check-out需要修改的文件，并替换新名字。记得当时写了许多perl脚本来自动化对perforce的调用，VS的调用，对代码，工程文件的修改等等。

　　一些细节

　　interface的使用

　　我们的重构工作对于接口可以说是无所不用其极，而正是大量的使用接口才让这种已经耦合很紧的代码的UI-核心的分离成为可能。比如某个核心层的操作完成之后是调用UI的刷新代码，而把这个刷新操作移到外面又是相当困难的，此时用接口是比较好的做法：

　　image

　　pInterface->UpdateUI();

　　当然还有一些其他的使用接口的方式，但归根结底都是为了分离实现。

　　使用vsprops

　　我们用的是VisualStudio，上百个项目都有其各自的设置，而其实很多设置都是差不多的，完全可以把那些一致的设置放到一个vsprops文件中，让每个vcproj文件都引用它。能在很到程度上提高一致性与简洁度。MSDN有其详细的介绍。

　　虚函数与rebuild。添加，删除虚函数，尤其是基类里的虚函数都会破坏原有的虚表，因此除非rebuild所有可能引用到的代码，不然会产生很奇怪的函数调用，具体可以看这篇：关于虚函数那点破事。

　　做这种大型软件的重构，让我学到比较多的是：

　　面对一些大型的软件系统不会犯憷，会比较有自信。

　　养成自动化的习惯，一些大量的手工操作，会很枯燥，很费时，做的很容易出错而且没有成感，但是把目标转换一下：写个程序把工作自动化，上面那些问题是不是都没了。