随着工程代码量的增加，往往完整的编译一次Proj消耗的时间可能足够你喝两杯咖啡了，我现在build一次我所在proj的代码需要5分多钟，这是很痛苦的，颇让人懊恼的。为了解决这个工作中的别扭事儿，我在网上搜寻了一番，找到了distcc这个分布式编译工具。

先看看distcc能帮助我节省多少时间吧。我在公司的一台Sun SPARC Solaris9主机下对整个项目源代码按照以前的编译方式进行了一次build，这次build用了5分多钟；同样我使用distcc编译(安装了两个节点，都是Sun SPARC Solaris9主机)，居然只用了1分多钟，试想如何有更多的服务器作为distcc的守候进程主机节点的话，势必编译性能还会有提升。

有了"惊人"结果后，我们来看看distcc的原理，distcc本身是gcc的一个wrapper，也可用作本地编译，但是更多的是其分布式编译的强大功能，简单来说：就是将gcc的编译任务分布到各个其他主机上去，然后再传回来整合。它提高的是gcc -c阶段的速度，链接阶段的速度由于肯定要在本地实施，所以distcc无能为力。另外distcc推荐分布的不同主机上安装的编译器版本最好要一致，否则可能会有意想不到的错误。

distcc的安装和使用方法甚是简单，我安装的是distcc-2.13-sol9-sparc-local，直接在root下pkgadd即可。然后在各个distcc节点启动后台守候进程：distccd –daemon –allow x.x.x.x/16，以普通用户启动即可。

客户端使用方法：
1、在自己的用户下，添加环境变量(如果你用的是C shell)：setenv DISTCC_HOSTS 'localhost x.x.x.x'，代表本机和x.x.x.x上安装并启动了distccd
2、将你的makefile 中的CC=gcc改为CC=distcc gcc
3、make即可 。同样你还可以在make的-j参数选项，如make -j 12，这样在单机上进行多任务并行编译，使速度更快。
4、如果你想观察各节点上distcc的工作状态，可使用distccmon-text 2 命令查看distcc在各台主机上的任务快照。参数2代表：每隔2秒刷新一次。

Distcc理论上是可以部署在不同平台上辅助进行分布式编译的，但是在异构平台上分布需要一段时间设置和调试，我推荐还是尽量部署在同一类型平台上吧。有了distcc，我们的服务器的计算能力得到了充分的发挥，个人工作效率也会有所提高的，不知道长此下去喝咖啡的机会会不会被剥夺了:)

昨天是周五，按照工作计划，上午和组内同事做个人阶段性目标沟通。在与一位曾经在国外公司里做过项目的同事沟通时，他给我讲了这么一个故事：某一年的圣诞节前夕(圣诞节在西方人眼里是地位最高的节日了吧)他所在的那家公司的经理预感到圣诞节那天他们公司的网站的访问量激增的可能性会很大，为了保证网站在那圣诞节那天能"挺住"，他要求手下的人对网站进行一次压力测试，并决定让手下用jmeter来做这件事情。手下人没有异议，由于没有用过jmeter，遂大家都忙碌起来，预研的、准备测试环境的等等。一切就绪后，正准备开始测试了，这时那位经理突然召集手下人说jmeter不能满足他们的压力测试要求，大家都惊愕之，并马上提出了反驳，因为jmeter工具是这位领导提出要使用的，现在又不用了，圣诞节已经迫在眉睫，更换压力测试工具肯定不能完成这个任务了。这位经理无奈妥协，结果是：通过jmeter压力测试后优化的网站顺利了通过了”圣诞节的考验“，不过大家都觉得这个过程很别扭。

上面的那位经理显然是犯错误了，我看到的起码有二：第一，没有经过对jmeter细致的评估，就断言要使用jmeter做为压力测试工具；第二，其领导意志的不坚定，险些使任务失败，并最终造成了公司成员的不满情绪，影响了整个团队，得不偿失。

这个故事也让我触动很大。记得在上一个项目的准备布局阶段，我当时很想在项目组内推行自动化页面测试，提高开发人员和测试人员的测试效率，到目前为止我也觉得当初我的想法是没有错的，但是问题就在于执行过程出了问题。我对web页面开发是外行，WEB页面开发过程会遇到哪些问题，我基本没有太多概念。当时部门内部正巧有一个服务于外国公司的项目使用了Watir-一款用Ruby实现的轻量级开源Web 自动化测试框架，很袖珍，上手简单。我就安排了一位同事专门花时间去研究了一下如何使用这个工具，并在组内做了一个Share。大家对这个工具提出了一些自己的意见和建议，并基本上认同了它。由于是试点，所以先安排放到测试组做自动化页面回归测试，由专门的测试人员负责编写测试脚本。就这样完成两轮测试后，收到一份文档-关于Watir在自动化回归测试过程的问题报告，里面列出了诸多问题，比如：自动测试过程中如遇到弹出对话框的情况，自动化过程被中断，需人为干预；测试对数据依赖很大，当数据量很大，需要多页显示时，没有找到很好的办法；页面元素变动较为频繁，用例脚本需不断更新，工作量较大；Watir只支持IE，对其他浏览器支持不好；Watir录制功能不甚完善等等。这些问题是我始料未及的，恰逢那个时候，我又发现了一个更为强大的页面自动化测试工具-Selenium，我个人也就渐渐的对Watir失去了早先的热情，Watir在我的不坚定的意志下没有收获很好的结果。现在看来，如果当时我持续关注、持续推进Watir的使用，积极解决发现的问题，也许Watir就会成为大家日常不可缺少的一个工具而存活下来，显然我没有这么做，我想和上面的故事一样，或多或少这也给组内的同事带来了一些负面的影响。

与此类似的是部门曾经多次考虑过使用C++来重新设计和实现我们的产品，众所周知C++开发效率高，性能也不逊于C，如果真的改成了C++，我们的思维也可以和这个世界接轨了(很多人认为：太多的新思想似乎和古老的C搭不上边)，大家认可，关键是领导也认可并鼓励一些有能力的开发人员抽时间研究学习C++，但是每每总是不了了之，领导始终没有坚定的意志做这次变革，开发人员也逐渐消磨的热情，回归到了C的世界。

打破既有规则，拥抱新事物，似乎一直就是一件很困难的事，而领导意志在一个组织内部目前来看还是起着决定性的作用的，否则再好的东西也会变成局部的个人兴趣，没有用武之地。如果一个领导坚定的推行大家都不认同的新事物(很可能是领导的个人喜好或者上级的命令)，那么这样带来的后果将更加严重。

所以作为领导的，确需三思而后行啊，用此文自勉共勉吧。