在工作中，我们常常会听到这样的声音：“原来的系统就是这么做的！”。

没错儿，在工作中我们潜移默化地受到了遗留系统的一些设计和实现的“惯例”的影响，另外天生携带的懒惰基因使我们很少去思考和判断这些惯例的正确性和保留的必要性。但事实上，我们确应该经常重新审视这些遗留的“惯例”，有选择的保留，并敢于放弃。

每种“惯例”的引入和使用都是有其特定原因的：或是可以简化代码编写，或是便于代码跟踪，或是利于代码调试，或是迫于对外部工具的妥协，也有的是为了偷懒儿^_^，甚至有些惯例的引入本身就是不妥当的甚至是错误的，只是当时无人喊出反对的声音，也就被保留了下来。

新项目启动已两月有余，除了前期参与一些编码外，现在的我更多是代码检查和评审者的角色。在这个角色上，我看到了一些本不该保留下来的遗留“惯例”，这里挑了几个拿出来说说。

#1 – 在源代码文件中记录代码变更信息
在遗留系统的一个典型的“惯例”就是在源文件中（包括.h和.c文件）记录代码变更信息，比如下面的例子：

/*
 * foo_test.c
 *
 * NUM  | description    | by     | date      |
 * 001  | 添加XX业务逻辑 | xx     | 20100805  |
 * 002  | 修改YY业务逻辑 | yy     | 20100809  |
 * 003  | 删除ZZ业务逻辑 | zz     | 20100809  |
 * … …
 */

在foo_test.c的开始处，开发人员记录了所有关于这个文件的所有变更信息索引，此外在该源文件中充斥着诸如：001+、002*和003-这样的注释信息，以跟踪源码的变动。

这个遗留“惯例”的出处已无法追溯了，也许是当初没有对版本控制工具的功能特性有着很充分的认识，也许还可能是当初干脆就没有引入版本控制工具，不过无论如何，在subversion、git等版本控制工具大行其道的今天，这样的“惯例”已不再合适，它会使我们的代码不再clean。

现在我们一般推荐采用版本控制工具的commit log与ChangeLog相结合的方式来管理和跟踪代码变更，更精确的说是使用commit log详细跟踪代码变更，而使用ChangeLog来跟踪功能变更和某些重要的bugfix。 在提倡频繁提交与集成的今天，ChangeLog会显得尤为重要，它与commit log相辅相成。如果没有ChangeLog粗线条地记录项目功能变更，指望大家从数量繁多的commit log中提炼出功能变更是不现实的、不具备可操作性的、也是不可接受的。

#2 – 过度使用续行符
在新项目代码里，我发现了一些使用续行符的代码，诸如：
void foo(int a, int b, \
         char *p, \
         struct foo_t *f);

printf("%s\n", "Foo Test, \
               ,Test Foo");

printf("%d, %s, %d\n", \
        a,\
        "Foo Test",\
        b);

我之前只是在遗留系统中见识过类似的代码，显然这是受到了遗留代码“惯例”的影响了。

续行符，顾名思义，当一行代码过长，影响代码整体美观或超出编译器每行最大字符数限制时采用的方法，用于指示编译器续行符前后的两行实际上应作为一行处理。以前的编译器不足够智能，甚至每行支持的最大字符数也很少，有些时候确要使用续行符来辅助编码。但是如今编译器愈来愈强大，续行符的使用场合已经不多了。将上面代码改造为如下代码编译器也完成可以处理：
void foo(int a, int b,
         char *p,
         struct foo_t *f);

printf("%s\n", "Foo Test,"
               ",Test Foo");

printf("%d, %s, %d\n",
        a,
        "Foo Test",
        b);

其中第一个printf中分属两行的字符串会被编译器自动连接成一行字符串对待，这还可以解决使用续行符导致的"Foo Test"和",Test Foo"之间出现多余空格的情况。续行符可以用到的场合似乎只剩下多行宏定义中了。

#3 subversion源码库中保存二进制文件
我们的产品一直运行在Sun小型机上，CPU是Ultra Sparc，OS为Solaris，长期如此也导致了我们很少考虑可移植性问题，甚至在遗留系统中，我们直接将第三方库的sparc solaris版本的.a文件放入了Subversion的源码库中管理，这样我们Checkout出来后便可以直接链接生成可执行文件。

这样的“惯例”延续到了新项目中，不过我们的新项目近期修改了目标，可移植性列上了日程，目标平台不再只是单一的Sparc Solaris了。如果我们继续坚守这个“惯例”，那么将会给我们带来不小的第三方库版本管理上的麻烦，甚至连Makefile都要跟随着不断做调整。所以是时候将特定目标平台的二进制.a文件从源码库中移除了，具体方法这里不赘述了。

变化是永恒的，经常反思一下你日常工作中那些所谓的“惯例”，它们真的值得继续保留下去吗？

记得恰好是在一个月前的今天，我发布了lcut(轻量级C语言单元测试框架)0.1.0版本
。由于发布仓促，文档没能及时跟上。在stackoverflow的一个关于单元测试的帖子
上，一位叫Craig McQueen的朋友也给出了建议："Some documentation would be helpful. Project background and goals, a features list, advantages over existing alternatives, etc would be helpful for people who are checking it out for the first time." 看完这个建议后心里那个汗啊！不过一想到用E文编写文档心里就有些打怵。就这样在这一个月里文档依旧没有改观:(。不过，lcut本身还是有一些进步的，这两天一直规划着为lcut增加mock的支持，今天终于将这个功能加进了lcut，并发布了lcut-0.2.0-beta版，欢迎大家试用，并提出意见和建议。

之前在单元测试过程中使用cmockery中提供的mock功能，cmockery也是lcut的mock功能的直接灵感来源。与cmockery不同的是lcut将对输出参数的mock和对函数返回值的mock区分开来，这样用起来更加直观。

这里用一个简单的例子(完整代码在lcut包product_database_test.c文件中)来说明一下lcut的mock功能如何使用：

/* product_database.c */
int get_total_count_of_employee() {
    database_conn *conn = NULL;
    int retv = -1;
    int total_count = -1;

    conn = connect_to_database("tonybai", "tonybai", "mysql");
    if (!conn)
        return -1;

    retv = table_row_count(conn, "EMPLOYEE_TABLE", &total_count);
    if (retv < 0)
        return -1;
    return total_count;
}

/* product_database_test.c */
database_conn *connect_to_database(const char *user,
                                   const char *passwd,
                                   const char *serviceid) {
    return (database_conn*)LCUT_MOCK_RETV();
}

int table_row_count(const database_conn *conn,
                    const char *table_name,
                    int *total_count) {
    (*total_count) = (int)LCUT_MOCK_ARG();
    return (int)LCUT_MOCK_RETV();
}

void tc_get_total_count_of_employee_ok(lcut_tc_t *tc, void *data) {
    LCUT_RETV_RETURN(connect_to_database, 0×1234);
    LCUT_ARG_RETURN(table_row_count, 5);
    LCUT_RETV_RETURN(table_row_count, 0);

    LCUT_INT_EQUAL(tc, 5, get_total_count_of_employee());
}

被mock的函数多为系统API或执行代价较高的第三方库函数，我们在业务代码更关心的是这些函数的接口行为，而C语言中函数的接口行为表现为：返回值和输出参数。我们需要通过控制被mock函数的接口行为来达到测试我们业务代码的目的，所以我们需要mock这些函数的返回值和输出参数。上面例子中connect_to_database和table_row_count就是两个被mock了的库函数。我们通过LCUT_MOCK_RETV来mock函数的返回值，通过LCUT_MOCK_ARG来mock函数的输出参数。在测试代码tc_get_total_count_of_employee_ok中，我们分别通过LCUT_RETV_RETURN和LCUT_ARG_RETURN来控制前面两个被mock的函数中mock obj的返回值和输出参数: LCUT_RETV_RETURN(connect_to_database, 0×1234)告诉connect_to_database返回(int)0×1234，相应的，LCUT_ARG_RETURN(table_row_count, 5)则告诉table_row_count执行后其输出参数*total_count的值为5。有了这些设定的mock obj我们就可以专注于我们业务层代码的白盒逻辑单元测试了，一旦connect_to_database和table_row_count的外部行为被控制后，业务层的代码get_total_count_of_employee的行为也就是可预期的了，我们用断言测试即可。

由于实现原理限制，如果你的函数输出参数类型或返回值类型为double*/float*，那么这个函数还不能使用lcut的mock功能，否则会编译出错。但绝大多数软件开发领域都很少使用浮点计算，所以lcut的mock还是可以满足大多数需要的。

题外话：
在公司使用代理上网，svn无法直接访问google code，这个问题一直困扰着我，直到今天才知道可以为svn客户端设置代理，设置步骤如下：
-> vi ~/.subversion/servers
-> 增加如下设置：
   [global]
   http-proxy-host = 你的代理主机域名或ip
   http-proxy-port = 端口
   http-proxy-username = 你的用户名
   http-proxy-password = 你的密码
设置后，svn立马就可以连上google code的svn server了。