The three chief virtues of a programmer are: Laziness, Impatience and Hubris. – Larry Wall
懒惰这个特点位于程序员的三大美德之首：唯有懒惰才会驱动程序员尽可能的将日常工作自动化起来，解放自己的双手，节省自己的时间。而GUI，不得不说，天然就是为了让自动化变得困难的一种设计。GUI更强调的是与人类的直接交互：通过视觉手段将信息以多层次的方式呈现，使用视觉元素进行指引，最后系统在后台进行实际的处理，并将最终结果以视觉手段展现出来。
这种更强调交互过程的设计初衷使得自动化变得非常困难。另一方面，由于GUI是为人类设计的，它的响应就不能太快，至少要留给操作者反应时间（甚至有些用户操作需要人为的加入一些延迟，以提升用户体验）。
程序员除了写代码之外，还有很多事情要做，比如自动化测试，基础设施的配置和管理，持续集成/持续发布环境，甚至有些团队好需要做一些与运维相关的事情（线上问题监控，环境监控等）。
- 开发/测试
- 基础设施管理
- 持续集成/持续发布
- 运维（监控）工作
- 娱乐
UNIX编程哲学
关于UNIX哲学，其实坊间有多个版本，这里有一个比较详细的清单。虽然有不同的版本，但是有很多一致的地方：
- 小即是美
- 让程序只做好一件事
- 尽可能早地创建原型(然后逐步演进)
- 数据应该保存为文本文件
- 避免使用可定制性低下的用户界面
这里列举一些小的例子，我们来看看命令行工具是如何通过应用这些哲学来简化工作，提高效率的。一旦你熟练掌握这些技能，就再也无法摆脱它，也再也忍受不了低效而难用的各种GUI工具了。
命令行如何帮助程序员提升效率
一个高阶计算器
在我的编程生涯的早期，读过的最为振奋的一本书是《UNIX编程环境》，和其他基本UNIX世界的大部头比起来，这本书其实还是比较小众的。我读大二的时候这本书已经出版了差不多22年(中文版也已经有7年了)，有一些内容已经过时了，比如没有返回值的main函数，外置的参数列表等等，不过在学习到HOC(High Order Calculator)的全部开发过程时，我依然被深深的震撼到了。
简而言之，这个HOC语言的开发过程需要这样几个组件：
- 词法分析器
lex
- 语法分析器
yacc
- 标准数学库
stdlib
另外还有一些自定义的函数等，最后通过make连接在一起。我跟着书上的讲解，对着书把所有代码都敲了一遍。所有的操作都是在一台很老的IBM的ThinkPad T20上完成的，而且全部都在命令行中进行（当然，还在命令行里听着歌）。
这也是我第一次彻底被UNIX的哲学所折服的体验：
- 每个工具只做且做好一件事
- 工具可以协作起来
- 一切面向文本
下面是书中的Makefile脚本，通过简单的配置，就将一些各司其职的小工具协作起来，完成一个编程语言程序的预编译、编译、链接、二进制生成的动作。
02 |
OBJS = hoc.o code.o init.o math.o symbol.o |
05 |
cc $(OBJS) -lm -o hoc5 |
07 |
hoc.o code.o init.o symbol.o: hoc.h |
09 |
code.o init.o symbol.o: x.tab.h |
12 |
-cmp -s x.tab.h y.tab.h || cp y.tab.h x.tab.h |
14 |
pr: hoc.y hoc.h code.c init.c math.c symbol.c |
19 |
rm -f $(OBJS) [xy].tab.[ch] |
虽然现在来看，这本书的很多内容已经过期（特别是离它第一次出版已经过去了近30年），有兴趣的朋友可以读一读。这里有一个Lex/Yacc的小例子，有情趣的朋友可以看看。
基础设施自动化
开发过程中，工程师还需要关注的一个问题是：软件运行的环境。我在上学的时候，刚开始学习Linux的时候，会在Windows机器上装一个虚拟机软件VMWare，然后在VMWare中安装一个Redhat Linux 9。这样当我不小心把Linux玩坏了之后，只需要重装一下就行了，不影响我的其他数据（比如课程作业，文档之类）。不过每次重装也挺麻烦，需要找到iso镜像文件，再挂载到本地的虚拟光驱上，然后再用VMWare来安装。
而且这些动作都是在GUI里完成的，每次都要做很多重复的事情：找镜像文件，使用虚拟光驱软件挂载，启动VMWare，安装Linux，配置个人偏好，配置用户名/密码等等。熟练之后，我可以在30分钟 – 60分钟安装和配置好一个新的环境。
Vagrant
后来我就发现了Vagrant，它支持开发者通过配置的方式将机器描述出来，然后通过命令行的方式来安装并启动，比如下面这个配置：
1 |
VAGRANTFILE_API_VERSION = "2" |
3 |
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| |
4 |
config.vm.box = "precise64" |
5 |
config.vm.network "private_network", :ip => "192.168.2.100" |
它定义了一个虚拟机，使用Ubuntu Precise 64的镜像，然后为其配置一个网络地址192.168.2.100，定义好之后，我只需要执行：
我的机器就可以在几分钟内装好，因为这个动作是命令行里完成的，我可以在持续集成环境里做同样的事情 – 只需要一条命令。定义好的这个文件可以在团队内共享，可以放入版本管理，团队里的任何一个成员都可以在几分钟内得到一个和我一样的环境。
Ansible
一般而言，对于一个软件项目而言，一个全新的操作系统基本上没有任何用处。为了让应用跑起来，我们还需要很多东西。比如Web服务器，Java环境，cgi路径等，除了安装一些软件之外，还有大量的配置工作要做，比如apache httpd服务器的文档根路径，JAVA_HOME环境变量等等。
这些工作做好了，一个环境才算就绪。我记得在上一个项目上，不小心把测试环境的Tomcat目录给删除了，结果害的另外一位同事花了三四个小时才把环境恢复回来（包括重新安装Tomcat，配置一些JAVA_OPTS，应用的部署等）。
不过还在我们有很多工具可以帮助开发者完成环境的自动化准备，比如：Chef, Puppet, Ansible。只需要一些简单的配置，然后结合一个命令行应用，整个过程就可以自动化起来了：
01 |
- name: setup custom repo |
02 |
apt: pkg=python-pycurl state=present |
05 |
copy: dest=/etc/default/graphite-carbon content=‘CARBON_CACHE_ENABLED=true‘ |
07 |
- name: install graphite and deps |
08 |
apt: name= state=present |
11 |
- name: install graphite and deps |
12 |
pip: name= state=present |
13 |
with_items: python_packages |
16 |
copy: src=apache2-graphite.conf dest=/etc/apache2/sites-available/default |
17 |
notify: restart apache |
19 |
- name: configure wsgi |
20 |
file: path=/etc/apache2/wsgi state=directory |
上边的配置描述了安装graphite-carbon，配置apahce等很多手工的劳动，开发者现在只需要执行：
就可以将整个过程自动化起来。现在如果我不小心把Tomcat删了，只需要几分钟就可以重新配置一个全新的，当然整个过程还是自动的。这在GUI下完全无法想象，特别是有如此多的定制内容的场景下。
持续集成/持续发布
日常开发任务中，除了实际的编码和环境配置之外，另一大部分内容就是持续集成/持续发布了。借助于命令行，这个动作也可以非常高效和自动化。
Jenkins
持续集成/持续发布已经是很多企业IT的基本配置了。各个团队通过持续集成环境来编译代码、静态检查、执行单元测试、端到端测试、生成报告、打包、部署到测试环境等等。
比如在Jenkins环境中，在最前的版本中，要配置一个构建任务需要很多的GUI操作，不过在新版本中，大部分操作都已经可以写成脚本。
这样的方式，使得自动化变成了可能，要复制一个已有的pipline，或者要修改一些配置、命令、变量等等，再也不需要用鼠标点来点去了。而且这些代码可以纳入项目代码库中，和其他代码一起被管理，维护，变更历史也更容易追踪和回滚（在GUI上，特别是基于Web的，回滚操作基本上属于不可能）。
04 |
stage(‘Preparation‘) { // for display purposes |
05 |
git ‘https://github.com/jglick/simple-maven-project-with-tests.git‘ |
10 |
sh "‘${mvnHome}/bin/mvn‘ -Dmaven.test.failure.ignore clean package" |
14 |
junit ‘**/target/surefire-reports/TEST-*.xml‘ |
15 |
archive ‘target/*.jar‘ |
上面这段groovy脚本定义了三个Stage，每个Stage中分别有自己的命令，这种以代码来控制的方式显然比GUI编辑的方式更加高效，自动化也编程了可能。
运维工作
自动化监控
Graphite是一个功能强大的监控工具，不过其背后的理念倒是很简单：
用户只需要将数据按照一定格式定期发送给Graphite，剩下的事情就交给Graphite了，比如它可以消费这样的数据：
1 |
instance.prod.cpu.load 40 1484638635 |
2 |
instance.prod.cpu.load 35 1484638754 |
3 |
instance.prod.cpu.load 23 1484638812 |
第一个字段表示数据的名称，比如此处instance.prod.cpu.load表示prod实例的CPU负载，第二个字段表示数据的值，最后一个字段表示时间戳。
这样，Graphite就会将所有同一个名称下的值按照时间顺序画成图。
图片来源
默认地，Graphite会监听一个网络端口，用户通过网络将信息发送给这个端口，然后Graphite会将信息持久化起来，然后定期刷新。简而言之，只需要一条命令就可以做到发送数据：
1 |
echo "instance.prod.cpu.load 23 `date +%s`" | nc -q0 graphite.server 2003 |
date +%s会生成当前时间戳，然后通过echo命令将其拼成一个完整的字符串，比如：
1 |
instance.prod.cpu.load 23 1484638812 |
然后通过管道|将这个字符串通过网络发送给graphite.server这台机器的2003端口。这样数据就被记录在graphite.server上了。
定时任务
如果我们要自动的将数据每隔几秒就发送给graphite.server，只需要改造一下这行命令：
- 获取当前CPU的load
- 获取当前时间戳
- 拼成一个字符串
- 发送给
graphite.server的2003端口
- 每隔5分钟做重复一下1-4
获取CPU的load在大多数系统中都很容易：
这里的参数:
-A表示统计所有当前进程-o %cpu表示仅显示%cpu列的数值
这样可以得到每个进程占用CPU负载的数字：
下一步是将这些数字加起来。通过awk命令，可以很容易做到这一点：
1 |
$ awk ‘{s+=$1} END {print s}‘ |
比如要计算1 2 3的和：
1 |
$ echo "1\n2\n3" | awk ‘{s+=$1} END {print s}‘ |
通过管道可以讲两者连起来：
1 |
$ ps -A -o %cpu | awk ‘{s+=$1} END {print s}‘ |
我们测试一下效果：
1 |
$ ps -A -o %cpu | awk ‘{s+=$1} END {print s}‘ |
看来还不错，有个这个脚本，通过crontab来定期调用即可：
4 |
LOAD=`ps -A -o %cpu | awk ‘{s+=$1} END {print s}‘` |
6 |
echo "instance.prod.cpu.load ${LOAD} `date +%s`" | nc -q0 ${SERVER} ${PORT} |
当然，如果使用Grafana等强调UI的工具，可以很容易的做的更加酷炫：
图片来源
想想用GUI应用如何做到这些工作。
娱乐
命令行的MP3播放器
最早的时候，有一个叫做mpg123的命令行工具，用来播放MP3文件。不过这个工具是商用的，于是就有人写了一个工具，叫mpg321，基本上是mpg123的开源克隆。不过后来mpg123自己也开源了，这是后话不提。
将我的所有mp3文件的路径保存成一个文件，相当于我的歌单：
1 |
$ ls /Users/jtqiu/Music/*.mp3 > favorites.list |
4 |
/Users/jtqiu/Music/Rolling In The Deep-Adele.mp3 |
5 |
/Users/jtqiu/Music/Wavin‘ Flag-K‘Naan.mp3 |
6 |
/Users/jtqiu/Music/蓝莲花-许巍.mp3 |
然后我将这个歌单交给mpg321去在后台播放：
1 |
$ mpg321 -q --list favorites.list & |
这样我就可以一边写代码一边听音乐，如果听烦了，只需要将这个后台任务切换到前台fg，然后就可以关掉了：
2 |
[1] + 10268 running mpg321 -q --list favorites.list |
小结
综上，优秀的程序员借助命令行的特性，可以成倍（有时候是跨越数量级的）地提高工作效率，从而有更多的时间进行思考、学习新的技能，或者开发新的工具帮助某项工作的自动化。这也是优秀的程序员之所以优秀的原因。而面向手工的，原始的图形界面会拖慢这一过程，很多原本可以自动化起来的工作被淹没在“简单的GUI”之中。
最后补充一点，本文的关键在于强调优秀的程序员与命令行的关系，而不在GUI应用和命令行应用的优劣。GUI应用当然有其使用场景，比如做3D建模，GIS系统，设计师的创作，图文并茂的字处理软件，电影播放器，网页浏览器等等。
写在最后：FOR Freedom 看看外边的世界，以及IT这一行，少不了去Google查资料，最后，安利一个V——PN代理。一枝红杏 VPN，去Google查资料是绝对首选，连接速度快，使用也方便。我买的是99￥一年的，通过这个链接（http://my.yizhihongxing.com/aff.php?aff=2509）注册后输上会员中心得优惠码，平摊下来，每月才7块钱，特实惠。
本文标签： 程序员 优秀的程序员 命令行 编程哲学 程序员的日常工作
转自 SUN‘S BLOG - 专注互联网知识，分享互联网精神！
原文地址 ： 《盘点优秀的程序员之所以优秀的原因：所以优秀的程序员几乎都喜欢命令行》
相关阅读:《Aaron Swartz – 互联网天才开挂的人生历程：每时每刻都问自己，现在这世界有什么最重要的事是我能参与去做的？》
相关阅读:《网站环境apache + php + mysql 的XAMPP，如何实现一个服务器上配置多个网站？》
相关阅读:《什么是工程师文化？各位工程师是为什么活的？作为一个IT或互联网公司为什么要工程师文化?》
相关阅读: 对程序员有用：2017最新能上Google的hosts文件下载及总结网友遇到的各种hosts问题解决方法及配置详解
相关阅读: 《win10永久激活教程以及如何查看windows系统是不是永久激活？》
相关BLOG：SUN’S BLOG - 专注互联网知识，分享互联网精神！去看看：www.whosmall.com
盘点优秀的程序员之所以优秀的原因：所以优秀的程序员几乎都喜欢命令行
原文：http://www.cnblogs.com/taidupa/p/6338137.html
