简单得很：

GirlFriend gf = (GirlFriend) new Object() 
gf.setAge(20)
gf.setName("XuKun Cai")
gf.setGender(Gender.FEMALE)
gf.setHeight(170.0f)
gf.setWeight(50.0f)
gf.setLegLength(120.0f)
gf.setMaterial(Material.SILICONE_RUBBER)
……

可以去 ruby-china 社区的开源项目上去提 PR，自己实现的终归是最香的

我是匿名区总钻风，我也看不到真实用户，但是以网警的技术，还是很轻松的
后端设计上可能会有 bug，如果能摸到日志应该可以大致追踪到，如果哪天社区上市了，你们可以请四大来审计后端设计和管理员的行为

用 AI 做数据挖掘，这就触及到我的知识盲区了，我们以前就是配几个 sql，传入时间、版本号，拿 echarts 画几个图放到报告里，当然 Metabase 里面也会存一份~
AI 太疯魔了，惹不起~

单纯只有 bug 数据的话，最多叫数据挖掘、数据分析，跟 AI 扯不到关系

一旦出了问题，团队、领导、所有人对你的体感，那都是直线下降，你之前做的所有好事，就跟消失了一样，别人对你的印象，一提起来说的都是，这不是当时写出 xxx bug 的人吗？这还怎么在职场生存？脸都没了，项目好处也跟自己没关系了

你想太多了，谁都需要经验和教训的累积来进步，哪有一开始就完美的？出一次问题就否定全部？你是不是太过在意别人的看法，自我 CPU 太狠了点……easy！easy！

奈斯，鸡器学习很赞，一看就是练习了一坤年的技术，黑子哥真棒，啥都会，仰慕 ing~

背后开两枪

请不要在社区讨论破解问题~~

我给你们理一下这个争吵的过程，你们看看是不是很可笑，然后我晚些时间锁帖~

• 1st、黑哥给了个莫名其妙的推论 “测试坚持唯技术论的人，最后的归属都会是搞培训班”，姑且不说这个推论搞笑不搞笑，但是这里吐槽的点是 “唯技术论”，应该说并没有否定技术的重要性
• 2nd、孙总说很多混到高薪的是靠技术的，也就说有这么一条路可卷；“技术重要” 和 “唯技术” 是两码事，所以此时应该没有把矛头对准黑哥，但是阐述有点上头了，觉得楼上大部分人没有清醒地认识到技术的重要性……但是，说实在的没看出楼上有这种论断的苗头出现，这是属于凭空创造假想敌
• 3rd、接着黑哥上头，讥讽孙总以自己的价值观 CPU 其他同仁……
• 4th、各种下头言论出现，不分轻重地互怼、不分是非地站队~

• 观点一：唯技术论是不对的，业务也很重要甚至更重要
• 观点二：技术是很重要的，卷技术是一条 “混出头” 的可行路线

压根争论的不是一个论点，二者都没毛病，你说你们吵毛线~~~

我看到你这么长的回复，再联想到你前面发的帖子说你连续几个月每天疯狂加班到深夜，心想必然是创业公司，晚上七点之前不用干活的

测试坚持唯技术论的人，最后的归属都会是搞培训班

你这句就是鬼扯了，我坚持了那么多年，最后的归属是失业——好在赋闲 2 年后凭着年前时摆弄相机的那点粗陋知识找到了个影像测评的工作~

30~45，取信 30，猎字当头，除以 1.5，实际 20K，我理解的没错吧各位大佬

来，说一下是哪个大厂？说出来让我们见识一下大厂的降本之道……

合情合理，完美操作，甲方圣明！

说真的，这世道有明明的一份功劳，我向来主张看中哪个面哪个，面不上再退而求其次面下一家，像明明这种凭借硬实力一下子拿 7 个 offer 的，给了那些用人单位更高的期望，希望人人都如 “我上次面的那个明明” 般强……而且多个明明叠加，搞的他们期望越来越高，但是现在出现了很多比明明更强或更年轻的人了，明明自己也遇到了困境，是不是明明自己造的孽呢？

明明三年前那会儿面试 11 个还能拿到 7 个 offer

坦白说第一眼看过去我觉得你在杠，仔细看了一下你发的内容，发现还是 GPT 在杠

额外说一句，用任何厂家的 AI，问问题的时候都不要带上倾向性甚至拉踩的方式，不然你得到的答案慢慢的、越来越接近你已经知道的信息，这是自己给自己创造信息茧房，而且这些 AI 很容易被 “投毒”，使用时更需小心。比如你要问：“格力空调比大金空调好在哪里”，不如问 “格力空调和大金空调各自有什么优缺点”。你预设了自己想要的答案，他们就会变成一种新的竞价排名工具……

这种为了杠而杠的问题，针对性太强了，GPT 显然在扮演理中客，强行否定……甚至为了杠而假定出对方说过某个错误言论，比如：

那种 “一旦用 LEFT JOIN，MySQL 就会被迫扫右表全部数据，而用 INNER JOIN 就能快速过滤只读少量数据” 的说法往往是过度简化甚至不准确的

“一旦用 LEFT JOIN，MySQL 就会被迫扫右表全部数据” 这句话谁说的呢？

在我看来，或许 GPT 连 “可能” 和 “一旦” 都理解不清楚，就没必要参与中文的逻辑解答了，要不你问问它 “INNER JOIN 和 LEFT JOIN 有什么区别”，看它怎么回答呢？

问一下 AI 就知道了，LEFT JOIN 的作用一般来说仅在于 返回左表所有行，右表部分无匹配，帖子里的场景 case_branch，起码会有个 main、master 或 base，必然会有匹配（如果没有，那就是数据结构问题了），为啥要用 LEFT JOIN？

在联表查询中，INNER JOIN 和 LEFT JOIN 的效率对比需结合具体场景分析，但通常 INNER JOIN 效率更高，原因如下：

1. 结果集大小

• INNER JOIN：仅返回匹配的行，结果集更小。
• LEFT JOIN：返回左表所有行（即使右表无匹配），结果集可能更大。处理更多数据会增加内存和计算开销。

2. 索引与过滤

• 若连接键有索引，两者效率接近。但若右表无匹配时，LEFT JOIN 需额外处理 NULL 值，可能略微增加开销。
• 若右表无索引，LEFT JOIN 可能触发全表扫描，导致性能显著下降。

3. 执行计划优化

• 数据库优化器可能将 LEFT JOIN 转换为 INNER JOIN（当左表所有行在右表均有匹配时），此时效率相同。
• 但若优化器无法确定匹配情况，LEFT JOIN 可能选择保守执行计划（如哈希连接），增加内存使用。

4. 数据分布影响

• 若左表大部分行在右表有匹配，两者效率差异较小。
• 若左表大量行在右表无匹配，LEFT JOIN 因处理更多 NULL 值而更慢。

总结

• 优先选 INNER JOIN：若只需匹配数据，效率通常更高。
• 谨慎用 LEFT JOIN：仅在需要保留左表所有行时使用，并确保右表连接键有索引。
• 实际验证：通过 EXPLAIN 分析执行计划，观察是否触发全表扫描或低效操作。

• 示例：若左表有 1000 行，右表有 100 万行且无索引：

  • INNER JOIN 可能通过索引快速过滤，仅匹配少量数据。
  • LEFT JOIN 可能需扫描右表全部 100 万行，导致性能骤降。

是什么样的魔鬼数据结构设计才会让你在 OLTP 应用里面敢随便用 left join 的
遇到这种问题我第一反应就是干死这种 sql，干不死就要重新设计数据结构

黑哥太霸道了，取关取关

你要不要去问问 kimi、ds、千问、文心它们这几个问题：

• 测试对象有 4 个输入，取值分别为（A1, A2）、（B1, B2, B3）、（C1, C2）、（D1, D2, D3, D4），使用 BC(Basic Choice) 覆盖方法获得的测试条件有哪些？
• 有函数 f(l, m, n)，l 取值 [1500, 1800], m[2, 15], n[3, 25]，采用边界值法和基本选择法进行测试，仅考虑边界内有效值，最少有几个测试用例，分别是什么？

听听 AI 在放什么屁……再决定要不要用 AI 写 case

昊翔本人？

参考 FMEA：https://zhuanlan.zhihu.com/p/523384133