最近两周我们在升级我们的项目到64位，简单记录一下。
背景
我们项目是在某个大型程序（暂且称之HostApp）上开发的一个插件。HostApp不断升级，需要的内存也越来越多。HostApp同时支持32位和64位版本，我们之前的版本一直只支持32位版本。今年我们的项目升级了一个原有的计算模块，需要的内存有所增加。悲催的是，当我们把带有新计算模块的整个系统升级到HostApp的最新版本2011后，内存终于扛不住了，一运行我们计算模块整个系统就挂。
我们真的需要升级吗？
遇到这问题之后，组内一商量，没办法了，升级到64位吧。虽然升级到64位不在今年的计划之中，但这是个绕不过去的坎。说干就干，大家把任务一细化，去研究项目所需的第三方的那些库都有没有64位版本，非托管的那些Fotran代码、C++代码如何编译成64位。就在大家开始干的热火朝天时，一个声音从一个高层的架构师那里传来：内存不够是吧？试试把 /3G 选项打开，再不行试试把计算模块挪到另外的进程中去。好像是啊，如果这两种方法可以解决问题，那就没有必要去升级64位，因为这毕竟不是计划内的工作，做这些肯定会影响原来计划内的那些任务。
这个事情告诉我们，问题可能有另外的解决方法，技术高度会影响一个人的技术视野，影响一个人的技术生产力。技术的高度来源于一个人的知识面、经验以及沟通学习能力。
我们到底需要支持什么？
既然组内决定了要升级到64位，并且已经做了挺多工作，那就先这么做吧。但是在做这个之前，我们并没有考虑清楚，我们到底需要支持什么。仅支持64位版本？同时支持32位和64位版本？这会影响我们如何去升级。开始的做法是大家觉得保留现有的32位这一套，再给所有的*.sln、*.csproj、*.vcproj、*.vfproj创建一套对应的64位版本*_x64.sln、*_x64.csproj、*_x64.vcproj、*_x64.vfproj。尽量保持所有源代码不变，这样就可以同时支持生成32位和64位版本。如下图。然而，做着做着却又发现，我们为什么需要32位和64位两套project文件？他们只是一些设置不同，不能在一套文件里支持这两种设置吗？答案是肯定的（参见http://stackoverflow.com/questions/145803/targeting-both-32bit-and-64bit-with-visual-studio-in-same-solution-project）。再接着往下做，我们发现有些源代码需要一些改动才能支持64位。那也意味着需要对源代码进行更多的改动才能支持这一份源代码支持同时生成32位和64位的可执行程序。我们真的需要同时支持32位和64位吗？如果有了64位版本，我们的用户至少90%会立马用64位版本，他们对此也是向往已久（由于内存原因）。剩下那些用户应该是由于机器原因用不了64位的，但这种情况下即使我们有新版本的32位他们也照样用不了，因为新版本的HostApp本来在那些老机器上都跑不好！现在问题看起来好像简单了，我们只需要支持64位版本就可以了。需求明确了，解决方案自然也就简单了很多。
在寻找解决方案的同时不断地反复推敲需求是很有必要的，多反问自己、和用户沟通，你会发现有些需要复杂方案来实现的需求可能用户根本不需要！
总结
* 技术实力、技术高度决定解决问题的效率。提高技术实力吧，对于技术人来说，这是一切的基础！
* 多花些时间研究业务，做用户真正需要的东西。不要试图用技术手段来解决业务问题！