2345技术员联盟

Unix 哲学指导工作流的构建

  • 来源:未知 原创
  • 时间:2018-05-28
  • 阅读:
  • 本文标签:

     不论是在过去的命令行、桌面端,还是现在的移动端,使用的工具一直在不断的变动。但在使用软件时,我一直习惯于遵从一个原则,那就是 Unix 哲学。尽管几十年来,软件的形态交互变化很大,但是我的核心使用模式都不会变,也就是 Unix 哲学的内容:每个软件做一件事,做好它,文本流来让软件协作,完成复杂工作,这个原则非常古老而经典,指导着 Unix、Linux、macOS 等操作系统上基本软件的设计原则。命令行时代,以及 Unix 哲学引言,作为前言,介绍一些命令行时代一些经典的联动使用方式。如果感到比较抽象可以直接跳到末尾的结论。(为了方便解释,第一行的中文解释了指令的含义,第二行写下了指令实际内容。「指令」其实是一个小的程序,来做一段专门的操作。)按照文件名查找文件夹里的一个文件,列出 目录名称 | 搜索 字符串ls dir | greptext,查找文件内的内容,输出内容 文件 | 搜索 字符串cat filename | greptext,这里的「|」是 Unix 中的「管道」,可以理解为,文本流的传递。管道前部的「输出」可以作为后部的「输入」,第一步的操作获得一个结果,第二部操作把第一步的结果作为输入,直接处理上一步的结果。当更多的「管道」连接到一起,就相当于将单步操作连接到了一起,完成复杂工作。


    虽然这个已经有四十年的历史了,但是核心思想就和现在流行的 Workflow 一样。命令行下的经典协作用法,这里的「搜索」就是利用着软件 grep。可以看到,grep 就是专门用于搜索,它不会在乎搜索的来源到底是什么。它仅仅将这一切看作文本流即可,而只需要做好搜索功能。同样的道理,读出文件内容的软件不需要搜索功能,列出目录的软件也不需要搜索功能,只需要做好各自的本职工作。只需要对外输出文本流,将职责之外的工作交给专业的工具即可。


    而整个流程,关注的一个重点在于「文本流」的传递。就像它的字面意思一样,文本最初从上游输入,到最终的下游需要的输出。为了达到目的经过了若干环节的操作。在 Unix 设计思想的指导下,每个环节操作偏向于原子性,拆分到专注唯一功能,但是功能做到极致。某种程度上,像是 iOS 上的 Workflow。每一步的指令相当于一个动作,联动在一起,做到复杂的工作。桌面工具时代,以及 Unix 哲学的演化,桌面工具领先了命令行一个维度,做到了丰富功能。比如,不再有人像最初那样,纯文本以及几个简单标记就写了整个文档,而是更加偏向于一个全才的软件,例如 Microsoft Word,实现全部的输入、排版、输出。这时候,一个工作的流程就是一个步骤,


    打开 Word (然后编辑/然后排版/然后打印),但,看起来的完善并不是我想要的结果,因为有些单独任务没有达到我想要的极致。我不需要一个大而全的工具,而是各个方面足够专才的工具。还有重要的一点,我需要一个套信息交互的文档流传递,来让各个工具协作使用。我会按照基本元素,拆分开我的工作,然后去找在各个部分最完美的方式来处理。例如,现在的任务是需要一个 Markdown 编辑器。我不会喜欢一个 Markdown 编辑器成品这个概念,而是把需要的工作拆分开来实现这个工作。首先声明一下,我并不是激进地在此否定现有 Markdown 编辑器的成果,也不是某种 Unix 哲学的原教旨主义,也不是对于集成品的排斥。我试用过市面上大部分的 Markdown 编辑器,各有优势,但是都有不能满足我的地方。


    那么放在实际行动,我将普遍的使用 Markdown 编辑器的工作拆分成这样的几个工作。输入 - 预览 - 输入,输入,一个编辑功能发挥到极致的编辑器,Unix 中推荐编辑器概念,也就是一个纯粹用来编辑的程序。把所有的编辑功能单独拆分,推荐每个人使用自己最喜欢、最习惯的编辑器,来接管一切文档的编辑。可以把自己的编辑器偏好写在一个环境变量里面,所有的编辑相关工作,例如改一个配置文件、修改一个文档,都会根据配置,自动调用你最喜欢的编辑器。在桌面时代,我更喜欢用自己喜欢的编辑器,比如 Sublime Text,来完成我所有的文字输入工作。在我使用习惯当中,它会比其他的更加有效率。我对于快捷键、模式化编辑充满了极致地追求,SublimeText 给予我的,其他完全无法做到。


    我追求更加复杂的移动。我的手在输入过程中不会离开键盘。因此我需要移动操作完全在键盘上,并且高效运作。A 左边的 Caps Lock 被我改成了 Ctrl,因为我需要频繁使用。传统类 Unix 系统上的 ^P,^N,^B,^F 实现上下左右是我需要的。另外的常用 ^A,^E 跳动行首行尾,^K 来删除光标之后所有。此外还需要 Alt 加方向键实现词级别的跳转,中文会分词,英文在空格之内。曾经习惯于命令行时代的 Vim,我需要编辑器的模式化来增强编辑能力,比如以上的移动键加上 Shift,就变成了「移动并选择」。每个操作都是有意义,而且操作的组合变成了意义上的模式操作。我还十分依仗 Sublime Text 许多对于编辑效率极致追求。选择一词、一句、一行、一段。上下文选择同一个符号。分词跳转时候算不算上分割号、算不算上引号...整行的上下移动、整行的复制…跳到行首、跳到行首第一个不是空白的地方…它的操作充满了各种细节,细致入微,熟练使用后很大的使用效率,就好像不凭借鼠标,键盘的一顿花哨的敲击就变得指哪打哪。


    Sublime Text的文本编辑,Word 不能达到这样的效果,也不可能这样做。它的复杂性不允许它在编辑操作占用这么多快捷键,也不允许仅仅将编辑放置于这么高的优先级。但是我追求纯键盘的高效输入时候,必须鼠标辅助的指指点点对我来讲变得累赘。在 Markdown 工作流中,为了编辑效率,我会倾向于用它来编辑 Markdown 文件。经历过了一定的学习曲线,我已经具备了习惯于用它快速编辑的效果。而大多数成品的 Markdown 编辑器可能不会特别在意长期去打磨一套优秀的快捷键,来达到足够高的编辑效率。作为编辑功能达到极致的编辑器,就算是 Sublime Text 有不符合习惯的地方,可以很容易进行定制。比如,可以很轻松的配置为,Command+1 变成,行首加上「#」,也就是 Heading 1 的快捷键;Command+B 变成,选择的内容前后加上「*」,成为 Bold 样式。并且这些可以配置成为「仅仅在打开 md 文件时候生效」。


    预览,纯粹而专注的工具,曾经流行过一些追求双屏同时编辑和预览的Markdown编辑器,有些获得很好的口碑,甚至一度成为流行趋势。但是,我个人认为,那些工具的预览部分功能,没有像Marked那样做到极致。首先科普一下为何预览编辑同步是可行的。文件本身被打开多次都是可行的,只有多个软件进行编辑,共同「写」这个操作可能造成一定的不一致问题。Marked对于一份文件只读,编辑器对于一份文件读写,两者共用内容是安全的。同一个文件的文本流,对于两者是共享的。当分屏打开 Marked 和编辑器啥时候,工作的拆分没有让人觉得让事情变得糟糕,效果是一致的。(当然了,目前介绍的软件组合,还没有实现「同步滚动预览」。但是这个并不是不可能实现,可能只是各个开发者还没这方面开发的意向),但是Marked可能更加像是一个专注于预览本身的工具,有时候做到十分完备。比如,不用再考虑「Markdown 编辑器是否支持 LaTeX 公式」。不管使用什么软件来编辑,预览时候 Marked 就可以配置 MathJax 来解析。


    比如,Marked 对于文本编辑的变动可以实时得知,在预览中标示出修改的部分。(需要说明的是,这一点需要编辑文件「保存」,也就是改动写回了文件,而不是仍然存在于编辑器的缓存中。),比如,Marked 还可以对内容进行拼写检查。这样而言,额外打开一个 Marked 来预览,可以比某些双窗口编辑器实现更多的功能。输出,使用瑞士军刀般的强大工具目前而言最出名的输出软件,可能就是 pandoc。具体 pandoc 多强大,pandoc 官网炫耀般地做了一个示意图。说明一点的就是,很多成品的宣扬自己可以多种格式转换的 Markdown 编辑器,本身就是集成了开源的 pandoc。很长时间内 pandoc 可能是最强大的选择。如果我有复杂格式由 Markdown 转换的必要,我会推荐用 pandoc 来实现。当然了,格式转换在很多软件上可能是主打,或者有时候是需要收费的额外功能。但是拆分这个操作,我可以让自己的格式转换输出做到更加专业。一些额外的 Tips以上的协作关键在于,文本流的共享。如果各自喜欢封闭,那么协作的基础就没有了。


    例如,使用 Ulysses 时候,到底是桌面端编辑器与移动端编辑器利用 iCloud 同步,还是去配置一个外置文件夹,让 Dropbox 同步?我会建议使用 Dropbox 同步,因为这样保证了一个足够的开放的环境让各个软件都有机会介入,而不是各自为自己建立一堵墙。我是希望软件共享一个编辑的地方,一个直接了当的 /Users/somebody/Dropbox/Note而不是一个私有的文件目录:/Users/somebody/Library/Mobile Documents/X5AZV9AG75_OR_OTHER_WEIRD_THINGS~com~soulmen~ulysses3/Documents/Library/AND_OTHER_STRANGE_FILENAME这样才可以保证软件之间的相互协作。(软件自用的 iCloud 存放于硬盘上,但是逻辑上不会给使用,比如无法在 Finder 中访问这个文件夹),输入、预览、输出,这三者都是各自功能中的佼佼者,而他们协作,让我实现了自己所需效率的最大化。单一软件的功能堆砌可能不符合我的胃口,但是开放内容,注重共享,给各个软件一个协作的机会,让每个人去打造属于自己喜爱的使用方式,可以有更广泛的前景。


    移动工具时代,逐渐完善的软件间协作,移动应用通常会被互相隔离,文本流的传递交互一度比较麻烦。iCloud 刚刚推出的时候,我一度认为这是移动文本流交互的新生。但是实际却陷入到了一种困境中。很多的应用将 iCloud 同步仅仅局限于了其移动版和桌面版之间,就像是自己愿意建起一道墙,在文本流可以交互的时代,继续维持工作分割的现状。这样的 iCloud 的使用范围,可能还不如应用自身支持个 Dropbox 之类的网盘来得实在。当然也有例外。有些应用并不会局限于自家的软件当中。例如,Documents 或者 PDF Expert 的文档库,是可以作为一个打开文件的位置来源,像是从 iCloud Drive 中打开一样,直接访问其内在内容。一个很好的例子是 Working Copy。Working Copy 是一个移动版本的git端,可以理解为,程序员的代码库文件。它 clone 下来的 repo,也就是说,下载下来的新版本代码,就是可以作为一个打开文件来源的位置。


    这就颇具文本流传递的味道,因为内容是跨应用而共享的。任何编辑软件打开位置都可以是这个代码库,编辑不局限于不是十分好用的、Working Copy 自带的编辑器,而是可以用任何自己喜欢的App来编辑代码库。例如,iOS 上很类似于 Sublime Text 编辑感受的 GoCoEdit,高效编辑工具带来更强大的编辑效率。编辑完毕之后,Working Copy 自动检测到了被修改的文件的代码变化。软件工程师就可以在 Working Copy 这里做提交修改等操作。编辑器做好编辑一件事,而代码库只需要做好了代码管理这样一件事,二者的协作来让整份工作以最佳的方式来实现。Url Scheme 可以成为另外一个种文档流传递的机制。甚至已经成为了不少工作流软件的实现基础。但是它慢悠悠地转换跳动,也让我很不愿意以这种缓慢方式来强制把工作拆分成工作流,反而去浪费更多额外的时间。比如,一个代表性的操作,桌面端,直接编辑器调用 Python 解释器来执行,计算一下最终结果。而在移动端上,即使可以把 GoCoEdit 编辑的文件传到 Pythonista 上执行看个结果,但是我更愿意忍受一下,只使用 Pythonista 上自带的编辑功能不强的编辑器,而不是拆分每个动作的细节。但是 Url Scheme 前景看起来十分美好。可以说,软件之间协作更加紧密方便了。我期待着它未来在应用上的继续发展,让繁杂的应用变得专注易用,让每个人的工作流构建更加容易。在移动端的时代,每个应用可以专注做好一件事,文本流的传递来完成复杂的工作。


本文来自电脑技术网www.it892.com),转载本文请注明来源.
本文链接:http://www.it892.com/content/system/Unix/20180528/97344.html

推荐阅读
无觅相关文章插件,快速提升流量