@DamienS 不是 这里只是用作 Code Review 的简写.

CR 这件事情我觉得从效率提升上来说的优先级是:
1. 好的 infrastructure: 我们公司代码的自动检查不仅仅负责语法, 规范, 还会自动优化 条件表达式 (比如一堆 XOR 如果可能的话他会改成更短更合理的形式) 以及 best practice 和 deprecated 的自动修复. 最后会跑配置好的测试. 这些全通过之后才会发送 CR 请求, reviewers 都会收到推送提示 (macOS 的话就是系统通知, 也有 Chrome 插件会持久监视)
2. Reviewer 人员的选择, 每个人 review 代码的严格程度是不一样, 如果你想快一点, 就选已知的比较松的人, 如果想提高或者对自己写的代码没信心, 就找 review 严格的人.
3. 组里 review 代码的风格. 我们 TL 之前介绍过他的风格, 不一定适合所有人但是我觉得挺不错, 主要的几点是: 1. 如果代码达到了目的, LGTM. 2. 可读性 > 语言规范 3. 小 CR > 大 CR 但是如果 大 CR 已经写好了, 除非自己看不懂, 否则尽量不要要求对方拆分. 除了这个之外, 我们组基本上收到 CR 会在 5~30 分钟内完成 Review. (没人要求这么做, 只是大家都这样, unblock 别人也是间接提升整个组的效率)
4. 就是自己写的代码了, CR 描述是否能提供足够的背景? CR 是否太大而不方便 Review? (比如我看到个 2000 行的 CR, 本能的会想 这 TM 得找个 30 分钟的时间段慢慢看, 现在没空 马上要吃饭了, 然后就.....)

当然话说回来,很多事情不是自己能改变的. 如果你是 TL 倒是可以尝试改变. 如果有机会的话, 去大公司去哪怕实习一个月, 也能看到别人的这套流程有多好.

额..刚才把你手头的和想要的看反了..


ps = list(zip(A, B))
myret = [[{"f1": p[0], "t1": p[1]}, {"f1": ps[2*i+1][0], "t2":ps[2*i+1][1]}] for i, p in enumerate(ps[:-1:2])]

ps = list(zip(A, B))

myret = [[{"f1": p[0], "t1": p[1]}, {"f1": ps[i+1][0], "t2":ps[i+1][1]}] for i, p in enumerate(ps[:-1])]

如果能把标题覆盖到图片上 可能会好一点

你是不是在光线暗的时候用多了?

如果只是自己用的话, 这些数据完全不够看, 在内存里随便跑.

如果需要持久化(比如程序崩溃了), 或者想着以后扩展性的话 可以存数据库, 也可以有历史可以给你 debug 用.

建议是先在内存里跑起来再说..回头再优化

@TangMonk 那就不 mini 了 😂

@shutongxinq

先下单了个 mini 周末试试不好用就去退了回头等 pixel 5 自刀

@Livid
@shutongxinq

在 pixel 5 和 iPhone mini 中纠结
X - Pixel 3 - Pixel 4 用户

方案一 等 150 ～ 200$ off 的 pixel 5 deal
方案二 直接转回 mini

但是
pixel 用下来确实流畅性明显和使用体验不如 iPhone （软件响应慢， 蓝牙 bug， 软件质量差， 都碰到过， 也可能我一直用的 developer 版的关系）

这次的 mini 尺寸很喜欢 可是。。。。听说电池很拉垮 而且很可能明年去刘海， 到时候又想换

哎 就没有省心点的选择么

前方友情提醒 mini 8G 几乎只能勉强用。。。。（ Chrome 会时不时 crash 的那种）

上个月刚买 mini 血亏。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

能转存个 google drive 之类的么 分享满了要注册才能下

how to invent everything
(是本老书了, 最近才开始读)

tl;dr: 穿越指南, 里面涵盖了从恐龙时代..到至今的重大发明, 生存指南等.

额
首先创业并不比打工简单
其次创业不是打工的后路

请问楼主面 63, 64 这种的 senior 也是和应届一样的算法面试吗?

我缺的是博客轮子么? ::狗头::

用过小米国际版 感觉硬件有点跟不上还是咋的 而且散热也不太行

后来换了 shield 提升的不是一点半点
没用过其他的盒子了，如果我这个 shield 坏了我估计还会买 shield