×

Loading...

@Ottawa

Topic

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。 -less_is_more(二剑霜寒廿八坛); 2021-11-29 {45} (#14146657@0)

        fb就没有code review，google也是要求balanced
        • 一般 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只管测试结果， -coca-cola(可乐); 2021-11-29 {442} (#14146828@0)
        不管code。其实会写code不代表写得好，能不能做到best practice还是大不一样的。还有些老系统经过多年多人的维护，管理不善，还没有文档，或者文档极少或太老，一大堆垃圾code，谁接手都是烂摊子。从一开始就好好管理的话，后期管理维护都省很多事。当然也有些人以没有时间作为quick & dirty的借口，故意写成垃圾code，加大后期维护的难度，以巩固自己的job security，不过这种手段很容易搞成人人头疼的垃圾项目，靠玩这种手腕的人的技术和人品可靠性都不好说。这样的人确实有
        • 那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我也得查查历史了解这段为什么需要改改的对不对。 -w4b(w4b); 2021-11-29 {143} (#14146854@0) +1
      有理论说八哥越早发现代价越小，最好release之前发现， 否则 Release 后发现再 recall ，要给从代工厂到仓储到分销商到最终用户某种补偿，花费大了去了。
      • 最重要的，代码的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)

More Topics

  • 大统华：这一段是讲，我得罪杂货部主管，他跟踪我
  • 大统华：是时候发出这个会议的录音了（绝无删节及后期制作，因为录音是大统华hr录了邮件发给我的，删节就是自我打脸，没那个胆）
  • 新形势下，推娃就得往南推
  • 送菜哥诉大统华:咬咬牙，请个高水平翻译
  • 这个在TD银行做data scientist的印度裔年轻人，在社媒宣传拿免费食品，真因为这件事情被炒？
    • 枫下论坛主坛 /  工作学习 /  事业工作