前言
随着总结的文章越写越多,我发现自己是一个“追求完美”的人,但同时也是一个“虎头蛇尾”的人,这两者看起来冲突,却可以融于一身。去写一个问题是总想从三皇五帝时写起,总想把各个分支情况都写清楚,这就会创造一个“虎头”,但写着写着就发现时间不允许了,或者已经触及了自己的知识边界,最后不得不退化成了“蛇尾”。
这对于总结和传播知识是不合适的,对于知识的总结应该做到详略得当,这一点上我还有很大的提升空间,推荐一本这方面做的比较好的书籍《图解HTTP》,这本书从始至终让人感觉到很丰满,没有哪一部分让人感觉是凑数的,特别的讲到电信号在同轴电缆中的传播,给人一种知识体系非常完整的体验。
言归正传,今天我要谈谈图形用户界面和命令行的区别,工作久了以后总会有点自己的心得,灵光一闪时就想记录下来,算是给今后的自己保存一点点瞬时的记忆,今天就不从三皇五帝开始讲了,我们从计算机的诞生开始说起。
世界世界上第一台电子计算机 ENIAC
,是一个占地170平方米,重达30吨的庞然大物,慢慢的计算机的体积越来越小,但主要用于特定领域,并未进入寻常人家,此阶段的计算机多用于完成特定任务,也就是输入指令完成任务,我们看到的更多的是黑框框,后来随着windows系统(当然苹果系统也出现了)的普及,鼠标点点点极大的降低了入门的难度,也使得图形用于界面深入人心。
关于Windows内置的四款游戏据说每一款都有其特殊的目的与作用,纸牌希望让用户熟悉拖动和释放鼠标;扫雷是为了训练用户使用鼠标进行精准的点击,并掌握左键与右键的区别;红心大战是为了鼓励用户使用互联网与其他玩家交流;空当接龙是为了测试32位的数据处理子系统是否正确安装。这些游戏的出现让人们快速适应了图形用户界面,甚至这是他们接触电脑的第一印象,可能他们并不懂得什么是命令行。
对比
图形用户界面和命令行不能说哪一种更好,只能说哪一种更合适,一些情况下图形界面会给你更直观的感受,一些情况下命令行可以代替重复性的操作。
图形用户界面
图形用户界面,简称GUI,现在绝大多数的用户面对的都是图形界面,而传统意义上的命令行总被看成是上世纪的东西,图形界面首先看起来很直观,就像给你一堆散列的数据很难看出关系,但是如果画一个折线图,立马就能看出数据的走向。
命令行
它的门槛要高一些,虽然使用起来不如图形界面清晰,但是在一些自动化程序中,命令行可以简化操作,省去了点点点的麻烦操作
举个例子
我们以git为例,他在被Linus发明出来的时候肯定只有命令行,但是后来git的图形界面工具多到数不清,一个又一个方便的软件被创造出来,但是git命令行一直没有消失,而且我每天都在用,是因为我不会用图形界面吗?当然不是,因为在我使用的大部分需求中,我只要敲一两个命令就可以完成了,不必拿起鼠标右键菜单再去等几秒中的界面刷新。
还有一方面我需要经常编写自动化脚本,使用Jenkins部署服务器程序,这些环境下是没办法使用图形界面的,只能用命令行还编写逻辑。
适用场景
图形界面
适用于需要直观显示的情景,以及需要根据显示结果反复调整输入的情景,比如过滤commit,我可以在界面上不断调整和尝试过滤的关键词,而结果会随着我的调整发生改变。
命令行
适用于简单命令和机械化的操作,最好是那种写完一遍可以用一辈子的逻辑,如果是类似过滤commit这种需求,我们必须不断的重新输入命令参数,也就是说命令行在我输入命令之后他的参数都确定了,绝大多数不能再调节了。
总有例外
命令行的参数输入之后真的不能调吗?大多数是这样的,但总有例外,这种例外要求命令结果处于定时刷新状态,比如 top
命令,因为它的结果是可以刷新的,所以当你按下键盘上的 c
、P
等按键时,输出结果是会发生变化的。
总结
- 图形界面和命令行两者没有更好,只有更合适
- 图形界面适用于直观显示需求,可以根据用户输入随时调整输出结果
- 命令行更适用于自动化场景,可以将指令编写到操作逻辑中,通常来说更加高效
发现了一种我称之为反围城的状态:外面的人不想进去,里面的人不想出来~