有关工程效率的一些思考
最近工作中花了很多时间处理了团队的devops和版本控制协作的问题，有了一些不成熟的想法，正好也是来到公司刚好一年的时间，借这个机会沉淀一下。
使用键盘，而非UI
我自己使用过一年的Linux作为主力开发环境，同时也有3年左右的Linux服务器维护的经历。这些经历让我更加习惯Shell环境，因此我也有一个习惯，任何开发环境，我一定会使用Shell辅助我开发，同时使用IDE等工具时，总是习惯尽可能用其快捷键位进行操作。
很有意思的是，我在大学期间认识的一部分朋友，大都也有这样类似的习惯。然而现在我身边还是有不少人习惯于用UI的交互方式进行日常开发，而用UI的结果往往是花费了更多时间去处理交互问题，这些交互问题浪费的时间最后积少成多拖慢了整个开发效率。
Shell和UI的本质
Shell的本质其实是一个REPL(Read-Evaluate-Print-Loop)，当我们使用Shell操作时，本身就是把自己的操作用文本线性地进行记录
而我们绝大部分时候使用的UI交互工具，往往都是在Shell命令基础上做了层UI交互的封装。基于此我提出一个自己的论断，欢迎打脸:
任何UI工具的功能必然是某一个或多个Shell命令对应功能的子集，并且这个Shell命令必然早于UI工具诞生
我也问过他们为什么更加喜欢用UI(鼠标)来完成日常的开发任务，原因无外乎:
- UI更直观
- UI更易懂，直接用UI比起用键盘更”快”
但实际果真如此吗？
UI交互真的直观吗
我想到近日有很多时间，我都在帮助我的同事解决他们遇到的各种Git问题。但遇到的情况大都是:
我用了UI上的XXX按钮，点了几个选择框后发现后续的功能没办法继续用了
同时附上一些截图到我的企业IM，问我为什么。
说实话这样我也不知道为什么会出现这个问题。
那假如我们换种描述方式呢？
我执行git merge –no-ff xxx && git pull -r后，我的merge commit不见了，这是为什么呢？
在我看来，下面这种描述是更容易理解和定位问题的，这也是我一直热衷于使用Shell操作的原因。
UI交互相比Shell虽然优化了展示信息的方式，但也增加了你理解和另一个人理解的难度，这有几个原因：
- UI封装后，部分描述会跟其对应Shell的描述不一致
- UI封装后为了尽可能地展示信息，会将信息和选项罗列，换句话说，你需要同时理解这个UI上的所有信息
UI本身不是文本，其表述方式往往是模糊不清的(如某个确定按钮, 某个选项卡等)，这样就只能用图片等方式辅助描述。因此，当你在UI上操作出现问题时，他需要首先理解这个UI所展示的上下文环境后，才能明白你要发生了什么。如果这个UI本身的描述和其对应的Shell不一致，那么你们就会面临一个黑盒，这个黑盒是需要额外的手段才能破解的(如此UI工具的帮助文档等)
所以，UI的直观，只是单纯的在画面上的直观，但是比起工程上要求的精准，UI是绝对不合格的。工程上要求的直观，应该是正确的直观。
UI交互真的比键盘交互快吗
很多人觉得鼠标点击是很快的一件事情，但实际上也不是这样。在一个复杂的UI环境，找到一个功能往往需要非常深的操作路径才能找到。而鼠标本身是一个定位精确度差的硬件，远不如键盘这样按下哪个键就来哪个键精准，操作鼠标还需要更多时间去定位，因此操作上显然还是键盘来的更加精准和快捷。
我们该如何培养使用键盘的意识
很多时候我们的困境是我们并不知道有更好的方式，所以只能保持现状。我在这里给一些如何培养自己多使用键盘提升开发效率的建议，总的来说就是一点:
DRY(Don’t Repeat Yourself) && Search
当你发现有一个UI操作范式你在反复使用时，不妨试着把它转换为一个键盘操作或者Shell命令，然后去使用这个你转换的结果；如果你发现这个操作范式可以被优化，试着去Google一下，往往会有很多人会有类似的疑问，而他们也会给你一个高效的操作方式。大家都是很懒的，没人愿意反复一个枯燥的点点点操作。