我自己写的 b+树选择了不固定阶，key 有长度限制，value 不限。过大的 value 通过扩展页分割存储到多个页中。

页大小可以选择，决定了就固定了。所以要么 key 有长度限制，要么引入其它结构处理超大 key 和 value 。记得 mysql 是有 key 长限制的。最新的版本不清楚

@tlerbao 另外要说明的是，团队使用 rebase 方案，需要培训和约束的。否则请用 merge 方案。

@tlerbao 另外多个分支并行开发时。rebase 方案操作步骤会更多，我会使用本地临时分支

@tlerbao
确实会存在。rebase 方案这个地方确实不完美。只要分支开发提交到上游就会有。确认没问题后，删除这个分支也不影响。但是一般会保留用于追溯。由于基变导致 commit log 编号不同，需要靠 commit 说明来对比。虽然有瑕疵对比 merge 方案，我更喜欢 rebase 。

简述书上有个"如何使用 Git Rebase"，我觉得不错

直接使用标准库里的 ast 相关库

我也是用 golang 自带 ast 针对性写的

@tremblingblue 对，我就是这样的。突然打断工作去做面试。趁着自我介绍过程看下简历，转换下思维

@tlday 有个地方有问题。推荐传递不推荐共享的思想和协程没有关系。之前看到一篇文章，目前 go 写的代码中，还是共享的比例高。

我这边是不用 replace 。部署 athens 之类的本地仓库。GOPROXY 设置为 athens 。私有包走内部部署的 git 服务。设置 GOPRIVATE 让私有包不走 GOPROXY

@wysnylc 另外你可以找下百万 Go TCP, 百万 websocket 同时连接的文章。有每个连接使用 go 程，和 reactor epoll 的性能对比。

@wysnylc 现在一般普通主流计算机，直接开几万协程确实没问题。以前开发写测试时，不小心开了几十万协程，还能跑。但是线程却不行，资源占用和上下文切换决定了它不可能开启同样多的数量时还能保证可用。
你的怀疑点应该是一次性发出这么多请求。这得看理解了，如果指发出第一个数据包开始，确实可能。
假设极端情况，被访问的服务器响应很慢，导致发出数据包请求后就在 io 等待。那么协程确实能做到同时有几万个请求在等待响应。只是线程要做到同样量级，需要机器资源就更多了。
不过实际上并没有优势，现实中不会这么极端，瓶颈通常也不在这。

代码上没碰到问题是因为用 orm 之类有映射功能的。原始的方式是和查询列顺序有关的。直接写*会导致这部分业务逻辑错误。写明列则只需修改需要增加列的地方。一个人了解所有项目是不可能的，允许随意使用*。那么发布时，可能就碰到惊喜。

看书效率高。但是关键是要动手

@beryl 小的迭代更新，大多不画。开发设计人员讲下方案，负责人确认下就好。新的系统设计和大版本升级，我遇到的都是给定足够宽裕的时间，设计完成后系分评审通过后才进行具体的排期。所以不适合赶工期的。赶工期的，都是临时补丁方案

类画主要的，帮助表达层次关系和依赖关系。
时序图画，帮助验证设计的细节问题。
存在复杂的状态变化时，状态机也画。

真的是网上拿来就用。刚不久前就一个同事卡在登录桌面前进入不去找我。我拿了了 u 盘进入，挂载后看日志，发现在显卡驱动库 panic 了。问干啥以后才说复制了网上的 wine 安装命令