标准学院派的答案，毫无问题，至于小公司衍生的野路子操作，无论是否合理，总归不是标准行为

1 轮之后遇到的可能性微乎其微，傻逼集中在初面~

运气好不碰到傻逼面试官：成功率 +80%

我还是喜欢看你桀骜不驯的样子，你赶紧恢复一下子

AppScan + Fortify

建议看看美团这篇，更全面、更实际：https://tech.meituan.com/2023/09/22/construction-and-practice-of-code-change-risk-visualization-system.html

回帖清一色的鄙夷，只要意见不合就是领导煞笔？
另外，莫非金字塔分层测试理论都已经沦落到如此不堪了？

“感觉产品质量无药可救”

你要是换个岗位，之前的测试、开发同事不会被你骂死？

用 py 的都是在攻工具链和基础设施优化
用 java 的是在做平台化工程
历史阶段不一样，都学比较保险，顺道 go 和 C++ 也粗学一下最好

还得说美团这个做得更好：https://tech.meituan.com/2023/09/22/construction-and-practice-of-code-change-risk-visualization-system.html

这种题解好像对你学习算法没什么帮助，大可不看

我一直很困惑的一件事是，QPS 难道不是 TPS 的一个概念子集吗，为何总能相提并论呢？
或者说把 TPS 定义成有数据写入的事务，QPS 只是纯数据读的事务？如果只是区分读写，为啥不叫 RPS 和 WPS 呢？
还是说 TPS 被定义成完整的事务，而 QPS 只是一个读的请求而不理会是否有结果返回？这样 QPS 还有啥意义？

不开心就只能抑郁了~

我 12、13 年开始带团队，20~50 多人那种规模，到 16 年的时候觉得实在很废、无聊，然后 16 年初自己申请转去做运维开发、devops 相关的一线工作，此后一直持续做各种效能架构、专家……直到失业几个月之后才开始后悔，为啥不一直苟住，很多躺尸的管理职位看不上我这种一线干活的，更多一线干活的技术岗位看不上我这种管理走出来的~~~我现在失业在家一整年了，很开心

所以，无所谓哪个好、哪个不好，而只是你走上了哪条路最好把它走到底，专心做好！

哪怕是月薪 10 万呢，一个月肯定在试用期内，离职证明都不需要开，简历上不写根本无所谓

对不起，没读懂，单纯的飘过~

唉，hibernate 多少年前~

咨询师的诸多案例里面，无一例外的走了 testcase-code-mapping 的路子，这种本来就不该成功，成本大过天，落地个毛线，repost 一下历史观点：

面试的的时候不止一次被问到自己做的东西如何落地的问题，这个挺 6 的~

面试官 核心意思是：我是你领导，不是摆设，你搞不定可以来找我，自己在那里瞎折腾个啥
这是个控制欲很强、对细节很在意的面试官，好坏不便评论，反正不是个吃白饭的就是了

想避免很简单，不发布就可以了

为什么拒绝新鲜血液 + 排外

典型的狗咬吕洞宾，不识好人心……我不做测试很多年了，我真心奉劝那些觉得测试 “轻松简单” 的人不要去做测试，原因有二：

• 这么想的话，过个几年你自己就要面临垫底、被刀，你职场能力再高……你是老板亲戚当我没说
• 不要把测试行业平均水准拉底了，这个职业现在什么样不说，以后真的不需要太多低端执行者

当然，哪天资本家觉得这个世界需要慢节奏、需要 peace 了，还有人劝你不要做这不要做那的，那他肯定是坏

无关责任不责任、到位不到位，就是没有把流程规范固化到平台、工具上，用工具在流程中做好检查和卡点。

自顶向下只追一个顶端数据，后面的所有步骤自然而然的卡死，不给偷懒、犯错的机会，这就是理想的操作。尽可能避开需要人的思维意识去干涉，这样大家按部就班，都不会累……

所以我上面针对代码提交规范就提了一嘴 commitlint，我对原文中只提 “规范” 二字表示不以为然，这些必须东西要有足够的客观约束，而不是靠人自主去遵守或执行……当然，流程规范是源头、是根本，没有这些的话，后面做的一切都可能会被质疑。

代码提交规范：在提交代码的时候，需要描述清楚提交代码的作用。

commitlint 了解一下