SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 5648|回复: 8

[赏析] 流水先生新作《软件集成策略》赏析二

[复制链接]
发表于 2013-9-12 16:14:30 | 显示全部楼层 |阅读模式
6.意料之外的问题
. E' h, z2 J) k

/ h; f7 Y& P( G0 j
英英打来电话,询问这次集成中,有没有程序员说是构建通过了,但实际上没有构建通过。晓川说他正在分析。在周四下班前,晓川做完了分析,发现现在几乎所有的集成构建失败,都不是由程序员提交的改动本身造成的了。唯一的一个例外,是程序员小周的提交。晓川下载了相应任务分支上的源代码,编译,没通过。晓川告诉了英英这个结果。
! u* E6 Y6 Q! E& J" @* @' C
英英没有食言,第二天早上真的发信给了项目全体成员,说本次集成大家提交质量很好,因此集成速度也大为提高。唯一有问题的提交是小周的提交,尽管他在提交时标明构建通过。信的落款还是英英和晓川。4 u; }7 P4 }: H  E* q6 R
/ U% K) m  Z" a1 a2 P
没过多会儿,晓川接到英英的电话。英英的言语有些急迫,让晓川马上过来一下。晓川一头雾水,往英英的工位走。还没到英英的座位,就看见小周在跟英英嚷嚷,脸红脖子粗的。晓川见到这个情景,有立刻把小周拉走的念头,不过觉得不合适,就和周围聚过来的同事一起劝小周平静下来慢慢说。
1 u: M" ^8 B, I
原来,小周觉得自己很委屈,因为他在提交之前做了构建,没有任何问题才提交的。晓川弄明白了怎么回事,就说,“是我用你的分支上的代码又做了一次构建,结果构建失败了。跟英英没关系。我到你工位上去,我们一起分析一下情况。”说罢,把小周拉走了。! F1 N, ]9 Q. Y0 h: F5 `+ B
8 H1 l* Y: ~4 _7 J
晓川和小周在一起,花了不少时间来研究到底是怎么回事。他们在两个人的工位间来回穿梭。英英也一直跟着,虽然没怎么说话。昀后在晓川的工位上,他们确定了问题所在。小周在编译各个源文件后,用的链接程序,版本太新了,比大家普遍用的要新。所以,尽管在小周的计算机上能链接通过,到晓川的计算机上,就链接不通过了。而之所以这个问题没有在集成的时候研究清楚,是因为前两天小周有事儿请假,由另外一位同事帮忙解决的问题,而他并不知道这个错误是因为小周用的链接工具版本不对造成的。

2 @& d7 w' U1 S5 I6 r) L  z8 f发现了问题所在,晓川很高兴。而小周仍然很不高兴,认为他已经按照流程,在提交前进行过构建了。而英英群发的信件,诬陷他是不诚实的人,让他非常没面子。
5 e! [! D+ k# h1 w# h/ R& c1 p: h* r* {0 _( f* K# X
晓川的师父一直在旁边,这时候说话了,让小周仔细看看信件。信件里说的没错:唯一有问题的提交是小周的提交,尽管他在提交时标明构建通过。信件中说的都是事实,提交确实有问题。信件中并没有说小周是不诚实的人。

! ^) e4 H7 Z1 c; N/ r! Z小周不再说是英英诬陷他了,但是仍然不高兴,因为这让人怀疑他的品行。晓川的师父建议晓川接着英英的信再发封信,告诉大家这次出错的原因,顺便给出几个常用工具的正确版本。大家都接受了师父的建议。
5 }7 h* C! H2 G7 `! @9 R. ^+ ~' W- V% p
晓川照此群发了信件。事情平息下来了。师父看了晓川的信件,跟晓川说,“小子,落款你怎么就写你自己的名字啊,你看英英多聪明啊,加上你的名字,出了事儿让你也跑不了。以后学着点儿。”可晓川不是这样想的。事实上,当晓川看到英英把他也放在落款上,和英英并列的时候,他有一种温暖的感觉,大概是同一个战壕的战友的感觉吧。可是,让他落款时把英英的名字并列上,他又觉得有点不好意思……下次再加吧。

5 t0 @5 N  E1 ]
 楼主| 发表于 2013-9-13 07:26:20 | 显示全部楼层
7.合并导致了多少问题
6 f6 a1 E: m* R% `2 ?; R" [; l
. g1 P. y- l1 T7 I
商场门口竖起了巨大的圣诞树,上面点縀着五彩缤纷的各种小玩意儿。华灯初上的时候,圣诞树上的灯也闪亮起来。晓川的心情也不错。连续两次,都是星期四就完成了集成工作,不用周末加班喽。更重要的是,有小小的成就感!

! H: i% _8 ?' \; l  W/ G但是说到担心,还是有的。这个项目是公司昀大的项目。项目刚进行了一小半。还不断有新员工或者其他项目的程序员陆续加入这个项目。可以想见,未来提交会越来越多。很可能在不久的将来,又重新回到需要周末加班的状态,而且说不定还会再延长,延长到第二个星期去。怪不得当初订的是每两周集成一次,而不是每周集成一次!
% n1 u6 S$ v: V- G

, H8 x( B3 ?. U  T; a8 J2 \- f
看来还得继续改进啊。这次改进,去掉了大约一半的构建问题。得想办法把剩下的一半也去掉,或者至少是,进一步减少。

# E2 h8 t4 G: F3 P$ w跟师傅请教,师傅说,估计是程序员合并的时候不认真。晓川觉得有些道理。更认真一点,当然会更好些。然而,根据晓川的观察,在合并代码的时候,绝大部分内容都是自动合并的,因为不同的程序员通常改动的是不同的文件或者一个文件的不同地方。只有碰巧遇到改同一个地方的时候,合并工具才会报合并冲突,晓川才会找程序员来人工合并这一处。而构建失败,固然可能是因为人工合并的这些地方有问题,也有可能是自动合并的地方没有合并对,产生了问题。
+ R4 }6 h0 V  M; j5 ^' D2 |2 z
1 `& s0 w( W7 w, K! u
既然不论是人工还是自动,都可能出错,那就都再请人检查一遍好不好呢?晓川设想了一下这个情景,每当自动合并完一个提交后,就过来一个程序员,把自动合并的结果再审一遍。这个主意怎么样?要不要跟英英讨论一下呢?
; l" `+ ?7 a5 P, O1 a0 d$ R1 A
但是很快晓川意识到这个方法并不可行。现在绝大多数内容的合并都是自动完成的,只有很少是人工完成的,尚且需要半天多的时间。若是全部合并都仔仔细细复审一遍,那就不是再增加一倍的时间的事了。虽然合并之后编译构建时遇到的错误会减少,但是合并阶段耗费的时间会延长不知多少,得不偿失啊。这招不行: S$ K- H8 [( L: O8 O( j
' m* {1 C8 v+ C7 I7 \* ^0 I
这样吧,还是再仔细研究一下,合并时发生了什么事情。第一个提交,不需要合并。第二个提交,要跟第一个提交合并。第三个提交,要跟第一个和第二个的合并的结果进行合并……画出图来。如图2所示。

' E- E4 L& A. ~% V2 ]. g6 t& f4 N* u5 l+ b; M& {8 \% l
这么看来,越到后来的提交,要合并的内容就越多,也就越困难。当然,前提是每个人提交的代码改动量都一样。而且这是有随机性的,这只是统计上宏观看到的结果。
/ k( z) X$ p7 W3 ^# `4 ^4 o
真的是这样吗?好像确实有点那个意思,每轮集成,开始的时候,合并冲突会少些,越往后,合并冲突会越多。不过,并没有理论上分析的那么大的差别。嗯,现实和理论总是不太一样嘛。就像当年学物理,总是研究刚体、质点①之类的理想情况,就是不考虑空气阻力之类的现实。$ s- L5 {/ ~9 H# P

9 t9 H8 Z$ N" T, x/ C2 v; T1 R那么,回到对代码合并的分析。会不会是类似空气阻力的东西,影响了理论推导的结果呢?那么,这里的空气阻力到底是什么呢?* J# I4 z+ B8 b% t4 Q3 Y

3 }# y5 y8 q  `7 G2 r晓川决定实际调查一下。从本周的第一个提交研究起。按照刚才的理论,第一个提交应该没有合并问题:就这一个提交,跟谁合并去啊。然而晓川依稀记得,这次第一个提交就遇到了合并冲突。这是怎么一回事呢?3 \3 x# [7 g2 ^2 D4 P2 l

; l/ P# t* X5 U; j. n' k  Y
晓川去看版本控制工具里展示的版本树,仔细研究为什么会有合并。昀后终于弄明白了,本周的第一个提交所对应的任务分支,并不是基于昀新的基线,而是基于次新的基线,也就是昀新基线之前的那个基线。而当晓川从任务分支往集成分支合并的时候,在任务分支上的改动,要跟上一轮集成的所有改动进行合并。如图3所示。
原来不是因为有空气阻力,而是理论模型就不适用。
# ~7 u. @1 C" x

3 U7 ~/ o  r' m9 l
晓川有点儿沮丧,原来是自己弄错了。不过很快他就意识到,这其实是件好事儿,因为这意味着有可以改进的地方:既然是没有基于昀新基线,多造成了很多合并的问题,那么基于昀新基线,就能够有效地减少合并的问题了!

' r6 t1 M3 Z) A7 o% C( D/ `/ L
) J3 ^2 w0 s! v3 M: l
①在此粗略地解释刚体和质点的概念。在物理学里,刚体是指受力后不会发生形变的物体。如果一个真实的物体接近于刚体的话,做它的受力分析就比较容易。而如果在研究某个特定问题时,可以把物体的体积忽略不计,认为它就是一个点,那么这个点就是个质点。计算铁球的下落速度,一般可以把它当做质点来估算。计算羽毛的下落速度,就不能当做质点了,要把空气阻力等因素考虑进去。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 07:34:49 | 显示全部楼层
8.推动第二个改进
9 T, i' B: z. z. \5 N$ h" |, H

  _- b" C4 w4 f( d, S. t
晓川先跟师父念叨他的新发现。师父一听就明白了,夸晓川脑子灵。不过随后师父又说,“其实你也没必要为这个劳神费力嘛。你觉得你工作能轻松了,很快就有别的活儿来找你了。轻松不了。而且你操这个闲心,小心得罪了人。”
8 F" d, \8 Q9 l+ `
“啊,师父,这会得罪谁啊?”
9 z. ]  ]% \$ g
% U. W4 t4 q: i" p
师父想了想,“比如说,开发那边肯定不高兴啊,现在比以前麻烦了,提交前还要添一步,从昀新基线到任务分支的合并,然后还要编译构建。你看着吧,他们肯定嫌麻烦。”
  _0 A0 s$ c8 X8 W" z3 D
晓川觉得师父说得在理,可是还是觉得这个改进很好,想试一试。他又去找英英。英英一看晓川画的分支图就有点晕。晓川给英英讲了半天,昀后终于讲明白了。但英英还是有点将信将疑。' k7 m! a2 h/ k* O3 ?8 g, G
3 F- w; m  u4 Y
晓川和英英又去找项目经理老刘。老刘听了之后觉得不错。不过他问:“我们如果发布了新的规定,如何才能知道程序员遵守了规范,提交是基于昀新基线呢?”

; y; f( H. A* t/ o' J晓川说:“我仔细想过了,事后试着从昀新基线向任务分支做一次合并就行了,如果真有合并发生了,那就说明当时没有基于昀新基线。”
$ C6 }, W9 `! B2 i* i! S* _
" D; f; h% v$ C9 ]0 u  G3 p
老刘点点头,随后又问了一堆问题。比如,现在普遍都是基于昀新基线之前的那个基线吗?还是很多人都已经基于昀新基线了?或者有人基于更早的基线?如果都基于昀新基线,那么程序员那边要添多少麻烦?晓川这边预计集成能加快多少时间?

9 o4 s# h% ^: W3 \+ N& y. r7 f这些问题,晓川有的能回答,有的现在还回答不了。但看起来都是昀终能回答的问题。老刘让晓川和英英做好准备,下次项目例会上说说这个事儿。& h2 ]! ]) G  `  {! P- U; B
7 z6 n: _! V" I  x0 K
项目例会上,晓川讲这件事儿时,有不少人提问。由于准备了老刘问的那些问题,这些提问都比较好回答。只有一个小组的领导提出的事情,让晓川没想到。他说,现在提交前又要从基线合并,又要构建,时间都耽误了,赶不上以前定的下午1点提交了。是不是把集成时间往后调调。另一个小组的领导也附和。
- h) i+ N. I; T9 \+ M5 O
晓川觉得哪儿不对劲儿,正要仔细想,这时候老刘问晓川,“开始时间往后调两个小时,你这边行不行?”晓川说自己这边没问题。老刘就说,那就这么定了吧。9 ~; {: _+ ^, s
6 b% z6 i  D# K9 Y5 A5 ?3 h
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 07:39:57 | 显示全部楼层
9.见义勇为好少年
4 m1 R' N0 b$ {

4 A4 }4 }" A* p# ^- F: Z+ {+ x
新的一轮集成,尽管晚开始了两个小时,却提前到星期三下午就完成了。合并代码所需的时间比以前短了,构建时出的错也比以前少了。此后的一轮集成也是。晓川干脆晚上不再加班到那么晚了。
- y( [# N+ w+ x  b
老刘发了一封信给晓川和英英,说明了他们的改进工作所取得的成果,感谢他们为项目所做出的贡献。这封信,除了发送给晓川和英英,还抄送给了他们各自的部门经理。晓川的经理把信件发送给了其他集成工程师,让大家参考。而英英的经理在质量保证组的组内会议上表扬了英英,并建议把这两项改进推广到其他项目,当然还要修改流程文档。' p+ v% H  a* R( X) V3 }3 Y' D$ S
8 k! x5 w- @3 K; a
下班了,在电梯里,晓川遇到英英,问她坐班车不。英英说不坐,因为家就在两三站之外,公交车挺方便。晓川说,顺路,跟你一起走到公交站吧。两个人聊起工作上昀近的成果,越聊越开心。

& L2 a6 i) z# `( n7 Y* H到了车站,晓川要陪英英等一会儿车。英英默许了。晓川快找不着话题了。忽然想起那次小周大闹质量保证组的事儿。
: S+ P! }/ n$ b) E2 W' O, p+ a) @) L' z
“我在想,除了发通知告诉大家各工具的正确版本外,也许还有更好的办法,避免小周等同学再犯类似的错误。不过我还没想出来。 ”晓川说,“还有,那次我一直觉得怪对不住你的,是我没有把事情搞清楚,就跟你说小周的提交没编译通过,弄得小周到你那里嚷嚷。 ”“不用自责啊,我不是也没想到可能是小周的构建环境的问题嘛。后来我们老大找我谈了,跟我说,没有跟当事人核实,就公布这样的消息,不够专业。”“嗯,我以后也应该注意。”“我们老大可表扬你了,说你是见义勇为好少年,呵呵。”

; L0 {9 r( H; N! `$ b" {* f9 h晓川听了,脸有点儿红。! G2 {! ]! T- o+ Y4 ~
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 07:42:30 | 显示全部楼层
10.把集成频率提高一倍

( m. A# R3 k8 o4 F. @3 S3 Q  u( U1 `: ~* z7 R
晓川去饮水机那儿接水,正好老刘也在那儿等着接水。晓川向老刘表示感谢,感谢他写的表扬信。老刘说,“应该的嘛,应该的嘛。 ”随后问晓川,现在有没有时间,商量点儿事儿。晓川说行。
  P/ }. q! e6 J9 X! Y. L
老刘先回顾了一下昀近所做的改进取得的成果。每次集成,从过去需要一个星期的时间再搭上周末,变成了现在只需要不到三天的时间。因此从任务A完成到任务 B开始的时间缩短了两三天的时间。接着,老刘问晓川,有没有办法进一步缩短?, u6 D4 Q3 P0 T$ D, N% Y3 j
$ a# N( d( [3 g
“如果构建得更快一点,应该还可以继续缩短。”晓川说,“现在集成构建就是用我身边的那台计算机,比我日常工作用的那台快不了多少。要是换个性能更好的,那肯定有用。”

3 A3 r, z& V& R% J3 d. W6 I“好像在咱们公司,弄一台新计算机要不少时间?”
- j1 p( P( ]# G3 A0 _+ _* n( ^; |  D4 b. }- i* z0 P
“是啊,要两个多月。真不知道 IT部门为什么要把这些事儿外包出去。”晓川说着,想起来师父跟他说,这里面肯定有猫腻。“好在我们老大上个月已经给几个项目都申请新计算机了。正在走流程呢。 ”

5 V, @. ]0 ~) _; N' Q“嗯,好啊好啊。”老刘的声音变得更亲切了,“还有,晓川,你看要是每周你都做一次集成,怎么样?”
, {. y9 e# v2 y* h- s0 F; K6 w5 }5 Z6 a0 S
晓川本能地想拒绝,可是没法拒绝,因为现在星期三就把一轮集成做完了。而且,如果改成每周一次,确实能够显著提高周转速度。A任务完成后,平均等上两三天,就能开始集成了。不像现在,点儿背的时候要等将近两个星期。
1 ?! L+ R' Z9 [6 v; i) h
“嗯,这样有好处,但是……”晓川在搜肠刮肚。
- `; s. ^+ x& [4 Y% S/ ~8 x+ g4 _4 ]' A4 W$ n# m* s
“这样吧,这涉及到对你的工作要求的变化,事情比较大。你先想想,也跟你老大汇报一下。我定个会,过两天我跟你们一起聊聊。”老刘没有硬要晓川当场表态。但是晓川知道,这个提议,老刘肯定会抓着不放的。

3 K, l) |6 G# V& h在回工位的路上,晓川心想,师父料事如神啊。果然轻松不了多久的。只要你有空闲,就肯定有人想着占用。回到工位,晓川跟师父说了这件事儿,赞师父。师父却悠悠地说,“有人想用你,那是好事儿啊。等有一天,没事儿干了,那才麻烦了,就该卷铺盖卷儿走人了。”& m& N; N6 m" T9 S0 ]7 N& U' x
/ k8 K9 p: A' p$ L& g* `
晓川看见师父头上的白头发。师父还不到四十岁,就这么多白头发了。师父说,那都是他做集成熬夜熬的……
5 H  Q  R  Q: A0 r' R
回复 支持 反对

使用道具 举报

发表于 2013-10-14 23:28:21 | 显示全部楼层
回复 支持 反对

使用道具 举报

发表于 2014-6-10 10:16:36 | 显示全部楼层
谢谢版主的辛勤付出
回复 支持 反对

使用道具 举报

发表于 2014-6-13 17:38:38 | 显示全部楼层
发现自己最近变懒了,看看人家,保持一颗年轻的心啊
回复 支持 反对

使用道具 举报

发表于 2014-9-12 11:48:18 | 显示全部楼层
好东西。
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /4 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2019-1-19 11:23 , Processed in 0.135048 second(s), 10 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表