@midsolo 我搞了很多年电商交易相关业务，这种场景我还是真没见过（这么多字段的表，和这么多的存储过程使用，只在某些银行业务听说过），数据量的话对电商场景来说并不算大，十年前电商交易架构已经比较成熟了，非常好奇为什么迭代成这种现状，方便的话可以再介绍下

@midsolo 你说的是真实案例吗，还是自己编的

@iOCZS 你真扯淡，那 QA 组织用例评审的目的是什么？

太暗了，根本看不清楚

不知道你们是啥规模和类型的企业，头是真铁啊

这个 JD 写的，完全不知道岗位需求是啥

大模型是在模仿，而不是理解，没有海量数据的情况下，只给他语法规则，他是无法理解一门新的语言的

orm 也有 SQL 优先类型的，想要简洁高效可以尝试换这种 orm 。

@GallifreyCAR 参考我的回复，建一个 sqliite 本地数据库，注入到你的 orm 的 client 上，即可实现数据库替换，单测时会走到真正的数据库操作代码，不需要做数据库返回值的 mock ，数据库读写逻辑本身就是一个需要单测覆盖的部分，不建议直接 mock 掉数据库。

我在团队内推行过单测的落地，我们团队现在单测已经常态化运行，可以和楼主聊一聊：

首先我对“使用了 go 全局变量的框架，没有使用依赖注入，没有使用接口和抽象，导致非常难写单测”这个不是很理解，现在业界成熟单测框架对各类对象的 mock 功能已经非常成熟了，你这个难写是指难以组织单测目录结构、还是难以卸除可用的单测例子。

对于数据库，推荐使用 Sqlite 创建一个本地数据库，在单测环境初始化的时候创建表并插入数据，拒绝引入任何依赖，方便后续单测代码维护。

单测用例也有不同的写法，比如最细粒度的，针对函数/方法级别设计单测用例，这种的好处是单测用例好编写，坏处是单测用例基本没有组织逻辑，全是零散用例；也有把单测当成集成测试手段的，在功能入口处设计编写用例，每个用例都是有具体业务含义的，这种好处是单测用例易于设计，运行成功代表功能可用，但是需要进行大量的下游调用方 mock 和数据组织，维护复杂度高。

单测写完只是第一步，对单测用例的维护是一个非常重的工作，必须前期设计好单测运行流程、单测组织结构、单测用例编写规范，建议从某个独立工程开始试点，真正把单测的编写和维护流程跑通，拿到收益。

单测会反推开发者进行更合理的代码结构拆分，提高代码质量，建议从增量代码开始卡点，增量代码写单测负担小，易于推行，并且效果直观。

单测代码行覆盖率只是一个可用观测指标，都是 70%的行覆盖率，单测真正覆盖了多少业务场景，执行了多少分支流程差别很大，重要的还是用例设计，所以建议 CR 对用例进行 review 。

猜测你这是履历上体现的能力没跟上工作年限，互联网太残酷，稍微慢点跟不上，就会被淘汰，最终突围的十不足一。

@pandachow 这个牛啊，不持有任何固定资产，是在国内吗

@popvlovs 你真是挺搞笑的，真把自己当救世主活菩萨了

这个云厂商的价格对比有没有算上人力成本？谁出钱？

工作挺有意思，有没有更全面的介绍？

都有，目前看电动车用的最多，其他两个，投影仪已经一两年没用了，pocket 一个月用一次吧，没想象的那么爱好记录生活。

感觉挺不要脸的，你要是割已经工作的人的韭菜还好，还没收入的学生你都割。

喜欢安静的话，郊区良渚文化村 200 够全款了