有人實踐過 Phabricator 以及 Arcanist 做爲 code review 的工具麼？（轉）

做者：覃超
連接：http://www.zhihu.com/question/19977889/answer/13539702
來源：知乎

平時就常常實踐. 整個公司的code review就是使用這個. 具體說來, 因爲個人project稍微有點特殊,因此我這一年在facebook工做的時候一直在用兩套Code Review工具: Facebook的Phabricator 和 Google的Gerrit (他們都是開源). 我以爲兩個工具都很快,很穩定,而後都有效地提供了code review必備的功能:好比比較任意兩個不一樣版本, 對任意一行代碼來寫評語, 以及能夠很方便地導入和導出代碼到本地機器. 用了將近一年的時間,若是我要給本身的公司選一個工具的話,我會選擇Phabricator. 主要是以爲這個界面很乾淨, 而後配色很是好看, 整個感受比Gerrit要現代化很多. 另一個方便地地方,就是Gerrit上面只能看到版本作的修改,而沒法直接展開整個文件(除非下載), 而這點Phabricator完成得比較好. 還有就是Phabricator上面能夠發各類圖片,顯得氣氛比較輕鬆. 具體你能夠在http://Phabricator.com上面註冊一個帳戶,而後去看看eprisetley的diff, 就能夠大體瞭解這個工具的功能和特色. 最後要說的是: 這個工具如今已經開源, 並不屬於Facebook, 並且開發它的首席工程師也已經離開Facebook本身創業. 在加上 AladdinZ 張超 在評論裏面說的亮點: (credit屬於他,並且的確也是我用後以爲有很大差異的地方) 1. Phabricator將全部文件的比較直接展開,而後放在一塊兒,方便人閱讀. 而Gerrit只有一個文件列表,而後用戶須要點每個文件,才能看到具體的修改; 2. admin的權限設置問題. 另外我還想到一點Phabractor比較人性化的地方: Phabricator還能夠捆綁unit test和以及格式檢查和規範的工具(e.g. JSLint), 而後用戶在上傳diff的時候, phab會自動用新版本的代碼去跑unit tests,以及運行JSLint, 而後在code review裏面就能夠看到unit tests有幾個failure和error,以及JSLint的報警信息. 對於Gerrit, 不知道可否相似配置一下.

著做權歸做者全部。
商業轉載請聯繫做者得到受權，非商業轉載請註明出處。
做者：趙戈戈
連接：http://www.zhihu.com/question/19977889/answer/24101951
來源：知乎

從 12 年公司老東家成立創新產品團隊開始到目前，Phabircator 已經從只有咱們團隊使用到如今老東家全面投入使用。剛開始因爲是創新產品團隊，不用受制於公司大環境的束縛，能夠自由發揮的空間更多。因爲我的比較喜歡玩工具，好比 Trac 和 Redmine 以及 Bugfree 都用過很長時間（固然歷來沒有以爲很滿意），正當老是不滿意的時候 Phabricator 進入了視線，通過一些使用和研究，咱們決定將傳統的 Subversion + ReviewBoard + Jenkins 切換到 Git + Phabricator 的平臺上，暫時拋棄了持續集成部分，輕裝簡從開始了咱們新的工具時代。Phabricator 最先是 Facebook 的內部審查工具，看過王淮的《打造 Facebook》都應該知道，Facebook 最厲害的工程師都須要進入工具部門去鍛鍊深造，因此質量就不明覺歷了吧。聽說後期 Phabricator 在 Facebook 資助下專心作這個，迭代和更新速度都很快，總體界面和 Facebook 的風格簡直是一模一樣（就以爲 Facebook 的傳統風格太像是工具了）。做爲資深使用用戶有資格發表點對使用 Phabricator 的一些見解：首先，Phabricator 是基於 PHP + Mysql 的，可是配置起來也不麻煩。我的也曾經貢獻過一些 Bug fix，從代碼上來講 Phabricator 雖然不是個人風格，但風格和寫法上很是不錯。全部的開發都是面向 OOP，資源的管理是分離的很清楚的，配置的管理是多重的（數據庫，文件，默認）等等。高手寫的代碼都值得追隨和拜讀。因此，若是你在作 PHP 建議來讀一讀。其次，傳統的概念上，項目、倉庫和任務都是以項目爲主綁定在一塊兒的。而在在 Phabricator，全部這些都不是耦合在一塊兒的。項目就是項目，倉庫就是倉庫，任務就是任務。但全部的東西都是以項目做爲線索鏈接在一塊兒的。一個任務能夠屬於多個項目，倉庫的 commit 和 review 只有在提交任務的時候，能夠結合進去。若是要想更好的使用倉庫，好比自動 Review，審查 commit，還須要用到 Owners，根據配置，全部人會擁有倉庫的審查權限，全部倉庫的提交也都有 Owners 來進行審覈。這種鬆散的組合，想必和 Facebook 內部開放協做的項目態度是有關的，對於開放的團隊來講很是有好處。<img src="https://pic1.zhimg.com/c20fe9690d437e8ff9907a0a279059e8_b.jpg" data-rawwidth="940" data-rawheight="455" class="origin_image zh-lightbox-thumb" width="940" data-original="https://pic1.zhimg.com/c20fe9690d437e8ff9907a0a279059e8_r.jpg">再者，代碼倉庫的支持很完整。Git，Svn，HG 一個都不落下（什麼，你說 CVS，那是什麼）。對於倉庫，Phabricator 有很好的自動檢測和拉取機制，你推的代碼，很快它就能收到，根據你定製的規則去指派給相應的人去審覈。除了能夠審覈，查看代碼也很是方便，甚至它自己支持了 ctags 的導入，若是你導入了 ctags ，在代碼中甚至能夠用 IDE 中快速定位的方式去查找代碼源自哪裏？高亮天然就不用說了，沒有一種語言不支持的，估計新版本連本身的 Haske Lang 都支持。<img src="https://pic3.zhimg.com/ee6064b75e5dcd2246eba696d98485f6_b.jpg" data-rawwidth="1254" data-rawheight="691" class="origin_image zh-lightbox-thumb" width="1254" data-original="https://pic3.zhimg.com/ee6064b75e5dcd2246eba696d98485f6_r.jpg">而後，輔助工具也很豐富，對於開發以外的各類需求來講均可以知足。好比文檔、圖片審查、倒計時、問答、代碼分享、投票、密鑰管理、日曆、聊天、文件共享簡直是費盡心思。文檔是代碼開發的重要部分，Phabricator 採用了本身編寫的 reMarkup 語法和Markdown 很是類似，可是多了表格，目錄索引，引用自有文件任務等功能，使用上很快就能進入，基本不會有什麼問題。簡單說說圖片審查，這塊是我最沒有想到的。不過也解決了一個咱們設計的痛點。能夠把設計稿提交上來給你們看，你我均可以圈圈點點，提交意見，最終定稿。不然，設計師這個跟開發同性質（須要被產品經理趕）的用戶只能上 Phabricator 看任務。其它的就很少說了，基本都是字面意思，若是你有用到最好，用不到也無所謂，只是輔助。<img src="https://pic2.zhimg.com/0f7e57ef71e7c8c4836efa5a3415c9f1_b.jpg" data-rawwidth="1051" data-rawheight="662" class="origin_image zh-lightbox-thumb" width="1051" data-original="https://pic2.zhimg.com/0f7e57ef71e7c8c4836efa5a3415c9f1_r.jpg">接着，要說下命令行。Phabricator 提供了個命令行叫 arc （Arcanist），總之很方便。它有幾個用處：操做數據（任務查看操做）；開發輔助（gitflow 工做流，查看提交的 diff，代碼檢查，執行單元測試）；輔助（文件分享下載、代碼分享，升級）等等。對於開發來講，命令行再熟悉不過，用好這個命令行能夠少上 Web 界面去操做，對工做效率的提高簡直是大讚。<img src="https://pic1.zhimg.com/ce9d8f3989b61ca06eacc9cebc17cfa4_b.jpg" data-rawwidth="565" data-rawheight="354" class="origin_image zh-lightbox-thumb" width="565" data-original="https://pic1.zhimg.com/ce9d8f3989b61ca06eacc9cebc17cfa4_r.jpg">最後，Phabricator 很潮很自由。看看界面上的文字上若是你不去查查字典，估計有很多詞你都不認識，應該很多是出自希臘古語。不過能夠經過配置關閉使用正常點的描述。在帳號系統支持上支持的很到位。Github、Facebook、Google 和公司內部的 LDAP 都能支持。Phabricator 的 API 是開放的，基於此你能夠作出來不少符合本身需求的東西。Phabricator 也對郵件支持的也很到位，配置好收發郵件後，就能夠像 Github 那樣使用郵件來進行工做流。總之。若是你在挑選 Review 系統拿不定主意，看完就果斷入了吧。這套系統是免費的開源的。就先說這麼多。

著做權歸做者全部。
商業轉載請聯繫做者得到受權，非商業轉載請註明出處。
做者：代緒
連接：http://www.zhihu.com/question/19977889/answer/24122118
來源：知乎

不僅是適用於開發，咱們產品團隊也將pha用於產品文檔撰寫和項目進度管理pha相似markdown的語法可以很好的控制文檔格式，在線編輯模式又提升了產品與技術直接文檔信息同步的效率，若是很好的使用郵件訂閱的功能，重要文檔的修改均可以及時的告知每個相關人員同時，task式的任務指派模式能很好的整理產品需求，將以往Excel管理feature的模式在線化，並且因爲task與wiki，code review都在一個系統中，每一個task的說明可以與產品技術說明直接關聯，每一個人均可以看到該task的相關進度對於產品經理or項目經理來講，phabricator也是很是好的選擇

著做權歸做者全部。
商業轉載請聯繫做者得到受權，非商業轉載請註明出處。
做者：匿名用戶
連接：http://www.zhihu.com/question/19977889/answer/24066695
來源：知乎

正在使用Phabricator，我感受它是：「真tmd的好」從拋棄jira，將redmine遷移到trac，專心折騰trac兩年，再用上gitlab之後，雖然每一個工具定位不一樣，可是整體感受沒有一個工具真的是在作「人」作的事情：
1. 溝通，Phabricator上的溝通是主對人，特別是owner這個角色，很是適用於使用快速迭代的團隊。你還在用qq和郵件作報告和推動迭代？2. 合做，Trac上沒法merge request，gitlab直接搬github。硬傷就不說了，問題是merge request並不是是admin/master的工做，gitlab須要新開一個fork的行爲，而Phabricator的audit是很是直觀的：誰是owner，就均可以對此commit進行審覈。3. 獨立，trac和gitlab都沒法對自身之外的repository進行窺探。因而我在Phabricator上將之前全部trac和gitlab的repository導入。一旦決定拋棄他們，切換到自主hosting就好。同時還支持mirror到源。4. 開放，你有新的皮膚想用？想用fontawesome？開源。自用自改。實踐就是：立刻部署立刻嘗試立刻切換就能夠立刻開始使用Phabricator而其餘淪落爲bugtracing（本來是什麼就是什麼）。其餘工具想不用想。裝個trac加插件話費一個禮拜匹配版本，jira買或者用盜版，gitlab無。

 http://www.zhihu.com/question/19977889