[心得] Google 如何進行 Code Review

看板Soft_Job作者 (黑人)時間4年前 (2019/09/07 19:48), 4年前編輯推噓40(41推 1噓 5→)
留言47則, 43人參與, 4年前最新討論串1/1
Blog 好讀版: http://bit.ly/how-to-do-a-code-review 最近 Google 釋出內部如何進行 code review 的相關文件! 這兩天花了點時間作翻譯 文章共分為六篇: * 程式審核準則 * 程式審核過程中要看些什麼? * 審核中該如何在 CL 巡航 * 程式審核的速度 * 如何寫審核評論 * 如何面對被推遲處理的評論 文章內容對於原文的翻譯外，亦有個人對於內容的理解 另外，加入自己在貢獻開源軟體中瞭解到的事情 自己本身並非專業譯者，文句可能不通暢或出現錯誤 分享給大家，也請各位多多指教與指正 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.136.251.13 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1567856937.A.C4F.html
推
09/07 19:58, 4年前 , 1F
推用心！
09/07 19:58, 1F
推
09/07 20:03, 4年前 , 2F
感謝分享
09/07 20:03, 2F
推
09/07 20:25, 4年前 , 3F
推用心！！
09/07 20:25, 3F
推
09/07 20:33, 4年前 , 4F
推！
09/07 20:33, 4F
推
09/07 20:33, 4年前 , 5F
推!
09/07 20:33, 5F
推
09/07 21:07, 4年前 , 6F
感謝分享
09/07 21:07, 6F
推
09/07 21:28, 4年前 , 7F
感謝分享 += 1
09/07 21:28, 7F
推
09/07 21:47, 4年前 , 8F
++感謝分享
09/07 21:47, 8F
推
09/07 21:50, 4年前 , 9F
感謝分享
09/07 21:50, 9F
推
09/07 22:00, 4年前 , 10F
謝謝分享
09/07 22:00, 10F
推
09/07 22:07, 4年前 , 11F
推
09/07 22:07, 11F
推
09/07 23:01, 4年前 , 12F
推
09/07 23:01, 12F
推
09/07 23:07, 4年前 , 13F
讚
09/07 23:07, 13F
推
09/07 23:18, 4年前 , 14F
推
09/07 23:18, 14F
推
09/07 23:44, 4年前 , 15F
推
09/07 23:44, 15F
推
09/08 00:09, 4年前 , 16F
推
09/08 00:09, 16F
噓
09/08 02:34, 4年前 , 17F
這套系統不是大家都適用 你的公司太小這樣玩會死
09/08 02:34, 17F
個人不完全認同因為「小」而否定內容所提及的幾個原則 規則是死的，它可以根據不同狀況來改變 我相信服務出包這件事，不管大小公司都是很嚴重的問題 因此人數少的話，能做的改變可能是較為寬鬆的審查流程 比方說只檢查會造成嚴重問題的設計，確保服務不會出現狀況 另外，當工作年資增加時越會需要習得相關「軟」技能 畢竟職位越往上越強調相關的技術，而非開發速度多快來決定 分享自己的想法，給各位參考看看 :)
推
09/08 02:48, 4年前 , 18F
感謝翻譯分享
09/08 02:48, 18F
推
09/08 03:04, 4年前 , 19F
Google如何QA: 就是多請一個SEQ.
09/08 03:04, 19F
→
09/08 03:05, 4年前 , 20F
不過全球級的產品預算投多點合理。不然出包影響範圍很大。
09/08 03:05, 20F
推
09/08 07:17, 4年前 , 21F
推
09/08 07:17, 21F
推
09/08 09:47, 4年前 , 22F
推
09/08 09:47, 22F
推
09/08 10:50, 4年前 , 23F
推推
09/08 10:50, 23F
推
09/08 11:08, 4年前 , 24F
這種東西都比不上老闆一句：我明天就要
09/08 11:08, 24F
推
09/08 11:31, 4年前 , 25F
推 謝謝分享
09/08 11:31, 25F
推
09/08 11:54, 4年前 , 26F
推
09/08 11:54, 26F
推
09/08 12:38, 4年前 , 27F
推，感謝分享
09/08 12:38, 27F
推
09/08 13:59, 4年前 , 28F
推，無關小不小，這是開發者的自我成長
09/08 13:59, 28F
推
09/08 14:00, 4年前 , 29F
推
09/08 14:00, 29F
推
09/08 14:26, 4年前 , 30F
感謝分享
09/08 14:26, 30F
推
09/08 17:19, 4年前 , 31F
推, 好文章
09/08 17:19, 31F
推
09/08 19:30, 4年前 , 32F
push
09/08 19:30, 32F
※ 編輯: life1347 (223.136.188.228 臺灣), 09/08/2019 19:39:08
推
09/08 21:10, 4年前 , 33F
感謝分享
09/08 21:10, 33F
推
09/08 22:34, 4年前 , 34F
值得參考, 不知道實際上在內部執行狀況如何?
09/08 22:34, 34F
根據個人經驗來說蠻有效的 很多文章內的技巧 我是透過翻閱 github 上大型專案的 review comments 加上跟其他人共事所獲得的經驗 但實際執行效果，每家公司各有不同 XD 能肯定的是有持續保持下去，而非三天打魚兩天曬網 過陣子會像文章內 speed of code review 所說的 審核速度加快、程式品質、同事素質會提高 當然一開始要導入非常嚴格的審核一定會造成反彈 建議標準從鬆然後逐日變緊，這樣大家程度也能逐漸跟上步伐 ※ 編輯: life1347 (223.136.188.228 臺灣), 09/08/2019 23:44:03
推
09/09 21:32, 4年前 , 35F
推
09/09 21:32, 35F
→
09/09 23:40, 4年前 , 36F
然後Android SDK證實這個方式也不會讓程式品質更好
09/09 23:40, 36F
推
09/10 10:46, 4年前 , 37F
好麻煩的感覺 如果更動到style跟function 還要分兩次
09/10 10:46, 37F
→
09/10 10:46, 4年前 , 38F
進... 不過嚴謹也是對啦
09/10 10:46, 38F
推
09/10 18:24, 4年前 , 39F
可以給幾個不錯的 review comments 的連結嗎?
09/10 18:24, 39F
建議直接找大型 open source 專案看 比方說出自 google 的 kubernetes https://github.com/kubernetes/kubernetes/pull/82289 類似這種多人參與的 review 就會不錯 ※ 編輯: life1347 (223.140.105.204 臺灣), 09/10/2019 22:52:14
推
09/11 02:48, 4年前 , 40F
推
09/11 02:48, 40F
推
09/11 11:56, 4年前 , 41F
推
09/11 11:56, 41F
推
09/11 21:50, 4年前 , 42F
推
09/11 21:50, 42F
推
09/12 22:12, 4年前 , 43F
推 謝謝分享
09/12 22:12, 43F
推
09/17 12:20, 4年前 , 44F
推 感謝分享
09/17 12:20, 44F
推
09/18 23:42, 4年前 , 45F
推
09/18 23:42, 45F
→
09/20 01:52, 4年前 , 46F
內部執行很單純:客觀且對事不對人
09/20 01:52, 46F
→
09/20 01:52, 4年前 , 47F
能做到大概就會遵守準則了
09/20 01:52, 47F
‣ 更多 life1347 的文章
文章代碼(AID): #1TSvafnF (Soft_Job)