这个歧视做为个体没办法改变，可以吐槽，但没什么意义。希望以后会变好吧

对于 Metaspace 没有设置 MaxMetaspaceSize 值，导致使用过多，本次问题是因为还没触发 FGC，就 OOM 了。
参考：http://lovestblog.cn/blog/2016/10/29/metaspace/

是的，我在 TCL 呀

1. JMV 内存在 02 段落写清楚了，大概使用了 561MB，还没达到 GC 的条件，所以没继续看；

2. Metaspace 正常情况下，本来就不会被 GC 回收，GC 回收的是堆栈空间；

3. 在解决方案中有提到减少业务的处理数据量，分批处理，减少反射的集中使用。其实在日常的业务代码中，也不提供过多的使用反射，对类的安全性也是个入侵。

4.因为很多代码处理逻辑的底层，使用了反射（包括上面提到的 spring 的 BeanUtils 的拷贝对象，json 的序列化） --没说 BeanUtils 处理 Json，而是说这两个都用到了反射；

感谢讨论。

接口文档完整 --这个基础就有很多团队做不到的。

在有完善的前置条件下，接口自动化当然适合开展，性价比也最高。

交付类的项目，给到工厂部署后，基本上就不会再动了，除非业务的工艺流程发生变化。

而且维护也交付给工厂的 IT 部门了，所以不太适合花时间去搞自动化。

水不水的，大家看着就好，不同水平的人本来知识结构就不一样。可能你懂的多，我的文章不就水了嘛。

不过确实是公众号同步过来的。

流量回放的技术成本更高，更加依赖基础设施。

测试左移其实也是为了更好的做测试，最基本的，左移能够保证你的测试用例是相对更准确和靠谱的。

左移不影响你测试能力的提升。有的人从技术层面去提升，有的人从业务的角度出发。在当下的互联网环境中，可能对技术的提升需求更显著。但是在实业或者制造业，一个慢懂 MES 或者 WMS 业务流的测试，价值远高于会技术的测试。笔者现在就在实业，比较清楚业务的价值。

所以不是所有人都适合 Leader 的，如果只是传声筒的作用，要他干什么。

活可以接，但该出的声音还是得出，能怼的还是得好好说

理论肯定是象和简化了部分场景，大方向上应该是没什么问题的。

缺人的情况下，更得注意做事方法，有些成本还是得花的，比如左移的时间、和开发对齐的时间，主动点。

无非是把时间花在提测前还是提测后。

市场越不好，越需要左移，而不是以 BUG 数来保命，本身就不靠谱

所以为什么要和他们计较呢，对个人来说，左移可以锻炼到更多的技能，还是非常有必要的

这个是典型的负载机性能问题存在问题，导致你看上去并发压力升高，但是到达服务器的请求数并没有增加。你看网络请求并没有增加哟。

已经在团队内部多次实践，文章中也有具体的案例了。

需要有安全的环境，还有适应的引导和鼓励，回顾会的一些方法可以用用

是的，很多事在做决策前，都可以用这种思路做下事前分析。

感谢认可

链接：https://pan.baidu.com/s/1R3p0K36e62ldMpEz2z7gNQ
提取码：2l5j
完整版

就是用的 commitlint

思维模式，执行力，业务感度。 三者缺一不可。

理论和实际总会有出入，本文讨论的只是一些可能，在符合 3 模型的条件下，加人是合理的。

不能因为延期经常出现，就觉得他是合理的。

防微杜渐，未雨绸缪。尊重团队产能，才会做的更好。

进的早，也要表现好啊，不矛盾

写用例浪费时间？那你怎么做测试执行呢？想到哪测到哪么？

可以做些测试以外的事，从研发全局的角度看看能做些啥。或者主业划水，副业搞起。

划水久了，真就水了。

不要被测试角色捆绑了。