阿狗工具

随着工作经验的积累，5年来也造了不少轮子，手头上也积攒了一系列自己开发的小程序等，各自都很独立，基本上都是业务相关性很强、或者实用性很强的，现在在考虑如何整合这些小程序。于是便有了下面的这番思考：

一、 程序同时支持参数从 本地命令行输入 、 本地配置文件输入 和 grpc中心服务输入 ，并配备默认值和优先级。

1. 默认值的最佳形式就是无参数执行，普通人点击即用，扩大用户群体；（懂程序的人，才去传参配置程序，使用程序的高阶功能。）这意味着，每个小程序都应当有默认参数，这个默认参数应当是最常用的参数。

2. 由于参数输入一共存在以上描述的3种形式，但程序只需要选定一种形式入参，因此 优先级 也是一种变相的默认行为，[2023-06-30更新]界面配置>命令行传参优先级>本地配置文件传参优先级>大于grpc中心服务传参优先级。之所以这么排序，是考虑到命令行传参需要的手动输入成本大于本地配置文件输入成本（原因很简单：本地配置文件可以只一次编写，下次执行就不用配置了；命令行传参形式，每次都得写参数，复用性差，所以花时间多）；[2023-06-30更新]界面配置需要等待界面配置程序运行起来之后再配置，相比手动输入花的代价更大，英雌优先级最大。grpc中心服务传参，更倾向于完全的自动化，较少辨别程序当前所在的执行环境（相比于本地配置文件传参的区别，就好比，一个参数存储在云端，一个参数存储在本地）。

3. [2023-06-30更新]界面配置，这种形式的传参是为了将用户的使用门槛降到最低的同时，提供一定的可配置性。

4. 本地命令行输入，这种形式的传参就是手动输入参数名和参数值。包括从cmd、shell、界面等多种交互形式。

5. 本地配置文件，这种形式的传参需要统一配置文件的默认路径（当然了，也应当支持自定义配置文件的路径）。

6. [2023-06-04更新]环境变量，这种形式的传参类似于“本地配置文件配置”，但可能存在环境变量冲突的问题，因此，优先级应当低于“本地配置文件配置”，

7. grpc中心服务，这里有个接口规范选型的问题，喜欢restful的完全可以用restful接口规范来替代我选的grpc。我之所以选择grpc完全处于自己对于go语言的爱好，和喜欢grpc 这个技术。目标是：对外统一小程序的访问接口。

二、附加

1. 程序应当记录除了默认值方式配置的之外的最终的配置是由谁设置的，比如key1由grpc配置的，key2是由本地配置文件配置的，key3是由本地命令行配置的

2. 配置程序的初始配置（默认、命令行、本地配置、环境变量、grpc X 开、关）默认通过环境变量配置，默认：（启用默认、启用命令、启用本地配置、启用环境变量、关闭grpc）。

3. 配置的key 和value为了简化，都只使用字符串类型