有时候突然会把几件不搭边的事情联系起来，竟然能够找到一些共通的地方。我在琢磨最近的几件事情的时候，脑海里不由得浮现出几个字：“半成品”
我是蛮反感工作中的半成品的，说有吧，使用效果一般，说没有吧，也投入了一些时间，概括一下就是投入和产出严重不成正比。
另外一类情况更偏于主观，做任务的人感觉一切都妥当了，但是验收的时候，发现不是设计理念的问题就是任务的精细度上面比较粗糙，如果本着差不多就行的态度其实也能过去，但是显然以后的事情谁能说的了，真要用到的时候，代码逻辑都忘差不多了，重新调试改动，这个工作如果前期能稍微充分难一些，也不会有很多返工。
所以在这件事情上面，我发现以前对自己，对团队成员的要求有些松散，以至于稍微带点要求和质量标准，就会感到大家有些吃力，其实对于职业发展来说是有害的，从0到1的构建主要为了效率和快速迭代，可能在一些质量标准上面可以打折扣，过度要求会有些刻薄，但是守江山更难，技术维护也是，都希望时间的边际成本能够越来越低，在已有的基础上构建和改进，那得下真功夫。
我举一个最近和半成品对抗的小例子，也是鞭策自己能够继续按照既定的想法往前走。
这是数据库软件的安装部署的例子，按理说这是很简单的一件事情了，如果要抠命令，基本都是个位数的命令，但是有一些需要额外补充的地方。
1)不同版本的参数文件，比如环境有5.5,5.6,5.7,8.0等，如何更好的支持多个版本
2)初始化用户和权限，根据业务特点有些预置的用户需要创建，配置相应的权限，不同版本下的语法格式都有差异，还有密码插件相关影响。
3)安装部署通常是和监控报警，备份恢复相关的，这些工作是不是可以作为可选项
4)单机多实例和service部署模式还是有一定的差别，如何平滑适配
5) 新增数据库版本支持，已有的接口和部署方式如何适配
MySQL 8.0已经推出了几年，也在内部做了一些测试和总结，而且早期我们直接入主MySQL 5.7版本，也算是积累了3年多的经验，所以果断决定新业务都按照MySQL 8.0的基线来推广。
已有的脚本都好几年没动过了，经过一番需求分析，发现这是一个半成品，主要原因如下：
1)脚本目前直接使用的场景很少，去年团队下大功夫开发的一键部署，因为流程长而显得比较脆弱，已经和这个功能有了很大的差别
2)脚本执行不稳定，因为之前的脚本设计中采用了很多分散的脚本，也就意味着是脚本调脚本的思路，逻辑相对比较庞大，混杂
3)新增8.0的功能，脚本需要整体改动，涉及的面比较大
4)目前脚本里面也存在一些细小的问题，一直没有修复
对于这些问题，我做了如下的一些事情。
1)备份脚本内容后，我开始删除一些过时的逻辑检查代码，去掉一些没有使用场景的逻辑和相关脚本
2)将多个脚本整合为1个，重新组织了脚本关联依赖
3)将依赖的参数文件模板和脚本模板都上传到配置中心里面，在脚本里面会用命令方式提取
4)把原来文件夹的脚本结构重构为一个单一的脚本
5)修改前端的配置，去掉冗余无效的配置项，修改调用逻辑
6)团队内部做了简单演示，团队提了一些改进建议，修正后发布
这些工作经过了很多的测试和整理之后，在不同版本中也做了相关的测试和验证。也算是让原本半成品的状态变为可用，而且是最新版本，接下来要做几件更细致的事情。
1)安装部署的时间目前在30秒以内，涉及数据字典的初始化，目前使用了一刀切的逻辑，后台sleep 20秒，保证这个过程的初始化时间足够，其实可以更加动态友好一些，做动态监测
2)考虑使用基于自制yum的配置方式，把一些固化的参数，命令等方式重新打包构建，这样后续就可以使用yum的方式快速部署了。
3)把软件安装和部署整合起来，提供多版本的软件支持和安装，比如8.0.19,8.0.20
4)使用基于压缩镜像的模式，可以把一个数据库压缩到极小容量，需要时直接解压启动即可，经过之前的测试，一个可用的数据库镜像大概在2M左右，解压后在2G~3G左右(涉及ibdata，reod等文件的容量)
本文转载自微信公众号「杨建荣的学习笔记」，可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。
