我提供另一个角度，这其实是你们的管理太粗了，隐含着强迫人汇报表功才有贡献值，还是太依赖人治而不是更细化的制度。
假设每个 task ，都分成 must have 、nice to have 两档，每档几个小项。
那么一个 task done ，就按照 nice to have 搞定了几项算贡献分，然后汇总分数，分数高的贡献度就高。
这样一来就相对公平的很多，价值取向完全变了，以搞定事情而不是汇报事情为导向。

楼主，你没留简历投递方式、途径。

以下是我遵循的一些规范，供参考。
----

# 数据库访问
求在 controllr 层向 datasource 层发起访问，不在 service 层发起。

# WHY ？！
在处就知道当前请求到底访问了哪些数据，无需层层抽象来回跟踪，有助于减轻心智负担、事务控制。
有助于 service 层保持无状态，service 层需要什么数据，在方法参数中声明完整。
把 controller 视为组织者，service 视为参与者。
数据的获取、写，由组织者负责。
数据的处理及运算，由参与者负责。

先定义一下什么叫编码基础。

听起点小说

replica set 可以单独用，但每个节点仍然要处理完整的数据集，应对不了数据集超过单节点能力的情况，不算突破了单节点瓶颈。

sharding 解决了数据集过大的问题。

先定义一下“代码能力”，目标不清晰容易事倍功半，甚至南辕北辙。

@SelectLanguage 前端业务的理解与后端不一样是很常见的，这个没问题，数据层面适配一下而已，但驱动界面的仍然是前端自己的抽象。

具体拿出方法的话，用服务端 API 实现数据层时使用 Promise.all 。

这么说吧，我写的界面，如果演示时我不告诉你，你都不知道其实我访问的是客户端本地的 mock 数据，等于是我对业务自己做了一层数据抽象，服务端 API 对我来说只是这层抽象的不同实现中的一种。
我自己开发的时候用的是我自己的实现，根本不需要服务端。

这波我站楼主，没有意识要做到 single point of truth 的还可以理解，但已经有这个意识了不想做、懒得做、嫌麻烦的，还是别写代码坑人了。
在我的团队里，这种问题第一次发现我会给个黄牌警告，再有下次直接红牌下场了。

@tcfenix 只用了一台华硕的 ac86u，有打开 QOS，游戏第一、视频第二。
打游戏的台式机走的是有线网络，其他客户端都是无线。

家用 1G 的路过，speedtest 实测下行 1G-，上行 50M+。

1 、家人（ 4 人+）同时打开爱奇艺、腾讯视频、优酷、芒果 TV 、抖音等在线视频应用时，我玩 PUBG 不卡。
2 、哥们叫我上线时，10G 的 steam 更新，2 分钟下完。

南宁电信，￥ 209。
1G 宽带、40G 流量、2000 分钟、1 主 5 副、固话。

翻一下高中课本，看看数学归纳法，递归的数学基础就是这个，代码实现是证明的形式。

这不是病，这就是能力差不会写代码，包括楼上那些说测试没用或者不写测试的。

首先你需要一个好的 ide，inspection 全绿能有效的屏蔽低级错误，改善代码风格。
然后你需要证明自己写的代码是是符合预期的，并且每次关键提交都要再自证一遍，如果能做到这个程度，考虑开始自动化测试就是自然而然的。

前面说利用数据库唯一索引的各位，应该考虑一下唯一索引为什么存在？我认为诸如唯一索引、外键等等约束，是因为在关系数据库诞生早期，是人工用 SQL 直接去操作数据库的，为了防止人为失误，所以建立了严格的约束。
现在操作数据库的大都是自动化代码，这些事情代码都能干，而且表达能力更强。

至于“再怎么做并发检查，只要不在数据库系统里做，理论上还是有重复”这样的观点，我只想说，难道关系数据库不是人写出来的？哪怕是不用数据库，只用各大语言的标准库去实现，也能轻松做到唯一索引这样的玩意，做不到还是别自称会写代码了。

如果现代的程序员们做不到前辈们能做到的事情，那前辈们会对我们非常失望以及感到悲哀吧。

Crucial MX500，供参考。

partitionBy、groupBy 了解一下。

函数式的集合操作可以说就跟你写 SQL 差不多，各大语言都有差不多的实现，相当于在语言中集成一定程度的 SQL 来操作集合。

如果你真的懂了这种集合操作风格，换什么语言都是一样的，极少再去用 for 循环了，思维已经完全换掉了。