用 github flow 比较多, 但如果我没有理解错,git flow 每次是从开发分支拉出来开发, 而不是从生产分支拉. 也就是”上游优先”原则. op 的操作每次从生产分支拉, 大致相当于"下游优先"了, 很多已经在上游修改过的东西, 你一拉分支,就又没有了,可能不自觉又从新改了一遍, 所以冲突很多.

如果你们有大量功能开发持续时间很长, 而且和现有模块又高度相关而不是新写一个模块(其实我有一点怀疑, 因为这里有 3 个关键词, 大量,持续时间很长,高度相关, 换句话说你们经常性的把已有模块翻来翻去 -- 如果是重构, 不符合大量, 如果是原代码结构比较差, 总要改则不符合时间很长; 如果结构好,每次都是扩展一个子类新写一个模块, 不符合高度相关), 那么可以尝试一下 gitlab flow, 否则 github flow 真的很简单好用.

>> 每个人的开发分支是从生产分支拉的，每个人开发完自己的需求后合并到测试分支。

装个 gitlab?

授权认证模块产生的埋点信息, 其分析责任在部门 A 还是部门 C?

1. 如果在部门 C,可以使用依赖倒置的方式, 让部门 C 来依赖埋点信息. 授权认证模块只需要把必要信息通知给接口, 不再关心具体埋点数据到哪里了.
2. 如果在部门 A, 那么数据收集模块应该具备多实例和一定的 API 兼容特性. A 和 C 各自使用自己初始化(参数)的实例.
3. 如果部门 A 和 C 都要关注, 那么说明 C 这样的业务单元不会太多, 或者在部门 A 内部有负责人, 那么 1 或 2 都可以.

https://cloud.tencent.com/developer/article/1497934?from=15425
这个是你要的吗?

有什么问题是 vscode 解决不了的吗？

另外，如果你只有几百个长链接的话，可以试试 MQTT ，单机绰绰有余。这个服务本身因为抽象的很好，也不需要修改和升级，业务逻辑订阅主体后丢队列里，重启切换一些消费者就好。

@sciel 这个机制看起来确实很 cool ，想问一下有使用的案例或者数据吗？我们之前对 MQTT 服务做集群也考虑过类似的方案，但 MQTT 可能跨节点订阅，导致所有的流量实际还是要打到所有的节点上。但似乎没有哪个 MQTT 集群用了这种方式来做集群。

https://plantuml.com/

配合 gitlab 或者 github + markdown + action ，实现 UML 图版本管理

》后端开发要晋升，除了设计系统外，有时候解决一个复杂的问题就能够拿出来说一下

其实差不多，后端可以用”我圆满的实现了这个业务==界面==“来晋升吗？那不是叫 CRUD Boy

10 年前的，不过应该变化不大
https://stackoverflow.com/questions/5664741/watching-variables-contents-in-eclipse-ide

github + github action + gist 分享

C 的门槛确实高，奈何做的方向几乎不怎么赚钱，而且需求少，所有收入也一般

@GeruzoniAnsasu
其实还是需求没说清楚，原贴的需求是插入，34 楼你增加了要按 index/顺序取数据的需求。所以我们要原谅产品经理老改需求:)

但问题是 op 原贴的浮点数方案也不能按 index 取数据，你要第三个，排序号是 3 的，前面可能有 1.1, 1.11,1.111.....n 个，哪怕范围也不一定可靠，除非你的数据有其它特征，比如每天插入的数量有限，大概率均匀分布等。然后再利用每天晚上重新索引等办法解决。 所以多想一步，只能假设没有这个需求。

比如现在是 A ，B,C ，C 差到 AB 中间。似乎输入只能是(A,C)？
--》
比如现在是 A ,B,C ，D 差到 AB 中间。似乎输入只能是(A,D)？

当然，这个方案只能快速插入，不能输出序号，但你提的浮点数的方案也不能输出序号。这个需求目前不太明确。

每次插入的输入是什么？
比如现在是 A ，B,C ，C 差到 AB 中间。似乎输入只能是(A,C)？

那么数据结构里最适合插入的就是链表，每行存一个 next 字段，每次插入只需要插一次改一次。

链表最大的缺陷是找到要插入的这个点很慢，但通过索引数据库帮你解决了这个问题，所以应该不需要更复杂的数据结构了。

@RickyC 如果文件个数很多，一个一个的打开，点宏也还是蛮大的工作量的

那可能我理解错了，以为你只需要提供 Python 到 C 的桥代码，你应该是希望有人帮你写所以 C 的（包括桥和逻辑）

我贴的链接是 numpy 的 C API ，也就是说你的 C++代码不需要这一部分的桥，直接调用 numpy for C 就可以了。

@kahloy py2sec 的文档描述，一定程度上实现了“加密”保护源代码的需求。换句话说，这种“加密”可能是非常容易反编译出来的，不过这个方法确实简单。是否满足需求楼主自己判断。

如果不满足的话，看看这个
https://numpy.org/doc/stable/reference/c-api/index.html

正在慢慢从 notion 转向 markdown + github 私有仓库 + gist 部分分享