ReviewBoard指的是什么

這篇文章主要介紹了ReviewBoard指的是什么，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

1 背景

近來參與一個較大團隊的項目實施，項目的金額幾千萬，人數近百。但是，項目實施后，暴露出以下幾個問題：

（1）質量不佳，團隊成員水平參差不齊，軟件外部質量、內部質量一致性差；

（2）需求不確定，時間非常緊，代碼頻繁修改，越來越丑，效率變低。

為了保證項目按時按質交付，質量改善刻不容緩。因此，在項目的初中期開始，做了以下三件事情：

（1）制定統一的界面規范，制定了統一參考實例，為所有成員進行定期界面規范的培訓和評審；

（2）制定統一的代碼規范，制定了《評審文化構建》、《代碼之丑》PPT，培養團隊的質量文化和評審文化，實施評審；

（3）引入管理工具ReviewBoard。

項目統一構建了標準、規范，有效保證了界面的一致性，但是代碼質量的提高卻不是那么簡單的事情。在這里，我暫不分享項目的情況，未來會通過更加詳細的文章來介紹標準、規范化軟件開發方法對于項目的重要性。

2 ReviewBoard介紹

這里倒是引出了一款優秀工具ReviewBoard。這款工具簡單易用，功能強大。通過 它來實施代碼評審非常有效。代碼評審分為提交前評審（Pre-Review）和提交后評審（Post-Review）兩種方式。提交前評審，即開發人員代 碼變更后，需要提交到ReviewBoard，經過評審通過后，才能提交到SVN源碼服務器，如果沒有通過評審，則代碼提交會失敗，一行都無法提交；提交 后評審，即開發人員先提交代碼，然后再提交變更到ReviewBoard，如果評審未通過，則修改代碼，更新評審直到通過為止。這兩種方式，各有優劣，我 們采用的是后一種，它不阻塞開發人員提交代碼，無法100%控制所有質量，但是可以達到80%以上。

ReviewBoard設計之初更多考慮的是支持Pre-Review方式，因此，存在 以下問題：（1）提交通過后，Review無法自動進行狀態變更為關閉，會與所有通過評審的ReviewRequest混在一起；（2）無法看出未通過評 審的請求進行再次更新，因為如果再次更新后，意味著要進行第二次評審。在管理過程中，會查詢哪些請求沒有通過評審，定期給開發人員發送通知。

因此，我決定對ReviewBoard進行訂制來支持以上功能。不 過，ReviewBoard是基于Python語言和基于Django框架開發，我從來沒有學習過Python，更沒有學習過Django，那如何來修 改？所以，我開始對ReviewBoard做研究。ReviewBoard***版本只能在非Windows運行，我在Ubuntu  14.04安裝部署，同時使用MySQL數據庫。因此，我開始來嘗試做修改。

3 嘗試修改ReviewBoard

3.1 探索***步：數據庫

首先，研究數據庫，驚訝發現其數據庫設計非常的整齊，壓根不需要查看任何文檔即可知道數 據庫的表、字段的意義。我找到了幾個關鍵的表，分別是reviews_reviewrequest，看看其字段，與界面顯示幾乎一致，一下子就明白什么意 思，順著字段意思，找到了另外的兩個關鍵表diffviewer_diffsethistory、diffviewer_diffset。查詢一下這些表 的數據，我很容易來解決***個問題，通過一條SQL語句即可將通過評審的ReviewRequest關閉，這樣就不需要查看到這些評審請求了。

3.2 學習Python并修改代碼

接下來的第二個問題，需要修改代碼，我花了3個小時學習了Python，通過在線的英文幫助，直接在控制臺做實驗，學習基本語法結構、學習類與對象編程、學習了Python模塊與編譯，對Python初步熟悉之后，我決定開始來進行代碼修改。

因此，我先通過相似列“Submitter”對所有文件進行查詢，通過它很快找到了 columns.py和grids.py這兩個文件，看了代碼之后，發現ReviewBoard的評審請求通過這兩個文件來實現，進行再次查詢名稱沒有再 發現關聯文件了。通過這兩個文件，可以發現，columns.py用于定義要顯示的所有的列，grids.py進行列的組合和顯示。那么接下來可以簡單的 進行模仿添加一個列了。該列定義為Diffs。

簡單說明一下，我定 義了DiffSetCountColumn類，繼承于Column類，類初始化方法為__init__，相當于構造器。這里的self是以前經常使用的 this，定義了兩個方法，一個是augment_queryset，用于當前列的數據顯示，定義名稱為mydiffsetcount，另外定義一個方法 render_data，即在表格中展現數據。這里參考了其它列定義。

接下來在grids.py中聲明對該列的使用，非常簡單。

25行新增：

DiffSetCountColumn,

99行新增：

diffset_count = DiffSetCountColumn()

接著重啟Apache服務器，可以簡單測試，驚訝發現可以工作了。

3.3 再進一步添加功能

有了這次嘗試，我接下來想再進一步來定制。目前各個小組提交到不同的SVN地址，通過SVN可以區分各個組提交情況。但是ReviewBoard沒有針對SVN地址的過濾。

首先修改columns.py，修改Repository列。

在這里更改該列支持Link，接著定義 link_to_object函數，這里找了一段時間，發現local_site_reverse可以用于獲取需要的url，然后再與url組合，一開始 沒有使用urlencode，一直無法正常呈現。由于原來在ASP.NET中，使用過urlencode，知道這里面有坑，就網上查詢了Python的 urlencode，然后解決之，發現可以工作了。不過，下一個問題來了，即鏈接后，如何進行過濾？這里發現其“show  closed”過濾功能，通過代碼查詢，知道在grids.py中，如何工作，那么，添加過濾也就不難了。如下。

grids.py 第116行

self.repository_query = ‘'

grids.py 第133行

      self.repository_query = self.request.GET.get('repository', '')       

      if len(self.repository_query) > 0:

           self.queryset = self.queryset.filter(repository_id=int(self.repository_query))

4 ReviewBoard令人震驚的優秀代碼基因

順利修改之后，我大為震驚，為ReviewBoard這款優秀的軟件說嘆服。為什么能夠 在1天時間里面，從Python學習到對一個完全黑盒子的軟件進行修改？答案就是ReviewBoard具有非常整潔的代碼。也就是 說，ReviewBoard擁有非常優秀的內外部質量。

數據庫設計，簡單清晰，結構非常清晰，可讀性很強，根本不需要任何數據庫文檔。文檔是多余的！！！

代碼風格非常一致，我們發現ReviewBoard的注釋非常少，Bob大叔的《代碼整 潔之道》強調了注釋是代碼意圖表現失敗的補充，***的代碼是一行注釋都不要。ReviewBoard的命名，從前到后都非常一致，大小寫、下劃線、類名、 方法名規則統一，命名準確無誤，沒有不專業的命名，沒有不專業的縮寫。ReviewBoard的類都非常簡單，在columns.py這個文件，你可以發 現每一個Column基本都在50行以內，每一個方法也非常簡單。ReviewBoard非常***的踐行了單一職責，清晰的告訴我，要完成什么任務可以通 過哪些類、哪些方法、寫什么樣代碼來完成。ReviewBoard代碼風格非常優秀，沒有丑陋的縮緊，沒有丑陋的擁擠，在該有空格的時候空格，在該有空行 的時候空行，在該縮緊的時候縮緊。這里，我看不出任何代碼腐敗的味道。跟著這種優秀的軟件“混”，我也很難寫出差的代碼。

在寫代碼這件小事上，可能很多人眼里只有架構、框架這類東西，可是實際上，很多工作多年 的程序員，代碼依然是狗屎一樣，沒有規范的風格，沒有良好的編碼習慣。很多人能夠去完成一件工作，但是，不漂亮。在沒有意識的情況下，隨著時間推移，只是 做的丑事更多而已。從我的編碼經驗，可以總結出一個程序員現狀，1～3年的開發人員，處于混亂狀態，他們能完成功能就不錯了；3～5年的開發人員，有些抽 象意識，但是，一種是走向黑客，代碼抽象的只有自己和上帝看得懂，一種是變得專業，傾向編寫一些讓團隊其他人員看得懂的代碼，還有一種就是保持現狀；5年 之后，開發人員又是三類，一類走向管理，也是不錯選擇，一類走向更高的技術路線如架構師或者專家，還有一類，就是變成廢物，隨著時間的推移，他們越來越沒 有空間，越來越沒有價值。一般而言，通過培養，年紀越輕的人，成長越快，越有前途，要提升他們的水平，代碼評審是最有效的方法，通過評審和培訓讓他們知道 什么是美、什么是丑，什么是優秀、什么是低劣。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“ReviewBoard指的是什么”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!