毕业后就一直从事于服务器端程序的开发，主要客户是中国移动，大家知道移动的产品都是电信级的，稍出差错后果都是严重的，所以在我们平时的工作中除了研发之外，还有的就是对我们卖给移动的产品的维护性工作，而这种维护性工作要求就是要"迅速解决现场的问题"。这几个月维护工作占据了我很大一部分精力，说实话，有些烦了，但是从另外一个角度来看，也说明了我们的产品在维护性方面做的不够好，否则移动的工作人员或当地的技术支持人员通过手册或者查看系统日志的方式就可以解决问题的。这让我反思。

一般来说，我们的产品在交付时都是有详尽的用户手册的，现场人员可以根据维护手册来查找问题所在。另外维护工作也是分层次的，在运行我们产品的各省移动公司都有我们的当地技术支持人员，而移动自己的网管人员在多年的维护过程中也逐渐的积累了丰富的问题解决经验。一般问题发生后，移动的人员都会试着自己来尝试解决，当其无法解决时，会将问题告诉当地的技术支持人员，只有在技术支持人员也解决不了问题的时候，问题才会反馈给我们研发人员，而研发人员就成为了系统的最后一道保护伞了。移动人员的素质我们自然控制不了，我方技术人员我们会尽可能的通过培训和讲解的方式传授解决问题的办法，并通过他们自己在维护过程中积累经验，但是一旦问题提交给研发人员，我们就需要在远程以最快的时间将问题解决。

研发人员一般来说对业务熟悉，对功能是如何实现也有把握，但是一个系统往往是很庞大的，很可能是经过"几代人"前离后继"(前人离职了，后人来继承)完成的，所以到最后很可能整个产品组内没有一个人对整个系统的每个角落都了如指掌的，这时问题就出现了。

对于研发人员来说，他们最擅长的就是通过问题现象去到代码里分析，现场产品因为在运行，一般来说我们不可能去用调试工具直接调试现场运行的程序的。而问题的现象一般是通过系统日志体现出来的；也就是说在研发人员解决问题这层，系统的运行日志对解决问题起着至关重要的作用。这样一来系统日志设计的好坏直接会影响到你解决问题的效率和质量。

而通过日志定位问题所在的代码位置一般有如下几个现象：

[现象一]  当你用某一个错误日志去search in project的时候，居然发现：
if (condition1 | condition2 | condition3)
      你查询的日志输出;
输出该日志的条件是多个或的关系，而且每个condition也许是一个复杂的函数调用，这会大大延长你跟踪问题的时间；

解决方法：
a) 尽量减少condition1 | condition2 | condition3的使用；
b) 对于复杂和关键地方的处理，给出"点睛"的注释；

[现象二] 当你用某一个错误日志去search in project的时候，居然发现：
Project中存在不止一条这样的错误日志，其位置可能分布在Project的不同源文件中的不同位置。这同样会大大延长你跟踪问题的时间和难度。

解决方法：
我们套用"幸福的家庭往往是相同的,不幸的家庭各有各的不幸"来说明：成功的日志往往格式相同，失败的日志各有各的特征。如果每条错误日志的特点都不相同，那么当我们search的时候，就可以一次定位问题所在了。

[现象三] 当你用某一个错误日志去search in project的时候，居然发现：
该日志是在一个宏的定义中输出的，而该宏散布在Project的各个角落。

解决方法：
不要在宏(广泛使用的宏)中做任何日志输出。

当然上述的某些解决方法可能与代码的可读性或者精炼性有悖，这就要看你是如何抉择的了，根据具体情况三思而后行。

另外对于查找问题而言，关键而详尽的注释会给研发人员带来很大帮助，否则他就很可能陷入复杂的业务逻辑中，长时间不能自拔了。

以上一点私人见解，仅供参考。

近期公司实行新的绩效考核机制，我的考核目标中就有一项叫做："成功使用新技术、框架、思路等至少3个"，呵呵，先不论绩效考核机制是否合理，既然已经这样了那就需要去适应。一直在做Network Application，早就知道ACE在业界中的名气，这回有理由找个时间好好挖掘一下ACE的思路，也为我的绩效目标增色啊^_^。

以上只是开个玩笑罢了。上周末去书店看到电子工业出版社再次出版的'C++网络编程卷一'，这套书的卷1以及卷2的英文电子版我早已有了，但是还是喜欢抱着纸板书看书的那种感觉，所以就顺便买了下来。翻看了一下，发现里面的内容恰恰是现在我所需要的，如果是前两年看这本书，理解起来肯定不会很透彻，因为那时的心中缺少的是恰恰是问题和困惑，没有了那些东西看书的效果也就大打折扣；反之如果作者的思路恰恰是把你扶上的正确的思维轨道，以帮助你解决了心中的那个结，你的收获就会是大大的。

记得前年的时候曾经下载过ACE并且尝试从源代码Build，结果是失败了，原因现在已经记不清了；这次重新下载ACE-5.5版本在Solaris 9上用G++ 3.2编译，居然顺利通过，其功劳应该归功于ACE的开发者之一Stephen D. Huston的'The ACE Programmers Guide'一书，而且从ACE自带文档中得知，ACE最先就是在Solaris上开发的。

Build过程：
1. 下载ACE的源码包；解包解压，一般你会在当前目录下获得一个名为'ACE_wrappers'的目录；
2. 设置ACE_ROOT环境变量；如我用的是csh，我就会在用户的HOME路径下的.cshrc中增加一个环境变量ACE_ROOT，比如：setenv ACE_ROOT '/export/home1/baim/ACE_wrappers'；
3. 切换路径到$ACE_ROOT/ace/下，创建config.h，在这个头文件中，我们需要做一件事，就是include一个你所在的编译平台的头文件，比如我是在Sun Solaris 9上编译的，我的config.h中的内容就是这样的：
//config.h
#include "config-sunos5.9.h"

不同的平台，包含的头文件不同，这些头文件也都在$ACE_ROOT/ace/下，你可以用'ls -l|grep config'来看看究竟有哪些config头文件，选择你所在平台对应的即可。

4. 切换到$ACE_ROOT/include/makeinclude下，创建一个叫'platform_macros.GNU'的文件，同样这里也有平台相关的一堆.GNU文件，我们只需在我们新建的platform_macros.GNU文件中包含对应文件即可。
如我用g++在Solaris 9上编译，我就该选择：platform_sunos5_g++.GNU
//platform_macros.GNU
include $(ACE_ROOT)/include/makeinclude/platform_sunos5_g++.GNU

这个文件里还可以放置make的编译选项，比如我要生成.a文件，我可以这么做：
//platform_macros.GNU
static_libs=1
include $(ACE_ROOT)/include/makeinclude/platform_sunos5_g++.GNU

5. 切换到$ACE_ROOT/ace/下，输入make命令执行即可。编译的过程是漫长的，大约1个小时，之后你就会发现在$ACE_ROOT/ace/下有libACE.so -> libACE.so.5.5.0*、libACE.so.5.5.0*和libACE.a出现了。

构建过程到此结束。

ACE的makefile没有.phony install，所以在你的ACE应用程序里可直接引用$(ACE_ROOT)/ace下面的头文件，直接链接$(ACE_ROOT)/ace下面的libACE.a库即可。

//HelloACE.cpp
#include "ace/Log_Msg.h"

void foo (void);

int ACE_TMAIN (int, ACE_TCHAR *[])
{
  ACE_TRACE(ACE_TEXT ("main"));

  ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IHi Mom\n")));
  foo();
  ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IGoodnight\n")));

  return 0;
}

void foo (void)
{
  ACE_TRACE (ACE_TEXT ("foo"));

  ACE_DEBUG ((LM_INFO, ACE_TEXT ("%IHowdy Pardner\n")));
}

//编译
g++ -o HelloACE HelloACE.cpp -I$ACE_ROOT -I./ -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread

这里有几点注意事项：
1、如果libACE.so.5.5.0*和libACE.a都同时在$ACE_ROOT/ace下的话，上面的编译命令默认优先进行动态链接。也就是说编译出来的可执行程序HelloACE在运行的时候如果找不到libACE.so.5.5.0就会报错。
2、如果想进行静态链接的话，可以将$ACE_ROOT/ace下的libACE.so.5.5.0删除或者改名，这样在执行上面的编译命令后即是静态链接。
3、注意g++链接.a和.o时是有顺序的，g++从左到右读入目标文件或.a文件中的符号，如果靠右边的目标文件或者.a文件中没有靠左面的目标文件或者.a文件中的未定义的符号定义的话(或者白话一点说：右边没有左边想要的)，程序就会报错。比如我们把上述的编译命令改一下，改为：
g++ -o HelloACE -I$ACE_ROOT -I./ -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread HelloACE.cpp
执行命令后，会出现下面错误提示：

未定义                  文件中的
 符号                       在文件中
ACE_Log_Msg::log(ACE_Log_Priority, char const*, …)/var/tmp//ccBl9Q0L.o
ACE_Log_Msg::last_error_adapter()      /var/tmp//ccBl9Q0L.o
ACE_Log_Msg::conditional_set(char const*, int, int, int)/var/tmp//ccBl9Q0L.o
ACE_Log_Msg::instance()             /var/tmp//ccBl9Q0L.o
ld: 致命的: 符号参照错误. 没有输出被写入HelloACE
collect2: ld returned 1 exit status

实际上上面的命令g++ -o HelloACE -I$ACE_ROOT -I./ -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread HelloACE.cpp等价于下面两个命令：

g++ -c -I$ACE_ROOT -I./ HelloACE.cpp
g++ -o HelloACE -L$ACE_ROOT/ace -lACE  -lsocket -ldl -lgen -lnsl -lposix4 -lthread HelloACE.o

其实上面错误提示中的"/var/tmp//ccBl9Q0L.o"，其实就是一个匿名的HelloACE.o

另外在'The ACE Programmers Guide'一书中，作者给了个Makefile，如下：
BIN   = HelloACE
BUILD = $(VBIN)
SRC = $(addsuffix .cpp,$(BIN))
LIBS =
LDFLAGS = -L$(PROJ_ROOT)/lib
#—————————————————
#Include macros and targets
#—————————————————
include $(ACE_ROOT)/include/makeinclude/wrapper_macros.GNU
include $(ACE_ROOT)/include/makeinclude/macros.GNU
include $(ACE_ROOT)/include/makeinclude/rules.common.GNU
include $(ACE_ROOT)/include/makeinclude/rules.nonested.GNU
include $(ACE_ROOT)/include/makeinclude/rules.bin.GNU
include $(ACE_ROOT)/include/makeinclude/rules.local.GNU

直接用该Makefile会让你的build更简洁，另外还有支持多个.cpp文件的Makefile在那本书里，大家可以参考。