目前的任务是处理成绩导出到Word的一处Bug，由于之前完成该模块的人员已经离职，涉及到该模块的交接文档也没有描叙详尽，所以我就当一个新知识来处理。在解决Bug之前，我的主观意愿是尽快找到问题的所在之处，就像医生会诊一样首先要找到病因再对症下药。
我将模块部署到本地项目中，调试。我很幸运，在本地项目中，Bug能够重现，表现形式也和错误报告中的截图一致，这是值得欣慰的，因为很多时候让人头痛不是出现Bug，而是Bug不能重现，这让我们处理问题的人无从下手。由于我事先已经熟悉过该模块的代码，对模块的实现流程已经做到较为熟悉，所以在可能出现问题的环节下了一处断点，最后成功捕捉到了异常，并确定这就是问题所在。（之前的开发人员在集成该模块时会做一条初始化记录，作为参数配置；但是部署给其他客户时，这条初始化语句不是每次都会执行的，所以程序在读到空记录行时抛出异常）
问题解决，我将项目部署到IIS上，准备给测试人员测试。但这时又出现问题了，我访问IIS先进行测试，发现模块还是有问题。本地调试正常，放在IIS上流程却还是不能走通。oh no~ 这也是一个让人头痛的情况。怎么办呢，IIS上又不能调试，错误环节无法定位。但找到问题所在是我纠错的首要准则。我是这样解决的：首先在数据库中创建一张错误日志表，然后我在一个大环节的开始和结尾处分别作错误记录日志。运行一次，错误日志表没有我期望的异常信息。接着，我缩小环节，在始末位置记录错误日志。随着环节不断的缩小，通过日志记录中查到的端倪，我找到了错误的所在。由于错误代码块有异常捕捉，这正是IIS上没有抛出异常而流程无法走通的原因。通过错误日志发现，原来Windows服务的启动是需要权限的，而通过IIS发布的一个页面去调用Windows服务时是匿名身份的，权限低。这就要使用以下代码，指定访问时使用指定的系统账户身份。<identity impersonate="true" userName="Administrator" password="your pwd" />
问题貌似解决了，但为了减少错误再次出现的可能性。我随机抽取了两家客户的数据库进行测试，发现流程还是不能走通。各种纠结，各种苦逼啊。而这回，我将矛头指向了Windows服务，我觉得可能是服务内部存在缺陷。可这是我之前从未接触的一个知识点，我不得不花一点时间来研究这项不曾了解的技术。遇到这类情况，我觉得也有必要总结一下。首先不能因为没有使用过一个技术，而上面又催着交工就着急，就害怕完成不鸟。个人认为对于在软件行业呆了2年以上的程序员，应该没什么问题是他下不鸟手或是解决不鸟的，关键是个时间问题。第一步，我在搜索了一些关于该技术的资料，这东西大致用来干什么，如何实现一些功能的，我做到了心中有数。关于查资料，我觉得先搜简单的资料，主要是为了掌握个大概，拔高的技术文章可以事后再沉下来研究。第二步，这时再来看项目有关windows服务的代码，因为做过准备，这时之前完全不懂的代码也弄明白啥意思了，整个框架也知晓大概了。这样利用前面说到的那些问题解决经验，藏在服务中的Bug也被我干掉了。
最后问题总算解决了，并敢说以后如果这个模块再出现问题，我也知道如何去解决它，维护它。
