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指的是什么”這篇文章對大家有幫助,同時也希望大家多多支持本站,關注本站行業資訊頻道,更多相關知識等著你來學習!