分类：
2009-03-15 18:21:22
为了协助工程中心完成AGC功能的客户验收，在楼上折腾了足足两天，一个简单的程序应用，原本只想用周五晚上一两个小时搞定的事情，结果从周五晚上一直搞到星期日中午，损失惨重。 回顾这次排除问题的经历，总的来说有两个阶段：
先是周五晚上，将程序顺利运行起来。因为之前工程人员已经进行了配置，所以，我以为把程序运行起来即可回家享受周末。不过，现实是残酷的。程序运行后，直接出core，退出。同时发现好多报错说找不到xxx文件的打印信息。想都没想，我就认定是文件找不到，造成的dump。肯定是程序版本太旧造成的问题。于是，就跑到其他工程上找程序。这个时候，不管是谁都会开始埋怨unix机器上使用u盘，是他妈的真麻烦。等我搞到最新的程序，一运行，完，问题依旧。我立马傻眼，搞什么飞机啊，难道最新的程序也有问题。给维护程序版本的同事打了电话，同事的回答差点让我吐血，原来那条报错根本没关系。昏倒，我真想破口大骂，没关系的错，你把它打出来干嘛啊，不过想想人家怎么打印信息关你什么事啊，完全是自己太懒，没去检查core文件，也就算了，还凭着一条臆测的错误折腾。唉，说到底，毛糙害死人。回过头来，用dbx工具查看core文件，问题立马搞定。原来配置有问题。程序终于不再出core。一看表。。。都已经八点半了。看着配合工作的同事，只得算了，明天再说。总结晚上的工作，大把的时间消耗在无谓的操作上，而原因就是缺乏根据的主观臆测，我既然不是神汉，做事情还是踏踏实实，有根有据的好。
第二天，虽然程序运行了，可是作为程序最大功能的负荷分配却还是有问题，简报不停的报警，说设定值太大。只得再查，又是dbx调试，又是看程序的，可折腾了整个上午，才发现，原来是配置文件有问题。。。无语了，结合前一天的白忙活，我这才领悟到配置文件是多么的重要，要是我愿意用1分钟的时间把整个配置检查一遍，至于用上一上午加一晚上的功夫来查问题嘛。我早该考虑到，程序在那么多工程上应用，怎么会唯独在这个项目上出问题呢，所以一旦出现问题，最有可能的就是配置文件出错。
总结全部的工作，感觉自己浪费了很多时间，尤其是在工作目标的不明确，让自己吃了不少闷亏。为了检查问题，我采用了比较笨拙的方法，我会从程序的主函数开始，向下寻找相应的功能语句。由于程序的复杂性，所以，自己花了很多时间，看了很多可能我根本就没必要理解的东西上。如果从一开始就从出错的相关变量逆向思考问题，需要理解的语句就少了很多，可以很快定位问题。
