This topic has been archived. It cannot be replied.
-
工作学习 / 事业工作 / 你们公司有强制code review的吗?
-less_is_more(二剑霜寒廿八坛);
2021-11-29
(#14146624@0)
-
小公司没有那么多繁文缛节,但写出的code不reliable,大公司peer code review是必须环节吧。元芳,你怎么认为?
-googoo2(Tuzki);
2021-11-29
(#14146651@0)
-
我们是开始code review,我的意见是这是对员工的不信任,而且项目这么大,没时间看别人的code,最主要的是没有pay for it。
fb就没有code review,google也是要求balanced
-less_is_more(二剑霜寒廿八坛);
2021-11-29
{45}
(#14146657@0)
-
一般 PR 都得加个 code reviewer ---- 是 mandatory 还是 optional, reviewer 的级别,容易不容易过才是公司/项目的区别。另外,有 code review 其实是帮 coder 分担责任的。
-xmlhttprequest(build5381);
2021-11-29
(#14146665@0)
-
我说,你们请一个专门做code review的,否则code review成了人情账了。还有,code reviewer并不承担责任,这是SOP里明确的。
-less_is_more(二剑霜寒廿八坛);
2021-11-29
(#14146673@0)
-
一般来说,code review 由 team lead 来做,这是一个 authority 的问题。
-xmlhttprequest(build5381);
2021-11-30
(#14147564@0)
-
code review肯定多花时间多浪费情感,不加钱没人愿意做
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14147968@0)
-
FB没有?难怪是铁打的营盘,流水的码工。对老员工,code review也许作用不大,但新员工还是需要老员工做code review的
-googoo2(Tuzki);
2021-11-29
(#14146667@0)
-
有code review的大公司主要还是靠review tools,developer之间谁服谁?一个括号都能argue半天
-less_is_more(二剑霜寒廿八坛);
2021-11-29
(#14146676@0)
-
逻辑问题review tools也可以吗?
-googoo2(Tuzki);
2021-11-29
(#14146679@0)
-
你以为code review能解决逻辑问题?读code要比写code还烦。
-less_is_more(二剑霜寒廿八坛);
2021-11-29
(#14146681@0)
-
改bug就容易吗?不也得读code,有的时候review code还要本地运行才能理解逻辑
-googoo2(Tuzki);
2021-11-29
(#14146690@0)
-
您这不是code review了,是检查作业……
-guestagain(guest again);
2021-11-29
(#14146708@0)
-
没有code是bug-free的,不review code让QA测试也可以,而且还能创造更多就业机会,码工也不担心下岗了,因为没有bug-free
-googoo2(Tuzki);
2021-11-29
(#14146712@0)
-
呵呵,我觉得您对code review有误解……
-guestagain(guest again);
2021-11-29
(#14146728@0)
-
那你的理解是。。。?
-googoo2(Tuzki);
2021-11-29
(#14146740@0)
-
你说的有道理, 但review tools开发时间长,难以跟上最新的发展。例如现在log里不能log PII, 要肉眼检查,非常痛苦。
-sxffff(lookingforjob);
2021-11-29
(#14147178@0)
-
当然要在 code review *之前* 定好 standard, code review 是执行 standard,要是 code review 还 argue 括号,整个 process 有问题。
-xmlhttprequest(build5381);
2021-11-30
(#14147600@0)
-
那要QA干啥?
-googlebot(bot);
2021-11-29
(#14146709@0)
-
QA只管测试结果,不管code。其实会写code不代表写得好,能不能做到best practice还是大不一样的。还有些老系统经过多年多人的维护,管理不善,还没有文档,或者文档极少或太老,一大堆垃圾code,谁接手都是烂摊子。从一开始就好好管理的话,后期管理维护都省很多事。当然也有些人以没有时间作为quick & dirty的借口,故意写成垃圾code,加大后期维护的难度,以巩固自己的job security,不过这种手段很容易搞成人人头疼的垃圾项目,靠玩这种手腕的人的技术和人品可靠性都不好说。这样的人确实有
-coca-cola(可乐);
2021-11-29
{442}
(#14146828@0)
-
那review有啥用,还不如QA有用,
-googlebot(bot);
2021-11-29
(#14146840@0)
+1
-
有用肯定是有用的,但就是事倍功半,剥削developer的工作时间。同时减少job security。
-less_is_more(二剑霜寒廿八坛);
2021-11-29
(#14146846@0)
-
很多人的coding standard不一样,windows developer和linux的格式就完全不同,谁都认为对方的code是garbage。
-less_is_more(二剑霜寒廿八坛);
2021-11-29
(#14146844@0)
-
Code review 是尽早发现问题,改进问题。从公司的角度看,成本最小。
-fourseasonscan(有话直说);
2021-11-30
(#14147474@0)
+2
-
很搞笑,code review能发现bug?明显不可能的,
-googlebot(bot);
2021-11-30
(#14147508@0)
-
code review已经和Agile一样,变成包治百病的工具了……
-guestagain(guest again);
2021-11-30
(#14148005@0)
-
印度人(追捧)的方法,火箭飞机都掉地上。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148014@0)
-
我的工作不写code,但是每一个 design change 都需要 peer review,哪怕是很小的变动,最少需要一周多才能release 给代工厂,请 peer review,审查人要用几天了解来龙去脉,别人让我review我也得查查历史了解这段为什么需要改改的对不对。有理论说八哥越早发现代价越小,最好release之前发现, 否则 Release 后发现再 recall ,要给从代工厂到仓储到分销商到最终用户某种补偿,花费大了去了。
-w4b(w4b);
2021-11-29
{143}
(#14146854@0)
+1
-
最重要的,代码的bug是review不出来的,只能run才能发现,
-googlebot(bot);
2021-11-29
(#14147034@0)
-
我的习惯是在production上直接改代码,没人查。在中国和在加拿大都如此。
-iamflying(叶和花);
2021-11-29
(#14146940@0)
+1
-
你这个太牛了
-keysi(K.S);
2021-11-29
(#14147063@0)
+1
-
分析数据和train model必须用真数据,这个只有production上才有。
-iamflying(叶和花);
2021-11-30
(#14147675@0)
-
也不是完全没有,我们这里有个俄罗斯人,自己管了个.net的程序,就自己经常在上面改
-keysi(K.S);
2021-11-30
(#14147899@0)
-
出问题后悔都来不及。
-343(讨个老婆姓熊);
2021-11-29
(#14147197@0)
+4
-
便利店数据?
-guanshui88(约定);
2021-11-30
(#14147721@0)
+3
-
没有便利店的数据。如果能拿到Dollarama的销售数据,那可是一个宝库,可以做很多分析用来提升销售和利润。
-iamflying(叶和花);
2021-11-30
(#14148563@0)
-
这个难道不是必须的
-keysi(K.S);
2021-11-29
(#14147041@0)
+2
-
不是。软件工程里面说过两件事:code review不是必须的,因为这是主观检测。还有一件事不方便说。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14147469@0)
-
unit test只能测试function level是不是work, code review能保证写的是不是符合规范和best practice,一个人写一样,以后根本没法儿维护
-keysi(K.S);
2021-11-30
(#14147909@0)
-
什么叫best practice? 见过日本人写的程序,一个函数只能一个出口,这样的人工智能也是弱智,所以日本的软件行业日薄西山
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14147950@0)
-
那是必须严格实行的
-tuteng(闻风而动);
2021-11-29
(#14147059@0)
+1
-
rolia 的 coder 很多大牛 ---- 人均 40 万,反 agile 反 code review... lol
-xmlhttprequest(build5381);
2021-11-30
(#14147602@0)
+4
-
还有,直接修改生产系统代码和数据。
-remdesivir(larevo);
2021-11-30
(#14147605@0)
+1
-
我都是小刀直接刻硬盘。现在都改成云服务我就失业了
-moonhalf(减肥减多久);
2021-11-30
(#14147788@0)
+2
-
买个电话 modem,嘴里发出 56k 的啸叫声,想连哪朵云都行 -- 试试看,你一定行的 👏👏👏
-xmlhttprequest(build5381);
2021-11-30
(#14147865@0)
+1
-
废话,我的code他们能看懂? 我做的事和别人讨论也是对牛弹琴一样
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14147922@0)
-
写的 code 别人看不懂并不是值得骄傲的事情 -- 而且这正是 code review 的原因之一:code review 是要确保 code 符合规范,简洁,易懂,可读可维护,DRY,等等等等。
-xmlhttprequest(build5381);
2021-11-30
(#14148210@0)
+1
-
只能说行业不同就不同,软件看的是思想,不是数据结构
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148246@0)
-
软件就是要把思想通过数据结构和流程呈现出来 --- 否则那叫 paper... 很多公司请了大学教授 / 科学家来做 r&d,但进 production 的 code,该怎么来还得怎么来...
-xmlhttprequest(build5381);
2021-11-30
(#14148261@0)
-
必须有的,而且太重要了。面试的时候不但会有关于code review的exercise, review进行中还会问到关于code review的best practice, attitude, etc. 的问题。这部分出问题基本上是deal breaker.
-dandandoudou(doudan);
2021-11-30
(#14147618@0)
+1
-
所以这事已经在软件行业形成了割裂
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148032@0)
-
必须的。你是不是每次都被别人打回来。
-cricketkiller(白牙青);
2021-11-30
(#14147741@0)
+1
-
我一般下班后checkin 这样一定会miss nightly build,qa第二天就没法检测
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14147938@0)
-
掩耳盗铃,太自信了并不好
-cricketkiller(白牙青);
2021-11-30
(#14148034@0)
-
自信不自信每个人的责任并没有改变
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148040@0)
-
估计是老虎的PG摸不得,摸老虎头也是心慌慌,人家吓得汗水都把衣服湿了
-googoo2(Tuzki);
2021-11-30
(#14148013@0)
-
昨天晚上1点多一个senior director起夜帮我把checkin approved。哈,然并卵,nightly build 早就开始了。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148020@0)
-
对啊,architech的code reviews就是走形式,没有实际意义,但commit code需要有人approved,才能ship
-googoo2(Tuzki);
2021-11-30
(#14148031@0)
-
二黑是文科男,矫情着呢
-cricketkiller(白牙青);
2021-11-30
(#14148038@0)
-
不通过review就不能merge。难道还有不走这个流程的吗?
-infinity7.1(notailor);
2021-11-30
(#14147751@0)
-
fb就没有code review,google也是要求不影响生产进度上的balanced,msft有一大套工具不需要人工review
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148024@0)
-
fb 没有 code review? 给个链接?最后一句是对的 -- 如果有工具可以降低人工 code review --- 但那不是 “没有 code review”
-xmlhttprequest(build5381);
2021-11-30
(#14148233@0)
-
我说的code review当然只指人工review,否则有啥讨论的必要
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148250@0)
-
process完善的大公司都有且是必须的,小公司一人身兼数职的那种不好说
-clear(clear);
2021-11-30
(#14147907@0)
+1
-
我们是大公司但我做的事是专家级的,没5年以上的经历别想动我做的一块
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14147928@0)
-
那真是找不到qualified reviewer给你review😊
-clear(clear);
2021-11-30
(#14147970@0)
-
你是architech?我公司的architech是个老同志,头顶光光的,感觉就是绝顶聪明,跟你一样不?以前国内南方某大学CS教授。他的code也有人review,不过就是象征性的review
-googoo2(Tuzki);
2021-11-30
(#14147996@0)
-
architect 手里应该没有code,我们group没有architect,另一个兄弟group因为做portal的就有一个architect,上任后把手里的coding全推给我们了,等同于重新分割界限。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148002@0)
-
各个公司不一样,以前一个公司architech整天写pseudocode和document,那个公司要遵守ISO9000标准,每个function都有pseudocode。现在这个公司architech一样coding
-googoo2(Tuzki);
2021-11-30
(#14148012@0)
-
没有专门的tech writer?
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148028@0)
-
大公司都有tech writer,但那个技术要求就低些
-googoo2(Tuzki);
2021-11-30
(#14148033@0)
-
除非是开发卷宗,连white paper都是tech writer写。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148048@0)
-
architect还写code?
-infinity7.1(notailor);
2021-11-30
(#14148621@0)
-
流程越多越好,增加就业。俺们写2行code,可以养活20多人的team。
-iga(nikita);
2021-11-30
(#14147983@0)
-
有的产品比如做网站大家都懂,code review没啥特别的负担,在扫描软件处理后还有需要人工review的,必须下功夫去了解功能结构,不增加人工必然不行。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148007@0)
-
code review 是个质检手段。难怪737 max 那么容易摔下来,这个行业居然有人认为质检都是多余的?
-liaison01(红桃A);
2021-11-30
(#14148309@0)
+1
-
737max为啥掉?因为是印度人编软件,他们还掉卫星。印度人都是agile一套,做出来的各种网站一年比一年慢,还每周都要要下线维护。
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148318@0)
-
现在有不是agile的吗?
-infinity7.1(notailor);
2021-11-30
(#14148626@0)
-
code review其实可以分担责任。我以前工作的大公司有code review的要求,不同组不同code要求不一样。前台程序做得严。后台程序不严,自己找个人看一遍就行。我现在的职位没人给我review, 我也尽量把code 和schedule多发几个人,给自己免责。
-piglet(小猪);
2021-11-30
(#14148360@0)
-
code review不分担责任,这是SOP里特别说的,否则谁愿意主动去做code review的事
-less_is_more(二剑霜寒廿八坛);
2021-11-30
(#14148366@0)
-
谈虚的没用,就是政策和common sense。我以前的公司规定是review过的code出了事儿个人没责任,没有review过的code自己全责。互相review, 工作的一部分。我现在的职位只我一个人,出了事儿我全责,如果没有任何人知道我做了什么,头儿是啥印象不用说了吧。
-piglet(小猪);
2021-11-30
(#14148374@0)
+2
-
Code review 不分担责任 -- 给个 link? 好像和Google code review standard 说得不太一样。
-xmlhttprequest(build5381);
2021-11-30
(#14148510@0)
-
想这样做,但是时间和人力成本不允许,放弃了
-webx(joy);
2021-11-30
(#14148671@0)