shakaraka

哪怕是先给盖章的 offer ，你再离职都好过你这样

笑了。就你的文字描述而言，就是个坑。哪有转正是这样的

@NewYear #4 能跑就不要动 😁

@Ketteiron #15

我带的团队是选用 bun,elysia,drizzle + DDD 架构开发的，目前已经做了 3 个大型后端项目了，规模的话大概就单单 domain service 的平均数量大概有 7 、80 个，初期我计划使用纯函数没打算使用 DI ，所以后面项目一团糟，现在用了我这个 ioc 就好了很多，因为在敏捷开发的时候，不能够要求团队成员做好代码规范，加上 js 生态就很灵活，所以一发不可收拾。

所以经过这个事情后，在团队中我认为规范、约束是一等公民。写业务只要按着框架写（类似 spring ），阿猫阿狗写的都差不多，如果是静态语言，那更好，免得像 js 一样写错都可以运行（同样的团队因素）。

至于 cloudflare worker 反代的话，cloudflare 官方有说不能够用 worker 进行反代业务，有封号风险。

因为有人在 docker hub 上上传反动的镜像，导致国内所有的 docker 公共代理全部停掉了

@Ketteiron #12

不过即使是 react 这种所谓纯函数的库，其实也有 provide 、inject 的概念，方式不同（通过 Context ），但概念还在。

@Ketteiron #12

你可以推荐哪些 js 、ts 、go 大型项目是使用你说的理念实现的？

我对于 DDD 和传统 MVC 目前是手到擒来的程度，即使我带着新成员开始新项目想尝试抛开 DI ，但随着项目越来越大，开发人员能力参差不齐（这点我掌控不了），导致乱象满天飞，只能通过一些“固执已见”的方案来约束开发人员。

双开还是双账号，你得区分。双账号做得不好那是软件自己的事，跟何况微信压根就不支持所谓的多账号在线，那体验肯定可想而知。

软件是多样的，系统只需要提供底座支撑就好。如果没有多开的需求，我想不到还有什么场景需要系统级别支持多开