外部工具包不要依赖服务的环境变量

1. 前言

虽然这周才过去一天，但自己真的是被bug围住了，果然程序员每天的工作就是在写bug<->解决bug中无限循环。今天遇到了之前给项目写的一个工具包的bug，这个工具包因为需要抽出来给到其他组使用，所以抽成了类工具包的一个小的项目。
在遇到bug之前，这个工具包都很正常的运行，直到遇到bug，这个bug的产生是因为这个工具包是从之前的单体服务中抽取出来的，于是对于一些环境变量的判断，也一起带过来了，而这些就是bug产生的主因。

2. bug模样

这个bug产生的原因是因为我依赖了使用这个工具包的服务的环境变量，这个在遇到bug之前并没有意识到，以为从单体服务中拆出来，这个环境变量一定会通过类似service_name=hello_service ./bin/main这样的命令去启动，这样启动后，服务中的工具包获取环境变量只需要采用os.Getenv("service_name")就可以正确的获取到对应的service_name了。
这个在我们的单体服务中是没有问题的，因为服务发布最后的部署脚本是通过这种方式启动的service_name=hello-service ./bin/main，但能够bug就说明一定存在漏网之鱼，这个漏网之鱼就是docker镜像的启动，这个镜像启动的时候是直接通过./bin/main直接启动了，导致采用此镜像启动的服务就缺失了service_name，于是就造成了这个问题。

func main() {if serviceName := os.Getenv("service_name"); serviceName != "" && serviceName="hello_service" {fmt.Println(serviceName) // if have serviceName and serviceName is hello_service, execute this logic} else {// if not have serviceName or name is not hello_service, do other logics.fmt.Println("env variable not have service_name, please check") }
}

3. 经验

虽然确实是个屁大的bug，但是以为会获取到的变量没有获取到而走到了其他的逻辑，这种往小了说可能影响不大，往大了说这个影响还是很大的。后面自我反思确实不应该能够让工具包依赖环境变量，因为你永远不知道使用者部署在什么样的环境中，而你提供的只是工具的能力。
编写的外部工具包不要依赖服务的环境变量，如果要依赖的话，尽量在获取不到环境变量的时候抛出错误或者给出一些信息提示，防止服务启动之后因为工具包中的环境变量判断失误而导致逻辑失效或者逻辑错误！

4. 小结

遇到bug，就感觉很挫败，但确实是自己没有意识到这个问题，包括在自测以及QA同学测试过程中，都没有意识到这个问题，最后上线虽然没有出问题，但只是暂时的安全，因为docker镜像一旦启动，问题就贯穿其中了。做事的时候还是要思考的全面一些，这个bug属于原则性问题导致的bug，如果自己之前就能够对工具包不要依赖服务环境变量有一个比较清晰的认知，这个bug以及服务中依赖环境变量判断的逻辑就不会这个写了，bug也就自然不存在了。