我还以为你想问原谅色 mini...... 正好我买的是这个颜色想进来回答
原来是绿屏啊.
我简单做过测试没有任何屏幕问题, 至于屏幕开了 true tone 黄不黄, 不过和我吃灰的 X 差不多, 但从 Pixel 4 刚切过来确实觉得挺黄的.
今天刚看到那个带壳失灵的视频, 但是我这辈子用过的手机从没带过壳, 也没法给你测试下, 手头也没别人有 mini 的壳.
其他硬件问题暂时用下来没有. 软件的话, 不知道是 iOS 的问题还是微信的问题, 从别的软件切进微信, 打字键盘的声音在 14.1 的时候第一声巨响无比, 14.2 的时候前几声特别小, 之后才恢复正常. 总之先甩给张小龙, 反正他虱子多了不怕咬 :狗头:
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 用.
建议是先在内存里跑起来再说..回头再优化