quick-setup如何简化shell脚本管理

type

status

date

slug

summary

shell脚本管理的痛点

三大痛点：难以结构化设计、难维护、难复用。其中结构化设计是根本，维护和复用是表象。

为什么难以进行结构化设计？shell脚本语法简单，解释器足够轻量足够简单，这是由它的主要应用场景决定的。

但还是有极少的场景需要大型脚本，这类脚本组织就会出现两个极端：一是单个大文件靠语法做结构，诸如某大神的8000行大脚本；另一个是拆成很多小文件，用目录进行管理，然后各种嵌套，这就需要自己有自己的一套文件管理和引用规范。无论哪种方式，缺少语法和解释器的功能支持，都很难简化结构设计。

正因为难结构化设计，所以难维护，难复用。

设想：一个8000行的文件，想修改某个功能参数找都得找半天，别说维护了，而里面的功能点也无法被别人复用（要么别人引用整个大文件，里面各种参数规则路由到功能部分，不会有人能够记住这些参数规则，包括作者自己）。而另外一种场景：拆成很多小文件，增强复用能力，但基于shell语法进行组合，在这种弱语法和弱解释器的环境下，需要很多复杂的文件管理规范和代码开销，增加大量不必要的心智负担，维护起来也会很困难。

大型脚本的拆解方案

我们从8000行大脚本的角度出发，如果要做结构化设计，应该如何抽象？

功能脚本

功能脚本是指脚本里面针对特定目的的自动化操作序列，通常来说就是某个连续的代码片段。比如说：安装配置docker，切换更新源，测试当前环境可用的代理，等等。

这些功能脚本其实就是整个脚本的核心，从场景需求出发，选择哪些功能解决场景问题。功能脚本之间通常是独立的代码段，少有需要关联的地方。为了方便维护和复用，每个功能脚本都做成独立的脚本文件，这样针对功能点的维护就少了很多心智负担。

框架脚本

完整的脚本除去所有功能脚本，剩下的就是框架了，不提供实质解决应用场景的功能，而是负责组织功能脚本，包括处理逻辑、参数获取、终端显示、错误处理等等。

框架脚本可以做得很简单，依次引入功能脚本就行了，也可以做得很负责，包含复杂的参数设置和处理逻辑，以及炫酷的消息提示，完全根据设计者的喜好。

文件组织

剩下的工作，就是如何将功能脚本和框架脚本分类，用文件夹组织起来，实现维护和复用的需求。在需要应用的时候，复制框架脚本，然后在里面引入需要的功能脚本，组织成最终的应用脚本。

这只是一种拆解方案，每个人根据自己的口味，可以拆得更细，也可以通过复杂的逻辑和参数来做成通用的应用脚本。但个人比较喜欢更少的分类，以及更简单清晰的逻辑。这些工作，纯shell脚本加文件管理就能够实现，不需要任何额外的软件支持。

quick-setup的方案

quick-setup就是采用上述的脚本管理方案，将脚本抽象为功能脚本和框架脚本，最终针对应用场景的应用脚本，是复制框架脚本，在里面组装不同的功能脚本实现的。只是通过quick-setup工具，能够很方便地达到这种效果，减少了很多工作量，而且带来了更多方案优化的可能性。

组件和组件库

功能脚本是最小的装配单位，在功能脚本的文件组织结构上，quick-setup只做了两级分类：组件和组件库。

组件包含一个或者任意个功能脚本，把相关的一系列脚本放在一个文件夹下面，那么这个文件夹就可以叫做组件。

比如与docker相关的功能脚本有：安装脚本、dockhub代理测试脚本、卸载脚本、配置脚本等。这些可以归为一类，都放在一个文件夹下面，叫做docker脚本组件。也可以是选择关系，比如同样是清理硬盘空间的操作，A脚本是针对A产品的，B脚本是针对B产品的，那么可以把他们放在一个文件夹下，叫做清理硬盘空间脚本组件。组件内脚本可以是任意关系，全凭个人兴趣进行分类。

组件库则是由任意数目组件组成的文件夹，以组件库为单位进行Git版本管理。

功能脚本的文件组织，就是组件和组件库这两个简单概念，每个人负责维护自己的组件库即可，复用则是以功能脚本为单位进行复用。

框架模板和菜单（配置文件）

框架模板就是框架脚本的模板化，采用golang template语法编写。正如前文介绍，框架脚本是做得简单还是复杂，全凭个人口味，不影响最终应用脚本的实际功能。有的人就是喜欢玩花活，而懒得折腾的，可以直接用别人的框架模板。

有了组件库和框架模板后，怎么生成最终的应用脚本呢？

这就需要“菜单”配置文件，采用yaml语法编写，主要包含面向应用场景的定制信息：使用那些组件库，使用哪个框架模板，使用哪些功能脚本，这些功能脚本的装配顺序是什么，这些功能脚本里面的参数修改成哪些值等等。

对于面向应用场景的开发者来说，其实只需要关注配置文件的编写即可，因为组件库和框架模板都可以用别人的。就像客户点菜一样，在“菜单”上勾出自己需要的菜品，下单即可。

qs命令（应用脚本生成）

qs命令即quick-setup命令的缩写，就是用来把“菜单”上设置的参数替换功能脚本里面的默认参数，然后依照“菜单”上功能脚本的组装顺序，装配到框架模板里面，最后生成最终面向场景的应用脚本。

这种生成机制带来了一个好处，就是可以替代某些面向通用场景脚本的复杂逻辑和控制参数设置。（在脚本里面写命令的参数控制逻辑本身就是一件让人很痛苦的事情）

而最终的使用者，运行应用脚本即可完成面向场景的自动化操作目标。

总结

shell脚本就像软件自动化的最后一公里，因为不熟悉Linux系统或者各类软件的部署配置特性，很多朋友就是卡在这最后一公里上无法进行到软件应用的下一步。虽然shell脚本属于软件自动化的二等公民，只是各类软件自身设计的自动化操作补充，但也不乏有很多热心的工程师喜欢写脚本替大家解决这最后一公里的自动化操作问题。

quick-setup shell脚本管理方案除了简化大量脚本的管理难度外，还有一个好处，就是简化分工合作：组件开发工程师的角色维护组件库，框架开发工程师的角色维护框架模板，集成工程师的角色针对场景编写菜单配置文件，最终用户使用qs命令完成应用脚本的生成。

假如有很多人参与维护和分享自己的组件库，那么在共享资源的环境下，有可能给终端运维节约大量时间和精力。