没房子娃咋上学？

请先定义“强类型”

luban ，可以支持复杂类型、关联 ID 和分表，展示界面还是依赖 excel ，但可以支持 csv 或者 json ，能用文本的 diff 工具（ xlsx 文件也可以用 beyond compare 这类工具去看差异），资源类型的配置有一个内建的校验器可以配置校验，但是想要实现自动完成/提示/搜索需要自己针对配表工具去开发。

多人协作这块，没有银弹，比较好的做法还是分模块不同的模块不同的人去处理，避免多人编辑同样的文件，这块 luban 的支持也比较好。

---

以上是 luban 的优点，缺点也很突出，类型系统对策划同学来说过于复杂，配置语法杂乱，扩展性没有它自称得那么好，对配置本身的编辑体验没有帮助。

二次开发的话，可以在 luban 的类型系统的基础上，用 Excel-DNA 写一些扩展，加强编辑体验，不过肯定需要投入人力物力去做这个事才能有比较好的结果。

客餐厅无主灯，卧室没做是不想压层高。做了还是效果好一些。

---
现在想法也有变化，觉得灯具满足照明的需求就可以了。

统一就高效吗？你喜欢的工具别人使用起来就一定效率高吗？
---

API 工具这种，我推荐在使用 JetBrains 家的各位使用.http 文件，可以放在 git 仓库里同步给所有人，也很适合 AI 去生成。

明显是流程的问题，code review 应该小步快跑，每个 commit 的内容少一些，反馈快一些，这样就不会改了一大堆全部被推翻。review 过了之后才会接受这个 merge ，才能进入功能测试流程呀，这样就不会出现产品上线等你这个 review 的修复了。

娃需要奶的情况下，带出去自驾玩会不会折磨的成分大于玩啊？

双方是对角线，那先手一方把棋子移动到尽头卡死对方的象不就赢了？

1. 把每天 5000 人访问这个指标转换为可以通过压测量化的指标：请求接口分布、每秒请求数、响应延时、并发连接数、数据库的 TPS 、数据库的连接数，一般认为在预期载荷的情况下，内存/CPU 等核心硬件资源使用率在安全线（ 50%）是符合预期的；
2. 编写施压端方案，这方面的工具或者方法就很多了，不同的业务场景适用的东西也不一样；
3. 确保施压端和服务端的可观测性，服务端重点是影响服务的可用性和稳定性的指标，施压端终点是影响用户体验的指标，这样才能产出有说服力的报告；
4. 执行压测，分析性能瓶颈，解决问题，直到压测表现符合预期

根据你的描述，很明显是业务逻辑的问题，包括但不仅限于死锁、死循环、资源争用、上游 API 的问题。

Java 没有默认参数、关键字参数这些功能，对命名参数也没有啥需求啊。。

因为 0 warning 真的不是一个简单的目标，也不是写代码的人都自觉就能达到目标。
不同的 IDE/插件，不同的 lint 工具，不同人的设置都会带来不同的 warn ，首先就得拉平所有人的工具集（短期内会损失工作效率）。
每个人都有自己的代码口味，对不同的规则有不同的取向，你们团队能不能实现一个“最大公约数”。
需要在 CI/CD 流程里配置 lint 检查，而且得和 IDE 一样（有很多规则的细微差别需要设置和琢磨，同样的规则在不同的语法解析器上甚至会得到不同的结果，这个并不是一个简单活）。
针对遗留代码，需要配置只检查修改的部分（你的 VCS 是不是支持，lint 工具能不能支持）
有些小团队人员变动频繁，这一套能不能一以贯之，能不能落实给每个新成员。

游戏技术栈地域性很强，不同的公司/品类/团队往往也有自己的一些小巧思，但是整体上还是没办法把很多 web 领域的前沿实践给落地，有水土不服的原因也有研发团队求稳守旧的原因。

脚手架的话，JHipster ，用 JDL 做数据建模在某些领域有奇效。

@Xheldon 手感我觉得还行，小盒子也比较方便可以放一些拔键器啥的，旋钮在一些时间轴的编辑之类的场景有奇效，整体我觉得还不错。

我的不松动，第一代的

会打架。
VSCode 不太清楚，JetBrains 家是不让这么搞的。

买换电池的别买充电的