从一开始就没办法白剽吧，各个行业各个公司的情况差的太多，测试的粒度周期因素完全没有可参考性，就算工具本身能直接用也不代表思考的过程可以省略的啊。

至少我自己看论坛没觉得最近干货变少吧，后面东西少的原因，我觉得是因为整体大家水平上来之后，不再讨论特别细节和马上就能上手的东西了吧

觉得很多公司 30+ 的人不要的逻辑很可笑，从整个人口普查的结果来看，18-35 岁的人口占比高一点的地区也只有 20% 左右，这其中还包括不做计算机和学历不够的；然后 2020 年出生的人口就比 2019 年出生的人口少了 15%。

30+ 不要按道理只能是一个特别短时间内的现象吧，不然到后面你哪里有人可以招的，说句不好听的，摆出这个规定就是在说自己公司最多开 3 年了，那这个年纪有这个本事的人干嘛非得来一个这么短命的公司，之后简历都不好写。

个人的学习路线：
网易公开课的 MIT 线性代数，尤其要利用这门课把很多单词混熟，后面会方便很多；
再就是吴恩达老师的机器学习和深度学习

练手的话是 TensorFlow，因为资料非常丰富群也很多，而且符号什么的和前面的课程是一致的

当然这个是我自己利用空余时间自己玩的，说来惭愧我也没搞明白应该怎么应用，因此没办法说我自己就是对的或者合适的，仅供参考

AI 的门槛正在降低，并不是学不学的会的问题，而是学会之后怎么用的问题，现在很多公司炒 AI 只是概念：

比如，很多公司的"AI 测试"只是运用了 Sikuli 进行了图像识别，具体怎么优化、怎么设计测试策略和目标、怎么提高产品的质量完全没有概念，结果每次 CI 的时候一大堆的图片需要上传，还有每一次需求都是天文数字的工作量，然后就是无论测试多少遍 BUG 一点都没有减少，除此以外根本没有提升；

然而，更悲剧的是，哪怕其中有灵光的下狠心把图像算法优化了，发现图像识别和自然语言变成公共的基础服务了。

对于这个领域不熟悉的测试，尤其不是大厂的测试，根本得不到信息，盲目学完然后盲目碰壁盲目失望这个是最有可能的，建议这个阶段还是稳扎稳打修炼基本功，有时间把线性代数好好补补，了解一下常用的框架，在常见的 AI 应用方向里面挑一个仔细研究一下，别太盲目跟风。

通过类加载器去获取

先调整好心态，多数时候未必自己就完全不行，只是简历上没有戳中用人单位的兴趣点，我的房东小我几岁小学没毕业，到我租到他的屋子的时候人家还有二十一套装修好散好味没租出去的，学历虽然是一道坎但并非绝对的。

整理一下七年间的得失，想清楚自己能忍到什么程度，按这个标准，在简历中适当迎合一下人家公司的业务需求就行。

感谢，我发现我对共性这个点理解偏了，基础服务类包括运营支撑之类的平台抽到中台是一个合理的考虑，之前我见过一个把上下紧密依赖的业务公共服务抽到中台的案例，结果是底层服务频繁迭代，导致上层业务进度和沟通成本失控，缺陷在业务下游被放大；汇报线也混乱，上游业务的运营策略要依赖中台的资源，结果导致中台和业务没办法协同，互相推责任，整体效率低下

感谢分享，很有用，不知道我的理解对不对，我举一个脑补的测试部门的 OKR 实例大家帮忙看看：

本周关注的任务：
P1: 上月所有版本问题回溯分析
P1: 本周版本回归
P1: xx 工具分享

OKR 当前状态：
目标：提高发版质量
关键结果：线上资损率 25%（2500/10000）
关键结果：月均缺陷率
关键结果：持续改进措施覆盖率（版本覆盖率：37/50，资损覆盖率：1900/2500）
关键结果：人员技能提升（新工具推广 3/12 团队）

未来四周计划：
推动所有团队的版本回溯
工具推广应用
检查预防措施执行情况

状态指标：
缺陷率持续下降
人员单位产出增加

部门架构上的划分问题并不是可以一笔带过的程度了：

1. 中台和业务线业务重叠的部分责任如何划分？
2. 业务线和中台都要快速迭代，但是中台的升级本身就会给业务线带来影响，如何能保证项目选择和快速交付的战略能够执行下来？
3. 这个组织架构在结构上并不属于项目型架构，也不属于职能型架构，矩阵的划分上不仅有权责交叉还有业务领域的重合，怎么保证在执行组织级策略的时候，干系人之间能达成一个平衡，纵向的资源整合如何操作？

可以设置跳过这个文件，在 exclude path 里面，但是这个方法是治标不治本的，完全无法预测这个类里面的方法什么时间维护过，会不会有数据类型的问题，遇到 JAVA 11 的新的安全策略会不会有代码编译失败等等等等问题。

建议，如果是这个文件彻底不改了，类似于金融行业很多的 Fortran 工具类，直接打成二进制文件，也可以避免因为 JDK 升级导致的编译失败。
如果还打算改的话，把风险暴露出来给相关的干系人，让开发那边给出整改的建议。