本来想写这样一篇文章很久了，虽然也有时间去写，但是这样的貌似纯理论的东西感觉还是很难下笔，今天晚上想着还是写下来好，以后自己看也是一个值得回忆的技术过程。因为我自己使用命令行比较多，所以对我来说，任何机器首先最重要的是命令行环境了，在Windows下面，使用cmd和一些alias工具去使用命令行，在Mac或者Linux下面，命令行更是鼓励的一种方式，可见命令行虽然在历史上很久了，但还是非常重要的。

其实我原来一直都是在微软的.net平台下进行开发的，C#固然强大，但是帮你做的事情太多了，你不需要关心内存泄露，也不需要关心垃圾释放，也不需要关心指针问题，更不用关心自动化等等了。当然，好是很好，但是对程序员的自身提高还是有一定阻碍的，特别是对那些从C#入门的开发人员来说更是这样，所以就会很难理解命令行和自动化为什么好了。当有一个新语言或者新的东西发布的时候，如Chrome插件，iPhone开发等等，很多依赖平台或者IDE很强的人就茫然了，无从下手了。

但是很多人让他们去写这样的东西，用记事本什么的，也可以写出来，但是效率那就是很低的了，这也就是对命令行等等不太熟练造成的，为什么国外的很多程序员很厉害，因为他们基础很好，高层的自然就好了，当遇到问题的时候，自然就会找到简单的，高效的方式去解决。

说了这么多废话，还是举例最快了。例如当我们进行软件开发的时候，我们大部分的流程是这样的。

这个过程貌似是传统的软件开发过程，比如有人做数据库，有人写后端逻辑，进行性能优化，有人做中层开发，封装后端的复杂的逻辑，然后有人做前端开发，调用中层开发的封装的逻辑。当然，任何一个步骤都是复杂和难以控制的，前端要考虑用户体验，UI，UE等等，中层要考虑类的封装和设计，考虑到扩展性和实用性，后端要考虑到性能处理等，DBA数据库开发要考虑到数据读取，IO优化，索引等等，既然各个步骤都是复杂的，但是是什么让我们的过程更加复杂呢，那就是teamwork。

在teamwork中，各个成员依赖于不同的成员，也可以说依赖于不同的成员的结果，例如使用其他成员的代码或者库，这就考虑到协同的问题，所以这就是为什么会有版本控制和流程控制了。当然，当只有一个项目的时候，这虽然也很麻烦，但是还算是比较好解决，但是当项目越来越大，产品线越来越长的时候，一些问题就突出的显现出来了。

举例说明，假设，微软的Windows和SQL Server都要读取XML，但是都使用相同或差不多的逻辑，但是每个团队都有自己的方法，当过了5年或10年，出了BUG，有人修改了SQL Server里的XML读取的方法，但是忘记更改Windows里的，但是Windows团队以为改了Windows里的库，就发布了，但用户一旦一使用，发现出现了崩溃的情况，这是非常正常的，也是无论在大公司还是小公司都会发生的情况，这个时候用命令行可以优化整个过程。

例如当Windows团队和SQL Server团队的发现都写了一个相同功能的类的时候，可以将这个代码放到一个公共库里面去，然后每次使用命令行，在编译的时候自动拷贝最新的库，以保证代码的正确性和兼容性。这样就会有几个好处。

• 代码维护简单：只在一个地方。
• 应用程序最新：每天build的程序都是最新的，每个团队成员都是使用的最新的库，不会有错误。
• 更改维护简单：更改一个地方，所有的代码都会更改为使用最新的代码，而不会这个程序是0.1版本，另一个是0.2，再一个是0.3。
• 跨应用程序维护：所有的应用程序都可以使用这个库，例如Expression或者VS就同样可以使用这个类。

其实将上面的需求联系到我的实际，就是我在平常的工作中会开发好多东西，例如Firefox插件，Chrome插件和一些Widget，但是这些东西的开发都是大同小异的，都是用HTML和JavaScript，这个时候，就要考虑这样的需求了，是不是所有的软件都可以公用一些东西？如下。

例如我有一些库，而且都可以使用到Firefox，Chrome和Widget里，怎么办，难道我每次都要自己手动从库中拷贝吗？那么如果是这样的话肯定会遇到这样的问题。

• Boss：Hey GuoJing，你这个可以运行吗。
• GuoJing：当然可以，只要XXX就可以运行了。
• Boss：哦，不错，不过另一个好像不工作，这两个代码应该是差不多的。
• GuoJing：额，寒，我记得我上次拷贝过来了，忘记了，这次再拷一下就行了。
• Boss：我们不能这样，我们要有一个自动化的系统。

这样的事情会经常发生，有些是显性的，例如你项目不能用了，不能工作了，有些却是隐性的，例如发布了1年之后才发现这个严重的BUG，那就真的就是一场灾难了。

所以命令行和自动化系统能帮我们自动的处理这些烦人的问题，我可以这样做。当需要打包或编译一个项目的时候，自动化的拷贝其他的项目的依赖库到我的应用中，如果其他项目需要编译，那么就先编译其他的项目，然后将最新的依赖库拷贝到我的应用中，如果依赖的库有问题无法编译，自动的通知负责人告知相应的BUG。也就是说，你的一个命令，会做很多的事情，而这么多的事情，仅仅只是一个命令而已。

命令行还有一个显著的特点就是，当你写对了一次，就不会再错了。这样就能保证我们系统的健康性和完整性还有一定的可重用性。

当然，这也可以不需要使用命令行，但是命令行是最简单，最轻便，成本最低的一种方式，如果一个团队的人都熟练使用相应的命令的话，效率会提升不只一倍。

其实，我们使用命令行和自动化的最主要的原因，不是为了耍酷或者说自己是一个真正的程序员，而是在项目中，更多的考虑重用，简单，依赖，可持续性的问题，对于小的公司，小的项目，可能这样的需求不是很高，甚至一个产品都不怎么测试的就发布了，但是对于大一点的公司和项目，自动化的处理，测试，编译，运行和发布都是非常重要的，这也是为什么微软会有用WTT自动化测试和Daily Build了，也是为了保证项目的完整性，健壮性和可持续性（例如微软的有些项目每天都会用很多机器自动的编译，然后自动的测试，自动的将结果发送到每个团队成员邮箱中，这样每个人都会知道哪里的问题，而不是打电话说，喂，好像你那里有问题，我们什么时候看看吧）。

命令行和自动化，其实就是为了简单，自动，高效。虽然一些小公司不太需要这样的概念，甚至可以说我的成本弄不起，但是为了将来的发展，和一个企业的习惯，尝试一下也不是不可以的。：）