@DinnyXu #22 @yoloMiss #23 是的，开发制度有很大缺陷，没有人在技术层面管理。 并没有人在意用不用 snapshot

@bthulu #24 这样也可以，就是在新加功能的时候要打两个版本的包

@Niphor #18 在多说一个事，A 之前私自改线上数据库（ A 有线上权限，数据库的权限管理也很乱），几百万的表，增加一个字段，把线上应用卡崩溃了十来分钟。没过多久又私自改库，把线上应用卡崩溃了十来分钟。 实在是没眼看

@Niphor #18 国企要钱没钱，要技术没技术。不打算转正，6 月份准备跑路了，不找事还好说，现在谁刚我我刚谁。研究生全职实习月薪 3.5k ，干的活跟正式员工一样，前段时间还算绩效，连 3.5k 都发不到玩个毛

@Lighfer #15 我没有改任何已有的接口，使 A 需要改动他的代码

@Lighfer #14 是的，我同意你的看法，我的做法就是新增了一个接口，并且本身就是新业务 新增接口，并且增加了 api 层的 jar 的版本号。在这个情况下 A 也不愿意改他的 pom 文件

先全部读到内存，然后把数据分片，除了最后一片都是 100 ，最后有个 50 ，不会漏

参与一下

@dayeye2006199 #3 artifacts repository 是什么，我们有 maven 的私服，微服务的 api 会打包部署到私服

@cppc #4 都是微服务，我们的微服务有 api 和 service ，api 是打成 jar 提供给别人引用的，因为要新增加接口，于是就升级 api 的 jar 包的版本，但是 A 不愿意升级 jar 版本

@passer9527 #5 我觉得不改 jar 版本是很混乱的，毕竟 maven 仓库设计的时候就带有版本号，比如要删除某些 API ， 有些人还没迁移，那么那些人打包的时候就会报错

@buliugu #6 我们没有区分，都是一个 maven 仓库，snapshot 和 release 也是混用

@Lighfer #7 我修改的就是微服务的 API 层，新业务新增加了个接口，打 jar 包升级了版本号，所以我认为他应该引用新的版本号

@Buges #8 是微服务的接口层，

@alexmy #9 是的，新增加功能 A 也不愿意升版本，这样的话 每次增加需求 除了正常升级版本打一个包，还要打一个 1.0 的包（给 A 用，暂时是这样）

@ikas #10 是的，但是 A 不愿意改他的 pom ，我觉得他认为这样需要沟通成本，并且可能会出错，代价比较高。

@Niphor #11 是滴，说的太对了，我想问的就是这样该怎么处理， 我的情况是我是实习生（差不多可以算 2 年开发经验吧） 国企 几十人开发，所以我就无所谓他们怎么搞，他们说啥就是啥

@DinnyXu #12 有私服仓库，但是没有规范约束如果使用，个人也觉得是 A 的问题。不过我没有计较，人家是好几年开发经验的正式工，而我只是实习生

随机一个 x=1, 随机一个 y=1, 于是变成了 1*5+1*6+z*20=1000, 求 z 就好了

https://zhuanlan.zhihu.com/p/101616055

看看这个

看着感觉和 mybatis 的 example 差不多

@zzfer 你努力了 他们也要被迫努力 哈哈哈哈

感觉是你来了，让他们被迫卷起来

试试 nanodet 这个很快

ssh 隧道

第一排第一个福虎生旺 蟹蟹楼主啦
[email protected]

试试向量数据库 milvus

支持一下

挺好，我觉得 minio 也挺好