感谢，昵称：feeeei

3080 卖 5000 ？ 是“一手”店铺吧，我觉得可以考虑一下矿卡

前几个周刚收了张 3090FE ，成色还可以，带盒子价格 5500

求拉 aV9naG9zdA==

aV9naG9zdA==

是不是叫 1109 事件更准确一点儿

胜利 9500 、胜利纳米 7

不差钱的话，就 YY 的弓箭 11

拉个 YY 的 65 线吧 25 磅左右，新手应该打不断

男生除非是肌肉型并且打单打可以买 3U ，其他都买 4U 规格
女生力量小，就想当个网前雨刮器可以买 5U

家用感觉还是奢侈，感觉适合小工作室用，尤其是设计类的工作室

ROG ？ RAZER ？ Alienware ？ XPS ？

这几个系列我印象里都能有超过 3w 的配置。
很多年前用过 Alienware 的笔记本，售后是真的好，有问题第二天上门现场换件儿

不扣税吗？？？ 为啥税后还这么高

不要搞这种开会形式的 Code Review ，因为每个人对项目代码理解的程度大多都不同。

有可能一个新功能，就组内的 2 个同事比较熟悉，剩下的只知道个大概，那么在 Code Review 的时候，很容易就他们俩知道在聊什么，其他人根本听不懂，为了照顾其他同事大篇幅的讲上下文，也有可能一时半会儿消化理解不完。


最合适的是让你的 Reviewer 给你看代码，IM 里面把 PR/MR 丢过去，Reviewer 有空了帮你看一下，遇到问题在 PR/MR 中写评论。
如果觉得这个问题其他同事也需要注意，就把这个 PR/MR 丢在你们开发小群里，告知大家需要注意一下这里。

买了个擦脸的护肤品，香港发货，现在还在广东，已经一个月了...

@tool2d #29

第一句话我就不认同，我认为必然有简洁的代码...

举个例子，写个排序，我是自己手写个排序算法简洁，还是直接 array.sort(list) 简洁？


再聊随着需求增加，会不断熵增，这个我完全认同，重构我也能接受。

但是你认为，重构屎山简单，还是重构相对清晰简明的代码简单？

很有可能在熵增的过程中，把控不好，产品层面熵增了 O(n)，代码层面熵增了 O(n²)，Code Review 做得好可以尽可能让业务熵增与代码熵增呈现一个线性关系。

@yzbythesea #28

我刚刚讲的只是举了几个在 Code Review 中关注的例子，并不全，我还是认为即使稍有一定工作经验的人代码也不一定就是 OK 的... 也许我们之间对代码 OK 的标准的理解存在差异。

比如要求实现一个订单支付的接口，不同的人也许会有不同的设计方式：
- POST /order/{order_id}/payment
- POST /order/{order_id}/pay
- POST /order/pay?order_id=xxx

也比如有的人曾经的工作经验是 HTTP Response 在程序中永远反 200 ，也有的人会相对更遵守 RESTful 。

这上面的取舍，在产品层面都无关产品质量，但是我认为这应该也是 Code Review 时应该把控的一部分。

也有可能一些团队对这些也有明确的约束，但是 Code Review 还是有很多东西值得关注的。


我日常中还有的一些 Code Review 纠正同事的案例还有：
- 这段写的多余了，我之前写过类似的，在 xxx ，你复用一下就可以了
- 这里可以使用语言的新特性、xxx 第三方库实现，更简洁
- 标准库里有标准实现，不用自己再写一遍，直接 xxxx 就完事儿了
- 这里用防御式写法，先把这几种异常情况先判断处理了，剩下的代码逻辑会更干净

还有很多是语言相关的，不清楚你主语言是什么，怕讲出来非这个语言的开发 Get 不到点就不写了。

@smilenceX #23 [握手]

@yzbythesea #12 @smilenceX #18

我对此持相反观点，不知道你听没听过 “代码是用来让人读的，只是顺便让机器执行而已”

CodeReview 不是为了保证 0bug 。比如一些边界值、异常情况没有考虑，直到测试阶段才暴露出来这太正常了。

CodeReview 最要求是更简洁、更已读、更适合的代码，比如是否落实了项目规范中的 MVC 、DDD 、比如是否 3 行代码就可以搞定的事情但是你不知道你写了 30 行、比如是否满足了 SOILD 原则等等。


简而言之：Code Review 是用来保证代码质量，测试是用来保证产品质量，这两者并不是一个东西。

你的观点是正确的，少量多次肯定是好的

我之前遇到过一些同事，一口气提一两千行代码，这是指望 Reviewer 是个神仙吗？
错误的习惯就应该就改正，而不是迁就他

还有就是，这种事情给我的启发跟教训就是，如果不是很好的团队，就不要搞民主，搞专政搞一言堂。

先把自己的方案推下去，日常多留心一下大家的执行情况，团队里面人员有执行不到位的即时纠正，之后再看情况了解了解大家的反馈，是否要做一些调整