手工Build的烦恼
要不是为了和女朋友留在一个城市，小李肯定去北上广奋斗去了。
现在他只能留在这个2.5线城市，进入这家软件开发公司，7,8个人，10来条枪，是个典型的软件小作坊。
上班第一天，CTO兼架构师兼项目经理兼开发组长老张把小李叫去，谆谆教导说：
“小李啊，我看了你的简历，我对你在公司的发展还是挺看好的，不过作为新人，你对新业务还不熟悉，没法开发核心系统，这段时间，你要一边学习，一边帮着项目做个很重要的工作：Build“
小李心说你还给我拽英语啊， 虽然心里这么想， 小李还是不动声色，面带微笑的问：
“这Build是什么东西？”
老张说：“我非常忙， 没时间给你解释，这儿有个文档，你看看就知道了”
说着，老张甩给了他几张纸 ，补充到： “有问题问小王， 他比你早来一个月，做Build已经很熟了”
小李仔细看了一遍，上面写着：
XXX公司Build 流程 （测试环境）
(1) 设置Eclipse 工作区， 编码为UTF-8, java 编译级别为JDK 1.7
(2) 从SVN下载最新源代码到Eclipse工作区
(3) 确保Eclispe工作区没有编译错误
(4) 手工修改下面20个配置文件
database.properties
cache.properties
user.properties
。。。。。。
(5) 把Eclipse中的Web项目导出成War 包
小王还特别在这里用红色的笔加了标注： Web项目所依赖的其他java项目也会被自动包含到War包的 WEB-INF/lib目录下
(6) 上传到测试服务器，安装
(7) 做冒烟测试
小李笑了：这不就是一个编译，打包，部署，测试的流程吗？ 还Build !
正在这时，开发骨干小梁叫小李了：“小李， 我改了几个Bug，马上要测试，赶紧给我做一个测试环境的Build”
小李不敢怠慢，立刻按照文档做了一遍，花了将近半个小时才折腾完。
可是到了最后一步，做冒烟测试的时候， 系统却启动不了了 ！
小李查了好久才发现，原来测试环境的JDK是1.6 , 但是Build文档上写的是1.7 当然跑不起来了。
小李暗暗的骂前任小王： 你小子肯定知道这里有个坑， 怎么不在文档上标注出来？
赶紧做个新的Build 放到测试环境， 这次冒烟测试顺利通过了。
刚松了口气， 测试小赵就叫了起来： “小梁， 你那个Bug 没有修复啊”
开发骨干小梁本能的反应到： “这不可能！ 我的代码本地都测试过了， 代码也提交了“
小梁接着把矛头就指向小李： “哎对了小李，你的Build是不是又搞错了。”
小李心头一惊 ， 赶紧去查，果然，在第4步，手工修改配置文件的时候把数据库改错了 ，指向了开发库，而不是测试库。
赶紧改吧， 原来做Build的小王也跑过来凑热闹， 在前Build专员小王，开发小梁和测试小赵三双眼睛的严厉注目下， 小李头上都要冒汗了。
还好，第三次终于成功了。 所有的测试都顺利通过。
（实际上，小李在紧张的忙碌中也忘了去更新那个文档，把JDK 改成1.6）
就这样过了一周， 小李每天都得战战兢兢的做四五个Build， 虽然做的越来越熟，出错越来越少， 但是每天还是占用了不少时间。
大好年华就要在Build中蹉跎了吗， 坚决不行。
自动化Build
小李决定把这个手工的、费事的、容易出错的Build给自动化起来， 将来谁要是做测试环境的Build，只要运行一个命令即可。
用什么语言来实现呢？ 当然是Java大法好 ！ 小李在大学修炼了那么久，自认为对OO,设计模式已经炉火纯青了， 现在终于有了用武之地。
小李白天工作， 晚上回到住处就开发这个自动化的Build, 每天干到12点才罢休。
但是小李不觉得累， 每天都恋恋不舍的去上床睡觉， 因为创造一个新工具，造福大家的想法一直激励着自己，有时候甚至觉得很快乐。
一个月后， 自动化工具新鲜出炉， 这其实是一套Java 的API, 小李把它称为BuildTool V1.0 专门用于下载源码，编译，打包，部署，测试。
例如，如果你想编译java 代码， 可以这么写：
小李对于FileSet这个抽象很得意， 它能代表一个文件集合， 既可以是java 源文件路径， 也可以是 classpath 的路径。
其他的API像下载源码， 打包，部署，测试也是类似。
现在小李真的只需要运行一个命令，就可以为测试环境生成一个build :
java BuildTool test
工作量一下子少了好多， 并且机器运行，基本上不会出错。
小李因为这个自动化的BuildTool, 获得的公司的嘉奖，还涨了一点工资。
对小李来说，这都不是最重要的， 最重要的通过设计和实现这个BuildTool, 自己的能力有了很大的提升。
自己已经不仅仅是一个只会用SSH框架的一个HTML填空人员了！
码农翻身评： 大部分人只会抱怨项目很无趣，没有挑战， 遇到问题也只会安于现状，
少数人会发现工作中的“痛点”问题，并且真正动手解决它， 给公司带来了价值， 这是提高自己， 让自己和别人区分开来的重要方法。
JAVA vs XML
今年的形势很好，公司业务发展的不错，招了一批新人，一下子接了3，4 个新项目， 小李主动请缨，替这些项目建立一个自动化的Build 。
但是小李很快就发现了问题， 直接用Java语言来编写，功能虽然能实现， 但是看起来就太繁琐了。
自己写的代码过几天看也得思考一下才能明白。
是自己的BuildTool API设计的不好吗？ 那可是精心设计的啊。
仔细思考了两天，小李终于意识到了问题所在： 不是自己设计的不好， 是Java 语言太“低级”了 ！
自动化Build要描述的其实是任务，是业务层面的东西。
而用java 是个什么都能干的通用语言， 用它来写肯定引入了太多的细节，导致了阅读和编写的难度！
小李想：能不能开发一套新的，专门为自动化Build 所使用的语言呢？
（码农翻身注： 这其实就是所谓的领域特定语言(Domain Specific Language , 简称 DSL )）
但是开发一套新语言那成本可就有点高了， 有点得不偿失。
小李百思不得其解， 直到有一天听到小梁和项目经理在讨论hibernate 的配置文件，突然想到 像spring , hibernate 都是用XML来描述系统的。
“那我的BuildTool也完全可以用XML来描述啊” 小李赶紧把那个编译java 的程序用XML描述了一下：
果然是清爽多了！ 和原来的Java程序比起来， 这段XML几乎就是自解释的 ！
XML可扩展性极强， 可以任意自定义标签诸如<javac> <srcDir> <classpath> 用它来描述Build的逻辑。
但是唯一不爽的地方就是： XML 无法像 Java程序那样运行， 只是纯文本而已。
不过这也无妨，只要用Java写一个解析器，用来解析这些XML文件然后在Java中执行就可以了。有了BuildTool V1.0作为基础， 写一个解析器不是什么难事， 很快 BuildTool V2.0 就新鲜出炉了。
小李不再帮其他项目组去写Build 程序，因为用XML描述以后，大家很快就能学会, 并且乐在其中。
CTO老张看到这个工具，大为赞赏， 它给小李说： “别叫什么Build Tool, 太俗， 别人听了一点感觉都没有， 我给你起个名，叫 ANT ”
"ANT? " 小李似乎看到很多小蚂蚁在不辞劳苦帮着做Build， 心里暗暗佩服老张： 这个名字起的太好了， 姜还是老的辣啊。
声明：原创文章，未经授权，禁止转载
你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公众号， 回复消息"m"或"目录" 查看更多文章
有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan QQ: 14703250
公众号 ： 码农翻身
“码农翻身”公众号由工作15年的前IBM架构师创建，分享编程和职场的经验教训。
9322
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
