原文  Case Study: Upsource in Miquido   ESAST CO LTD 為 JetBrains台灣經銷,獲授權翻譯

Upsource幫助我們的行動應用程式很棒

Radoslaw Holewa
我的名字是 Radoslaw Holewa ,我是Miquido 的共同創辦人與CTO。Miquido是家行動應用開發公司,做業務導向的應用開發,客戶包含Skyscanner、Aviva、 HelloFresh、Nestle 及更多。 這篇文章我將分享我們公司內的程式碼審查過程與為什麼程式碼審查對Miquido開發非常重要。

程式碼審查能幫助程式品質的改善, 產出高品質的軟體,這是眾所週知的。但程式碼審查(code review)對軟體開發公司而言是否能加速知識的擴散並不是哪麼明顯。 這裡我將分享我們運用Upsource做程式碼審查,所獲得的不僅提升了品質,也升級了我們開發者的學習曲線。

處理程序

首先,讓我先說明一下背景以及我們的處理程序。 每個在Miquido跑的專案都根據Scrum軟體開發程序進行,核心採用JetBrains工具。我們有2星期長的衝刺(sprint)、每日站立會議、展示會期(demo sessions)、夜間建置(night build)以獲得客戶回饋…等。當然,我們也做每日程式碼審查。程式碼審查在每天早上進行,每單一工作日開始, 當工程師剛抓了一杯咖啡看完重要emails後立即做的第一個任務。

通常這會花個 10-20 分鐘來審查昨天所做的變更。 我們採用git-flow的流程,所以我們的工程師審查變更大多都在功能支線(feature branches)上, 在被合併前的支線。 我們的審查是在提交之後(post-commit approach)。 你也許會問為什麼呢? 我將於後面告訴你更多。

程式中少些瑕疵(bugs)等同於專案會更加順利

第一,很明顯的,自從我們開始做程式碼審查, 有實行審查的專案比沒有實行的專案順利許多。其實要比較不同的專案並不容易,因為每個專案有它不一樣的困難點。 找到正確的程式碼審查效能的度量也很難。仍然,整體做過程式碼審查(code review)的專案的結局多比較沒什麼痛苦,沒有花太多時間在測試與解決瑕疵(bug-fixing)。

當然,不能說這些專案就完全沒有瑕疵(bug-free)。這只是說少了很多在第一眼就發現的瑣碎問題,避免了測試者與開發者間來來回回的乒乓球遊戲。這反應在測試人員少花很多時間做測試與回報瑕疵 ,專案管理人員花在管理問題的間接成本也大幅將低,而且開發者也少花很多時間解決瑕疵。

這是很顯著的進步,不過對我來說這還不是我導入程式碼審查主要的目的。

學習曲線顯著地改變

我們觀察到開發工程師的進步比以前快很多,尤其是資淺的工程師。取代有可能因為沒做程式碼審查造成他們一再重複不好的實踐方法,我們直接教他們什麼是好的寫法,很快他們就知道什麼是好的實踐並瞭解要如何來運用。

這對於需要高度技術能量的團隊有很大的幫助,尤其在找到好的開發人員很困難的時候,這好處特別珍貴。

將專案整體的知識傳播給整個團隊

一個模組由你團隊的某一開發者持續做了兩個月,當他或她去度假,剛好發現了其負責部份很嚴重的問題,但沒人對那部份的程式碼有所了解。 聽起來很熟悉吧?

程式碼審查可以避免這樣的事情發生,因為平時專案中的知識已經交流過。在Miquido,每一位開發者的程式碼每天都給不同的團隊成員審查過。 如此所有團隊成員都有足夠的知識跳進其他人的程式碼救火 。

程式碼審查提升工作動機

動機對於我們工作有很大的影響。 每個人都想要做出很棒的作品,往對的方向前進的感覺。 一個產出糟糕程式碼的專案很讓人洩氣,這已經不是什麼秘密了; 如果開發者因為災難的專案想要換工作也不是稀奇的事。

程式碼審查是我們提高工作動機的方法: 堅持做最佳實踐的動機以及使專案讓人樂於參與以提高每天工作的動機。沒有凌亂如義大利麵的程式碼或不能改變的樣板程式碼(boilerplate code),沒有痛苦的更動。

“我沒時間做程式碼審查 !” 喔~真的嗎?

正如單元測試(unit test),有些人以交貨期限太緊沒時間執行為藉口而不做程式碼審查(code review)。 嗯,我不相信。

我認為,改善的學習曲線(技術更好的開發工程師)、將專案知識傳播給整個團隊(降低風險),以及提升的工作動機(人員流動率低)這三個理由已經足夠決定採用程式碼審查。 再加上如此專案的品質將提升(更容易做變更),如何判決已經很清楚。 每個專案花5%的時程做程式碼審查絕對值得。

度量程式碼審查的效能

要找出用什麼來度量專案程式碼審查的效能很困難,因為一個專案是否成功有許多不同的因子。有一種你可以採用的度量是在程式碼審查時回報的瑕疵數量。 這個數量雖然不同專案會不一樣,但會由於團隊越來越有經驗後逐漸下降(更常用在最佳實踐中)。

你可經由和開發工程師的直接對話來度量工作動機是否提高。 我們發覺這些參與有程式碼審查專案的團隊成員對於流程中有這樣的要求很欣賞且將這視為團隊的優勢。

要提交前還是提交後做審查?

是否提交前還是提交後審查程式碼各有優缺點。提交前審查是強迫開發工程師必須做審查這個動作。個人覺得審查最好是成為習慣,而非施加壓力去要求執行,這是為什麼我比較喜歡提交後再做審查。

當然,這也有可能產生不良影響: 如此就無法保證每個提交都一定會被審查過,所以理論上,品質可能會比提交前審查的結果低一點。 但從另一面來看,提交前審查也可能太過嚴格,導致阻礙測試版本的發佈,尤其是當審查者無法到位的時候。

你可猜到,在Miquido我們採用提交後審查的方法,建立了習慣,為專案負責的文化,所有人都關心專案程式碼的品質。 這方面 UpSource 幫我們很多。

為何選擇Upsource?

我第一次看到 Upsource,它還在1.0前版,但已經很讓我印象深刻了。 過了一些時候,我已經為Miquido找到程式碼審查的工具,我做了些既有解決方案的比較(包含商用與開源)。

市場上有許多程式碼審查的工具,從非常簡單如Bitbucket code review功能 (我們在Miquido用bitbucket git repositories) 或 Codebrag, 到功能豐富者如Crucible或Gerrit。

比較過這些不同的工具, 我決定應該要選擇Upsource, 因為我覺得以下幾個優點很重要:

  • 現場託管: 安裝在自家辦公室的伺服器,速度會比雲端的工具來得快多了。
  • 提供不需另外設置就有的Java檢驗(現在還有PHP、 JavaScript 和 Kotlin – 我真等不及 Swift 與 Obj-C),這又是另一層級的品質控制。
  • 很棒的程式碼導覽, 現在這方面又做得更好!
  • 有 JetBrains IDEs的插件 (我們使用 IntelliJ、 AppCode 和 PhpStorm/WebStorm), 如此可更簡單的做程式碼審查,不需要離開IDE介面!
  • 很好的搜尋功能。
  • 使用者介面簡單,卻又漂亮 (與其他工具相較起來很明顯)  對我來說這看起來是最佳UX設計的程式碼審查工具(我個人不是很喜歡Gerrit的UI).
  • 可跟JetBrains其他工具整合且創造實際的協同作業系統。
  • 那時價格真的很便宜 (現在價格高些但比第一版多很多功能),便宜到我覺得不用考慮開源工具買下就對了。

雖然有以上的那麼多優點,我仍在期待以下的功能:

  • 支援 Swift 和 Obj-C (我們開發行動應用程式,大部份業務是開發iOS app)
  • 更有價值的程式碼審查分析 (對於超過50個專案的設定,很難去追蹤整體的程式碼審查的表現)
  • 支援 Bitbucket pull requests (目前只支援 GitHub ).

Upsource 並非完美的工具. 尤其是如果你是提交前審查程式碼的愛好者,這不會是你要選擇的工具。但是如果你跟我一樣比較喜歡提交後審查的話,我個人意見是它會是你目前市場上最好的程式碼審查工具。 只要使用的方法對了,它將給你和你的團隊在品質與知識傳播有很大的提升效應。

upsourcequote

你可能會有興趣

歡迎加入 JetBrains Taiwan-Team Tools 社團

企業採購歡迎來信info@esast.com

JetBrains IDE 新創公司特價優惠

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

分類

03-JetBrains, UpSource

標籤

,