每日站会、代码审查、结对编程 之开源中国实践

标签: 工作日志 | 发表时间:2016-03-22 19:00 | 作者:
出处:http://my.oschina.net/zjzhai
在我来到开源中国之后,尝试将每日站会、代码审查、结对编程这三种编程实践带入团队。而这个过程,我个人觉得是一项非常宝贵的体验。我觉得可以拿出来和大家分享。

先介绍下目前我们团队的结构:3名Java开发,1名前端,2名实习。

以下我不会详细介绍它们分别是什么,也无意讨论它们有什么好处坏处,本文侧重分享在实践它们的过程可能遇到的问题,以及我们是如何处理的。


每日站会
每日站会 Stand-up :是每天进行的会议旨在在组队成员之间进行状态更新。'半实时'的状态允许参与者了解到潜在的挑战以及用于处理一个困难或者耗时的问题的协调精力。它在一些敏捷软件开发过程中有着特定的价值,譬如Scrum,但是同样可以在任何开发方法论中被使用。术语 “站” 衍生于通过保持与会人员站立的状态(长时间站立会导致不适)从而帮助控制会议的时间的实践。

我们每天会早上花十几分钟(具体时长看团队大小),大家一起站(是 )在卡墙前过卡。卡墙其实就是 Team中的任务看板。就这样,我们从“已验收”列到“待办中”列,从上往下,一张卡一张卡的过。这里的卡是指定义了一个小功能需求的卡片。 


站会不过是向领导汇报
我在实践每日站会的时候,发现不少人把每日站会当成一种“向领导汇报”的过程。比如他们会习惯地汇报:我昨天做了1,2,3 blabla。一大串,仿佛说得少就是做的少。所以这个过程,我不断地指正,你们不是在向领导汇报,我们只需要对这件事情负责,说到你的卡时,你就说你的卡的当前状态就好了。慢慢地团队里就养成了对事不对人的文化。为什么呢?每日站会就是提醒我们每日的工作就是对这些“事”负责。

随着时间迁移,我们的团队就慢慢习惯了这种站会。也会在站会上开一些开玩笑了。不要认为这是浪费时间,这是团队文化中很重要的一部分。

站会时间把控问题
站会还可能会遇到的问题是站会时间的把控。所以,我们每日站会会有一个主持人。如果大家说偏题了,主持人就必须指正,让相关人在站会后自己讨论。如果大家讨论的这个问题是个大问题,那么,也是在站完会后再讨论。另外,主持人还要是轮换的,这样就可以将团队所有成员带入项目。

站会上的新人问题
每日站会常常遇到的问题是过卡时,这个人说得太细了,把功能的具体实现细节都说出来了。这时,我们不应该立即打断他。出现这样的情况,说明他一定是新人。我们应该选择在站会后单独找他重申一次每日站会的目的和内容。当然,一开始实践每日站会时,团队里除了你每个人都不懂时,你就有必要马上指正了。


代码审查
代码审查(Code review)是指对计算机源代码系统化地审查,常用软件同行评审的方式进行,其目的是在找出及修正在软件开发初期未发现的错误,提升软件质量及开发者的技术。代码审查常以不同的形式进行,例如结对编程、非正式的看过整个代码,或是正式的软件检查。 


我今天没有什么好说的
一开始,我实践时,遇到的最大问题是:团队成员喜欢说,我今天没有什么好说的。这句话听起来冷漠,其实背后的原因是大家不完全理解代码审查是什么,而不是因为他们真的没什么好说的。

这时,我会说:只要你今天做了的事情,你都可以说。然后,他们常常不知从何说起,接着,一上来就给我们讲代码细节。

遇到这种情况,我们需要再强调一遍代码审查需要说什么:上下文、你是如何解决问题的、解决过程遇到什么问题……有时被审查的人可能说的不够明白,我就会帮助补充。

这个过程,你可能会发现有些人在表达能力上的不足,导致听的人一头雾水。我的做法是理解他说的,然后尝试帮助他更好表达出来。这样,提升他的表达能力的同时,让他在团队里也更有归属感。

说得太多了
有时,有些成员可能会说的非常非常细。多人这样了,就会导致代码审查的时间过长。发生这种情况,将表达能力的问题排除外,大概就是这个人没考虑哪些应该是自己应该重点说出来的。这时leader就要站出来指正了。

没写代码怎么审查?
其实,我们实践的代码审查并不是十分严格。因为有时,我们一天下来没有写代码,而是做调研工作。遇到这种情况,被审查人也需要主动分享他今天的习得。有时,他说出来某个问题,也许其他成员也遇到过同样的问题,并解决了。这样就为团队节约时间。


结对编程
结对编程(Pair programming)是一种敏捷软件开发的方法,两个程序员在一个计算机上共同工作。一个人输入代码,而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员,审查代码的人称作观察员(或导航员)。两个程序员经常互换角色。 


如何将结对编程带入团队?
我们的做法由一个懂得结对的人分别和团队里每一个人进行结对。结对前,详细说明结对可能遇到的情况,比如双方有争执,一直都是一个人写的情况,双方都遇到不懂的情况……然后,结对时穿插结对编程的知识。

团队成员中的两个都没有结对编程的经验,怎么办?
实际情况是我们遇到更麻烦的事情。
因为我在前端不擅长,所以我决定让两名前端结对。问题来了,这两个人都不会结对,在沟通方面也不是非常擅长。让他们结对后,我发现他们一起结对的时间非常少,一天下来基本就是各做各的。这时,我发现不对劲。我就分别找他们谈。为什么要分别呢?是希望他们大胆说自己的感受。

在和他们谈了之后,发现根本原因是他们没有完全理解结对编程的目的。这时,找到他们俩再重申一遍结对编程是为了什么,以及如何结对。

新人对结对编程常常有的疑惑?
他在写代码,我看着有什么用?
软件开发是一项集体脑力活,知识的流动在这项活动中非常关键。结对编程是促进知识流动的行为。
看别人写代码的人,我们称为“观察者”。写代码的人,我们称为“驾驶员”。观察者的职责是对写代码的人的代码进行审查。其实除了这点,我更看重的是这个分享思维方式的过程,会加速双方的成长。这个过程还能营造一种相互学习的文化。

我觉得我一个人一下子就写完了
说这句话的人的能力不会差。其实有这样的想法很正常。这时,我们就鼓励他多分享。当我深究下去时,他说写那些东西根本不需要动脑。还很得意的样子。不知道你们有没有发现其中的问题:他在做体力活。更大的问题是:他还不知道自己在做体力活。这时,我会说:当你在做体力活时,和机器没有区别,说明你在退步,这时,你应该跳出来,挑战自己,比如coach别人,或找到一种避免这种体力活的方法。

如果你有什么疑惑,可在本文评论留言。

以下是小结

每日站会,代码审查,结对编程实践的先后顺序的?
本质上是没有先后顺序的。但是如果你是一位新来的leader,你就需要考虑你加入的团队的情况了。我们是先施行每日站会,代码审查。最近一个月才开始实施结对编程。为什么呢?因为对这些编程实践,如果强硬推行,可能会受到排斥。你需要时间让团队成员消化。


给人留下“什么都管”的印象
由于我带来了这些新的实践,看到团队成员实践过程的一些问题就会指出,所以经常给人“什么都管”的印象。
当leader什么都管时,leader要问自己为什么什么要管,而团队成员也要反问自己为什么什么都要被管。排除leader的性格问题外,大多数时,是因为团队还处于比较初级的阶段。你问问自己,团队里有多少人可以自己做leader的就知道了。leader应该跟大家说清楚这点。这样大家就理解你了。但是这个“初级”的阶段要多长时间?就要看你什么时候培养出另一个leader了。


你会发现我在本文没有谈什么M捷或者精Y,是因为我想就事论事,不想谈理论,只想解决实际问题。

问题来了,你发现团队中没有人会结对,你作为leader不懂得如何结对编程时,怎么将结对编程带入团队中呢?
这时就需要请外援了。好听一些,请咨询顾问。如果你觉得看了我的文章,觉得我还行,也可以找我。我在开源中国众包发布了一个专家服务: 将每日站会、代码审查、结对编程带入团队

当然,你觉得看这文章对你有帮助,也可以打赏10元:

相关 [站会 代码审查 结对编程] 推荐:

每日站会、代码审查、结对编程 之开源中国实践

- - 翟志军
在我来到开源中国之后,尝试将每日站会、代码审查、结对编程这三种编程实践带入团队. 而这个过程,我个人觉得是一项非常宝贵的体验. 先介绍下目前我们团队的结构:3名Java开发,1名前端,2名实习. 以下我不会详细介绍它们分别是什么,也无意讨论它们有什么好处坏处,本文侧重分享在实践它们的过程可能遇到的问题,以及我们是如何处理的.

结对编程 VS 代码审查:对比开发者文化

- - ITeye资讯频道
从上一份工作到现在的这份工作,我从结对编程的开发文化过渡到同行代码审查,这个转变过程是一个非常有趣的经历. 我认为我要记录下些我所注意到的变化. 你可以找到很多标题是/(结对编程|代码审查)的(利|弊)/这种样式的文章,这些文章的作者都可以给出一套清晰且有说服力执行方案. 我认为只要权衡它们的利弊,这两种方案都是非常有效率的.

代码审查过程

- - 博客园_知识库
   英文链接: Code Review Processes.   对我而言,把代码产品化而没有合适的审查流程,就像是一场抽抽乐游戏. 代码当然也有可能会挺好,不过总还是有一定概率某人的哪块积木没抽好,然后一切就轰然崩塌. 无论是采用持续集成服务、结对审查、QA审查,还是所有这些方案的组合,都可以大大降低引入风险的概率.

Google 是如何做代码审查的

- litefy - python.cn(jobs, news)
在上一篇文章中提到过,我已经不在Google工作了. 我还没有想清楚应该去哪里—有两三个非常好的工作机会摆在我面前. 因为在这段做决定时间里,我不再受雇于任何人,我想可以写一些专业性的东西,一些很有趣,但也会在同事和管理工作中导致关系紧张的东西. Google是一个非常优秀的公司. 他们做出了很多令人称赞的东西—既是公司外部,人们可以看到的东西,也是公司内部.

代码审查中应该做的事

- China Moon - Solidot
威客 写道 "Mark Chu-Carroll从Google离职后,虽然已经收到了很多offer,但还没有决定去哪里. 他在其博客中分享了一些关于代码审查的趣事(中文). Google确实是一家很酷的公司. 不论是在公司内部或是外部,Google都做了很多让人赞叹的的事情. 这里我想介绍一些不涉及商业机密,但鲜为外人所知的事情.

敏捷代码审查指南

- - 博客 - 伯乐在线
“通过一次真正彻底地代码审查(code reviews),仔细阅读你的代码,找出问题,这是我知道的最好的方式去检测早期的bug,但是他们很少去这样干过. 某种意义上是因为他们花了大量的时间去写好代码,但是我认为主要是因为绝大部分 程序员害怕其他人审查自己的代码. 作为专业的程序员我们要克服阻力,如果你不愿意别人阅读你的代码,然后只是按照自己的意愿写,如果其他人没法读懂它,又怎能让别人使用呢.

代码审查(Code Review)清单

- - 博客 - 伯乐在线
代码审查可以帮助提高代码质量,避免由于代码习惯而造成的 bug. 下面列出的这些要点因该可以作为大部分代码审查的指导,如果是 Java 应用的话,这些建议应该被视作最佳实践. Javadoc 应该在每一个类和方法中添加. 如果是修复某个 bug,应该添加 bug ID. 走捷径的方法或者复杂的逻辑要有解释.

我所钟爱的代码审查

- - 译言-电脑/网络/数码科技
This is pretty standard fare for developers in the "real world", but I have never heard of an academic research group using them, and had never done code reviews myself before joining Google..

代码审查不是用来……

- - 外刊IT评论
提示:如果您在阅读器里点击订阅本站的文章链接时发现有一个中转页,这说明你的订阅地址有误,本站的订阅地址(RSS)是:. http://www.aqee.net/feed/,请及时纠正. 事实上,今天的我们正是从这种一直坚持探索的漫长道路上走出来的. 我们尝试各种技术、方法和工具,直到我们走到今天的成就(但这并不是说我们就此停步).

我们如何进行代码审查

- - CSDN博客研发管理推荐文章
本文来源于我在InfoQ中文站原创的文章,原文地址是:. Jim Bird是一位经验丰富的软件开发经理、项目经理与CTO,专注于软件开发与维护、软件质量与安全等领域中疑难问题的解决. 在过去的15年间,Jim曾管理过团队建设并主导过高性能的财务系统的建设. 他的主要兴趣在于如何提升小团队的效率以构建真正的软件:高质量、安全、可靠、高性能及适应性强.