V2EX › dayeye2006199 的所有回复 › 第 57 页 / 共 79 页

多给开源项目交 PR 把，有人免费给你 review 代码，有人教你怎么写测试和保证覆盖，多人参与的项目肯定会对结构和设计的易读性有要求。我的经验是可以参加参加大厂认真开源出来的项目。如果这个东西是谷歌拿出来的，那大量的 contributor 其实就是谷歌内部的工程师，你交 PR 的时候，其实变相过了一遍接近谷歌标准的 review 。

很不巧，这些东西很多在平时工作中都缺失了。

2022 年 1 月 14 日

回复了 cxh116 创建的主题 › 问与答 › 单机 8 核 32G, 用什么技术才可以做单表 20 亿数据的过滤查询?

试试这几个：

1. 你的查询基本上都是 = 条件，所以考虑用 hash index ，不用 btree index ，大概有 10-20%的性能提升；
2. 使用 CLUSTER- 基本就是重排数据记录，让相近的数据在同一个 cluster 里面；这样应对比如查询所有 from_addr = xxxx 的记录的时候有奇效，因为这些记录都是邻居；
3. 使用 PARTITION - 思路和 sharding 接近，但是不需要引入多机；方便 query plan 并行化执行

2022 年 1 月 14 日

回复了 yuxing1171 创建的主题 › 程序员 › 你认为什么是 10 倍程序员

@yidinghe 没有 vim mode 不能令人信服

2022 年 1 月 14 日

回复了 yuxing1171 创建的主题 › 程序员 › 你认为什么是 10 倍程序员

@singerll 1s = 1000ms

2022 年 1 月 13 日

回复了 leontung 创建的主题 › 程序员 › 大家有没有尝试过用什么工具提升团队 Code Review 时候的协作效率？

我觉得其实工具倒还是次要的。以下几点我觉得对 review 的效率更重要：
1. 每个 PR 只做一件事情 -- 加一个 feature ，修复一个 bug 等等；这样可以保证一次需要 review 的代码量不会太大
2. 一些格式问题，常见的语法问题等等不要人来 review ，用 linter 和分析器来解决，review 之前保证先把这些低级错误给修复了
3. 特别复杂的 PR 需要附上设计文档，作者需要阐述大概是怎么实现这个功能的
4. 测试还是需要写，否则全靠人来把握代码正确性，reviewer 的心理负担会很重

2022 年 1 月 13 日

回复了 leontung 创建的主题 › 程序员 › 大家有没有尝试过用什么工具提升团队 Code Review 时候的协作效率？

原来只有我一个人永远看的是网页。。

2022 年 1 月 13 日

回复了 Tinywan 创建的主题 › PHP › 2022 PHPer 路在何方？

如果发觉自己只会一个语言 X -- 换一个就很费劲，那确实应该有点担心

2022 年 1 月 11 日

回复了 hananonamida 创建的主题 › 程序员 › Django ORM 查询问题

直接.raw 把，别勉强

2022 年 1 月 11 日

回复了 idealhs 创建的主题 › git › 一个不同代码托管平台间 PR 工作流程相关的问题

也是分支到分支的。只不过是你 fork 出来的这个仓库的一个分支，到原仓库的分支；
因为你没有推送原仓库分支的权利，所以只能这么弄了；这个一般是给开源库贡献代码的姿势。

如果你们是自己组织内部用，那直接在原仓库里面开分支，推送原仓库，然后发起 PR 合并分支就可以了；没必要走这个模式。