※ 引述《yestheway (LKK)》之铭言：
: 大家有没有遇过这样工程师…
: 我们公司最近在开发新的专案，找了一位新来的工程师帮忙一起做。这个人Coding速度真
: 的很快，交给他的功能很快就能做出来。每个sprint下来，他也一直不停的接新ticket和
: 开发新东西。
: 最近这个新专案终于要上线了，结果QA却测出了一大堆bug！！由于数量真的太多了，但
: 又为了承诺客户如期上线，所以只好把我和其他2个工程师也叫来，一起昴下去帮忙解bug
: …
我也很好奇，怎么你们不一开始就做呢?
: 结果不去看还好，一下去看他里面的code，真的是非常可怕…又臭又长像流水帐一样，结
: 构也是乱七八糟，很多逻辑明显没有想过或设计过硬干去写出来，没有任何弹性和维护性
: ，大家花了非常多时间再改他的程式，真的改的非常辛苦...
这种code chatgpt 是可以代劳的，大概也就是哪样的光景。
为何你们不join?
: （对…我们为了赶这个专案，完全skip code review、skip unit tests 等等。二来 这
: 新专案相对独立，不影响现有系统。所以他commit 什么 就merge什么，闹得今天这下场
: 。我们的例子，正好回应前几篇某些人质疑为何要code review......）
: 最后产品虽然如期上线，但这下好了，老板和PM现在超喜欢这个工程师，后面很多v2 要
: 衍生的新功能，都要叫这位工程师来主导开发…
: 我们几个帮忙“收烂摊子”的人，听到真的有种不好的预感…一来害怕又有更多有问题的
: 程式被他写出来，后面又要花更多时间来修改；二来有种功劳你在接，烂摊子我们在收的
: 感觉…
: 我们原本找主管说这些问题，但目前公司大老板想正积极开发这项产品，他们只希望快点
: 见到结果，似乎也不太在乎原有的开发流程了，只想先快点把东西生出来，给客户demo…
: 各位如果面对这种情况，和这样的工程师该怎么办？公司想快速看到成品，找了一个产出
: 快的人，虽然短期快速看得到成果，但却后患无穷…
这种故事就真的很有趣。
但这位神人在做时，你们在做什么?
为何已经赶成这样了，他好不容易写好，哪你们改他的同时有CODE REVIEW 吗?
有: 谁REVIEW? PM? 老板? 神人? 还是互看?
这不就很神? 有空改写有空测，还有空
REVIEW，还可以用更短的时间完成且没BUG，这绝对是台湾之光。
没: 整篇是想表示你们很神? 因为他写到到快DEAD LINE 了，结果你们可以在这个
更短的时间，将他的重写完，还不用review。神囉.....
还真的是鬼月到讲鬼故事。
至于code review 囉....你是知道怎么做?
IEEE 1028-2008 lists the following review types:[6]
Management reviews
Technical reviews
Inspections
Walk-throughs
Audits
还是你只是 Software peer review?
正式同行评审的程序会定义参与者特定的角色，
进入评审及离开评审的品质准则，在同行评审程序中要确认的软件度量。
在检查过程中，会有以下的角色。
作者：建立待检查工作文件的人。
主持人：领导检查流程的人，主持人规划检查流程，并且进行协调。
朗读者：朗读整份文件的人，一次读出一部份，其他的检查者会指出有缺陷之处。
记录：在检查过程中记录大家找到缺陷的人。
检查者：检查工作文件中是否有缺陷的人。
检查流程中的各阶段包括有：计划、简介会议、准备、检查会议、修正及追踪。
以上中文来自WIKI，和英文WIKI 一致。
工程，还是以结果论英雄。
偏偏由一票没programming 背景的人，发明了一票"方法"，让哪些
傻傻的programmer 去跟，还有人将他们当神拜。
不管agile, code review, 等的源头，都是没/没什么专案实绩的人发明的。
真的除了人月神话。这本书还有20th review 版。