做工具要有"码德"

本文约 1100 字,阅读需 3 分钟。

最近在搞别的事情,没时间写公众号了,不过遇到值得写的,还是要草草记录一下的。

这周经历了一件比较奇葩的事情,大致时间线如下:

  • 周四下午的时候,发现自己一个脚本使用的maven发布功能有一个奇怪的问题:正常来说,如果我发布的产物版本以-SNAPSHOT结尾,那么maven源的产物名称会替换成一个时间戳。但是在使用内网的maven仓库的时候发现并没有,在晚上多次尝试后,确定本地路径是可以的,只有发布到内网的maven仓库才不会替换成时间戳。

  • 周五晨会同步了这个问题,有位同事比较有经验,沟通中说了一句:有些仓库可能是做了限制。我当时以为是命名有什么要求?就没有深究。

  • 上午找了teg的同事,一开始我截图的时候发布的版本和拉取的版本差了个.0(截图的时候,发布的是1.0.0-SNAPSHOT,拉取的是1.0-SNAPSHOT),该同事一直强调是我没写对,我一直在解释这是我在测试,截图只是示意这个问题,即使写对了版本也拉取不到依赖。

  • 最终,该同事get到了我的核心意思:发布-SNAPSHOT版本,maven却没有替换成时间戳,这样再去拉取-SNAPSHOT版本的时候,就会解析失败,因为解释的是时间戳格式的。

  • 一开始该同事表示公司几千人都在用,怎么都没问题。我直截了当表示,自己怀疑他们改了规则,要换一个maven源验证一下,该同事直接改变口径,表示他们为了避免存储浪费关闭了这个功能,并表示愿意给我打开。

  • 此刻我想起之前的一个仓库,确实是支持的,于是把自己的脚本换了一个远程仓库,发现确实正常了。原来的仓库在对方开了配置之后也正常。

回头看晨会同事那句话,恍然明白他的意思,只是在teg同事承认他们修改SNAPSHOT规则之前确实很难往那个方向想,毕竟这是默认的规则,就这么悄悄改了,还不给使用者任何提示,作为一个开发者,个人感觉很没有"`码德`"。

值得一题的是,按照他们的默认规则,xxx-SNAPSHOT确实不会生成时间戳格式的文件,但是xxxSNAPSHOT仍然会,这基本算是他们的一个bug了,因为gradle只有版本是-SNAPSHOT才会去拉时间戳格式的文件,所以没有-之后,会直接按照版本名去拉,他们却换成了时间戳,也会发生报错。

总的来说,最让我气氛的是,作为一个开发,设计一个工具,没有基本的同理心和原则,建议"`耗子尾汁`"。

还有一个就是沟通的问题,我本来有两个机会提前解脱,一是同事跟我讲的时候,我没有继续追问,因为有点反常识,事后看才恍然大悟;二是反馈问题的时候,自己描述问题没有十分准确,过于随意,反而花费了更多的时间去解释纠正。

以上。

总阅读量次。