10/23/2019 一种支持插件式开发的命令行工具开发模式

0x00 前言

我想你一定没有真正通顺地读一遍本文的标题。

是的,这不重要。

大概只是扫了一眼,抓取到 插件命令行 这样的关键字,所以你点开了这个链接。

不过我相信你一定是一个命令行开发的狂热分子,又或者只是对命令行开发有一点点感兴趣。

无论如何,我非常建议你花几分钟阅读完这一篇,然后我们可以通过其他的方式,继续讨论命令行开发的话题。

0x01 故事的起因: 我开发了太多的命令行工具

一开始只是因为懒(社会进步的动力),把一组经常要执行的命令,用Node开发成一个工具。

得益于Node出色的编程能力,以及丰富的file system API,它非常有效地把我们从繁琐的重复工作中解放出来。

在处理重复工作这件事上,计算机比人类可靠得多。 —— —— 某先哲

于是我们陷入了魔怔。

我们为本地开发流程规范开发了命令行工具。

我们为 持续集成/发布 过程开发了命令行工具。

我们为容器集群管理开发了命令行工具。

我们为我们见到的一切,开发了命令行工具。

渐渐地我们发现事情变得糟糕起来。

命令行工具让我们从重复工作里解放出来,却让我们陷入了重复的命令行开发当中。 —— —— 某先哲

0x10 插件,命令行需要插件

功劳最大的是 James, 他为我们准备了咖啡和小甜点,于是我们总结出目前的困境:

  • 你不可避免地开发好几个独立的命令行工具
	如果我们把上面的几个工具集成到一起,那么它将变得非常臃肿。
	而且把一些不相干的命令全部放在一起,绝对不是个好主意。
  • 我只想专注于我的命令在做什么,而不是一些重复的东西
	我们每开发一个新的工具,不得不做一些重复的内容,以便它看起来像一个完整的工具。
	因为我们要求它只管且漂亮。
	比如帮助信息、用例、格式化输出、参数定义、显示版本、升级。。。
	总之就是很多。
  • 我很喜欢你做的这个功能,但是只能复制你的代码,这样看起来很蠢

    不仅如此。
    有时候,我甚至希望自己做出来这个功能,可以方便地分享给其他成员。

几乎没有任何分歧,我们认为接下来我们要做这样一个东西,它要实现这些特点:

  1. 一个非常出色地完成帮助信息、用例、格式化输出、参数定义、显示版本等重复工作的命令行工具脚手架
  2. 一个只关注命令行为逻辑的开发约定(你只需要写你的功能代码,而不是那些啰嗦的环节)
  3. 命令必须是可以共享、替换、组合、进化的插件单元

平凡与伟大之间的距离,有时只是一杯咖啡。 —— —— 某先哲

0x11 正文开始:现在你可以使用一下 @mohism/cli-wrapper

如果你现在就去浏览 cli-wrapper文档 , 并顺利开发出一个命令行工具,那这将是一个很好的开始。

因为对于 cli-wrapper 的定义:

  • 首先它是一个脚手架,快速生成一个基础功能完善的项目,然后只写一点点你的创意

    cli-wrapper默默地为开发者提供了一系列我们过去开发命令行中被认为是good part的部分。开发者无需去学习怎样引导命令怎样使用鲜明的输出信息怎样存储本地文件怎样去接收交互参数

    你需要的仅仅是,弄清楚你要做的功能,然后写下为数不多的代码

  • 其次,cli-wrapper开发的命令,都可以发布为插件

    这是一个令人兴奋的设计,我们之前的工具里有一些功能,是应该被共享到其他更多的工具里的, 比如 升级本程序问题反馈。(截止到目前,你已经可以在npm上看到 升级本程序

    而现在这一切变成现实。

    更可怕的是,我们把所有的命令都分别发布为插件,然后像乐高积木一样,任意组合出我们需要的命令行工具。

0x0д(overflow) 最后的最后

上面只是介绍了 cli-wrapper 这个项目的起源和一些粗浅的特性。

如果你是一个命令行开发爱好者,我强烈建议你

  1. 移步 cli-wrapper文档 并尝试开发出一个命令行工具
  2. 这个地方提出你宝贵的建议
  3. 或者直接联系我们,交流一下命令行的开发心得。

侧栏导航