Tony Bai

虽然部门一直在做C应用 ，但这么多年来，在C应用的安装包制作以及部署方面做得还是很初级，可以说还没有达到规范的程度。各个产品线的C应用安装包种类多样，水平参差不齐：有些产品的源码包即是安装包，把源码包拿到生产环境下编译后使用；有的项目则将编译好的目标文件(.o)以及第三方库放在安装包中，在生产环境下重新链接生成可执行文件；有的组则稍微专业一些，安装包中放的是编译好的可执行文件，但在目标主机上安装和执行时也都遇到了一些问题，诸如运行环境中的第三方库版本号与程序所依赖的不一致等。

去年年底，我就将"C应用安装包制作和部署"的改进作为今年的一个工作重点。这两天我粗略地考量了一下这方面的内容，这里也简单地谈谈。

总的来说，摆在我们面前的有三个主要问题：
1、安装包的组织方式不规范，不统一；
2、安装包的制作方式不规范，不统一；
3、安装包的部署方法不规范，不统一；

好了，下面我们就来针对上述问题逐一说说改进思路（注意以下内容并非普适）。

一、安装包组织方式
在Linux 平台上应用的标准安装包是rpm或deb，但这种安装包形式似乎不太适合我们这种C后台应用。我对rpm或deb安装包了解的不多，但印象中这类安装包的安装一般为完全安装，但我们的应用升级版本时多数为增量安装或局部替换，因此做成rpm或deb虽然看起来专业一些，但实际操作起来并不灵活，因此自定义的安装包组织方式似乎更符合我们的需求。

下面是一个安装包的组织结构样例：
INSTALL_PACKAGE/
      - install.sh
      - README
      - app/
           - foo-1.0.1*
      - env/
           - conf/
           - log/
           - bin/
           ...
      - deps/
           - libs/
              - bar/
           - tools/
      - scripts/
           - deps_check.sh
           - ...
      - others/

其中:
app目录下存放的是可执行文件;
env目录下存放的是可执行程序运行时所需要的目录结构，包括配置文件等;
deps目录下存放的是可执行程序运行时所依赖的第三方库以及一些工具;
scripts目录下存放的是安装包安装过程中所需要的辅助脚本;
others目录下可以存放无法在上述目录下存放的其他数据;
install.sh是总控安装脚本，可以用于在目标主机上安装app、完整安装运行时环境、安装依赖libs或工具，执行scripts下面的必要脚本。

这样的一种安装包格式比较灵活，我们可以根据需要通过install.sh安装可执行文件或某个配置文件或其他数据文件。将INSTALL_PACKAGE目录打包(.tag.gz or .zip)就得到了我们的安装包。

安装包命名是要符合一定规范的，也便于进行配置管理。一个典型的安装包命名规范：程序名-版本号-平台-操作系统-编译模式.tar.gz[.zip]，例如：
foo-1.8.3-x86-linux-64bit.tar.gz
bar-2.9.3-x86-solaris-32bit.tar.gz
zoo-1.3.2-sparc-solaris-64bit.zip

二、安装包的制作方式
以往的安装包都是直接基于项目源码库构建 出来的，很多运行时目录、配置文件以及辅助脚本也都与源代码存放在一起，这样一来让源码库看起来很臃肿，二来一份源码控制无法对应部署到多个不同客户现场的安装包，也就是说不同客户生产环境下的配置、数据等都是不同的，但源码库只有一个，我只能保存一份配置，因此在生成不同安装包是似乎要临时修改，且无法将这些修改做版本管理。

我的一个想法就是将安装包涉及到的相关文件和目录从源码库中剥离出来，针对每个项目源码，我都会建立若干个安装包工程，安装包则是这些工程(project)的产物，且可以针对不同客户做有针对性的安装包修改和版本管理。记得Microsoft的Visual Studio就有单独的安装包制作工程模板，这里也算借鉴Visual Studio中安装包工程的思想了^_^。

下面是一个安装包工程的示例：
foo_INSTALL_Proj/
      - Makefile
      - distributions/
         - foo-2.9.3-x86-linux-64bit.tar.gz
      - src/
         - install.sh
         - README
         - app/
         - env/
           - conf/
           - log/
           - fifo/
           - bin/
           ...
         - deps/
           - libs/
           - tools/
         - scripts/
           - deps_check.sh

         - others/
其中src下面的内容就是上面提到的安装包的组织，通过安装包工程我们就可以灵活控制安装包中的每一个元素，而对源码没有任何影响。

三、安装包的安装模式
有了前面两个问题解决作为铺垫，这个问题就很好办了。我们的应用大致有两种安装模式：本地安装和远程安装，实际上也是一回事。本地安装就是手工将安装包放在某个目标主机上，然后解压，并利用安装包中的install.sh来安装需要的文件；而远程安装多半是用远程控制工具将安装包上传到目标主机（可能是多台），并通过远程命令在远程主机上执行本地安装。

这里想到的一个改进就是在目标环境中部署应用前，首先执行一次部署约束检查，检查目标环境是否满足新应用部署和运行的约束条件。这在以前的部署步骤中是没有的，约束检测脚本可随安装包携带，比如放在scripts目录下。

总之，规范化的安装包组织形式、制作方式以及部署方式不仅是一种专业化的表现，它与一些自动化工具的结合还会促进团队或组织整体效率的提升 。

对于我这个上班族来说，这假期真的不能太长，否则就适得其反了：不但不会得到很好的休息，反而感觉更累了。也许很多朋友和我有同样的感受^_^。这不，这个春节在家待得就比较"闹心"，特别是后几天，想上班的冲动那叫一个此起彼伏啊，终于今天如愿了^_^。

今天是壬辰龙年春节后的第一个工作日。如以往一样，办公室里比较冷清，很多同事还尚未结束休假。这可真是做整年谋划的黄金时间啊，我是这么想的，也是这么做的。

2012元旦后我就一直在考量，考量的内容除了个人目标外。还有团队目标和组织目标，以往考虑个人的居多，现在逐渐开始考虑团队和组织了，也算是一个进步吧。下面分别列一下目标清单。

一、个人目标
1、将Blog进行到底
2011年写了80余篇blog，今年力争百篇blog，在家庭琐事繁多、工作日益繁忙的今天，这个目标很鸡血啊！

2、全年至少精读50本书
"书中自有黄金屋"(颜如玉就算了^_^)，不读书总感觉空虚。经过2011年一年读书习惯的养成，特别是购买了电子书阅读器Bambook后，我对实现这一目标很是自信。另外我目前的纸质"存书"(买来后尚未读)也是很多的，今年也打算好好的"扫扫"。

3、学习一到两门新语言
"每年学习一门新编程语言"- 《The Pragmatic Programmer》一书的教诲不敢忘却，今年计划尝试一下Clojure，Lisp的又一种dialet，结合了强大的JVM，可以使用已有的丰富的Java类库，个人感觉Clojure似乎比Common Lisp更有前途；Lua，在云风的blog中经常提到的一门嵌入式动态脚本语言，前不久刚发布了5.2版本，我也打算了解一下。

4、深入使用Common Lisp和Python
去年学习了Common Lisp，但感觉还不够深入，今年打算再加深一下；至于Python，我已经在实际开发中运用了，但也只能算初级运用，今年也打算继续深入学习和使用一下，至少在buildc重构时以及为c_style_check.py添加新feature时可以用到。

5、继续为开源做点力所能及的事儿
在相继开源了lcut、cbehave和buildc等小工具后，今年尚未有很明确的新目标。最基本的计划是对buildc进行重构，并为c_style_check.py增加新feature以满足我们团队内部的需要。

6、坚持每天至少回答一个Stackoverflow上的问题
这个既可以锻炼一下自己的English Comprehension和Writing水平，同时也可以为这个知名的IT Community的知识管理作出一点贡献，顺便也给自己增加点人气数值。

7、养成几个好习惯
春节前读过刘未鹏的《暗时间》，受益匪浅啊。感觉自己在很多方面与书中提到的“先进行为和思维方式”还差得远，所以结合这本书中提到的内容，我计划在如下方面培养自己的好习惯：
- 做好读书笔记，留住闪念，提高读书效果
- 继续提高关注力，加强潜意识效率
- 减少中断式的任务查询，加强积极的任务安排和计划（改善时间管理）
- 尝试按"主题"读书，提高读书效率
- 加强新知识的总结
- 加强事前准备工作
- 注重"元知识"的学习和积累(所谓元知识，就是能够产生或推导出知识的知识)

8、理顺管理知识体系
做了几年的技术管理，团队的规模也是日益庞大，但总是感觉自己在技术管理这方面还很初级，知识脉络还不清晰。今年打算多反思一下这几年在项目产品开发、团队管理等方面的得与失，让管理能力真正成为自己的一种核心竞争力。

二、团队目标
2012年我给产品研发团队确定的关键词是"收获"。经过2011年的铺垫，今年该是"收获"的一年了。不过收获前，我们依旧是要付出辛勤和汗水的，我心里很是清楚这一点。围绕着这一点，我确定了今年团队的几个行动原则：

1、以终为始
开年伊始我们就要十分明确：我们的最终目标是什么？我们要成为一个什么样的团队？我们要开发出什么样的产品？我们产品上线后能给客户带来什么样的价值？只有明确后，我们再围绕着这些制定全年的计划和目标，基本上还是很靠谱的。

2、创业精神
这四个字是今年年底公司大BOSS在一封内部Mail中提到的 - 公司刚刚走过20年，又迈上了新征程，需要大家具备创业的精神来支撑公司未来的发展。想到"创业"，我的第一反应是：辛苦。所以给团队定下此原则也是有深层含义的，那就是在人力资源有限的情况下，完成目标是要付出很大辛苦的。这的对于大BOSS提出的"创业精神"的解读也许有些狭隘了，但这的确符合我们团队今年所面对的情况。

3、追求高效 
高效是一直我所倡导的团队文化之一。关于提高效率，我的观点是个体能力提升与组织基础服务并进。在今年我对团队的期望依旧如此。我们要考虑的是围绕着这一原则，我们该做些啥。

4、过程与结果双赢 
《暗时间》中刘未鹏提到"看中过程，而不是单次的结果，因为再好的过程也有可能失利，但从长远来看，好的过程总体上必须导致好的结果"。对此观点，我很是赞同。因为我一直所追求的也是"过程"与"结果"的双赢，只有这样才能推进个人、团队乃至组织的持续成长，若只有结果，也许只是收获一时的成长，但能否持续成长就要看造化了。

关于团队的具体目标，这里就不好说了。

三、组织目标
这里只说我能看到的且可以付出努力去争取的。

1、资源整合与合理调配
随着产品和项目的调整，现有的内部资源分配亟需调整，无论是人力资源还是硬件资源，特别是硬件资源，可使用现有新技术做出合理调配，让每台服务器都能物尽其用，减少因硬件资源不足而导致的进度延迟的情况。

2、尝试降低或消除部门间"壁垒"，积极促进部门间的沟通交流
做这件事的目的同样是为了消除浪费，整合资源，形成合力，制度化的部门间沟通平台的建立是大有裨益的。

3、人员招聘选拔
部门在人员招聘选拔上尚不够规范和系统，略显粗放和随便，这样除了会导致成本浪费之外，还可能导致所招之人根本无法达到预期，即所谓“招错人”现象的发生。这方面亟待加强，至少要做到“严进”二字。

以上就是我谋划的2012，目标的确有些鸡血！但我相信只要持续努力，持续去做，一步一个脚印，其结果肯定是好的。

2012，是农历龙年，也是中华民族的本命年。龙，是我们民族的图腾，大家对龙都是有着特殊的情感的，比如壬辰年的生辰龙票就特别抢手。

龙年了，果果也长大了，越来越像女孩儿了，呵呵（因头发短，常被人误认为是男孩儿），下面是果果近期的一些写真^_^，请您欣赏：

这种玩具难不倒我

瞧，我的眼神犀利不！

妈妈给我买的眼镜，知性不？

数一数，墙上有几朵花？

过年了，我的新衣服喜庆不？

好了，最后在龙年的大年初一，我代表的我的宝贝女儿果果给您拜年了。祝大家龙年新春快乐，阖家幸福，身体健康，万事如意。

构建是软件开发过程中最常见的活动之一，也是很容易被忽视的环节。规范以及高效的构建对软件开发过程而言是大有裨益的。C语言并非一门年轻的语言，其历史已甚为悠久了(相对于还年轻的IT领域^_^)。从C语言诞生以来，市面上存在的C语言应用何止千千万万。这些C应用的源码组织形式种类万千，从最简单的单个源文件，到复杂的诸如Apache httpd server这样庞大的Project。不过无论这些C应用的源码组织形态如何，构建都是这些应用开发过程中必不可少的一步。

伴随着C语言的普及，C语言应用的构建工具也逐渐发展起来，随着Project构建复杂性的增加，大致可分为四个阶段(个人观点)：
* 命令行构建
对于简单应用来说，其源文件数量一般较少，且可能都放在一个同目录下，构建这样的工程的最简单的方法就是直接在命令行上输入编译命令(诸如gcc -o foo foo.c bar.c)。这种方式在C诞生早期的简单应用或对于刚刚C入门朋友来说是最常见的。

* make工具
随着Project复杂程度的增加，使用命令行编译构建的难度日益加大，大家开始使用make工具。make工具的实质是帮助项目管理依赖关系。C应用构建的最终目标一般都是一个可执行文件，该文件一般是由所有源文件的目标文件以及依赖的第三方库链接后生成的，也就是说该文件依赖项目源文件的目标文件以及第三方库。我们可以将这种依赖关系用make工具指定的专用语法描述出来，形成Makefile文件。后续我们如果要构建该Project，只需敲入make即可。make工具会自动分析Makefile中的依赖关系，并执行依赖关系对应的命令，并最终完成构建。

* autotools
虽然make工具很好地解决了复杂Project的构建问题，但make本身的学习曲线也是很陡峭的，也就是说要为一个复杂的C应用编写Makefile脚本并非易事，特别是复杂Project中那更为复杂的依赖关系，可以让任一一个程序员望而却步。大家都看到了这一点，因此就有了autotools工具集的诞生。autotools工具集由autoconf、autoheader、automake和libtool等工具组成，其主要目标就是简化项目Makefile的编写。使用autotools，我们可以为C应用的Project自动生成Makefile，这显然是一个很大的进步，对于复杂的Project尤甚。

* 新兴的通用构建工具
虽然autotools的出现解决了一些C应用构建难的问题，但autotools自身使用起来也是略显复杂的。特别是它由若干工具组成，并需要这些工具一起配合才能完成一个Project的Makefile的编写和生成，学习这些工具本身也要耗费很多时间。随着一些脚本语言的流行，一些新兴的通用构建工具逐渐出现在大家的视线中，诸如Scons、rake等。这些新工具吸取了make等门槛较高、不易用的教训，利用脚本语言特有的性质打造出了更加简单易用的构建脚本，现在很多C应用都开始使用这些工具简化构建脚本编写了。

究竟是使用哪种构建工具，这还是取决于项目所处的"环境"，包括项目的复杂性，人员的平均技能水准等等。但有了构建工具还不足矣，我们再来看看关于C语言应用构建还有哪些应该关注的地方。

一、规范化项目源码组织
项目的源码组织是应该先于构建脚本实现的，因此良好的项目源码组织也有助于构建脚本的编写，同时也有利于组织内部的标准化和复用。但C应用的源码组织的确没有统一的标准，也没有最好可言，也许只有适不适合。下面就是我们所使用的一个典型的C应用(非公共库)源码组织示例：

Foo_proj/
    - Makefile
    - sub_proj1/
        - Make.rules(由buildc生成)
        - Makefile
        - include/
        - module1/
            - xx.c
            - Makefile
            - tests/
                - xx_test.c
                - Makefile
        - module2/
            ... ...
    - sub_proj2
        - Make.rules(由buildc生成)
        - Makefile
        - include/
        - module1/
            - xx.c
            - Makefile
            - tests/
                - xx_test.c
                - Makefile
 ... ...

针对这个示例有几个注意事项要说明一下：
a)
以前在很多Project中，都会包含一个顶层的(toplevel)Make.rules，这样的设计考虑无非是希望项目下的其他sub_proj可以复用该Make.rules，这看起来似乎方便了。但实际这样做是在各个子项目间建立了一层构建耦合关系：很多子项目都有个性化的构建需求，这样一来可能会频繁对该顶层Make.rules进行修改；或是当无法修改顶层Make.rules时子项目还是会在自己下面增加一个子Make.rules以满足构建的个性化需求。我们莫不如去掉顶层Make.rules，而在各个子项目中添加自己的Make.rules。特别是在有了buildc工具以后，每个子项目下的Make.rules都是自动生成的，这样不但不会增加太多的额外工作量，还从根本上去除了子项目间的一种耦合，完全可满足sub_proj的个性化的构建需求。

b) 顶层的Makefile依旧保留，一般作为一键构建整个项目时之用。顶层的Makefile实际来看就是将各个sub_proj串接起来，再说白些，就是遍历的调用各个sub_proj下的Makefile。

c) 针对每个module的单元测试代码与被测试的module代码存放在一起(比如放在module下面的tests目录下)，这样使得被测对象与测试代码物理上接近，易于源码的测试，同时逻辑上看也很紧凑。

二、构建执行的简单和高效
构建是一个频繁的日常开发活动，简单和高效是IT开发者对"构建"活动的两个基本要求。所谓"简单"就是尽量不让或少让我动手，懒惰的程序员们最多只是希望敲入一个命令就可以完成项目的所有构建，这就是我们所说的"一键化"。一键化从另一个角度来说也是一种"高效"，但"高效"更重要的含义则是指尽量缩短构建的时间。要想做到这点，一是需要一个清晰明了的构建脚本实现，把项目内部的各种依赖关系打理清楚，只作必要依赖，减少不必要的重复构建；第二则是选择一款高性能的构建工具，目前来看make本身的性能还是很棒的，一般来说还是强于scons这样以动态脚本语言实现的工具的，特别是再加上并行编译和分布式编译后，构建时间将大大缩短。

三、第三方依赖包的管理
在开源软件大行其道的今天，很多商业项目都或多或少的用到一些开源包，即使没有用到开源包，组织内部也可能存在项目间相互依赖的情况，比如：业务部门的应用很可能依赖基础研发部门提供的通用库，这样就出现了一个第三方依赖的管理的问题，这也是我们在进行构建设计过程中所不可忽视的一个重要方面。

关于第三方依赖包的管理，至少我是见识过如下几种方式：

* 将第三方依赖包的源码导入到你的项目，伴随项目一并构建
这样做的好处之一就是完整：大家在构建项目时无需东找西寻，依赖的代码就在项目库中。好处之二是便于一键构建，依赖包的源码就在项目中，可以任你"宰割"；第三则是便于在不同平台上移植，因为直接存储了源码，在每个平台都是依据所在的平台构建对应的版本。

不足之处：这样做会导致项目代码库庞大，构建时间漫长；另外也不便于第三方依赖包的更新升级。一旦第三方依赖包有bugfix或新feature，你可能需要手动的同步代码。一旦依赖的第三方包有很多的话，这可是一笔不小的工作量；最后每个项目都单独存储一份第三方依赖包会导致大量重复，重复可并不是一个好味道。

* 将第三方依赖包构建后的二进制文件放入项目代码库
这样做的好处在于提高了构建效率，节省了第三方依赖库自身的构建时间。但这样做的不足之处依然很多，直接存储源码方式的大多数不足都被该方式继承了下来，除此之外，这种方式还会导致在不同平台上构建难度的增加(不同平台上的包的二进制文件是不同的)。

* 对第三方依赖包进行集中单独管理
将各个项目所使用的第三方依赖库做统一集中管理，而不是放在每个项目中，并且只存储构建后的二进制文件而非源码。组织形式示例见下面：

3rds/
      - libevent/
           - 2.0.10/
              - README
              - source_code_package
              - sparc_32_solaris/
    - include/
    - lib/
              - sparc_64_solaris/
              - x86_64_solaris/
              - x86_64_linux/
           ... ...
      - netsnmp/
      ... ...

这种"分门别类"的第三方依赖包集中管理方式既有利于加速构建过程(直接用二进制，省下源码编译)，同时也便于依赖包的统一升级和管理(专人负责，通过版本号区分)。这种第三方依赖包的管理方式也是使用buildc构建辅助工具的前提。这种方式也是有缺点的，那就是需要有专人负责对该公共库进行管理，包括新版二进制包的制作与上传。

至于在具体项目中究竟采用哪种方式还需要根据project的具体情况作出权衡，如果你依赖的第三方包较小且很少，那方式一很适合，redis就是这么做的；如果你不要支持多平台，那么第二种方式也可行；对于组织而言，似乎第三种方式是规范、统一和一致的，这也是我推荐的方式。

四、适于与第三方工具集成
持续集成是公认的优秀实践，市面上有很多优秀的ci工具。持续集成的第一步就是构建，因此一个好的工程构建是应该能与ci工具很好结合在一起的，也就是说要充分考虑构建脚本与ci工具的结合。

一般来说持续集成工具判断成败与否的根据就是你委托ci工具执行的脚本的返回值。对于C应用构建过程来说，一般是make的返回值。0即成功，其他均为失败。对于单元测试用例的执行过程而言，也同样是此道理。C的单元测试集实际上就是一个个可执行程序，每个程序的返回值都是需要认真考量的，不能随意。如果你使用类似lcut这样的框架工具，你就完全可以通过框架工具来帮你完成用例执行返回值的设定。

良好的项目构建设计是项目迈向成功的重要一步。在日常开发工作中我们不仅仅要关注软件开发过程中的"前段"，比如需求、设计和编码；对"后段"的一些活动，诸如构建、测试和部署也要给予足够的关注。以上所讲仅是经验之谈，谈不上绝对正确，因为关于C应用构建的资料相对较少，也没有统一的标准，这里权当抛砖引玉了。

每至年关，回首一年工作中的成长，便有一种充实和幸福的感觉。

2011年我在工作中的成长可概括为如下几点：

1、建立并围绕原则为中心开展工作
现在想来，以前的工作有些盲从，心中没有原则，自然也就没有主线，也许这与当初的职位角色有关。2011年职位提升了，思维方式也有所了转变。我花了更多的时间对当前的工作进行考量，而且考量的过程不是过去那种仅仅从项目组或产品线的角度，而是尽量上升到组织的角度，并针对当前工作建立起一系列原则，这些原则成为了我在工作中决策的基本出发点。以这些原则为基础，安排自己与他人的工作就有了着力点，一切显得十分自然合理。

2、学会着眼大局
逐渐学会和适应了从组织层面去思考问题，以追求组织的"可持续发展"为原则；做长远考虑，不局限于眼前得失，懂得奉献；积极尝试打破部门间壁垒，积极主动地投入到工作中去，先予后得，充分发挥兄弟部门的力量，促成任务的完成。

3、更加注重行动
以前的我由于忙于一线事务，很多改进都停留在了想法提出的层面上。但今年在积极地对产品线的组织结构进行调整后，我个人有了更多的时间思考改进，更多的精力投入到改进的实施上去，并且取得了良好的效果。知识库建立 、利用虚拟化改善开发效率、提议的制度化 、效率提升思路的转变 等都是在此前提下得到大步推进的。

个人感觉这三点已经逐渐固化到我行事的思维方式中去了，这让我真真切切地体会到了自己这一年来的成长。

这周五我做了一件"恶事" - 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的，但却真实地让我给碰到了。

我以前只是有招人的经验，但从未做过"开人"的事情，这是第一次，心里总有些不忍。原计划由这名同事的直接Leader与他谈这件事情，但这名女leader更是抹不开面子，索性我就直接上阵了。过程还算顺利，这名同事表面上也没有太多意见，但我心里清楚：他肯定很郁闷，这个周末估计会很失落。我们也不想这样的事情发生，但之所以做出这个决定也是因为这名同事"所作所为"实在是太不给力了。

这名同事进入我们产品线大约有一年半时间，他并非是我们招入的，而是由领导从其他项目组安排过来的(恰逢那时我们缺人)。最初安排他做开发侧的技术支持角色，负责产品的升级支持以及生产环境问题的解决，算是隶属开发运维团队。但一段时间后他似乎没有得到运维团队内部的信任，给他派的活儿都是很边缘的，生产环境遇到大的问题基本都绕过他而直接找到原开发人员解决，形成这一局面的原因无非有二：一是他无法独立地及时解决生产环境中的问题；二是在自己无法解决的情况下，也没能很好地协调他人将问题解决。长此以往大家索性就不找他了。团队内部不能养闲人，我们还是给了他机会 - 尝试让他做些开发团队的工作，把他直接安排到上面提到的那位女Leader的项目组里面。经过了大半年，他给出的成绩单却是：失去了所有团队对他的信任，大家把他彻底孤立了起来。团队并非一开始就失去对他的信任，而是不断给他机会，给他的工作都是相对比较简单的，时间上也相对宽松。但即使这样，他也是不断延误进度，提交上来的东西也是频频出错，耽误了自己不说，还耽误了其他团队的整体进度，大家逐渐开始对他都不耐烦了，我这里也不断收到大家对他的抱怨，局面就是这样形成的。年中面谈时，还曾明确给他指出了不足，并就改进绩效计划达成一致，但他依旧没有达到我们的预期。木桶理论告诉我们：在一个团队里，决定这个团队战斗力强弱的不是那个能力最强、表现最好的人，而恰恰是那个能力最弱、表现最差的落后者。于是我们从全局考虑，从团队的整体考虑，我们做出了上面那个无奈的决定。

我做了一下换位思考，如果我是这名同事，到底是什么原因让我走到了这步田地呢？下面我就来帮他分析分析。

首先，我想这位同事没有走好融入团队的第一步棋 - 赢取团队的初始信任
对于一个刚刚进入团队的新人（无论是有工作经验的还是刚毕业的新人），赢取团队的初始信任都是最最重要的。下好这第一步棋其实并不难，把你的直接上司分配给你的第一个任务做好即可。当然如果要赢得超出预期的信任，那就得做的完美一些。在这个阶段，你最好能专心投入，甚至“牺牲”一些个人时间（对于程序员来说，这很容易理解^_^），快速地熟悉新环境、行业领域业务知识、产品以及团队风格。一旦你的第一个任务达到或超过了大家的预期，团队对你的信任也就建立了起来，后面的事情就变得自然而然了；而一旦你搞砸了第一个任务，那就相当于从团队成员那本来就积蓄不多的情感账户中取款，那后续走势如何就要看这个团队的耐心了，他们到底会给你多少次犯错的机会呢！

其次，能力不足且没有努力做出改进
赢得信任需要有资本，这最起码资本就是个人从事这个行业工作的能力。绝大多数行业中处于能力平均水平的人维持一份稳定的工作都不难。但问题就在于如果这个人没能认识到自己能力的不足，或是即使认识到能力不足，但也不努力改进，那这个人就危险了。我的这位同事身上显然就发生了这个问题，这一年多以来他的能力或技能只能说是原地踏步，在IT这个行业里，大家都知道这意味着什么。

最后，态度！
俗话说："世上无难事，只怕有心人"。这句话从侧面反映的是一种做事的态度，而我的这位同事被诟病最多的就是做事的态度上。我从多方面反馈了解到，他似乎就没有把分配给他的任务当成自己的事来做，总是囫囵吞枣，不断犯错，不断被指出，之后依旧不断重复犯错，似乎一点改进的意识都没有。如果把工作视为可敷衍了事的事情，那后果可想而知。

也许还有一种更为深层次的原因，我也不敢肯定，那就是他也许根本对程序员这个行当不感兴趣。缺少动力，行将就木，做一天和尚撞一天钟，因此有了糟糕的表现。如果真是这样的话，那就是严重地对自己不负责任了！说得严重些叫浪费生命，也许他换个行当就能出类拔萃呢。

在组织层面如何为避免此类事情发生呢？也许只能严把入口。但说起来容易做起来难，仅仅通过几次面试，很难全面地去认识一个人。刘未鹏不是写过一篇文章叫"怎样花两年时间去面试一个人"吗，显然也印证了这一点。

最后还是要对这位同事说一声：你还年轻，这仅仅是一时的挫折，绝不应该就此消沉，反思一下，找到一条更适合自己的路，好好的走下去。

近期完成了与组员的年终绩效面谈，收集上来一些意见和建议，其中有一些涉及到部门对大家反馈的意见和建议处理不妥的情况，对此我也做了认真的考量，于是就有了这篇短文。

组织的基本单元是人(即组员)，组织的运行依靠的也是组员，组员对组织的运行情况最有发言权，组织内部存在的问题他们会第一时间感知到，也许他们也是第一个尝试解决问题并作出改进的人，因此他们的意见和建议是最最宝贵的，作为一个组织的领导者首先应该认识到这一点，下面的内容也完全是基于这一前提的。

基于"组员的意见和建议是最最宝贵的"这一共同认知和前提，我们下面就应该去考虑如何让组员更主动积极的提出有价值的意见和建议、如何充分利用这些意见和建议进行组织的持续改善了。致力于成为一个气氛活跃，畅所欲言，行动迅速，不断追求自我改善的组织，首先就是要在组织内部建立起一个意见和建议良性的反馈机制。在杰克.韦尔奇的《赢》一书中，韦尔奇谈到了通用电气所实施的“群策群力”计划其实也是这样的一种机制。

大多数组织不会有通用电气这么大的规模，但小组织也应该有小组织的做法和特点，有些做法可以被借鉴，这里就我所在组织内部的做法以及所遇到的问题谈一下我的看法：

1、建立制度化的意见和建议的"Pull机制"
这是一种意见和建议收集的"官方渠道"，就好比古代的皇帝早朝或是如今的人民代表大会制度。"官方"会定期收集下面的意见和建议，并给予处理。这是组织领导层的一种主动希望听取大家意见和建议的意愿的体现，所以这里也称为"Pull机制“。这种采纳意见和建议的频度是因组织而异的，可以是半年一次，也可以是每季度一次，甚至可以做到月度。这种机制可以保证组员有的放矢，至少算是有机会、有地方可以发表自己的意见和建议了。

2、建立明确的日常建议和意见反馈渠道
"新鲜"的意见和建议最具有说服力，同时也可以加快问题的解决速度，随时发生，随时解决。这种渠道实际上才是一个组织内部最需要重视的，也是发挥作用最大的一种意见和建议反馈机制。组织内部应该与所有成员明确反馈渠道的运作方式，比如通过专用邮件列表、设置意见和建议收集和处理专门负责人、频度更高的制度化的项目反思会、头脑风暴会等。

3、意见和建议的及时处理与应答
我们的反馈机制务必要做成"闭环"的，大家最最重要的意见和建议一旦提交后，千万不能被石沉大海。组织内部应该由专人负责整理意见和建议，并给予提交者以应答，最好的做法是让组织内所有成员都得到关于某意见或建议的应答，无论该提议能否被及时解决掉，都要给予应答，那些不能被及时解决掉的提议，也要给出改善计划说明；如果组织认为某提议无需处理，也要给出充分的理由，避免打击提议者的积极性。以上这些做法可以充分展示一种对提议者的尊重，对所提意见或建议的重视；对于提议者来说，这无疑是一个正面的反馈。

在这方面应避免以下两个问题：
1) 避免"谁提议，谁负责解决"的提议应对思维和做法
很多组织的领导层形成了"谁提议，谁负责解决"的思维惯性，他们简单地认为“这事是你提出来的，你就负责解决吧”。一旦形成这种思维，其结果很可能是提议者无力解决，受到打击，后续不愿主动提议了；或者让其他成员认识到领导的这种习惯做法后也不愿主动提议了。这样长久下去会严重压抑一些想法的提出。对于提议，组织层面应该细致分析，合理计划，拿出确实可行的方案，安排适当的人（也可以是提议者，但事先需合理沟通，作为正式任务授权，并给予时间和资源上的支持）去做。

2) 避免“没下文”的情况发生
很多提议被组织层面认可，但在具体改进时在资源和时间上给予的支持太有限，导致很多无法提议的改进最终无法达成，这样会形成负面心理反馈，打击组员提议的主动性。

4、定期反馈提议的改善成果
为了形成正面的反馈效应，可在组织内部定期公布提议的改善成果，并在每项改善结果中署提议者的名字，这会给提议者以及其他组员带来巨大的心理激励，会促使组员更多更主动的提出自己的宝贵意见和建议； 有条件的组织还可以给予改善成功的提议者以适当的物质奖励。

还有其他一些措施有助于良性反馈机制的建立，比如招聘思维活跃、有思想的组员（对人的认知往往很难）、培养意见先锋（示范带头）等等。以上措施实际上对组织的长远发展是及其有利的，组织可以充分的发挥出组织内成员的价值。正如通用电气公司家用电器事业部的一位员工所说：“25年来，你们为我的双手劳动支付工资。而实际上，你们本来还可以拥有我的大脑，而且不需要支付任何工资。”。

组织内部建立良性提议反馈机制更是"以人为本"的一个良好体现，它强调了对组织内员工的充分尊重。别忘了：你对待员工的态度和做法就是你的员工对待客户的态度和做法。

2011年我的确读了不少书，掐指算来纸版和电子版加在一起近50本，其中以技术类居多，但其他方面的也有一些。这里列出来做个简单回顾。

一、技术类
· 《你必须知道的495个C语言问题 》
早在这本书出版前，其译者已经在网上完成了C FAQs的翻译(在这里 )。这本书是基于最新C FAQs做了重新整理(包含C99 )。虽说是最新，但因C语言近几年来变化很小，内容与之前译者在网上公开的那个免费版本相差不多。这本书适应面很广，初学者可以从中了解到很多谭氏教程中没有的东西；有经验的C程序员可以把它当成一本手册，需要时翻看。对于那些很在乎C语言细节的程序员来说，翻看一遍也未尝不可。

· 《The New C Standard - An Economic and Cultural Commentary 》
这本书的作者真是牛X的一塌糊涂。整本书居然是对C99规范的逐句解释，而且写成了一部1600多页的大砖头。这本书应该未正式出版，我看的是作者在网上放出的免费电子版 。如果你痴迷于C语言规范的细节，这本书是一本不可多得的辅助资料。

· 《C和C++安全编码 》
Cert C/C++安全编码经验的浓缩版，读一遍的确可以提高一些编码过程中的安全意识。

· 《Practical Common Lisp 》
Peter Seibel编写的一本荣获Jolt大奖的Common Lisp 入门书。你在这里可以看到这本书的免费电子版 ，其中文版名为《实用Common Lisp编程 》，现在在我的书架上也躺着一本，我还没抽出时间来看。如果你是Common Lisp初学者，这本书是不二的首选。

· 《ANSI Common Lisp 》
Lisp语言的著名吹鼓手Paul Graham的大作，成书于Common Lisp标准化之际，是一本不错的Common Lisp入门的辅助资料。个人认为将《Practical Common Lisp》与此书结合在一起来学习，会加深你对Common Lisp的理解。

· 《Haskell - The Craft of Funcitonal Programming 2nd 》
这是一本比《Programming in Haskell 》更适合作为函数式编程语言入门的书。书中第一章对函数式编程基本概念的讲解很是到位，并且这本书已经被译成了中文，书名为《Haskell函数程序设计艺术》，在网上可以免费下载到。

· 《Seven Languages in Seven Weeks 》
估计大家都见过《21天学会X语言》这样的编程语言教程。21天学会某种编程语言已经有些差强人意了，但这本书更狠 - 书名的直译是"七周学会七门语言"，但显然本书的目标不是这样的。作者的原意是希望读者通过阅读本书了解更多的新兴编程语言以及编程范式，改变编程思维，另外通过本书的阅读可以初步掌握各种语言，并且对语言的掌握程度不仅仅是"Hello World"这一层次。今年年初与其他人合译了此书，也是在那时将这本书通读了一遍。我负责翻译Prolog、Scala和Haskell三个章节。在书中作者将每一门语言比作成一个电影中的人物，使得内容更加生动形象(但翻译起来就没那么容易了^_^)。特别值得一提的是：该书还荣获了今年的Jolt大奖，由此可见业界对该书的认可。

· 《Python参考手册(第四版) 》
像Python这样的动态编程语言，一直以极高的开发效率著称，这也是我今年学习和使用Python的一个原因，Python强大的标准库可以帮我快速实现一些想法(buildc 就是用Python编写的)。《Python参考手册》这本书并不适合作语言入门之用，里面对语言细节的讲解很少，其内容更多适用于工程参考，包括库函数使用、打包、发布等，这正是当时我所需要的。

· 《持续集成 》和《持续交付 》
持续集成已经是存在已久的一个最佳实践了。《持续集成》一书对这方面内容做了极其系统的讲解；持续交付将持续集成的概念做了进一步延伸，将软件开发的前段（设计、编码、单元测试）与后段（功能测试、压力测试、发布、部署、验收测试）衔接在一起，形成了一个整体，并通过自动化手段实现了这一概念。在我看来《持续交付》一书更像是一本cookbook，作者将自己实施持续交付过程中采用的方案以及遇到的问题都详实地记录在书中，分享给大家。这本书获得了今年的Jolt技术图书类最高奖，很是值得一读。

· 《深入理解计算机系统 2nd 》
本书的第一版是在大学毕业后不久读的，当时真有一种相见恨晚的感觉，读完后战斗力陡增。若干年后第二版的中文版终于出炉了，我又迫不及待地买下，并通读了一遍。这本书究竟咋样，从我豆瓣上给的评语可以看出："如果只允许我为程序员们推荐一本书，那么我会毫不犹豫的将这本csapp推荐给大家。太经典了！"

· 《Binary Hacks 》和《Debug Hacks 》
讨厌日本人，但有些时候你的确还得向日本人学习，这两本书都是由日本程序员执笔的，而且内容都是有关系统编程以及OS内核编程和调试的，内容比较深，需要你静下心来细心体会，国内程序员往往比较浮躁，愿意做底层技术的很少，坚持下来的就更少了，这方面日本程序员却是我们的典范。有关系统级编程和调试经验和技巧的资料在市面上比较少了，这也凸显了这两本书的价值。

· 《A Bug Hunter's Diary 》
这本书只是粗略的浏览了一些，书里的案例实在看不下去，总觉的Debug这事儿只有自己亲手去做才能有所得，就像看《盗墓笔记》一样，看完后你依旧不会倒斗，只有亲自倒一次斗才能学到真本事。

· 《Linux系统编程 》
知名Linux内核维护者Robert Love的作品，结合底层原理的机制讲解是本书一大特色，但总体比较平淡，有些地方更像是函数使用手册，建议有经验的程序员快速浏览一遍即可。

· 《Linux系统管理技术手册 》
简直就是一本Linux系统管理的大百科全书，内容涵盖各种主流Linux发行版，如RHEL、Debian、OpenSuse、Ubuntu 等，极其适合放在抽屉里随时翻阅，我就是这么做的。

· 《Pragmatic Guide to Git》和《Pro Git》
前者适合Git入门，后者适合Git进阶。一个版本控制工具，没有什么好说的。对于Git学习的建议是：要领悟Git背后的思想，另外不要将Git命令的含义与svn等传统版本控制工具的命令混淆，Git命令需全新认知。

· 《软件研发之道 》
典型的"新瓶装老酒"，该书早在N年前就出过一中译版，名为《微软团队 - 成功秘诀 》。如果你看过后者，你大可不必购买此书。不过如果你没看过这本书，那么还是建议看看，虽说书中讲的是微软当年Visual C++团队的事情，但读后你会发现其中的思想至今仍极具价值。

· 《编程之道 》
这是一本奇书，一本悬在空中的书，全书通读完后，你可能依然不知作者所云，但你的内心却已被作者的思想洗礼。

· 《编程匠艺 》
如果你认为《代码大全2nd》是好书，那么你也会喜欢这本书，它们是一类的。

· 《大话设计模式 》
这类书的目标都是意图将晦涩难懂的《Design Pattern 》一书通俗化。但一般看这类书的时候，身旁还要放上一本《Design Pattern》，随时翻阅查证。今年在考量用C实现Pattern 时顺便读完了这本书，总体来说算是国内讲解DP比较优秀的一本了。

· 《企业应用架构模式 》
Martin Fowler在2003年的作品，也是当年Jolt效率大奖获得者。当时也是企业应用架构蓬勃发展的时期 - J2EE大行其道，轻量级框架方兴未艾。作者将当时进行企业应用架构设计一些经验模式进行了详尽的总结并写成此书。在企业应用设计方面，我了解甚少，这也是今年阅读此书的一个主要原因。

· 《走出软件作坊 》
为数不多的国内IT企业技术管理者的经验之谈，很多人在书中会找到自己的影子。

· 《黑客与画家 》
Paul Graham的又一部大作，与之前的那本不同，这本更像是Paul的散文集，看完后是否能受益，全看你的悟性了。

· 《构建高性能Web站点 》
我不是搞Web开发的，但此书前三章对Web站点性能影响因素的分析还是让我受益匪浅的。

· 《程序设计语言原理 》
从China-pub淘来的一本特价书，但读了之后我感觉即使是原价买来也是很划算的。

· 《程序开发心理学 》
温伯格的经典之作。由于原著成书较早，经过几十年很多思想其实早已经通过其他渠道灌输到我们的大脑中了，但越是这样我们越是惊叹于温大牛惊人的预见力。要知道这本书最早成书于1971年。

· 《算法技术手册 》
今年读的唯一算法类书籍，这本书不像《算法导论 》那样钻理论牛角尖，也不像《程序员实用算法 》那样着重于算法的实现，它旨在赋予你精确选择算法的能力，以帮助你精确高效地解决面临的问题。

二、社科类
· 《赢 》
杰克.韦尔奇退休后的总结之作。记得上次陪LP参加桩考，我用了大半天时间在我的Bambook 上把这本书浏览了一遍。不过在我这个层次上尚无法理解杰克全部之言。这本书对于不同层次的人会有不同的价值。它就是那种需要你在不同时期反复多次阅读的一本书。也许若干年后再读此书，我会有更深刻的认识。

· 《浪潮之巅 》
今年我读到的最震撼之作。之前吴军在Google黑板报上连载时我并未太过在意，这次系统地通读一遍后，让我眼界大开，从书中学到了许多，同时也激发我想到了许多。

· 《搞定: 无压工作的艺术 》(Getting Things Done的中译版)和《时间管理：小强升职记 》
前者是GTD时间管理理论的源头，后者则是国内GTD牛人的经验之作。时间管理是今年我的一个重点改进目标，这两本书给了我很大帮助。

· 《哪来的天才 》
这本书向我们阐述了一个观点：刻意练习是天才的一个必要条件。如果你不认同，那么打开这本书，慢慢看吧。

· 《把时间当作朋友 》
原新东方英语教师李笑来的作品，很难想象他这样的职业能写出这种题材的书。

· 《重来 》
来自一个创业公司创业者们的颠覆性观点。

· 《少有人走的路 》
感觉没有外界宣传的那么好，也许我还没有悟到。

· 《卓有成效的管理者 》
管理学大师的作品总是值得一读的，虽然你很可能已经从其他场合学到过其中的思想。

三、传记类
· 《活着就为改变世界 》和《史蒂夫·乔布斯传 》
看《活着就为改变世界》时，乔布斯还活着；后来乔布斯去逝了，我拿到了《史蒂夫·乔布斯传》。感谢京东的促销活动，让我以超低的价格买到乔帮主留给世人的这最后的礼物。两本书都告诉我一个事实：乔布斯的确与众不同，但讨厌他、憎恨他的人也大有人在。

· 《世界因你不同 》
以前看过李开复的《做最好的自己 》，对李开复有些了解，所以读这本传记时也就走马观花了。

· 《留德十年 》和《牛棚杂忆 》
一直很想知道季羡林为何被称为国学大师，通过回忆录是了解这个大师的一个很好的途径。

四、小说类

· 《盗墓笔记系列 》
这类题材的书籍总是吸引人的眼球，就如作者所说的“盗墓代表着人类一种最原始的欲望，求得财富和探询死亡，这种刺激，恐怕是人就无法避免的"。不能去倒斗，看看别人如何倒斗也能满足一些欲望^_^。

· 《三体 》
慕名而读，名不虚传。作者超凡的想象力让人不能不折服，至少第一部是如此。

· 《高地 》
今年看的唯一一部军旅题材小说，在部门旅游来回的途中把这部小说看完，情节跌宕，情感细腻，值得一看。

五、其他类
· 《准备去美国读书 》
为了了解美国教育是什么样子的，从图书馆借阅的，如果你和我有同样的目的，这本书还是可以满足需求的。

· 《实用IT英语 》
简直就是为IT人士量身定做的外语书，着重培养"英语思维"的形成，感觉书的内容也比较新颖。

很多朋友可能会问：工作这么忙，家庭生活琐事那么多，哪里还有什么时间读书呢？我又何尝不忙呢，每天8小时工作，周末还要陪果果。这里的关键还是要有坚定的读书信念，养成良好读书习惯，就好比一日三餐那样，非读不可。另外还要不断提高读书效率，充分利用零散的时间。现在市面上电纸书(比如kindle、bambook)越来越成熟，便携性也越来越好，你可以把坐车、等车以及闲暇休息这些零散时间充分利用起来，一年下来你挤出来的时间也是惊人的。

2011年眼看就要接近尾声了，这里也对自己在2011年的"所作所为"做个小结^_^。

这一年来工作之外的我过得还是比较充实的，从下面的数字也可以看出：
- 写了81篇博文
- 开源了2个工具(CBehave 和buildc )
- 合译了一本书（"Seven Languages in Seven Weeks "，不过尚未出版）
- 读了近50本书（通过豆瓣读书 统计）
- 新学了一门语言 - Common Lisp
- 新用了一门语言 - Python

学无止境。我内心中追求的是"持续成长"，让自己感觉每一天都有进步，哪怕仅是一点点，所以上面这些事情对我来说绝对是快乐的，有成就感的。

在工作方面，2011是"蓄势"和"布局"的一年。无论是在产品开发还是团队组织调整方面，我都按照我的思路进行了重新布局。这样一方面可以提携一些骨干，让他们可以在更重要的岗位上发挥出更大的能量；另一方面也可以大大减轻我个人身上的一些事务性工作，让自己可以轻装上阵，静下心来思考一些事情，踏实地去做一些对部门长远发展有价值的事情，比如在线代码同级评审 、知识库 的建设、开发构建管理辅助工具、使用虚拟化技术改善开发测试效率、生产环境软件升级的自动化操作等。这些工作也反过来让我变得更加主动，更敢于去打破常规。

年初在个人工作计划中设定了多个目标，现在看来大部分已经做到。但感觉在"给予下属同事更多关于高效工作方法和提高解决问题能力上的指导“方面做的还很不足。另外感觉自己在"包容他人"这块的进步似乎依旧不大，甚至感觉自己的脾气愈发见长，眼睛里基本容不下沙子，看来性格秉性这东西要改起来还真难。

我一直告诫自己：代码还得写，千万不能让自己手冷。这方面上半年做的还不错，下半年写的有些少，这几天感觉手有些痒痒了，特想写上个三天三夜。

2011的家庭生活总体来说是"平淡中蕴含着幸福"，特别是每次下班进门时果果 迎上来抱住我的大腿的时候，幸福的感觉尤甚。

既然是小结，那就写这么多了，都是捞干的了。至于来年的计划、目标以及愿望就留到来年再说道吧。

这几年我一直从事C语言 项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make 工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。

这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种内部公共库、第三方开源库悉数找到，并安装在指定目录下，修改Makefile中这些第三方库的路径配置。只有做完这些后，你才能顺利地执行Make。以后每当你更换一个环境，你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多，要完整地搭建一个项目构建环境所耗费的时间也是很惊人的，特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力，你的构建脚本还要支持在多个平台上的构建，你要为项目所依赖的第三方库准备多个平台的版本；当某个依赖库版本进行了升级，你还要手工在多个环境下进行更新。

为了使项目构建更加容易，我们曾经对Makefile脚本进行了改进，比如自动判断和设定当前顶层路径、自动判定当前项目代码所在的平台，并根据不同平台设定不同的变量值；甚至将项目依赖的第三方库放入subversion 服务器，构建项目时通过Shell脚本自动checkout对应平台的依赖库并链接。这些改进都是有效的，但在修改了多个项目后，我们发现了坏味道，那就是在不同项目的Makefile中充斥着大量重复性的脚本代码，这让后续构建脚本的维护十分困难，在一个项目中修正了构建脚本的bug后，很容易遗忘另外几个项目中存在着同样bug。此外每次构建都重新下载项目依赖的第三方库会导致构建变的十分缓慢。

我们在构建中遇到的问题大致就是这么多了。估计很多人会问：你们为何不用autotools 生成的configure来生成项目构建脚本？为何不用scons 等更加高级的构建工具呢？我的回答是即使使用了这些工具依旧无法解决现有的所有问题。比如利用configure->make可以屏蔽掉一些平台移植的问题，但依旧无法解决第三方库依赖的问题。scons我也试用过，但了解不甚深入，我的印象中它的主要功用是简化构建脚本的编写，让大家从Makefile那纷繁复杂的源文件依赖关系中解脱出来，至于在区别平台以及解决第三方库依赖方面估计也无能为力；另外还有一个原因那就是让大家从已经十分熟悉的构建模式中转到scons的成本也是不小的。

我们的问题其实并非构建脚本的编写问题，而是构建环境的管理问题。autotools和scons所解决的问题属于前者，即构建脚本的编写问题。而解决C语言项目构建环境管理的工具我了解的不多，在互联网上也没有google到。在这方面Java项目倒是有一个很好的工具 - Maven 。利用Maven可以做很多事情，我对其了解不多，这里也不多说，但这里提到Maven是因为它的一个Feature启发了我，这个Feature就是对第三方依赖包的管理。虽说C项目依赖的第三方开源包也越来越多，但与Java项目相比那还是小屋见大屋。实际情况是一个Java项目如果不依赖十几个或几十个第三方开源包都不好意思拿出去说。这样一来如果手工找齐这数目庞大的开源包会让Java程序员头痛不已。Maven的这个Feature恰好帮助Java程序员解决了这个难题。Maven可以根据配置自动从互联网上下载指定版本的依赖包，后续Java项目的构建可直接使用已经下载到本地的包；Maven似乎还会定期自动更新第三方包的版本。

受到Maven这个特性的启发，我于是就开发了这款C语言项目构建管理辅助工具 - buildc (项目主页http://code.google.com/p/buildc)。buildc工具本身是用Python 语言实现的，这主要是考虑到Python较高的开发效率以及自带功能强大的标准库。这也是我第一次用Python写程序，个人认为buildc的代码十分混乱，内部实现耦合较高，扩展性差，也谈不上什么风格，都是命令式语言的思维，代码本身并没什么价值，以后有时间定会重构 ^_^。

buildc目前主要实现了两个功能：
1、第三方依赖库的远程获取和本地管理
2、根据目标主机环境、目标主机本地缓存的第三方库情况以及项目本身所依赖的第三方库的最新配置，自动生成一份包含了依赖库环境变量信息的Make.rules文件，或重新更新已有Make.rules文件(上一次由buildc生成的)。项目中的Makefile只需包含(include)Make.rules文件并使用该文件中的变量即可。

buildc的使用是有前提条件的，那就是第三方库必须按特定规划集中存储在一个版本控制服务器中，buildc目前仅支持Subversion。我不是很清楚Maven是如何从互联网上获取对应第三方开源包的jar包的，但我们很难直接获得C第三方库的二进制版本。这里面主要有两点原因：
1、C语言的第三方包多以源码包的形式提供；
2、Java号称"一次编写，到处运行"，也就是说Java第三方库仅需提供一份jar包即可运行在多个平台上；但C的二进制库不能，每种平台都会有对应的特定的版本，我们无法将一种二进制库应用到多个平台上。

因此我们首先需要构建组织内部的第三方库集中存储服务器，将各个产品需要的第三方库在各个平台上进行构建，并将得到的静态库或动态库放入版本服务器中。符合buildc要求的二进制库的组织形式如下。比如在svn://127.0.0.1:6666/3rds这个repository下面我们的第三方库按如下组织形式存放：

3rds/
      - libevent/
            - 2.0.10/
                - README
                - source_code_package
                - sparc_32_solaris/
                     - include/
                     - lib/
                - sparc_64_solaris/
                - x86_32_solaris/
                - x86_64_solaris/
                - x86_32_linux/
                - x86_64_linux/
      - netsnmp/
            - 5.2.0/
                ...
            - 5.7.0/
                ...
      ... ...

可以看到每个第三方库的组织形式都像下面这样：
package_name/
    - version/
        - CPU_MODE_OS
            - include
            - lib

一旦第三方库都按如此形式存储，buildc就可以获取到该服务器上的二进制库了。前提满足后，我们就来看看buildc在日常构建过程中的使用方法。

一、buildc的安装
buildc目前尚未做成python安装包，只是以源码形式提供的。所以现有情况下只需Checkout或下载buildc源码包到本地即可以使用。

buildc的源码目录结构如下：

buildc*        # 脚本入口
build_utils/   # 源码库
templates/     # Make.rules.in模板
samples/       # 配置样例

为了方便在任意路径下使用buildc，可将存放buildc源码的目录加入到PATH环境变量中去。另外你可能还需执行'chmod u+x buildc'来为buildc加上执行权限。

二、环境初始化
执行buildc init，buildc会在你的HOME目录下建立.buildc.rc文件。该文件用于配置所有可用的第三方库的信息。

$> buildc init
Copy /home/tonybai/proj/build_tools/samples/buildc.rc.sample to /home/tonybai/.buildc.rc OK!
Please config /home/tonybai/.buildc.rc before you use other buildc commands!
Copy /home/tonybai/proj/build_tools/samples/buildc.cfg.sample to ./buildc.cfg OK!
Please config buildc.cfg before you use other buildc commands!

# $HOME/.buildc.rc
foo_repository = ('svn://10.10.0.156:6666/foo',
                       '~/.buildc_libs/foo',
                       [
                        ('snmp', '5.7.0', 'lib/libnetsnmp.a'),
                        ('libexpat', '2.0.1', 'lib/libexpat.a'),
                        ('libiconv', '1.13.1', 'lib/libiconv.a'),
                        ('libevent', '2.0.10', 'lib/libevent.a'),
                        ('lcut', '0.2.0', 'lib/liblcut.a'),
                        ('instantclient', '10.2.0.5.0', 'lib/libnnz10.so')
                       ]
                      )

bar_repository = ('svn://10.10.0.156:6667/bar',
                         '~/.buildc_libs/bar',
                         []
                 )

external_repositories = [
                          foo_repository,
                          bar_repository
                        ]

其中foo_repository和bar_repository分别代表两个可用的集中存储第三方库的服务器，每个repository中的详细配置包括svn repository的url、这个repository的本地缓存路径以及构建所需的该repository中的第三方库信息。

buildc init还会提供一个buildc.cfg配置文件，该配置文件在后面再细说。

三、第三方库的本地缓存管理
有了正确的.build.rc配置，我们就可以初始化第三方库在本地的缓存了，执行buildc cache init。

$> buildc cache init

===>Begin init repository [svn://10.10.0.156:6666/foo]
Create dir: /home/tonybai/.buildc_libs/foo
library [snmp] does not exist!
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux]...
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux] OK!
library [libexpat] does not exist!
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux]...
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux] OK!
... ...

buildc cache init命令会根据.buildc.rc中的配置，从各个repository中下载对应该主机平台的第三方库，存放在对应的缓存路径下备用。

如果repository有更新，我们可以执行buildc cache update来更新本地缓存(在实际的日常开发过程中你可以将该命令加入到crontab中来定期自动更新本地缓存)：
$ buildc cache update

===>Begin update repository [svn://10.10.125.156:3560/3rds]
Update [snmp]...
Update [snmp] OK!
Update [libexpat]...
Update [libexpat] OK!
... ...

当不需要本地缓存时，我们可以通过buildc cache remove删除之：
$> buildc cache remove

===>Begin remove repository [svn://10.10.0.156:6666/foo]
Remove [/home/tonybai/.buildc_libs/foo] OK!
<=== End remove repository [svn://10.10.0.156:6666/foo]
... ...

四、生成项目Make.rules
第三方库的本地缓存建立好后，我们就可以来配置项目了。在前面执行完buildc init时，buildc生成了一个项目配置模板文件buildc.cfg(.buildc.rc和buildc.cfg本身也都是Python源文件)，我们将该文件移到项目的顶层目录下，然后对该文件进行配置，下面是一个例子：

#(proj_name, (major, minor, revision), author)
project = ('foo', (1, 3, 1), 'tonybai')

# [(libname, libversion, [archives*])*]
external_libs = [
 ("snmp"  , "5.7.0", ["libnetsnmpagent.a", "libnetsnmphelpers.a", "libnetsnmpmibs.a", "libnetsnmp.a"]),
 ("libexpat" , "2.0.1", ["libexpat.a"])
]

# [def*]
# e.g. ['-Dprint_msg=printf', '-D_SELF_DEBUG_']
custom_defs = [
                '-Dprint_msg=printf',
                '-Derr_msg=printf'
              ]

# [(var, value)*]
# e.g. [ ('WITHOUT_DB_IMPORT', 'TRUE'), ('SUPPORT_MYSQL', 'TRUE') ]
custom_vars = [
                ('WITHOUT_IMPORT', 'TRUE'),
                ('WITHOUT_NM', 'TRUE')
              ]

# [include_path*]
# e.g. ['./include', '/home/tonybai/.include']
custom_includes = [
                    './include'
                  ]

# [(lib_path, [archives])*]
# e.g. [('/home/tonybai/.lib', ['libfoo.a', 'libbar.so']), ('.libs', ['libzoo.a'])]
custom_libs = [
                ('.libs', ['libfoo.a']),
                ('', ['libzoo.so'])
              ]

这里简要说明一下这个配置文件的各个配置项：
* external_libs是项目所使用的第三方库列表，这些第三方库必须存在于该主机的本地缓存中，也就是.buildc.rc中拥有这些库的配置；
* custom_defs是项目需要额外传递给编译器的命令选项集合；
* custom_vars是你想额外在Make.rules定义的变量集合；
* custom_includes是额外需要单独指定的的头文件包含路径集合；
* custom_libs是项目所需额外的(不在本地第三方库中存储的)库路径，比如一些系统库。

完成buildc.cfg的配置，我们就可以通过buildc config-make来生成Make.rules文件：
$ buildc config-make
Can not found Make.rules in current directory!
Generate [/home/tonybai/proj/foo/Make.rules] ...
Config [/home/tonybai/proj/foo/Make.rules]...
Config [/home/tonybai/proj/foo/Make.rules] OK!
Generate [/home/tonybai/proj/foo/Make.rules] OK!

生成的Make.rules如下：
#
# Make.rules for foo
#
# tonybai
# 2011-12-08
#
# @Generated by buildc@
#

# Project information
TOPDIR = /home/tonybai/proj/foo#@topdir@

# Platform information
OS = linux#@os@
CPU = x86#@cpu@
CMODE = 64-bit#@cmode@

# Version information, (MAJOR.MINOR.REVISION)
MAJOR = 1#@major@
MINOR = 3#@minor@
REVISION = 1#@revision@
VERSION = $(MAJOR).$(MINOR).$(REVISION)

# Compiler options
DEFS = -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_DEBUG_ -DVERSION=\"${VERSION}\"
... ...
CUSTOM_DEFS = -Dprint_msg=printf -Derr_msg=printf #@custom_defs@
CC = gcc -m64#@cc@
CFLAGS = $(FDEBUG) $(FWALL) $(FPIC) $(FOPTIMIZE) $(DEFS) $(CUSTOM_DEFS) $(INCLUDES)

# Library infomation
snmp_ROOT = ~/.buildc_libs/foo/snmp/5.7.0/x86_64_linux#@lib_roots@
libexpat_ROOT = ~/.buildc_libs/foo/libexpat/2.0.1/x86_64_linux#@lib_roots_end@

LIB_INCLUDES = -I $(snmp_ROOT)/include -I $(libexpat_ROOT)/include #@lib_includes@
LIBS_DEPEND =  -L $(snmp_ROOT)/lib -lnetsnmpagent -lnetsnmphelpers -lnetsnmpmibs -lnetsnmp -L $(libexpat_ROOT)/lib -lexpat#@ libs_depend@
CUSTOM_LIBS = -L .libs -lfoo -lzoo#@custom_libs@

# Headers
DEFAULT_INCLUDES = #@default_includes@
CUSTOM_INCLUDES = -I ./include #@custom_includes@
INCLUDES = -I $(TOPDIR)/include $(LIB_INCLUDES) $(CUSTOM_INCLUDES) $(DEFAULT_INCLUDES)

# Libraries
DEFAULT_LIBS = #@default_libs@
LIBS = $(LIBS_DEPEND) $(CUSTOM_LIBS) $(DEFAULT_LIBS)

# Other definitions
WITHOUT_IMPORT = TRUE#@custom_vars@
WITHOUT_NM = TRUE#@custom_vars_end@
... ...

你可以对比着项目buildc.cfg的配置来查看Make.rules的构成。如果bulidc.cfg配置发生变化，那么再次执行buildc config-make会更新当前路径下的Make.rules。Make.rules的生成和更新使用了基于模板的标记替换技术。

五、利用Make.rules构建项目
可以看出Make.rules中将平台信息和第三方库的依赖信息都放置在对应的变量中了。项目的Makefile只需要包含Make.rules便可以利用这些信息进行项目的构建。可以利用的Make.rules中的主要变量包括：CFLAGS、LIBS。我们甚至可以为项目再编写一个"一键构建"脚本，该脚本中只需包含两行代码即可：

buildc config-make
make

你无需将Make.rules提交到源码版本库中，但需要将buildc.cfg作为项目的一部分。这样在任一一个通过buildc做项目构建管理的环境中，你的项目就都可以进行"一键式"构建了，再也无需为配置项目路径和寻找构建第三方依赖库而发愁了。另外通过buildc进行构建管理的项目将会很容易地集成到持续集成过程中。

buildc与make的组合模式很类似于maven和ant 的组合，但buildc目前的功能还无法与maven相比，不过buildc也不打算做成maven的模样。buildc后续可能会支持从更多种版本管理服务器(比如git )下载第三方库，支持按指定模板生成Make.rules(目前只有一种模板)等特性。从目前实践的情况来看，buildc 这个项目构建管理辅助工具十分适合我们内部的C项目构建，也许它也同样适合你的项目，有兴趣的朋友不妨试试。