锋利的blade到底锋利在哪里

转自新浪博客

刀是什么样的刀？

诸位看到标题，千万不要以为我是模仿《锋利的JQuery》，或者什么书籍，而是因为，介绍Blade的文章，标题不得不这样。

Blade由腾讯台风云计算平台出品，大约在2012年下半年开源，它是一把专用于构建软件的宝刀。Blade的字面意义应该是"刀锋"，意思是使用该软件构建软件更加强大，更加便捷。该系列宝刀，最早应该是由Google这位顶级刀匠打造而成，当年事迹见诸互联网记载：

http://google-engtools.blogspot.hk/2011/08/build-in-cloud-how-build-system-works.html

http://mike-bland.com/2012/10/01/tools.html#tools-blaze-forge-srcfs-objfs

 

听说Google内部打磨的宝刀，其名为"火焰刀"，英文名为"Blaze",一样是锋芒毕露，炙热灼物，其面世后，以其熊熊烈焰，统一了google内部的软件编译方式。腾讯出品的blade, 英文写法，只有一字之差，不过"火焰""刀锋"各得风流，虽说取名有点像偶像致敬的意思，但是也是锋芒不让。

 

提起google的宝刀，其实到google洗练过几年武学的IT牛人们，在远走他方后，也都各自打磨了一把。我的前东家，就成绩打磨过一把类似的宝剑，取名"Ymake",名字是虽然朴拙了一些，但是假如你见过他们亮出过宝刀，也会被其锋芒所吸引。在云壤的江湖朋友们，都称道其"活儿好"。

 

就互联网上能搜索到的铸刀秘诀而言，我能搜索到的，应该是我的前任授业恩师放出去的，其实他应该还没有加入云壤。项目地址为：

https://code.google.com/p/qa52/

其BUILD语法，虽然还没有简洁到极致，但是功能上似乎看起来也已经有模有样。

 

其示例的BUILD文件如下所示：

假如你仔细瞅瞅，会发现语法已经基本接近google开放出来的BUILD文件示例。

 

好吧，花了九牛二虎之力，追溯了blade的历史掌故，却还没点到题上。言归正传，blade其实是一个多语言的构建工具，之所以使用"构建"，而不是"编译"两字，实在是因为软件构建并不仅仅是软件编译，而非我喜欢故弄玄虚。Blade除了编译软件以外，还奉上了很多其它的福利，比如集成了单元测试，性能测试等。这正如一把好刀，不仅应该能杀人，还且最好能力最短的时间内杀死对方，刀光一起，人已倒地，但是刀不流血，刀已回鞘。

 

那么，Blade藏身何处，不急，以下就是它的所在：

https://code.google.com/p/typhoon-blade/

https://github.com/chen3feng/typhoon-blade

目前该项目与陈峰维护，其微博名为"陈三丰"，虽然我猜测可能是由于"陈峰"这个名字已经被他人抢先使用，继而只好采用拆字法，将"峰"一分为二，是为"三丰"，不过从名字看，倒也和大侠张三丰很有渊源，就此而言，blade(刀锋)由他维护倒是最妙不过了。

刀锋的锋芒在哪里？

 

既然号称刀锋，那么其锋芒何在？为什么有了make这把天下闻名的好刀，还要试试blade的锋芒？

那么下面就在历数一下blade的不同凡响处。

天下武功，唯快不破

 

江湖上最知名的刀，无不以快而闻名，blade的一个好处，也是其编译速度快，快得益于几个方面：

1,可以进行并行编译和并行测试，

2,使用了ccache等库，可以将编译中间结果进行缓存。

3,如果使用了distcc模式，则可以享有更多的用于编译的硬件资源。听说google内部的blaze有三个模式，一个是Local，一个是distcc,一个是Forge，按理说，forge模式由于运行在大规模的集群中，编译的速度应该最为快。

刀虽为刀，却不仅仅是刀

 

在仙剑奇侠传四中，宝剑望舒，被男主角云天河各种虐待，从猎野猪、烤肉、劈柴到射箭、御剑，无所不用其极。而一把好刀，其功能自然不应该局限与杀人见血。

Blade作为一个构建工具，其作用不仅仅是替代make和makefile,且听我细细道来：

1，Blade是软件工程的利器，有助于模块化，模块化的力度控制自如，对于提高系统的可维护性，复杂性的隔离，代码复用的最大化，都有很大的好处。

2，Blade提供了单元测试的最佳使用方式。

假若单元测试和代码是分离的，编译代码和运行测试各自为政，那么往往测试只是测试，很难对开发有什么帮助，因为很多时候，虽然有测试代码，但是测试却很少被运行，或者时过境迁后，测试多有失效。大家假如编译过一些开源项目的话，可能就会有类似的经验，编译完静态库，拿到静态库文件就完了，很少有人去运行所有的单元测试，确保所有的测试都能运行通过。

有了Blade，通过cc_test将gtest_main.a默认链接，使得单元测试的代码简化到极致。同时，主要运行blade test target,就能在编译完目标程序后，运行（而且可并发运行）相应的单元测试，以随时跟进代码是否已经偏离了该有的轨道，开发是否早已脱缰狂奔。

只要发布部署时，使用上Blade test target, 那么就可以保证，上线的模块，能够通过所有单元测试用例的验证把关。Blade集成单元测试，提供cc_test,看似功能简单，但是正是这个简单的功能，使得测试驱动开发，开发者测试等理念，能够在google全功能范围内得到认同并贯彻实现。

3，blade实现了递归编译。

Blade build …即可对当前目录及其子目录下的所有编译对象进行编译。该功能虽然小，但是却很实用。在一个十几人的团队中，百万行级别的代码规模，只有递归编译功能，可以很方便地实现一个循环编译工具，当某个模块编译失败，或者某个单元测试失败后，自动发出邮件通知相关的开发人员，以保证频繁的开发提交代码成为开发。当然，相关的功能，可以通过类似hudson之类的软件完成。不过blade 递归编译，对中小规模的代码而言，基本已经游刃有余。

4，blade 实现了依赖查询。

Blade query可以查询依赖到某个模块的所有模块，这个对于代码重构而言，是个不错的功能。假如你在重构code base,或者是修改接口，或者是fix bug,或者是改进性能，

都可能使得使用到该库的相关模块，集体罢工，单元测试无法通过。这时候，假如使用上blade query,你就可能编译相关模块，使得你提交的代码，不会给其它模块带来麻烦。

5，blade绑定了静态代码审查功能。

对整个项目而言，严把质量关非常重要，因为一旦一些烂代码进去了，清扫牛粪的工作将会非常痛苦而且艰巨。这里的异己分子，可能包括bug,风格差异迥异等。

Blade 会在进行编译之前，会所有被变更的编码，使用指定的静态代码审查功能进行代码审查。C++代码审查脚本，google cpplint较为知名，地址为：

http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py

当然，每个公司都可以定制其自己的检查脚本，以符合其自己的代码风格等。

Blade绑定该功能，可以避免出现一些常见的Bug，统一团队的代码风格，对公司工程文化的塑造有润物细无声之效。

6,blade是编译的统一入口，并且是开放的

这点是最重要的，也是blade的锋芒所在。因为Blade是统一的编译如果，因此修改统一的编译选项，设置统一的编译警告级别，实现cc_test等全部成为可能。

只要愿意，你不仅可以在编译前实现代码审查，也可以在编译时设置不同的参数，选择指定的编译器，更可以在编译后，运行单元测试，统计单元测试覆盖率，当可以定制各种操作。

因为统一，所以要升级编译器，使用统一的警告级别等牵一发而动全身的动作成为可能。因为开发，实现cc_test, cc_benchmark, proto_library, thrift_library成为可能。

 

好使的刀，方为好刀

假如刀虽然，但是太笨重，使用起来仿佛破解机关，这只有寂寞的高手才能使用了，普通人得知，如同废铁。因此，好使的刀，才是好刀。

Blade之所以好使，在于其采用了足够简洁的语法，比如下面便是编译一个静态库libencoding.a的语法描述:

cc_library(

    name = 'encoding',

    srcs = [

        'ascii.cpp',

        'base64.cpp',

        'hex.cpp',

        'percent.cpp',

        'shell.cpp',

    ],

    deps = [

        '//toft/base/string:string',

        '//thirdparty/stringencoders:stringencoders'

    ]

)

你需要的只有三件事，要打造的刀叫什么刀，它需要使用什么特别的原料，它需要依赖哪些现成的原料。也就是name, srcs,deps, 换言之，就是编译对象名，编译需要的源文件，需要依赖的其它静态库。你需要描述的有且仅有他们。怎么编译，编译选项，在哪里编译，中间产物是什么，中间产物放在哪里，你通通不需要关注。刀一出鞘，东西已在那，躺在了你希望它在的所在，热乎乎的，等你去品尝。

这种简单到极致的语法，好处却有很多。比如：

1, 容易学习，容易记忆，你需要记忆的只有name, srcs,deps等掰着十指都能数的过来的关键字和规则，剩下的就是，告诉它用到哪些代码文件，用到了哪些外部的库。

相比Makefile繁琐的语法，BUILD文件可谓清爽宜人。

2,简化到了极致的好处是，各种cc_library可以在力度中间轻松转换，因此使用了BUILD文件后，模块划分会更加合理，哪怕有一个文件，其它模块可能可以使用上，你也可以方便地将它打包到一个静态库中，这样其它地方只要依赖上这个cc_library，就可以坐享其成。

我曾经见识过各种thrift文件，protobuf文件散落在代码各个目录甚至分支中，如果使用上thrift_library, proto_library,将thrift文件定义出细粒度的library,则可以避免因Makefile中频繁描述thrift/protobuf源文件生成与编译的痛苦。

羞于告诉他人的是，我至今都对Makefile不太熟悉，不过所幸，Blade已经开源，我从此不必也不像和Makefile再打交道，我也没有必要告诉别人说，我认识Makefile这个哥们。

宝刀待屠龙

江湖中向来有"武林至尊,宝刀屠龙,号令天下,莫敢不从,倚天不出,谁与争锋."的说法，blade既然是一把绝世好刀，在倚天剑面世之前，各位江湖好友，不妨试试其刀锋如何!