Inside

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

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

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

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

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

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

听起点小说

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

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

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

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

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

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