: 我們公司最近在開發新的專案，找了一位新來的工程師幫忙一起做。這個人Coding速度真
: 的很快，交給他的功能很快就能做出來。每個sprint下來，他也一直不停的接新ticket和
: 開發新東西。
: 最近這個新專案終於要上線了，結果QA卻測出了一大堆bug！！由於數量真的太多了，但
: 又為了承諾客戶如期上線，所以只好把我和其他2個工程師也叫來，一起昴下去幫忙解bug
: …
我也很好奇，怎麼你們不一開始就做呢?
: 結果不去看還好，一下去看他裡面的code，真的是非常可怕…又臭又長像流水帳一樣，結: 構也是亂七八糟，很多邏輯明顯沒有想過或設計過硬幹去寫出來，沒有任何彈性和維護性
: ，大家花了非常多時間再改他的程式，真的改的非常辛苦...
這種code chatgpt 是可以代勞的，大概也就是哪樣的光景。
為何你們不join?
: （對…我們為了趕這個專案，完全skip code review、skip unit tests 等等。二來 這為何你們不join?
: 新專案相對獨立，不影響現有系統。所以他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 版。
--
open source projects:
https://github.com/terrylao/但這位神人在做時，你們在做什麼?
為何已經趕成這樣了，他好不容易寫好，哪你們改他的同時有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 版。
--
open source projects:
--