- 主题:各位是从哪里获取code review的动力的？
网上那么多开源项目用来学学习
同事写的代码有啥可学习的
kpi定了review代码的人有责任
那就要给工期
别人写了四天的代码，你仔细review，尽量避免连带责任，至少需要花半天时间
一周几个工作日，天天review代码
项目组认可这个时间开销
开发人员就无所谓
【 在 z16166 的大作中提到: 】
: 动力主要来自KPI。。。KPI要求流程里必须有这步，发布出去出了问题可能要担连带责任（主要责任还是写这个代码的）
:
: code review是个挑错性质的东西，不怎么受人待见，而且容易起争执
:
: 极少数情况下是为了学习别人的好代码，那种已经不算review了，算learnin
: ..................
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
为别人的代码bug负责的话
review代码会需要大量的时间
这个都是工作量
会影响正常工期
真要互相review的话
每周至少要花一天时间再这上面
就问项目经理同样不同意
【 在 z16166 的大作中提到: 】
: 开发（包括写代码的、看代码的）、测试，一起为bug负责，不是流行惯例？
: --
: 发自xsmth (iOS版)
: --
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
厂家的这个服务程序如果没有你说的这个
负责人可能是刚毕业的人
你去推他开发出来
要开各种会
消耗时间精力
惹一肚子气
还不一定能成功
实现功能就完了
敏捷开发的精髓就是
我走之后哪管洪水滔天
你今天写的代码
下周可能就被重构了
【 在 PaoloMaldini 的大作中提到: 】
: 你们俩的实现都很奇葩。。且不说这玩意儿有用没用
: 即便要做，也应该是让服务端直接写个返回200的空接口专供测试用吧
: 哪能用业务接口测试去
: --
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
因为互联网思维和敏捷开发流行啊
敏捷开发，互联网思维
1. 先实现功能，后面再优化（将来优化的活也不一定我干，谁干谁倒霉吧）
2. 这套代码上线三天后可能被重构
3. 这个部门搞不好下半年关门
4. 作者搞不好下半年离职
做0-1的吃肉
做1-100的喝汤
快速实现是王道，实现了就升职加薪，后面不干这个了
优化代码是底层，犯得上么
【 在 xeagle 的大作中提到: 】
: 这个观点确实很有代表性“代码能工作，为什么要改呢”。慢慢的，就变成了垃圾场
:
: 发自「今日水木 on iOS」
: --
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
三对一review？
review者承担代码错误责任？
你知道这种review的方式，review一个人的代码需要多少工期么？
项目经理同意么？
【 在 toutouqi 的大作中提到: 】
: 所以，review必须有约束机制，比如不修改不让merge。可以提前约定好，5个人的组必须3个以上同意才可以merge代码，提意见以功能和潜在问题为主，这些意见必须改，coding style意见仅供参考等。
: --
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
现在很多互联网公司的qa是质量监察部门
什么叫监察，我想你肯定明白
架子大得很
偶尔出来查一下
出了问题查一下
监管才是主要工作
大多都是程序员自测后直接上线
出了问题大家半夜一起起来查
这种规则下
你代码写的越严谨越吃亏
【 在 cn62 的大作中提到: 】
: 公司里随便搞，反正有测试兜底。
: 开源项目如果没人认真review，肯定死的很快。
: --
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
必然有啊
但是他就是再好
有知名开源项目写的好么？
学习是有成本的
为啥不学更好的？
你是上学的时候
班级有作文比你写的好的同学么？
那你们上课的时候为啥主要学课本上的文章
不学习你那位同学的大作呢？
【 在 z16166 的大作中提到: 】
:
: 你的同事里面没有代码比你写得好的？
: --
:
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
所有review代码都是工作量的问题
对于review者和被review者同样适用
你这种review的方法
review的工作量更大
如果review者要承担出错责任
必然是让开发者把问题揉碎了讲清楚
然后自己的代码被别人review的时候也是如此
如果一周五个工作日
1对一互相review的话
这个过程至少要花费一个工作日
现在很多公司
把工作量拍的满满的
这个工作日的工期你向项目经理申请么
【 在 z16166 的大作中提到: 】
:
: review的人回复“我review完了，没有进一步的意见了”，这个操作代表啥？
: 是负责任，还是不负责任，还是说既不代表负责任，也不代表不负责任呢？
:
: 说到review质量，有时候写代码的人写了较长时间的代码，代码量和复杂度都比较大，如果要在短时间内review完，那确
: ..................
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
老师展示范文
那是以前
因为那个时候没有知识爆炸
节奏也慢
你可以和你孩子了解下
现在老师还这么做么？
极少
【 在 z16166 的大作中提到: 】
:
: 跟自己业务结合得紧的同事代码，我会学的。
:
: 开源的代码，未必和业务结合得紧
:
: 同学的大作也会学习，老师把某些同学的范文展示给一众同学，目的也是要大家学习。
:
: --
发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*
首先
你的例子本身就不合适
老师选范文
让别人学习
选的过程是老师做的
这个时间成本是老师出
学生付出的是学习成本
当然可以偶尔看看
毕竟他山之石
同组review代码
可能偶尔有一个亮眼的
但95%代码并不能让人眼前一亮
你花了95%的时间对你个人提升是无用的
这个成本要你个人出
所以不如直接去学习经典开源的代码
如果有人把同事代码中眼前一亮的部分挑出来介绍给我
我是愿意看一看的
在学习角度讲
这个区别是本质的
当然
只是聊天
各抒己见罢了
【 在 z16166 的大作中提到: 】
:
: 一样啊，好的作品，不光是作文，包括手工作品，放在展台/橱窗里，那不是让人学习的吗
:
: 不能一个学校、一个老师没那么干，就认为全国的老师都没那么干了吧
:
: 不过，这样讨论下去也没啥结果，就当灌灌水也好
: --
:
发自「今日水木 on iPhone 12 mini」
--
FROM 111.206.214.*