建站
咨詢
售后
建站咨詢
新聞中心
這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
代碼審查：ThoughtBot官方給出的代碼審查指導(dǎo)原則
這篇文章的內(nèi)容由ThoughtBot在github上官方主頁提供，指導(dǎo)你如何在github上進行代碼審查和如果讓別人審查自己的代碼。
針對所有人的審查
- 接受這樣的事實：很多編程上的主張都是一種個人觀點。應(yīng)該討論它們的利與弊，提出你的傾向觀點，迅速的達成一種解決方案。
- 提問，而不是命令。(“把這個變量命名成
:user_id你覺得怎樣？”) - 請求說明。(“我不明白。你能解釋一下嗎？”)
- 避免代碼的歸屬之爭。(“我的”，“不是我的”，“你的”)
- 避免使用一些會被認為是有關(guān)人身特征的詞語。(“笨蛋”，“愚蠢”)要把所有人都看作是有魅力的、聰明的、善意的。
- 要明確。要記著并不是每個人都能理解你的意圖。
- 要謙虛。(“我不能確定——我們來分析一下?！?
- 不要用夸張修辭語。(“總是”，“從不”，“永遠”，“毫無…”)
- 不要諷刺。
- 展現(xiàn)真實的你。如果你不是幽默型的人，不喜歡使用一些表情符號或動畫gif圖，不要勉強。如果你是這種人，請自信的發(fā)揮。
- 如果有太多的“我不理解”或“另一種方案：”的評論，請專門針對這個人進行交流?？梢园涯銈兙€下的交流總結(jié)成一個帖子附在后面。
讓別人審查你的代碼
- 對審查者的建議表示感激。(“謝謝提醒。我會把它改正?！?
- 理解審查是對事不對人。審查的是你的代碼，而不是你。
- 解釋為什么代碼寫成這樣。(“因為xxx原因我才寫成這樣。如果我把這個類/文件/方法/變量改個名會更清晰些嗎？”)
- 整理所作的改動，在以后的迭代中重構(gòu)它們。
- 在做修改的版本上注明代碼審查的鏈接。(“Ready for review: http://github.com/organization/project/pull/1″)
- push提交要基于最早的一輪反饋，并形成一個獨立的分支。等這個分支上的任務(wù)完全完成了再合并。這讓審查者能夠根據(jù)早先的反饋找到你的單獨的更新。
- 努力站在審查者的立場上理解。
- 爭取回復(fù)每個評論。
- 直到最后一個人退出登錄后再合并分支。
- 直到持續(xù)集成測試(TDDium, TravisCI,等)告訴你這個分支的測試套件通過后再合并分支。
代碼審查的過程
先要清楚你提交的代碼的必要性(是修補bug，提升用戶體驗，重構(gòu)…)。然后：
- 針對你感覺非常好的地方以及不是很好的地方與作者交流。
- 找出既能解決問題又能簡化代碼的方法。
- 如果討論變得過于哲學(xué)或理論，把討論轉(zhuǎn)到線下，做成一個有規(guī)律的每周五下午的討論會。同時，是否采用你提出的實現(xiàn)方案，讓作者自己做決定。
- 提出你的實現(xiàn)方案，但要表現(xiàn)出作者也在考慮這種方案。(“你覺得這里用一個自定義校驗如何？”)
- 努力理解作者的立場。
- pull請求登出時，加一個:thumbsup:或“可以合并了”的注釋。
關(guān)于程序風(fēng)格樣式的評論注釋
審查者應(yīng)該對那些不符合樣式指導(dǎo)的地方進行注釋。例如這樣注釋：
- [Style](../style):
- > 按名稱的字母順序排列多個路由。
對上面這個提醒的一個回復(fù)的例子：
- 哦。你眼真尖，謝謝。已在 a4994ec 修復(fù)。
如果你不同意某個指導(dǎo)原則，請在指導(dǎo)repo里創(chuàng)建一個問題，而不要再代碼審查中爭論它。同時，請運用這個指導(dǎo)原則。
英文原文： code review
譯文鏈接：http://www.aqee.net/code-review/
文章題目：代碼審查：ThoughtBot官方給出的代碼審查指導(dǎo)原則
分享網(wǎng)址：http://m.5511xx.com/article/dhidsde.html
