随想一篇，不是技术总结，饭后闲聊。
程序故事
有一个前端组件一直在升级迭代，引入该组件的地方特别多，我需要知道各个版本号组件的使用情况。前端工程师给的方案是在package.json增加了version字段，接口调用的时候，会上报该version作为该组件的版本号。
但是在进行简单的 bugfix 的时候，大家总是忘记了升级这个version字段。导致上报的版本号总是不对，所以一直期望前端开发去解决这个问题，开发人员流动性很大，断断续续持续迭代了3年，这个问题也一直没得到解决。
期间有一个人给我说解决了，方案是通过在 commit 的时候通过一个叫
husky做校验。如果不运行前端工程，git 直接提交就能跳过这个校验了。
所以最好的方案，还是在编译的时候进行拦截，这样就不能对外发布了。最近又换了新人，我交代其弄下，但是给我得反馈是大半天的投入也无产出。所以我晚上尝试自己弄下，虽然我这种 jquery 时代的前段对现在的 node 生态的开发不是很了解，但是我觉得这个问题应该也不会怎么复杂。
大概研究了下 node 工程编译可以自定义命令，所以我把原来package.json的scripts命令稍作修改
{
"scripts": {
+ "versionCheck": "node versionCheck.js",
"lint": "npx eslint --ext .js,.ts,.tsx,.jsx src",
"reboot": "rm -rf node_modules & tnpm i",
"dev": "ice-scripts dev --analyzer",
- "build": "ice-scripts build"
+ "build": "npm run versionCheck && ice-scripts build"
}
}- 发现编译的时候，环境变量中有当前集成分支的名字。
process.env - 进程退出，除了
0，其他均为不通过。process.exit
const pkg = require("./package.json");
//比如 xxx_releases_2022091321053636_xxx/1.1.5
var branchName = process.env.BUILD_GIT_BRANCH;
if (branchName == undefined) {
// 本地环境跳过检查，我为测试到这，因为我本地没 node 环境
process.exit(0);
}
var gitVersion = branchName.split("/")[1]; // 1.1.5
var pkgVersion = JSON.stringify(pkg.version).replace('"', "");
if (pkgVersion !== gitVersion) {
console.log("\033[40;31mpackage.json: " + pkgVersion + " !== " + gitVersion+ "\033[0m\n");
console.log("\033[40;31mcdn version: " + gitVersion+ "\033[0m\n");
console.log("\033[40;31m版本号检查不通过，请修改 package.json 里面的版本再提交\033[0m\n");
process.exit(1);
}其实整体耗费的时间也就是下班到家弄了2个多小时。
但是前端同学经常因为我发现上班的版本号不对，而要求再次升级一个版本号。就没人去思考优化下这个点么？
想到自己
回想工作这些年，慢慢养成了个习惯，有点像方文山头脑中闪出什么好的歌词就记录下来，有一些小的可优化的点，都会先给自己记录一个任务。
有空的时候就会去实现，看到工程变得稳定、产品更完善、体验更好、系统更健壮、性能更好。（虽然很多时候适得其反搞出一些问题，也会遭受一些冷嘲热讽，我没太在意）公司很多时候后台的开发其实产品的参与是很少的，开发自己的发挥居多，我也经常和我下面的小伙伴分享自己的一些优化逻辑和想法。
也经常告诉代价，不忙的时候希望大家能给我主动提：“最近不忙，你看我能不能把某某地方优化下增强下？” 虽然一直在强调，但是几乎是 0 反馈的。
工作不可能一直都是忙碌的，如果周报里没有内容，在当下降本增效的大环境下，可能是很危险的一件事。目前只能是我来去安排填充这些空档。
另外一方面，可能我这个习惯对于一个工作3~5年的人是一个好习惯，但是对于我一个10年老兵，主管的评价却是太注重细节，没有大局观。更高层面的自驱可能就不是这么浅层次的思考、优化、完善了，可能需要更缜密的计划和更长时间的规划和实施，后面自己也需要更主动的去尝试突破，比如一个产品维度去更全面的思考聚焦，然后结合外部的合作。