 |
MrGba2zThe opinions stated here are my own, not those of my company. V2EX 第 45554 号会员，加入于 2013-09-17 11:22:12 +08:00 |
MrGba2z 最近回复了
70 天前 回复了 jarl 创建的主题 › iPhone › 如何快速将 iPhone 电池健康掉到 80%一下 |
70 天前 回复了 jarl 创建的主题 › iPhone › 如何快速将 iPhone 电池健康掉到 80%一下 |
下载 NGA app 打开放着十分钟解决。。。。。。。（不开玩笑。。。
76 天前 回复了 johncang 创建的主题 › 问与答 › 想做全职 up 主。不想露脸，有没有什么好办法？ |
或者唢呐哥。。。。戴头套
76 天前 回复了 johncang 创建的主题 › 问与答 › 想做全职 up 主。不想露脸，有没有什么好办法？ |
LKS 戴墨镜
109 天前 回复了 MrGba2z 创建的主题 › 问与答 › 有了解代办手机号的吗? |
110 天前 回复了 MrGba2z 创建的主题 › 问与答 › 有了解代办手机号的吗? |
253 天前 回复了 dbldong 创建的主题 › 问与答 › 请问，一次存大量数据，后台操作时间较长，如何在前端展示进度 |
计时器到 99 然后卡住 后台返回了再 100
（用户打你别找我）
（用户打你别找我）
253 天前 回复了 TimLang 创建的主题 › iPhone › 有没有已入手 12mini 绿的朋友，网上信息很少 |
我还以为你想问原谅色 mini...... 正好我买的是这个颜色想进来回答
原来是绿屏啊.
我简单做过测试没有任何屏幕问题, 至于屏幕开了 true tone 黄不黄, 不过和我吃灰的 X 差不多, 但从 Pixel 4 刚切过来确实觉得挺黄的.
今天刚看到那个带壳失灵的视频, 但是我这辈子用过的手机从没带过壳, 也没法给你测试下, 手头也没别人有 mini 的壳.
其他硬件问题暂时用下来没有. 软件的话, 不知道是 iOS 的问题还是微信的问题, 从别的软件切进微信, 打字键盘的声音在 14.1 的时候第一声巨响无比, 14.2 的时候前几声特别小, 之后才恢复正常. 总之先甩给张小龙, 反正他虱子多了不怕咬 :狗头:
原来是绿屏啊.
我简单做过测试没有任何屏幕问题, 至于屏幕开了 true tone 黄不黄, 不过和我吃灰的 X 差不多, 但从 Pixel 4 刚切过来确实觉得挺黄的.
今天刚看到那个带壳失灵的视频, 但是我这辈子用过的手机从没带过壳, 也没法给你测试下, 手头也没别人有 mini 的壳.
其他硬件问题暂时用下来没有. 软件的话, 不知道是 iOS 的问题还是微信的问题, 从别的软件切进微信, 打字键盘的声音在 14.1 的时候第一声巨响无比, 14.2 的时候前几声特别小, 之后才恢复正常. 总之先甩给张小龙, 反正他虱子多了不怕咬 :狗头:
257 天前 回复了 kpppp 创建的主题 › 程序员 › 我发现 我公司的 review code 这个目的已经变质了。 |
@DamienS 不是 这里只是用作 Code Review 的简写.
258 天前 回复了 kpppp 创建的主题 › 程序员 › 我发现 我公司的 review code 这个目的已经变质了。 |
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 倒是可以尝试改变. 如果有机会的话, 去大公司去哪怕实习一个月, 也能看到别人的这套流程有多好.
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 倒是可以尝试改变. 如果有机会的话, 去大公司去哪怕实习一个月, 也能看到别人的这套流程有多好.
Select Language