很多 web 前端开发者们 把自己定位成了 “用户体验工程师”，
这是因为前后端岗位的划分，使得软件架构分成了两个部分：界面 和 逻辑。
逻辑 关注的是，软件系统如何提供功能。
界面 关注的是，“人” 如何使用 “软件系统” 提供的功能。
前端开发的工作，大部分都是跟 “界面” 相关的，但并仅不限于 图形用户界面（GUI）。
命令行（CLI） 和 应用程序接口（API），等等，也是界面。
GUI 对于普通老百姓而言，使用成本更低，以后没准还会出现 AR/VR 界面。
但如果用户是 开发者 的话，CLI/API 也许是更好的选择。
本文就分析一下，面向开发者提供的软件服务，有哪些容易遗漏的体验优化点。
CLI/API
开发者 跟 普通老百姓 的 用户画像 是不一样的，
开发者会写代码，而老百姓则不一定。
所以，图形界面（GUI）的方式 也许 不是最优解。
开发者可以敲几行代码 调用 某个功能，而不必在界面上用鼠标操作。
这种 “调用” 天生具有可组合性，并且管理 “代码” 正是开发者们所擅长的。
很多优秀的开源 web 系统，除了 GUI 之外，还包含了不少 CLI，
比如，gitlab/gerrit/jenkins 等等。
我们在做一个软件系统的时候，优先从 CLI 入手，我觉得是一个好办法，
它可以避免我们把精力过早的聚焦在 图形界面 上。
A good system can't have a weak command language.
IDE plugin
开发者们 日常打交道最多的工具就是 IDE 了，
要想提升 开发体验，应该抓住 IDE 这一常用的 “用户端”。
很多 IDE/编辑器 都具备扩展功能（plugin），
然而，编写常用编辑器的 扩展，却仍然不是主流的软件功能的提供方式。
常规的做法只是给软件系统包装一个 GUI 界面。
开发者们 要想使用软件功能，需要打开这个 GUI 界面才可以。
这就有了一种割裂感，
尤其是完成不同功能的时候，只能去各个系统 GUI 中跳来跳去。
IDE 插件可以很好的串联起这些功能，但前提是各个系统已具备了 CLI 调用方式。
GNU Emacs is a LISP operating system disguised as a text editor.
浏览器插件
几年前我们做网络编程时候，经常区分 C/S 和 B/S 两种开发模式，
浏览器端开发 属于后者（B/S），但现在不怎么提及了。
大部分前端开发的工作，都受限于浏览器环境中，不会考虑对浏览器本身做点什么。
今年九月份，Browser Market Share Worldwide 有份报告指出，
Chrome 市场占有率已经达到了 64%。
不像 C 端浏览器那样发散，开发环境中的浏览器，是更可控的。
所以，我们可以假设 开发者们 使用了一致的 Chrome 与系统进行交互。
这样一来 Chrome 插件能起到的作用，就不容忽视了。
不像浏览器环境那样，Chrome 插件完全是 C/S 模式下对 Client 进行扩展。
它有多种多样的办法与本地进程通信，这就大大扩充了站点的能力范围。
结语
以上我们的分析思路 是挖掘所有针对 开发者 友好的 “端” 上场景。
开发者们日常接触到的 “端” 是与老百姓不同的，
甚至跟普通公司内部的 其他用户 也是不同的。
GUI（常规的图形界面端），CLI/API（terminal 端），
IDE plugin（开发工具端），浏览器插件（Chrome 端），
这些端共同形成了一个整体 —— 开发者界面。
因此，不同的 “端” 上应用，只是 “开发者界面” 的具体形态罢了。
合理的打通各端，可以极大的加强软件系统的可交互性。
未来 移动办公/物联网 也会兴起，这就意味着新 “端” 出现。
比如我们完全可以在 移动端 处理审批，用 手环/手表 接到系统的反馈。
随着开发者人数越来越多，开发体验 能带来的价值会越来越大。
按十小时工作制来算，每人每天节省一小时，就能省出 10% 的人力成本。
技亦灵怪矣哉。