这就是莫明其妙的点，两位没啥实绩的人，出了一本书，胡邹一个方法。
然后一群人拿来当圣经在拜。
这就是外国的和尚会唸经的概念，要是像人月神话的作者这种有实绩就算了。
偏偏没有还当神，就是一堆不没开发过软件的人，拿来唬人用，然后病毒式传开。
说实在的，还真的跟红卫兵没两样。
至于code review，这个也是一个很妙的妙论。
是review 什么? 格式/style? framework/pattern? 正确性?
还是说，科举的殿试，皇上出题，大家来写，皇上来评?
不然，谁有这种美国时间来评?
格式，有formatter。
有没有用OOXX 无敌framework，还是有没有design pattern一下? 啊你能call 不就好了
正确性? 哪要K 他的SPEC? 不会吧。
anything else?

所以问题其实是人 好的人才能把概念落实到实务上篇DrTech板友就指出来了

这行不就这样，一阵子就有新东西，敏捷就刚好名称取个好，下一个猜是low code no code的*

问题是人是一定的了，哪有一种法规是自己会执行的?但重点是，这是两位没实绩的人写出来的东西。

low code我看是不行了啦 他要炒作的时机点刚好在GPT问市之前一点 GPT一出来声量就没救了 错过炒作时机

一个公司的共同 code style 跟老屁股告诉你有什么好用的共同方法库之类的吧像是产 json 的方法那么多，各自都用各自的方法的话有问题的时候又是一笔时间成本

用什么framework 不是在案子开始时定好的?

low code怎会不行,一堆搭上gpt的low code来推销,似乎蛮好用

初看当然好用阿，但真的用下去就知道了...

说到low code 之前的Dreamweaver算不算一种

labview winform 算不算 low code==

Code review当然是正确性优先啊！帮忙抓没考虑到的case，还有是否有遵守共同的style ，其实最主要是互相抓对方的blind spot至于可读性很主观，但我通常会示范怎么写比较简单易懂，取得共识

很多人乱用资料结构，算法乱写，你用code scan tool上找不出问题呀，这时候只能靠code review你看过一堆人检查是否存在用list在那边contains 然后在那边纳闷为什么效能很差就会觉得需要code review

正确性，就需要读需求，就是一份工作两人分。至于效能问题，嗯，台湾的问题不大。

你list都能放进APP了，效能能差到哪...又不是刷题

你没遇过有人把10万个items放进list，然后用contains去找新进来的有没有在list内？还看过更神的还用for loop去做equals比对找item?这样效能不会有问题？

以现在的PC来说，10万不算数字。要能让你明显感觉到基本是50万起。再说contains 的行为和for loop 何异？另外，是否存在，别以为用hash 就一定快。哪还是取决于你的key 的分布如何。

真的遇到再跟我说10万不是数字吧，你的base跟要比对的量都是10万等级的还不是数字吗？

er...真的遇到的是破千万的，十万的一直都不当回事。

十万跑 list 迭代很有感吧

你是写C? java? C#? python? VBS?好说也给个SAMPLE CODE 出来有感一下吧。

蛮猛的 怎么现在连code review都要被翻桌了这不是基本常识吗...没人review 推一个叫做nbNumber的变量上去 你猜猜看是什么意思^^openWheat() function huahaGift是啥^^

哦,连变量命名都出来呢。真的是笑死人。想必你对你做的案子的英文的名词都非常熟，还能中英对照呢.

review最基本要写到第二个人能看得懂 接着确保基本正确性有时间可看有没有更好的写法能提出来 很多时候这个过程帮助产品更好 也是让自己能进步的方式 因为其他成员可能有更好你没想到的方法 教学相长也可以进步牛逼数字 开麦客风 豪华礼物 你答对了吗^^review过的话这些垃圾就不会进去害人害己了

案子不赶，人力很多，高手很自信他的写法更好。review!

很赶的话乔一下review看重点正确性就好了 除非无法忍受的东西不然就别修 或是先注解之后再修也是一个方式之前书上也有讲过了 很多时候写程式写都很快 但看会很久 因为写太烂了 为了写快写一堆垃圾 几周后出问题你回来看可能连你这跟亲爹都认不得 最后还是功德回向到自己身上

看别人的正确性，就是自己没事做，专做这一块.就是人力过剩.要不然,大家都有自己的要写,谁有这命去批改作业,还吃力不见得讨好的. 正如,你认为你的写法比较好,我认为我的没问题，就有人说10万就很有感,我是无感.这时谁来裁决? 有一位全部人都认同的大神来裁决?还是就随他去? 哪reviewer的不爽,改成reviewer的,则原作不爽. 不然再花时间写一个测试, 来评比?benchmarking 来一翻两瞪眼, 时间太多?不是周周要sprint? 这要不要加插进去sprint?

帮人家改作业没必要。但是你是project owner不看的话都不怕人家塞什么垃圾进去吗？

这么怕就不要找这些人一起做囉。再说，我要是想做点什你真的有本事找出来?

Who knows :)

真的能回废话，who knows 有什么好合作的?

code review确实花时间但利大于弊吧，除了正确性外，程式码品质好未来比较好维护，短空长多但如果案子简单以后也不负责维护，那为了抢快省略review感觉也行

总是有很多东西是你讲一下别人会觉得合理就改变的事情吧...万事都要有一个主宰来订定要听谁的？ 我不认为多数时间就review个code分歧会到这么大啦 真的不行也可以找leader来定夺除非你真的认为你的code就是你的code 永远不会有第二人去做修改不太懂内 code review有这么洪水猛兽吗? 我真的蛮意外的

没啊,人力问题,管理问题而已。说白了就是钱的问题.再说, 我也不知什么叫"程式码品质好", 有比较基础?找个opensource 的project 为例吧.还是又 是所胃的leader 说了算这种管理方式?不知两位大神, 看我的opensource code 有没有要加强的.

你回复我的也是废话：）反正你没在担心。

怪拐 你真的分不出好的程式码跟坏的程式吗？算了 可能新手吧 那我无话可说了

我不知什么叫好什么叫坏，你给出来个定义。我是新手.看一下我的PROJECT 吧,请你来评一评。

有一本书叫做 clean code可以去看一下 design pattern 也可以了解一下 什么情境用什么pattern适合 还有基本的solid原则

你还是评一下我的project吧，好让我学习学习你这位大神clean code 的作者，连是位软件工程师这点都没出处.我看还是算了吧.

code review的重点在角色转换和权责划分，你不觉得写code和看code的观点不太一样吗？你要说成本的话，你觉得请一堆资深并信任他们都能做好自己的事，和请一堆一般加一个资深主管做review，哪个比较省？另外code review也有一点训练的意义在再者，code review可以让主管提早发现不同员工负责的模组的之间的问题并及早解决，而不是到串接那天才发现两人牛头不对马嘴或跨过界

不就是,这位天才资深，要弄清楚所有的需求?