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

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

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

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

#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文件从源码库中移除了，具体方法这里不赘述了。

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

自从LP上班后，果果一直由岳母照顾。带小孩子是一件很辛苦的差事，这个我和LP也十分清楚，这不这个十一假期我们让岳母回家歇息歇息^_^，这七天就由我和LP照顾果果。

平时我和LP都是朝九晚五的作息，由于公司离家较远，我们下班到家基本上都是晚上六点以后了。我回家更晚，有时候到家时果果已经被哄睡着了。这样我们和果果在一起的时间实际上并不多，甚至对果果新近养成的一些习惯了解得都不多，一切还要慢慢适应。

以前喂奶、添加辅食、把尿等都是岳母一个人包办，现在我和LP共同承担。之前果果每天的作息基本已经养成：
1、早上6点果果睡醒，先把屎把尿;
2、喂白水（<50ml，早起成人要喝杯白水，婴儿也不例外^_^）
3、大约7点左右第一次喂奶（果果现在一次能喝180ml母乳，据说同龄男孩儿可以一次喝光240ml)。
4、陪着果果玩耍，直到8点半左右，哄果果睡觉（白天果果每觉都比较短，大约半个小时）
5、9点多果果睡醒，喂少量白水;
6、10点左右添加第一遍辅食-半个鸡蛋黄（用水搅成泥状，吃完后补充点白水，防止噎着）
7、11点左右第二次喂奶
8、陪着果果玩耍，直到12点左右，哄果果睡觉（现在天气冷了，一般不带果果出去看大自然了，另外果果已经五个多月了，从母体中携带的免疫因子正在减少，也怕带果果出去着凉生病)
9、12点半左右，果果睡醒，继续陪着她玩耍;
10、下午1点半左右添加第二顿辅食-50ml果汁或鲜水果煮的水(因为果汁或鲜水果煮的水都很甜，所以果果很爱喝)。
11、下午3点左右，第三次喂奶，一般果果吃完奶也会睡上一觉。
12、3点半或4点多果果醒来，陪她玩耍半个小时，然后给果果洗澡。（果果特别爱洗澡）
13、洗完澡的果果恢复了精力，能持续玩耍两个小时，到了晚上6点半或7点左右，第四次喂奶并哄果果睡觉。
14、凌晨1点半或两点，果果醒一次，LP第五次给果果喂奶。
15、果果一觉到天亮。

国庆前三天是“适应期”-我们要适应果果的作息。刚刚从工作状态转换为长假休息状态，这个身体还是很疲惫的，所以前三天我和LP都感觉特“困”，甚至有时陪果果在床上玩耍时都能睡着。另外果果也着实“不老实”并且精力充沛得很，看什么都是新鲜的，争着去抓去拿。果果这个阶段还喜欢“啃”东西，只要能拿到她手里的，全部往嘴里塞。所以时刻都要看住果果，不能离人。 哄果果睡觉是最累人的。果果困的时候，显得很是烦躁，大声喊叫，躺在床上左翻右翻，抱起来后小脑瓜儿是左转右转。另外果果体重近17斤，如果哄上一段时间仍然不能将她哄睡着，那胳膊就会开始酸痛。还好有我和LP两个人，我们可以换着哄^_^。

“适应期”过去后，一切变得自然了些，我和LP的体力也恢复了，白天也不感觉那么困倦了，带起果果来顺手多了。果果也适应了我们，之后家里更多的是果果的笑声和笑脸。不过给果果喂奶还是很费劲儿。果果一直吃母乳，LP白天上班将乳汁挤到专用的“母乳保鲜袋”里，再放到冰包里保存。回家放到冰箱里，留着果果白天用奶瓶喝。LP放假在家就不用这么麻烦了，果果可以直接吃母乳。不过不知道是不是果果习惯了奶瓶，这几天果果甚是不愿意直接吸母乳，除了半夜那次（果果夜里起来迷迷糊糊的，给什么都吃^_^）。这个问题让我们很是头疼，每次喂奶果果的大喊大叫又哭又闹的不愿意吃，直到换成奶瓶。

今天是十一假期的第六天了，如果说带果果不累那是假的，真的很累，甚至感觉比上班还累。不过正如dutor所说，这里面的“幸福和快乐”也许只有我自己才能体会到^_^。当然LP她也能体会到，呵呵！