SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 9724|回复: 16

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

[复制链接]
发表于 2013-9-12 15:09:28 | 显示全部楼层 |阅读模式
SCMLife的资深版主,配置管理专家流水先生又出新书啦,从本周开始,我们将逐步为大家刊登部分章节,带领大家一起来感受流水先生10年配置管理管理的经验总结,希望能带给你一些启发和思考。
: U, }5 l6 V' q$ ?- f9 o) Y3 K: |* b# n
& H3 `+ K1 @+ p; k8 D7 }2 `: H赏析目录:
0 n! a/ }  _, U=== 第一部分,是一个职场故事 ===
6 P% C' V+ E- b) X
1.集成这破活儿
4 K0 j) j( B% q; t& j
2.对项目的不利影响竟然这么大' X+ i1 n  E, h
3.构建错误是怎么来的3 O2 i6 q8 i- {- B* ^; o1 T  j' I
4.与QA 部门的同事沟通: z" t5 p9 Y) T. a
5.确定第一个改进方案
8 [8 @' x* j$ i; Z4 D1 I( w
6.意料之外的问题
: a+ n7 p# k; M$ U
7.合并导致了多少问题; {/ a% m6 s6 `$ Y( `  E: A
8.推动第二个改进5 ]5 |: v1 h, O3 P5 J; [2 y- H  [
9.见义勇为好少年
8 x: T8 b" v- C# l6 i, T0 E) I6 `/ ^
10.把集成频率提高一倍
5 W& @. m$ m0 F
11.把改进方案讲给老大听
/ X2 s# l+ v9 |: M% I0 W/ P
12.跟项目经理谈判
% }8 Y6 s# i/ N8 `, E( j9 A
13.敲定第三个改进1 c5 X! D4 i, w7 U. o
14.每日构建
  x* u' L) T/ m  {2 h2 b( i
15.在春节到来之前6 v9 c# u7 g0 A8 ?/ L& k
16.老大给的材料
6 W: H8 ~( Z1 I+ V9 ]2 E1 k
17.持续集成竟然这样干
& {& J8 o! _0 s8 B
18.阿根廷探戈% W+ J" x$ D( u1 c
19.用哪个持续集成工具好
9 A- z  J+ D/ |1 w6 [1 Z, n) h1 H
20.英英的强烈反应
0 I4 X2 q" c2 g# P8 }' n( K
21.同时解决两个问题
# ~1 n# z! y% L7 u$ v+ G
22.失败的改进
+ h8 M! k' m/ @! X- u) L; V* r
23.自动冒烟测试
5 Q: j% D6 p# l; J6 X6 E
24.不可靠的自动测试
: @( j, I1 m3 e( e* g" C
25.如何进一步缩短工期
; c3 U1 z3 k% Z! z
26.没用的提交说明
' ?6 t$ k9 h( D/ ^
27.缺陷为什么这么多+ Z( ~, b! d! D& f% p/ n  H$ ^: O
28.草原夜色) V9 Q' S, C' s) T! n5 Q+ m
29.十字路口+ H7 T# a9 {2 R' |* z* G6 V% `
30.我还没答应呢
1 y6 |4 S5 Y+ Q" e
! t! ~& @3 M* f0 h- B0 V0 G1 r4 o# C& L5 q# U5 |
第三章  集成优化的本质% h$ m! b: k( W4 f1 K, m3 s2 P. p6 [$ O
    3.1  从项目三角形说起: V0 v! a& _' }& m
    3.2 集成优化的目标  }# e9 E; n! V- q0 a
    3.3 资源及其成本
: Q9 l. }- ^* I* j; O    3.4 什么决定了项目时长! l5 w- V. k) a# N+ p( z1 G! b
    3.5 从虫子的视角看集成  R! o1 W& A9 t( [0 D- B( ]
    3.6 从不同的视角看虫子
" L# m9 R+ K+ P7 R7 H: T" G. b$ p2 F# ^7 h7 R( L( F

% r6 a. O* p) m# G$ J第 四 章   第一组旋钮:检测的力度和方法0 Y4 D0 F. K0 l8 E& W, R
    4.1 提交前检测力度" i: I' |* T: T  [
    4.2当项目临近发布时
3 H9 R1 v2 J; A    4.3 为了让后续工作更顺畅/ l3 }' G' p/ i% T. ^1 v
    4.4 提交前检测方法
/ c+ E+ b/ ?% s    4.5过程导向还是结果导向
) n, k9 Z  T# {8 M' v- B' b) n5 o    4.6 狭义集成时检测力度# w  I! @: ]& o  U5 i% B
    4.7 狭义集成时检测方法+ i' P8 P$ j1 Y  M; q7 M+ ?
    4.8 狭义集成时发现问题以后4 v* ^5 @( f# D7 l& d
    4.9 狭义集成后检测类型和力度
6 r" s. p& C' X1 Q5 q/ \  a    4.10 狭义集成后具体检测方法
" T% W/ B0 p. T: H" u, W
# ~: Q3 _) ~! U9 ?
* L7 e2 y. d5 K# r0 Y- D0 a& {" H; `( `1 {6 R5 u
6 H# h* d6 _+ x( t0 C
5 S! W9 J; l9 r1 b5 i7 k
 楼主| 发表于 2013-9-12 15:22:41 | 显示全部楼层

第一部分 一个故事

1.集成这破活儿
: A# t2 v( T9 S4 A" c8 i
7 ^: V" c) m/ g) ^8 x) [0 p
下午四点,窗外阴沉沉的天,办公室里灯火通明。雪纷纷扬扬的下着。这是今年的第一场雪。周围的同事在议论今天晚上几点能到家。大家的担心不无道理,因为去年一场这样的大雪,让住在城南的同事夜里十二点才到家。
8 `: `$ x1 V1 s  t8 l6 E' S9 _3 Y
晓川坐在计算机前,对此毫不在意,因为今天注定要夜里一两点钟才能离开公司,注定要很晚才能到家,跟下不下雪没关系。谁让今天是星期一呢,软件集成的日子。9 u; n2 D% w: o6 o- h- u
' Y" i3 V2 V: U
晓川在等一个同事解决刚冒出来的版本合并冲突。他就坐在晓川的座位上,用晓川的计算机,晓川在旁边看。看着看着,晓川的思绪回到了学生时代。学生时代昀深刻的记忆不是学习,不是考试,而是长跑。提前一个星期就知道要测长跑,接下来的日子就好像乌云慢慢遮住太阳。到长跑之前的那一天晚上,简直连作业都写不下去。第二天去上学,体育课前换衣服,体育课上做准备活动,然后哨音一响,享受吧。

1 B# |' o2 C/ E) M$ a1 c" \怎么会想起当年长跑来呢?嗯,大概是因为现在的工作和长跑有点像。提前很久就知道要集成,因为计划就是每两周集成一次。然后就很不情愿地看着集成的日子一天天来临。这是因为集成是件痛苦的事情,星期一下午一点钟开始,要是没有遇到任何问题的话,那用半天就能完成。但几乎不可能真的半天完成,也不知道究竟多久才能完6 u% S- T5 a: [. M1 q- v
成。一般来说呢,周一夜里,哦不,是周二凌晨,要忙到一两点钟。周二早上起晚一点儿,来公司接着干。嗯,如果顺利的话,到周三夜里,或者周四凌晨,就能出版本了。当然,经常不顺利。要周四上班接着弄。一般来说,到周五下班前就能做好了,能回家睡个好觉。不过也不一定。迄今为止昀倒霉的一次是上上个星期,星期天上午才弄好,整个周末都差不多搭进去了。
  j. k3 m, x; {8 I& g( }
事实上,情况越来越糟糕。记得项目刚开始的时候,还是不错的。那时候,他师父带着他一起做。那是在阳光明媚的初秋。开发团队还不大,每次集成,没几个提交。合并挺快,也不容易出问题。接着编译一次的时间还短,也就一二十分钟。而且顺利的时候,编译一次就通过。当然后面还有链接、打安装包、创建基线等,虽然步骤多,但是都比较快,也不容易遇到问题。有一次,一天多的时间就全部完成了。师父说,学成了,以后可以独立工作啦。自己那时还挺高兴。不过师父也说,以他的经验,后面会越来越苦的。现在看来,果然是这样。
$ t7 i) g+ Y5 g' S1 `7 F
6 x1 [; |2 ]* P/ k' ^9 ?/ ]
怎么就摊上了这么一破活儿。晓川心想,自己真倒霉。不过再仔细想想,其实也没办法。上大学时,自己学的不是计算机专业。现在能在这么一个有些规模的公司里从事软件研发相关的工作,已经很不容易啦。还挑啥啊。
; ]& `% ~; H4 \9 p3 a$ ]  U1 X( D* F8 X
晓川上大学时,学的是物理专业。之所以报考物理专业,是因为中学的时候,特别喜欢物理。特别喜欢物理,或许是因为那时候物理学得太好了。参加物理学科竞赛,获得市里的一等奖呢。那时候想,一辈子要献身物理,要做个科学家!但是等上了大学,再保送上了研究生,慢慢的,好像就没那么喜欢物理了。主要是因为,物理这门学科已经很难再有新的发展,新的突破了。嗯,可能还因为,学物理,将来很难找工作。不管是什么原因,当晓川用计算机编程模拟一个物理实验的时候,他意识到,其实他更喜欢计算机,而且学得也挺快。那么,等将来毕了业,就找个跟计算机编程相关的工作吧……
5 l& a" d; q; b' ]8 v5 J  s
* g# e9 c. P) A& I& A9 S. {3 a
坐在晓川座位上的同事,解决了版本合并冲突。晓川从回忆回到了现实。继续奋战!

$ R( ]+ a' e3 {
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-12 15:31:30 | 显示全部楼层
2对项目的不利影响竟然这么大7 N* Y( T8 U) [  u( G* j$ ?- V' h" G

# T& A+ }4 V+ @: Z0 L项目经理老刘跟晓川说,等这一轮集成做完,一起聊一聊。晓川听了有点紧张。不过想一想,自己已经很努力了,也没有什么可担心的。其实关键是程序员提交的质量。倒正好可以借这个机会跟领导沟通一下。周一早上。老刘先是说了些感谢的话,感谢晓川的辛苦工作。晓川听了很欣慰。接着,老刘用笔记本给晓川展示了一张巨大的图,跟他说,这是项目的任务计划图。好复杂啊,晓川看得一愣一愣的。老刘见状,转向白板,在白板上给晓川画了张简单的图。如图1所示。0 k/ x( J/ l+ a2 l
- |0 _& u! J* N* k& {6 t3 E1 v
   “晓川,我想让你了解,你的工作对于这个项目有多重要。看这张图,这是一个典型的例子。开发任务B、C、D 要想开始,必须在开发任务A 完成之后。类似这样一个一个任务串在一起,就决定了项目至少需要多久才能完成。这个你能理解吧?”
. u2 t' L2 s7 i- e
  “能。”

& @4 X/ o; y* [) [7 S; r/ Y
“但是现在 A任务完成后,B、C、D任务不能立即开始。即便是 B、C、D任务的人手已经到位了也不行。你知道细节。”

! z2 l/ B- X- s9 G% n+ [0 P4 e2 E6 s* E+ X
“嗯,A任务完成后,要等到下一轮集成时才能去集成。而集成本身也需要时间,要等集成结束,A任务对应的改动进了基线才行。这时候大家才能看到 A任务的成果,B任务才能开始。”晓川很熟悉。

0 r& b3 t7 n( R! Q- c, B“现在要等多久?”老刘问。6 z% c5 \( U$ n( p, {5 g- h
1 l6 @' \7 n1 j$ s
“嗯,那要看我这边集成需要多久。刚结束的一次是整整一周。哦,不止是集成的时间。还要算上等待集成的时间。如果刚好是周一上午完成的,那几乎不用等。如果不巧是周二完成的,或者就晚了一步,是周一下午完成的,那就要先等上两个星期。也就是说,平均要先用一个星期等待进入集成环节,再用一个星期等待完成集成。”
* W: ~4 U- n: I& E  u& r  t8 U5 Z
晓川说完,陷入沉思。以前只是觉得自己的工作很辛苦,没想到,整个项目都在看着我,指望我快些、再快些……
3 K9 i8 c. z  O& \) H
7 @  Q  D& X' y* t' k: G- T
“我知道你很辛苦,晓川,”老刘说,“现在你也知道我多么期待你把工作做得更好。你有什么好主意吗?”
7 S9 O" P) b) ]
晓川:“我觉得关键是开发人员提交代码的质量。如果他们在提交前保证代码是可以编译通过的,那集成的时候就不会有构建问题了。现在昀费时间的就是集成的时候反复构建。”/ u% v( y) d+ r  ?% M

- z$ f; P7 O3 F8 D" W老刘:“你是说,大部分时间是用在反复构建上,而不是在这之前的版本合并上?”
, ?! @* z" T/ p' U. E
/ h. P4 G% O1 f4 M" G: J
晓川:“对,是这样。比如这次集成,星期一下午一点开始处理大家的提交。您知道,大家的代码改动,都在各自的任务分支上。所谓提交,就是告诉我,等到集成时,要把他的分支合并到集成分支。在我合并的过程中,可能会遇到版本合并冲突,我就要协调,谁提交的,就找谁解决。快下班的时候我给所有的还有提交没有处理的程序员发了邮件,让他们待命,准备解决冲突。这样,到晚上九点的时候,所有的版本合并冲突都解决完了。而后面的时间,就都费在反复构建上了。”

  P; F3 U* X; H; N  V: @% `) a老刘:好。那看来反复构建昀费时间。然后你的思路是,如果程序员提交的版本都是能构建的,你这里就不需要反复构建了?

# h5 m& M' \) V( b, K7 f. r. b
对。这样的话,说不定周二早上,任务 BCD就可以开始了。 晓川很有信心。

& Q- }1 B9 h9 l0 V, R# n
如果程序员的提交都没问题,你确定你构建的时候就肯定没问题么?

" J+ }) u$ j/ j( P
老刘降低了语速,一个字一个字地说。
3 o% g1 Y  p1 }' \3 W
“那当然,但是……”晓川意识到了什么,好像这里的逻辑看似简单明确,其实并不是严格的推理。
2 A( Q& N( N( s, a$ t8 ?3 z9 p" P7 [8 `; Z$ H

2 Q3 R6 p, C/ _: A% Z" }
这样吧,我看到你有一些想法,这很好。你再想一想。多调查调查,看看现在究竟是什么原因需要反复构建。也跟大家聊聊。总之,请你帮忙想想办法,缩短从任务A完成到任务B可以启动这中间的时间。

本帖子中包含更多资源

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

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-12 15:50:55 | 显示全部楼层
3.构建错误是怎么来的

4 q) C; Z7 ^8 @, o8 P+ _/ Y  `- c4 Y7 K
晓川在回到工位的路上,回想着跟老刘的谈话,心中感慨万千。老刘并不是去指责我,甚至不是命令或要求我,而是请我帮忙。对于我不成熟的想法,他没有贬低,甚至没有告诉我应该怎样做,而是让我继续想,提示我要多调查。
* w7 b; x: n/ a. r9 x
回到工位,晓川跟师父聊起这些。师父说:“老刘当然没法命令你了。他只是项目经理,不是你部门经理。他要是敢指责你,你就跟咱们领导说,有人给你撑腰。至于他不告诉你该怎么做,那要么是他也不知道,要么是他不愿意从他嘴里说出来。这人一看就是个老油条,你小心点儿。”
  z3 P1 t8 e; D$ K, `' ]' [
  ~! E) G1 \3 |
“谢谢师父提醒。”

5 H" P5 I9 g8 P' P6 R# t6 J( @都说公司里面有办公室政治,看来确实是这样啊,晓川心想。师父年长我很多,这方面我要多听听他怎么说。不过,到底为什么构建总是出错呢?老刘说得也对,我得调查分析一下才能知道。. ^3 Q# R* A/ {9 n
* _8 E& b2 ]. V& m* X, i
晓川着手调查。就以上个星期刚做完的集成为例吧。每次构建出错,我是定位到出错的源文件,然后通过源代码版本控制工具查一下这个文件昀近是谁动过,然后就找相应的程序员去改正,然后把改正直接检入到集成分支。嗯,那我去看一下在集成期间,是谁把改正检入到集成分支上的,就能知道是谁的提交造成了问题。
; z  y- }- x9 W4 {9 X# Q# J
晓川去查看源代码版本控制工具的版本库中集成分支上昀近所做的改动。咦,都是晓川改的……哦,是因为程序员都是跑到我的计算机上改的,所以都是以我的名义检入的。唉,这么查,查不出来了。
8 L! Z3 k- O/ \& o1 t
( X: c# f& m: Y$ K- E+ Q+ K
晓川只好根据每次改动所改的具体文件去查。因为修改这个文件,让编译能通过,那意味着这个文件的前一次改动是有问题的。这样,再去查这个文件当初是谁在哪个任务分支上改的,就能知道是谁在哪儿惹的祸了。
就这样,晓川用了大半天的时间,到快下班的时候,整理出了一张表,表明这次集成遇到的每个构建错误,各是由谁,在哪个提交中带进来的。下班啦!

2 U! w# i! q- J, o下了班,晓川在外面随便买了点东西吃。吃着吃着,觉得不对劲儿。倒不是吃的东西不对劲儿,而是想起了自己下班前的工作成果,觉得不对劲儿。$ u' f) H3 k% W" N2 ~0 T

7 n  b/ Z( G  g% @
每个构建错误,确实是某个提交带来的,确实是因为某个提交的存在而存在的。如果没有那个提交,就没有相应的构建错误。但是,这并不能说,这个提交本身是有问题的,是有构建错误的。因为程序员在提交前构建的内容,并不是我构建的内容。我构建的内容,是多个提交合并到一起之后的内容。

& k1 F, K+ I) }! O事实上,这正是老刘质疑我的地方。“如果程序员的提交都没问题,你确定你构建的时候就肯定没问题么?”我那时也觉得有点不对劲儿,自己的思路不严谨。怎么今天下午调查的时候又给忘了!不成,我得继续研究清楚。不然一周后,新的一轮构建又要开始了,就顾不上了。
3 K6 m& J2 S( b
! a& w+ Q5 V$ E  t' m& v6 ^* K  T4 h
星期二上班,晓川来到工位,解锁计算机,开始复现程序员在提交前的环境。这个比较简单,因为程序员工作在任务分支上,在提交前把所有要提交的内容都保存在任务分支上,所以,只要把任务分支末端的源代码取出来,放到本地工作区里,就得到程序员在提交前的环境了。

7 {7 b0 N! H0 K# ?: x) F在这样的工作区里,晓川开始编译构建。构建要一个多小时的时间,因为没法做增量构建,只能全量构建。一个多小时后,构建结果出来了,构建是成功的!
, y5 _& J; s$ M4 J5 W
+ |, s$ q6 |# Z! q( C4 q# {
晓川又做了几个试验。结果不尽相同。有的是成功的,有的报错。虽然不能完全确定,但是凭记忆,应该就是在集成分支上构建时报的错。这么说,集成分支上构建报错,有两种可能,一种是提交本身的问题,一种是几个提交相互合并带来的问题。在数量上,大概是一半儿一半儿。
, T) ]# }9 ~# t( ^8 `6 R8 W
得到了分析结果,晓川觉得挺有成就感。高兴的时候想想,嗯,集成这工作呢,其实也挺轻松的,因为大部分时间都在等。等着程序员解决代码合并冲突,等着构建。构建失败了,等着相关的程序员修复。而有时候是大家一起陪着等。等着把提交的代码都合并到集成分支,相关的程序员们才能回家。等出了基线,依赖于基线中内容的新的任务才能开始。等着等着,时间就等过去了。青春就等过去了。
/ B6 U' c0 p# q: w  K: E6 Y3 J" p1 ?  _9 {; r) p: t' u: ?  G
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-12 15:57:46 | 显示全部楼层
4.与 QA部门的同事沟通
. N* F' i8 Z+ [" O
8 X) t$ h- f" U* G- N. v- `
晓川的思路是,虽然集成时构建失败不全是因为提交代码的质量问题造成的,但是毕竟这是其中的重要因素。如果提交的代码都是可以编译通过的,那么集成时构建失败的情况就会少很多,集成所需要的时间就能够减少很多。这样一来,我的工作就能轻松很多。嗯,更重要的是,就像老刘分析的,项目就不至于被集成卡住这么长时间了。我拿后面这个理由去说服别人,应该更容易。
- [; m' ^% B: E
在去找老刘之前,晓川先去找了一下项目的 QA。QA负责质量保证工作,具体地说,制定质量保证相关的规定和流程,并且监督执行①。晓川隐约觉得,取得QA的支持,这个改进才好做。而这个改进,又像是 QA会支持的——凡是加强质量的工作,大概他们都会支持吧。
+ n1 A* A. q; r3 O9 y( r. k, Q0 O0 t* K. r0 x4 D- o- |
去找 QA谈这件事,晓川稍微有一点,怎么说呢,有一点忐忑。 QA他们组,准确地说,是 QA她们组,基本全是女生。而这个项目现在的 QA,他在项目开会时见过,是一个和他年龄相仿的女孩儿,叫莺莺,刚转到这个项目组。晓川从小就不太会跟女生打交道。说话之前会心跳加速,而且也不知道该说些啥,说句“很高兴见到你”之类的就没词儿了。嗯,这次要好些,毕竟是要谈工作嘛。

8 o" A$ V/ l* I! e, Y' F
晓川到莺莺的工位上,莺莺给他搬了把椅子。晓川把前因后果讲了一遍。讲完莺莺说,“你等一下”,然后就转身开始操作她的笔记本电脑。她们 QA整天到处开会,所以都配备的是笔记本电脑。晓川在旁边坐着,看着她的侧脸。过了一会儿,莺莺指着一份文档跟他说,“你看,咱们公司的研发流程里规定了,在提交之前必须保证构建通过。”

: j' F# \0 T2 b. U! o% I2 V4 k“哦,我都没有读过这个流程。”9 e: b! t, K3 S: G7 `
6 Q( y) m# n7 r% \* ^9 V0 H
莺莺听了,复制下文档的网络存储地址,用邮件发给晓川。“那估计也有程序员没有读过。”
" r& J7 c0 O$ b2 s  W. j) x
“或者读了却没有照着做。”! \  g6 _) i( o! G9 k* d
( z# ^0 S2 M- J7 l4 }( i- ?# O
“嗯。不管什么原因,我再跟大家强调一遍吧。希望能管点儿用。 ”莺莺说完,又自言自语道,“也不知道能管多少用……”
* a1 r. F( Y$ ]. C/ V& i( E/ M( ]. k( _6 ?
晓川不知道该说点什么。
3 I, P0 v% R; P0 W
“我再问问我老大吧。然后联系你。”莺莺昀后说。
7 z5 H9 R& h8 y8 U' I0 h! I& [8 h$ U/ [) l
晓川回到座位,查看未读邮件。这些邮件当中,有莺莺刚发过来的带有那份流程文档的链接的邮件。晓川回复“谢谢你。”点发送按钮之前,又加上了称呼和落款,“夏莺莺:谢谢你。董晓川”,分成三行。
! s" a) b+ q6 V8 M! N' J/ R1 w
邮件发送出去,过一会儿收到了回信,只有一行,“不谢,我叫夏英英。”+ i1 C- B& m1 h. s

; i2 h- J$ e/ w9 H1 o0 U5 X: _( F( v' u" g
①在不少软件研发组织, QA部门(质量保证部门)是测试团队的代名词。这里讲的情况不是这样的。
2 R& \+ J4 f% ?" ^$ B# E0 D& l
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-12 16:01:41 | 显示全部楼层
5.确定第一个改进方案

9 \# t8 i& o# v7 L! Q- y2 L8 X. o- [/ |( T: O
英英带着几套方案来找老刘和晓川讨论。方案一是,晓川收到提交后,先在其任务分支上进行构建,没有问题了,再把改动合并到集成分支。老刘提醒,这样晓川要额外费很多时间在任务分支的构建上,因此总的集成时间可能反而会延长。英英问,那能不能让别人代替晓川进行这样的检查。老刘说,可以考虑,先往下看看其他的方案。
! v# M( m' K$ f1 _5 `! Z
方案二是,在提交前,由晓川检查,程序员是否进行了构建并且通过了构建。晓川说,在技术上,这很难查。无法保证程序员向晓川出示的构建结果,就是其任务分支末端的代码编译出来的。事实上,之所以程序员提交了会构建失败的代码,多半是在构建成功后,又改了些内容,以为肯定没问题了,所以没有重新构建就提交了。
7 C  F4 ~0 a0 W' a5 R, w7 m# T: q3 |
方案三是,由程序员所在开发组的领导提交。也就是说,程序员先给领导发信,领导核实后,再给晓川转发。没等晓川说他觉得让领导们给他写信不太合适,英英自己就把这个方案否决了,因为既然方案之二晓川很难查,那方案之三领导也很难查。

# U- E( u1 y1 T6 t" z( `+ z* i4 \: n4 R7 y方案四是,程序员在申请提交的信里写上“已通过构建”五个字,否则晓川不集成这个提交,打回去重新提交。老刘问,如果程序员说是构建通过了,其实构建没通过,那怎么办?英英说,如果晓川事后分析出这样的事情,她就负责通报批评。0 U1 R$ O! E2 o
( X# m' o+ j$ Y2 u4 t0 y% K) B" x  V
接下来,在项目例会上,英英跟各个小组的领导们重点介绍了第四个方案,大家觉得尽管这个方案不完美,但是相对来说是比较好的,于是讨论通过了这个方案。
4 S1 r, j! `7 K- Y+ u9 W% x4 m0 T0 u$ A- W. D+ f
会后,英英写了封信给项目全体成员,详细说明了情况,并强调了如果出现了言行不一的情况,要通报批评。信的落款是英英和晓川。

7 R# m7 o( u, b% J  C执行的情况是这样的。在下一轮集成里,有两三成的提交没有标明“已通过构建”。晓川逐个给相应的程序员打电话,让他们在保证构建通过后,重新写提交申请。经这么一折腾,星期一晚上到11点才完成了所有提交的合并。那些不得不重新写提交申请的程序员,成了加班到昀后的程序员。晓川也有点累。不过这是值得的。因为在周四中午,而不是周末加班,这一版基线就出来了。
& ^5 n' K0 e9 u7 s5 y, Z) Z
4 g0 f, r* B* m6 v
回复 支持 反对

使用道具 举报

发表于 2013-9-16 10:35:17 | 显示全部楼层
太好了,拜读一下。
回复 支持 反对

使用道具 举报

发表于 2013-9-17 15:27:02 | 显示全部楼层
遇到问题要深入分析根因,找到最优方案,从而解决。
回复 支持 反对

使用道具 举报

发表于 2013-11-7 11:15:23 | 显示全部楼层
这本书出了?
回复 支持 反对

使用道具 举报

发表于 2013-12-4 11:51:48 | 显示全部楼层
读完《软件集成策略》第一部分的一个故事之后,忽然觉得这样子的工作很有意思,攻克一个又一个的难题,寄情于工作。很佩服流水先生的思路,把通常被认为是很理论很枯燥的软件集成问题,通过这样幽默风趣又有点浪漫的故事叙述出来,自然而然地牵引着读者看下去。继续期待第二部分的精彩内容。
回复 支持 反对

使用道具 举报

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

本版积分规则

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

GMT+8, 2018-1-20 12:09 , Processed in 0.087023 second(s), 8 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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