作者:覃超
链接: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

有人实践过 Phabricator 以及 Arcanist 作为 code review 的工具么?(转)的更多相关文章

  1. 15个最佳的代码评审(Code Review)工具

    代码评审可以被看作是计算机源代码的测试,它的目的是查找和修复引入到开发阶段的应用程序的错误,提高软件的整体素质和开发者的技能.代码审查程序以各种形式,如结对编程,代码抽查等.在这个列表中,我们编制了1 ...

  2. 项目管理系列--好用的代码评审(Code Review)工具

    1. Gerrit Gerrit is a web based code review system, facilitating online code reviews for projects us ...

  3. <转>如何进行code review

    转自: http://pm.readthedocs.org/zh_CN/latest/codereview/howto.html 如何进行code review? code reivew是保障代码质量 ...

  4. 如何在团队中做好Code Review

    一.Code Review的好处 想要做好Code Review,必须让参与的工程师充分认识到Code Review的好处 1.互相学习,彼此成就 无论是高手云集的架构师团队,还是以CURD为主的业务 ...

  5. 项目管理系列--从零开始Code Review[转]

    从零开始Code Review 这篇帖子不是通篇介绍Code Review的方法论, 而是前大段记录了我们团队怎么从没有这个习惯到每天都进行review的过程, 后小段给出了我的一些建议. 希望能对诸 ...

  6. Code Review最佳实践

    我一直认为Code Review(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题.包括像Google.微软这些公司,Code Review都是基本要求,代 ...

  7. Code Review最佳实践(转)

    我一直认为Code Review(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题.包括像Google.微软这些公司,Code Review都是基本要求,代 ...

  8. 漫谈Code Review的错误实践

    从刚开始工作时到现在,已经写了7年的代码,大部分代码都被人review过,自己也review了很多人的代码.在上一家公司的时候,我负责的一轮面试是专门进行Code Review的练习和经验谈. 通过在 ...

  9. 【转载】 漫谈Code Review的错误实践

    原文地址: https://www.cnblogs.com/chaosyang/p/code-review-wrong-practices.html ------------------------- ...

随机推荐

  1. cisco路由器IPSEC VPN配置(隧道模式)

    拓扑如下: R1配置hostname R1enable password cisco  crypto isakmp policy 1        #创建IKE协商策略,编号为1 encr 3des  ...

  2. 自己定义控件(2.2):SurfaceView和SurfaceHolder

    本例需求及流程: Activity载入自己定义的SurfaceView-> SurfaceView 构造器中启动线程A.循环改变SurfaceView的x,y坐标,当x,y坐标到某点时设渐显标志 ...

  3. POj 1879 Tempus et mobilius Time and motion (模拟+群)

    题目特别长,大意为球的传递. 三个轨道,一个库.各自是分钟单位的轨道.5min单位的轨道.一小时单位的轨道.还有就是n容量的库. 每过一分钟,一个小球从库里面出来,库符合先进先出,进入分钟轨道.假设分 ...

  4. c# Unicode字符串的解码

    前两天工作中遇到个奇怪的问题,一个unicode字符串(即“\uXXXX”形式)变量,调用HttpUtility.UrlDecode解码过后,还是原样,要么就是乱码状态.无奈之下只能自己写一个解码函数 ...

  5. cocos2dx 制作单机麻将(一)

    今天開始打算解说下cocos2dx下怎样制作国标麻将 前半部分先解说麻将的逻辑部分,由于都是代码,可能会比較枯燥无聊. 这部分讲完后,你也能够用其它游戏引擎来制作麻将 后半部分,就解说余下的cocos ...

  6. Window8.1 64位无法使用Debug命令的解决方法[附牛人代码]

    偶然看到网上一篇文章,讲的是世界黑客编程大赛第一名的一个很酷的程序,大小仅有4KB,使用debug命令执行. 悲催的是win8.1的debug命令不能使用. 错误例如以下: 解决方法例如以下: 1. ...

  7. 收藏的一段关于java大数运算的代码

    收藏的一段关于java大数运算的代码: package study_02.number; import java.math.BigDecimal; import java.math.BigIntege ...

  8. GitLal+sourceTree版本号管理

    GitLab+sourceTree版本号管理 假设把代码提交到github上,仅仅能是公开的,除非你花钱了,可是我不想花钱,所以我选择了gitLab作为gitserver,使用gitLab的详细过程例 ...

  9. Android-IA Power Manager (S3)

    Sleep and wake up

  10. Nagios+pnp4nagios+rrdtool 安装配置nagios(一)

    基于的软件版本 Apache-2.0.63  php-5.3.2 nagios-3.2.3  nagios-plugins-1.4.15  rrdtool-1.4.5 nrpe-2.12 pnp4na ...