论一个架构师能有多离谱

说下背景：
有一个公司内的其他项目组提供的自增 id 的接口， 接口是按照场景来自增。
我们项目使用了一个场景，有 3 个服务都在使用这一个场景，线上也已经跑了一段时间了。
这架构师就出了个想法，要把调用自增 id 的服务收拢到一个服务里，另外 2 个服务去调用收拢了自增 id 接口的服务。
结果他测试下来发现怎么从 0 开始自增，然后他就搞个循环把 id 自增到线上最大的 id ，防止 id 冲突，贴下代码给大家看下。


@Override
@ElasticJob(name = "RefreshReqLogIdNumJob", cron = "0 0 0 * * ?")
public void execute(ExecutorContext executorContext) {

@Value("${aicenter.refresh.req.log.num:10000}")
private Integer refreshNUM;

log.info("开始刷新 reqLogNum 信息");
Long newReqLogId = 0L;
for (int i = 0; i < refreshNUM; i++) {
SoaResponse<Long, Void> aiCenterReqLogId = aiSquenceLeafFacade.getAiCenterReqLogId();
newReqLogId = aiCenterReqLogId.getResponseVo();
}
System.out.println("aicenter_new_req_log_id:" + newReqLogId);
log.info("完成刷新 reqLogNum 信息");
}


不敢想象是一个架构师写的代码，review 代码的时候我直接怼他：循环 10000 次调人家接口你也是能想的出来，你调研人家接口支持的能力了吗?你给人家打崩了责任归谁， 完事他问我该怎么办？？？
我给他方案是让她找改接口负责人改下改场景的自增 id ，从 10000 开始就好了，也不会影响人家系统可用性。

完事他很不爽，说：这个不现实 大半夜的改表？

我真无语死，我说你去调研下，这种事情你别想当然，然后就是啪啪打脸，结论是人家可以支持的。而且建议改 id 而不是循环调用人家接口，

更可笑的在后面： 最后发现是他把场景值传错了导致从 0 开始自增。。。。。。


作为一个开发有 10 的架构师了，最基本的风险规避能力都没有，写代码像刚毕业实习生写的，这种传值传错了的低级错误也能犯。 真是不敢恭维，不过也无可奈何，谁让人家是领导内推的呢，而且听说还是领导老家的。 。。。