Re: [轉錄] Code Review: 大家都應該做的事情
此篇純粹是讀後感。
看了這串討論，能看見一些不同的心態：
除了 Code Review 是有用的 vs Code Review 是無用的，
我比較注意到『公司又不重視程式碼的品質』這個想法。
回想起我首次接受別人 Code Review 的情況：
是在參與 Open Source 專案開發的時候，
那時參與的是 Eclipse Plugin 的開發。
開發的流程為：
1. 當實作新功能、或 bug fix 時
1.1 認領 ISSUE
1.2 請依規則建立獨自的 branch 在上面實作。
2. 當實作完成後
2.1 利用 Google Code 的 Code Review Issue Template 建立 Code Review Request
2.2 指定熟悉該問題的其他開發者為主要 Reviewer
2.3 等待其他開發者 feedback 或是投票 (+1 贊成 -1 反對，或沒意見)
3. 獲得 Feedback
3.1 至少得獲得其他 2 名開發者投票贊成才能進行合併 branch 的動作
3.2 若有人提出修改意見，請建新的 branch 重新進入 Code Review 循環
此網址為投票頁面的範本：
http://code.google.com/p/opensocial-development-environment/
source/branch?spec=issue94&branch=%2Fbranches%2Falbert%2Fplugins%2F20090917a
先前參與這個 Open Source 的專案主要是能體驗一下比較完整的協作流程，
也能獲得參與開發的 Google 工程師替自己 Code Review 的機會。
而那一陣子 Code Review 的經驗，主要是即使參與的人都有一定程度的實作能力，
但我們並不是非常熟悉實作對象 Domain，
或是經由被 Review 大家能在不經意間貢獻出比『土法煉鋼』更好的方法。
畢竟也沒人全懂 Eclipse Plugin 這座寶山內的好貨，
可能只是在追程式碼時，突然看到『啊！原來能這麼寫呦』的激動，
突然能被分享出來是多麼快樂的經驗。
而這個專案的開發流程，是偏向於預防性的。
至少對經驗不是那麼足夠的我們來說，
太糟糕的實作，不會污染原來的程式品質。
然而，在真正的工作情境中，我比較少遇到 Code Review 的情況，
但我有辦法主動要求有經驗的實作者協助我。
處理一些我不太擅長的議題，像是多執行緒程式的撰寫，
我目前還有所不足，但我能借用老手的眼睛來檢視我的陷點。
對於請求協助、給予協助我一向是很積極的。
大家在一條船上，要有點公德心，別開個小洞悶著不說，
等到水淹到腳了就補得很痛苦。
表現這些積極的態度，是期待能在氣氛上傳達出去。
雖然一開始大家不太好意思說有問題，
但漸漸的大家願意承認，自己正在鬼打牆，需要人幫忙。
不過這距離我期望中的『氣氛』還有些距離，
但其實無所謂，這比起什麼都不做好太多了。
即使大部分的時候 Code Review 不是自然、主動地，
而公司方面對於程式品質有一定的想法，
但沒有太多實際的強制規定，
不過我還是做我想做的，
寫點測試、加新 Feature 前，先 Review 一下，
有沒有需要先 Refactoring 的地方。
沒有人要求，我也會繼續下去。
因為我是個『修行者』。
堅信：
我們不能用本能膚淺理解出來的土法煉鋼方式，來從事謀生之經濟行為。
這樣的行為一點都不『經濟』。
公司、老闆有沒有要求什麼的，都無關緊要。
面對這份職業，你有將自己提昇至專業等級的覺悟嗎？
不然就不要用那土法煉鋼的手法來估量程式是否能寫一輩子。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.231.54.215
推
08/18 23:22, , 1F
08/18 23:22, 1F
推
08/18 23:37, , 2F
08/18 23:37, 2F
推
08/18 23:54, , 3F
08/18 23:54, 3F
→
08/19 00:03, , 4F
08/19 00:03, 4F
→
08/19 06:44, , 5F
08/19 06:44, 5F
推
08/19 12:53, , 6F
08/19 12:53, 6F
推
08/19 20:01, , 7F
08/19 20:01, 7F
推
08/19 20:17, , 8F
08/19 20:17, 8F
討論串 (同標題文章)
完整討論串 (本文為第 11 之 18 篇)：