我帮你点了上升
我非常认同你的观点，不认同这个技术组长，他应该按照你的方案做而不是指出你提出方案的漏洞，
下属就是要执行上级的方案哪怕是错的，这样才能避免这场冲突，确实是你的下属不够聪明。
我要是在现场我一定喷他，技术副总下次给客户演示的时候出现了新的漏洞跟他就没关系了他就是不明白。

@drymonfidelia #28 在测试环境删掉索引不是为了测试 EXPLAIN 是否能命中索引嘛。。。 跟快不快又啥关系啊。。

可能确实是你认知问题。。
app 本身是需要兼容老版本的，你一个接口返回太多东西以后怎么兼容，后端做版本判断？

已经要到卖树的程度了吗

8 年经验面什么级别啊？ 资深开发？ 还是专家

过于简洁了吧

@drymonfidelia #25

当然是在测试环境测试啊 锅锅。。。 你直接干生产啊。

你这排名也到不了前面，服务器成本都赚不回来。

当然是留言板了 https://i.imgur.com/agAJ0Rd.png

猜测问题来自于滥用联合索引导致的
你可以把整个表的除唯一索引之外的联合索引删掉，按照单字段索引创建问题应该可以顺利解决。

这种相当于全部重构，整体流程不是这样的，这种项目对公司没有产出，现有功能是正常运行的，随时可能停止。
类似的活我干过，主要是为了性能优化，原来项目也是类似的需求，只不过原始版本太老了，性能差。
1.先用写一个代理工具，先收集一下请求流量的多少和接口的响应速度以及请求的高低峰。
2.了解现有项目接口的串行调用逻辑，按照业务系统操作流形成接口脑图同时制定重构计划（方便测试和定位问题）。
3.了解老系统用了哪些中间件，比如缓存/阿波罗/队列消费之类的，这里需要做好迁移方案尽量一起动。
4.根据因为前期有了代理工具可以收集入参出参可以进行数据对比检查和测试。
5.上线后的调用逻辑是
客户端请求 -> springboot 重构系统 -> 老系统
未重构的接口走老系统返回的数据直接返回
重构的上线前期对比自己的数据结果和老系统的结果是否一致，一致正常返回，不一致返回老系统的值并告警排查，稳定一段时间后减少老系统的请求转发（也可以等项目整体上线全部稳定以后再整体切换）。

整体切换对中间件的依赖连贯性更好，但是会产生双倍流量负载，包括数据库和缓存需要考虑扩容

这是什么机霸 App 啊 https://i.imgur.com/agAJ0Rd.png

到底是什么理由必须买这垃圾东西啊。。。

@craftx #6 企查查看下股权比例即可，这是入职之前能了解的。

@craftx #5 入股多少看你的业务需要多少领域的合伙人和初始资金比例以及融资预估情况预留多少给稀释。
有一个前提是不管怎么样都不存在纯技术入股 资源入股，必须真金白银拿钱出来。
拿钱就有话语权，不然就是扯淡。