uglyer

是个单例？

为啥用正交相机渲染，没有透视关系转动视角乍一看有些许反直觉。

可以把具体的表结构以及插入记录和执行时长贴出来具体分析一下。

设置 PRAGMA synchronous = OFF 和 PRAGMA journal_mode=WAL 后，我本机测试(m1) sqlite 单表连续插入每秒能到 6 万多条 CREATE TABLE foo (id integer not null primary key, name text)； INSERT INTO foo(name) VALUES(?)

另外，使用预编译语句也能提升一些性能。

@gearkey

我不太理解你说的不存在货币没有收入，大家要在一起干活，怎么做到抛开基础薪资。

“销售货款平均分配给生产团队成员”，我对这句话的理解也只能理解为 出售完成带来的额外的收入。

@gearkey

别别别，不要来一个高帽，当时是我的 TL 推行这种过于理想化的制度，我是极力反对的，但是最终还是执行了，然后当时反对这个制度时提出的一些可能会带来问题假设，每个都出现了。

可能我们描述各自的场景有所偏差，不清楚你们公司团队规模，帖子中一些细节不知道具体要怎么执行。
讲讲我们团队强行用类似（部分）的方式带来的具体情况吧，希望对你有所启发。

最多的问题是价值只用时间来衡量导致。
1. 所有数据都是公开的，大家能清晰的看到其他人的情况，评估一定会存在或多或少的偏多偏少，当有人工时与收入强挂钩时，这种矛盾会推到台面上被放大。
2. 产品提的一个需求，一定会有多种不同的实现方式，大家会倾向于选择时间长但是并不是最优雅的方式实现。

试过这种方式，当时就能想到的几种弊端最后都一一出现了，不要强上。

1. 所有人的薪资并不相同，能做的事情复杂度并不一致，并不是所有人都能对所有需求分解后的任务在每个环节进行准确的评估。
2. 执行效率并不相同，完全相同技术栈的同学评估时间可能差异巨大，效率低的同学为了自己在有限时间内一定能完成，会给一个更长的时间预估，为了利益最大化，效率高的同学同样会这么做。
3. 团队协作中，一定会存在无法用工时衡量的东西，大家(或部分同学)需要参与日常的工作，这部分内容时间跨度越长，越难以开展。
4. 对于大多数创造性的工作而言，用时间来衡量对有创造性输出的同学并不公平，一个好的点子可能能带来巨大价值但实现他的时间并不长。 因为利益相关，大家更愿意做时间长不容易出错更容易出结果的任务。毕竟好的创意没那么容易出现，出现到落地也有非常多的时间在验证这个想法上(那验证的所需的工时在制度中算还是不算？)。
5. 认同二楼说的，会变成大跃进，只追求字面上的数字，所有事情都难以推动，人会慢慢离开。

17 年的项目尝试过，除了对象序列化遇到一些坑之外其他方面都挺好的，能极大的提高效率。
对于团队成员，kotlin 不熟悉的语法，先用 java 写 用 idea 提供自动转换的工具 翻译为 kotlin，基本上一周左右都能熟悉了。

为什么不走内网的 endpoint

换个思路，弄个类似水晶球，只要外面等玻璃，底座换成个投影仪。