一个软件开发者的解决问题的心得——善于利用蛛丝马迹
作为一个软件开发者，研究问题以及解决问题是我们的职业所要求的。针对一个问题，我们想要研究它，学习它，那就需要搜集相关的材料，学习这个问题所牵扯到的知识。只有掌握了一定的知识，那么利用我们的推理、观察、思考等才可能尽快地解决问题。
最近研究c#操作word脚注（footnote）。在网上搜索关于c#操作脚注的内容，少之又少。我研究的问题是这样的：如何生成脚注的时候，在脚注的内容前面，不生成序号，或者生成后，可以删除掉，因为前面的序号我想自己控制。如图：
图上面的正文中的[2] ，和hello前面的一样，我想自由控制hello world前面的东东。有两种方案：
方案一：生成脚注的时候，自定义标记，插入空的符号，此方案用代码没有实现。
方案二：删除掉hello world前面的[2],然后加入自己的编号。
方案二，c#代码实现的时候，也是特别难，不知道怎么做。我在网上搜索，根本没有答案。后来我在笔记本中找到这样的一段代码：
Word.Range oRange = this.Application.Selection.Range;
oRange.Text = "1234567890";
object styleName = "Intense Emphasis";
oRange.SetRange(1, 5);
oRange.set_Style(ref styleName);
测试了下，发现这段代码原来是用来添加页脚的，从代码里面的单词也可以看出。跟我研究的脚注（footnote）关系不是很大。不过，我试着用了前面两句代码，摸索着，修改如下：
1 WordOpt.WordApplication.ActiveWindow.ActivePane.View.SeekView = Word.WdSeekView.wdSeekFootnotes; 2 Word.Range oRange = WordOpt.WordApplication.Selection.Range; 3 oRange.SetRange(0, 2); 4 oRange.Delete();
这样就实现了方案二。
由此可见，一两句的代码，对我们研究的问题，也可能会产生很大的作用，直至问题解决。值得一提的是，我在前期收集材料的时候，把代码片段保留下来，当时也不知道能不能用上，只是觉得有点关联。
第二个例子：我用vsto做了一个word插件，同事负责打包。在32位word上可以安装成功，但在64位word上，加载不了插件。
同事问我，你当时是怎么测试64位的？我说我安装了64位操作系统，然后装了64位word。其实这不是她想要的答案，于是我在本地再次测试。我先生成debug文件，把debug下的东西拷贝到虚拟机上测试。但同事是release打包，然后测试的。我在debug下生成的东西，安装是没有问题的。于是我release了下，然后在直接安装vsto文件时，报出一个错误来，xx.dll哈希值与清单中计算的不一致，这下把我搞懵了。后来，为了解决这个问题，我把清单文件打开，也不知道怎么办。我想了下，debug都没有问题，于是我把debug下的xx.dll拷贝到release下，结果又报清单上的dll版本与实际文件的dll版本不一致。这下，我想看看debug下清单，找出xx.dll信息来，令我吃惊的是，它和release下的信息有一个地方不同，这个地方立刻引起了我的注意。我想这就是在64位上装不成功的原因。于是我跟她说了下我这个小发现，结果她重新打包，一会儿问题就解决了。
<assemblyIdentity name="Samson.NoteFirst.RemoteCallInterface" version="1.0.0.0" publicKeyToken="B9552CFE9AEF3411" language="neutral" processorArchitecture="x86" />
看了下 processorArchitecture="x86"，这不是说的32位吗？
由此可见，从一个细节的地方着手，就可能会直接解决问题，但前提是如何发现这个细节，这个一方面是知识经验，另一方面是直觉和灵感。灵感经常在苦闷和无助，但是一直苦苦思索和追求当中，像闪电般刹那间闪现。知识和经验那得靠时间来积累，直觉得有好的观察力和洞察力。
