2006-11-26

谁是敌人?

很傻的问题,岂能不辨敌我?然而在特定情况下知道敌我之分和真正用相应行动来回应敌我是不一致的。近几年的新闻报道的科索沃、阿富汗与伊拉克战争中,给我最大的感觉就是战争中(尤其是美国及其盟友方面)死人越来越少了。从强大的一方来看,其打击的目的是摧毁对方的反击能力,现代战争中,摧毁运输通道与大规模杀伤性武器即可达到目的。而读史记等书就有不同的感觉,好像中国自古以来一大特色就是人多,命贱,像蚂蚁一样,不起眼的战争也是万人级的伤亡,时不时就“坑**万”。其实目的是一样的,摧毁对方的反击能力,因为古代打仗的决定性因素就是人,而现代战争的决定性因素变成了武器系统。然而即使进化到现在,战争中一个小问题还没有解决,即误伤自己人,古代打仗,大家一起往前冲,挥刀狂砍,相信死在自己人刀下的冤死鬼不少,现在新闻中也经常报道美国与其盟友内部互相误伤的事例。可见,真正能明辨敌我不容易啊。

近日在site工作也遇到了这种尴尬,如果把调测与解决问题看成战争,显然tester与developer是盟友,共同的敌人是存在的问题,tester发现问题,developer解决问题,互相配合赢得战争。而实际的情况并不如此完美,往往在内部展开了暗斗,tester发现问题,developer想掩盖问题,于是tester想扩大问题以引起注意,developer更想掩盖并反击,其结果是双方文明地“剑拔弩张”。比较尴尬,不过也还算不坏,至少在争吵中还是能解决问题,大方向上不至于在和和气气中输掉战争。也许tester和developer之间的现实关系就是这样,在和共同的敌人斗争的同时内部打打闹闹,不值得奇怪。但理想的情况应该不是这样的,盟友之间应该“狼狈为奸”才对。问题出在哪儿呢?

首先是沟通。

沟通应该是个普遍问题,由于表达能力及方式的有限,不可能完全表达清楚思想及感受,人与人之间总会产生误解,因此一方的话传到另一方可能意思就反了。本来好意提醒错误的存在,会被认为是挑衅、找麻烦;本来仅想描述错误,却被理解为对其的指责,于是“仇恨”的种子便生根发芽,茁壮成长。
避免这种情况需要双方做到就事论事,不带强烈的感情色彩,尤其tester在找到问题时不能太过得意,以免产生误解,找到愚蠢错误时也不要过于愤怒,人总会犯错误。

从辩证法上来看,双方也有不可调和的矛盾,立场不同,tester的本职就是找错误,错误找的越多越有成绩,而developer虽然解决问题多也有其成绩,而往往由于其解决的问题就是其先前留下的,便成了其污点,问题越多,污点越多,越会被人指责,于是不可避免想掩盖错误,质疑与模糊tester的战果,有责任心的tester是不能允许这样的,于是会更加努力证明developer的确存在问题,矛盾的双方的人民内部斗争便开始升级。
从辩证法的观点看,双方也应该是统一的,共同为了同一个终极目标而奋斗:消灭bug。为什么往往会忘记这点呢?developer难道不知道掩盖问题无异于给自己埋炸弹吗?不知道故意抵赖与狡辩是不职业的行为吗?否也,这些理放在平时谁都懂,但是一到参与其中,便很少有人能做到恰到好处。为什么会这样?是什么使正常情况下的正常人变成非理智人?

是压力!

如果没有各种限制,比如时间限制,完全在理想情况下,放松的状态下,双方心平气和,相信都是谦谦君子,互相谅解、礼让,好好就问题论事、解决问题。但是实际情况不可能是这样的,每个项目都不可能没有时间限制,总是时间不够用,受各种条件制约。于是,对于tester找出的问题,developer必须在限定时间解决,找的越多压力越大,而往往问题多的地方正是前期质量较差的地方,需要修复的时间越多,带来压力更大,developer不堪重负,于是设法掩盖问题。尤其是再有从上层来的压力的时候,developer更会崩溃。同时,tester在site上遇到的问题多,也会倍感压力,更多来自客户,一般很多问题都不便向客户坦白,而是寻求内部尽快解决,于是把受到的压力也传递到developer那儿。由此可见,tester和developer都会很有压力,压力倾向于汇聚于developer,但developer也会通过抵赖的方法来自卫并反击tester,并且可能会通过各种解释使上层相信tester报告的问题不准确或不存在,使上层challenge tester,让tester做更多的测试来证明的确是问题,加重了tester的压力,于是“怨恨”在双方之间传开,不加控制会造成不合作状态。

在压力情况下,不光tester和developer会失去理智,manager也同样会失去理智。人总是偏向于听好消息,对坏消息有拒斥心理,于是developer很容易使manager相信问题不大,能很快找到“银弹”,而tester专报告问题,并且有时会夸大问题,显得很讨厌,便有可能受到无理惩罚。至此也明白为什么历史上在皇帝身边出了那么多得势的花言巧语的奸臣,而又冤死了那么秉言直书的忠臣:(

事态至此,如果不加控制,恐走向毁灭的深渊。如下方面入手:
1. Developer从被问题导向变为主动解决问题,当tester发现一个问题时,应在解决这个问题的同时,举一反三,解决相关可能的问题,而不是仅解决这个问题,然后把脑袋埋进沙子里,等待tester发现另一个问题再解决,这样会很被动,并且会让tester很恼火,类似问题重复出现是很令人沮丧的一件事。如果在某一模块发现问题较多,则不待tester发现问题,主动重新review 设计和代码,提前发现和解决问题,不至于被报告问题时手忙脚乱,这样也会减轻tester的工作量,否则每提交一个版本都要做回归测试,很累的。

2. Tester描述问题尽量客观,不带情绪与成见。记录更多的问题相关发生环境,帮助developer定位问题的原因,让developer强烈感觉到是盟军,而不是敌人。

3. Manager控制自己情绪,听取客观情况,协调developer与tester之间的沟通,必要的时候为双方减压而不是一直加压,直到崩溃。重要的职责是指导相关人员有条不紊地解决问题,而不是责骂,否则会使developer和tester都向其隐瞒问题,直到无可隐瞒,彻底崩溃。

其实,如上的努力只是没有办法的办法,项目已经进行到测试的阶段。如果项目正在设计或编码,还是奉劝developer多做努力,通过design、review、UT等把容易发现或可以预见的问题尽早发现和解决,带入到最后阶段的问题越多就越被动,直至失去理智把盟友当成敌人斗,岂不缪哉?!

2006-11-12

世界是否需要超人?

在《超人归来》电影里,当超人重返地球时,发现地球上的人们已经习惯了没有超人的生活,连以前的“地下”恋人也发表文章《世界不需要超人》,说明地球上已经不需要超人的存在,当然这里存在着爱恨交织的因素,但至少说明人们接受了没有超人的现实。习惯了接受崇拜的超人同志也不免有些失落。不过超人就是超人,依然怀着普济众生的理想与信念,“准时”在灾难的第一时刻出现在现场,救落难的地球人于水深火热中,继续扮演灾难救世主的角色。从此,人们知道超人又回来了,代表正义的力量和邪恶做斗争,除暴安良。直到影片结束,都说明了一个问题,那就是地球还需要超人,需要超人的力量来战胜邪恶。

看这个电影,突然想到一个问题,既然地球毫无疑问需要超人,但一个超人够用吗?需要多少个超人才能满足需求呢?地球上同一时间出现问题的地方绝不止一个地方,超人如果不能像孙悟空一样能分身,只能救一处,舍弃其他地方,就会产生不公,凭啥厚此薄彼?!因此需要多个超人,到底需要多少呢?这需要知道地球上的灾难事故数据模型,再给出超人的事故处理速度、移动速度,可以算出总共需要多少超人才够用。

超人只是电影中的美丽幻想,至少在目前还没有这样一个外星人来地球学雷锋做好事。要地球稳定还得靠自己,也就是地球本土的正义化身--警察。当然,从性能上比,警察和超人是没有可比性的,但从功能上说,二者的目标是一致的。二者都是代表正义救死扶伤、除暴安良。为了能及时赶到事故现场,超人使用超人类的本领--飞,警察则使用警车。为了打击犯罪分子,超人还是使用超人类的力量,警察则使用武器。因此,超人更准确地说应该是超警。

由于人类警察的性能局限性,需要很多的警察来完成同样的事情,在技术落后的情况下,只好使用人海战术。即以数量来弥补质量。既然完成同样功能,没有超人的情况下,我们可以用土产的警察,我们为什么还需要超人呢?由于没有超人能力,警察有很多事无能为力。于是,倍受邪恶力量折磨的地球人幻想能有超人来解救自己。

可是这个答案并不令人满意。我们需要超人首先是因为地球上存在邪恶力量,没有邪恶力量或灾难的存在,就不需要警察,更不需要超人。没有人会在路不拾遗、也不闭户的安定社会里装笨重的防盗门,同样,没有人在没有邪恶、没有苦难的安乐社会中幻想超人的救助。因此,超人是伴随邪恶存在的,正如乱世出英雄,是乱世造就了英雄,给了英雄成为英雄的机遇,太平盛世是很难出现让人崇拜的英雄的,即使有也是向外开疆拓土、对抗外敌的英雄。

既然英雄总是伴随苦难而出现,我们为什么还需要他们?他们的存在不是目的。如果能够以他们换来大众的幸福安定,当然不需要他们存在。没有人会为了崇拜英雄而树立英雄,除非英雄的定义已经改变。同样的道理我们不需要超人,不需要在灾难中拯救人的超人。我们需要的是没有灾难,天下太平。超人的出现,说明了我们地球还有很多灾难,远离太平。如同医院,医院能把人从病痛中解救出来,但没有人会盼望去医院。

普通大众追求的是生活的幸福,希望生活在太平盛世,而非英雄辈出的乱世,即使爱看英雄们的故事,但不愿意回到那个时代等待英雄的解救。我们需要的是治世能臣,而非乱世英雄。治世能臣能预知灾难,提前准备或化解灾难,而非当灾难发生时凭借一己之力泼水救火。虽然少了那份惊心动魄的刺激,但防患于未然能最小化灾难带来的影响。

世界不需要灾难营救的超人,套用到软件开发团队就是:团队不需要解决bug的大牛。真正需要的是能提前预知、防备bug出现的大牛,此大牛应从Design, coding, review, UT等过程中尽量杀bug于未形中,而不是等bug被发现再发力去修补。当然,总有捕捉不尽的bug,还能在关键时刻解决bug的大牛是更理想的牛:)

预知、防备问题需要的更多的是经验、机智,而超人式解决问题靠的更多的是力量。软件开发亦然。

2006-10-31

迈出第一步!

系统上线了。
第一个业务割接成功,运行正常。
虽然还不完美,但总是要上线的。没有也不可能完美的东西,继续完善吧......

2006-10-26

一个男人和三头驴

昨天晚上(凌晨)回去的路上,一同事说:一个男人领着三头驴。
四人汇心大笑~~~~~

鄙驴荣任驴长 :)

2006-10-21

潜规则

曾几何时,潜规则这个词流传开来,于是乎很多陋习都有了一个看似冠冕堂皇的说法:潜规则。官场上卖官鬻爵是潜规则,生意上吃喝玩乐是潜规则,借过节送礼是潜规则,单位上晋升按资排辈是潜规则................................

所有不能在阳光下光明正大地运作的规则都用潜规则称之。和潜规则向对应的写在纸上贴在墙上的我想称之为明规则。我们从来不缺乏明规则,正式场合大家口口声声的也是明规则,而低下盛行的却是潜规则。为什么?! 我们是不正直的民族?I don't know. 怎么解决? I don't know.

行贿受贿大家人人喊打,可是依然在潜规则地运行着。轮到自己又如何呢?打破之?相信有人能做到。有几人?I don't know.

集体受贿的时候,有几人能不被潜规则地拖下水?I don't know.

谁知道,请告诉我。

2006-10-17

演讲技巧需要改进

今天给用户做培训的时候,有人用MP3做了录音,我也拷贝了一份。回来后自己听了一段,发现和自己的感觉有很大不同。不听不知道,一听吓一跳。

有以下不足:
1)用了太多“这样说”、“就是说”、“然后”......等词语,给人感觉不是很连贯。以前听别人做演讲或讲课的时候会取笑人家用很多的口头语、重复语,今天才知道自己也一样 :(
2)有些话只说了一半,没有把意思表达清楚就跳到另一个方面去了;也有些话说了很多遍,啰里啰唆。
3)感染力不够,感觉激情不够,语调变化太小。使听者犯困,亲眼看见有人睡着了 :(

以后好好改进。

2006-10-16

根本问题

有人说好的问题是解决问题的一半,即能提出正确、关键的问题,对解决问题有很大的帮助。好的问题让被提问人往正确的思路思考回答,而有误导性的问题则会使被提问人误入歧途,回答的东西离问者想问的东西十万八千里。

往往提问者会对问题进行思考分析,排除自认为不可能的答案或可能性,进入到更加具体的问题,以便能更快得到答案。大多数情况下,这是有效的。但也有很多时候,提问者会误把可能的情况排除出去了,产生无效的问题,离原始问题越来越远。

今天就有一例:早上去site发现无论如何试上不了外网了,于是断定或者上面改网络配置了,或者网线坏了,因为我们是通过引一根网线到上层管理中心路由器连接到外网的。于是上去换了网口,不行,又问管理中心的人是否改网络配置了,得到的答案是没有,于是便认为是网线坏了。下午又有人试图重新试一下,上去换了网口还是不能连上网,于是又去问人家是否改了网络配置,得到的答案还是没有,于是更加认定是网线坏了。为了确认是网线坏了,拿了一根确认是好的网线,抱着笔记本上楼去直接连到路由器上试试,结果还是连不上,正觉得奇怪的时候,那个两次回答我们没有改网络配置的人说了一句:“我们也是从早上开始就上不了网......”听此言差点晕倒,从早上就开始折腾分析,反复询问,根据得到的回答推论出是网线的问题,并且抱怨人家网线做的差没用几天就坏.......被这一句话推倒。

我们分析来分析去,自认为只要问一个问题就能判定原因,哪知被这个问题引到了牛角尖,忘记了路由器上面还得连到其他网上去,整个路由器也可能就连不上网。其实,拿最原始的问题“我们为什么上不了网?”去问,别人肯定很快就会说出那句话,而我们却拿另一个自认为更精确而却并不是真正问题的问题去问,结果自然得到了不是答案的答案。

看来,在问问题前,自己捉摸的太多并不总是最有效的。尤其看似简单的问题,会有思维定势,往往得不到创新的答案,需要从最原始的根本问题开始问起,进行头脑风暴。

2006-10-14

执行力

今天去和客户谈事,最后要找他们的一个人执行,这位领导就带着我到他们组其中一人座位面前问能不能做这事,这人回答有事。又到另一个座位问另一人,又有事,问了三四个人都是有事,直到最后一个人才答应做这事。当时顿感悲哀,不为别的,只为这个领导。此人乃老电信技术四大金刚之一,技术上有相当功底,很多想法也颇为新颖。掌握几国语言,据说汉语在其中算是最差。一起吃过饭,聊天,发现其文史功底也不差,可以说相当有才华。只可惜过于耿直,在人事上不太擅长,在这种企业里不太合适,于是仕途上不顺。颇感惋惜,有虎落平原之感。

就这件事来说,不算大事,但说明了一些问题,也颇有教育意义。
1. 如果手下员工的确忙。那说明其事先没有考虑过谁忙谁不忙,谁应该做,谁适合做。在分派任务的时候这些因素是要事先考虑的。或者其根本不知道低下人整天在做什么,这应该是做领导的失误。
2. 如果手下员工不忙,而仅仅是推托不想去做。除了说明其没有事先考虑上诉因素外,还说明了其对下执行力不够,平时没有培养到足够的威信,于是有事分派不下去。

前段时间非常流行执行力的书,没有看过。也不知道这地方用执行力这个词是否合适,但没有更合适的词了,暂且这么用吧,如果用错了就算通假词:)

关于执行力我认为:第一步是对要执行任务的分析,搞清楚要执行什么;第二步是分析执行时需要的资源;第三步是执行的时间期限;第四步是执行的反馈与检查。听起来都是废话,真正做的时候好像不太容易,否则就没有那么多扯皮的事了。今天这事在第两步就出问题了,没有分析出做这件事谁最适合,导致一个个问,一次次被拒绝。这也是损伤威信的事,尤其在所有人面前,有人会想:***拒得我就拒不得?于是便拒了。如此,非集体讨论分派任务的情况下何不把人叫到办公室去分派?

威信没有建立起来,我想这和第四步有关。每一次执行结果及对其的反馈,都会对下一次执行造成影响。比如做一件事情成功了,会对下一次做类似的事情增加信心,对责任人的奖励会激励所有人;做一件事失败了,对经验的总结会对为下一件事做“前车之鉴”,对责任人的惩罚会对其他人形成警告。还是那个蹂躏定律:先蹂躏一番,以后就老实了。

威信的建立不是很简单的事,每个人性格不同,有人用怀柔之法(胡萝卜),有人用强硬态度(大棒),还有人采取中庸之道(胡萝卜加大棒)。
用胡萝卜的就是通过经常的奖励来激励他人,或者给大家描绘一个美妙的愿景,鼓动大家朝那个方向奔跑,曹操的望梅止渴就是这个方法。在这个共同方向下,大家有一定程度的自由与民主。
大棒就是经常用惩罚或命令的方式,常见于军队式的管理,令下必行,不管命令正确与否都要执行。否则惩罚。诸葛亮的挥泪斩马谡就是一例。大棒听起来挺吓人,抡出去必然使对方受伤。但是很多情况下,作为中国人,和和气气惯了,真正能毫不犹豫抡大棒的人有几个呢?
胡萝卜加大棒就是两种方式的灵活使用。说着简单做时难。

作为管理的一个环节,执行是不可或缺的。缺乏执行力的管理必然失败,导致管理者的痛苦。

路漫漫其修远兮.............

2006-10-11

你感觉幸福吗?

前几天有个纪录片介绍德国一个社会调查机构从二战结束开始调查有幸福感的人群比例,一直到现在,结果发现随着物质生活的提高,人们的幸福感非但没有提高,反而降低了。一开始觉得奇怪,想想也很正常。小时候家里除了过年很少吃肉,所以每次吃肉都感到满足与幸福,家里也不是很穷,因此隔段时间就能吃上一顿,所以就经常有幸福感。而现在只要想吃,每天都可以吃到肉(不要鄙视我:)),但是却没有那种盼望吃肉的欲望了,反而会因为担心腰上的游泳圈而控制自己口腹之快,完全没有了那种因物质生活贫乏而产生的幸福感。

和很多人聊天都有一个感觉,那就是小时候都玩得很快乐,很幸福,小时候吃的东西也很好吃,现在吃同样的东西总是没有同样的感觉,也许东西还没有变,但是感觉变了,因此留下很多遗憾。也许小孩子容易满足,也许是其他的原因。初中的时候,春天下午放学后经常拿着网,到附近的河里去捞河虾,那段时间特别专注,几乎成了每天的工作,每次都能捞不少的河虾,晚上家里就吃河虾鸡蛋汤,感觉好极了,甚至骄傲地可怜城里人“他们能吃到这些新鲜的河虾吗?”,颇有“日喝河虾汤一碗,不辞长住小河湾”之感。今日也成了当初被自己可怜的人,真的少了这份幸福感。每次看到超市卖的虾皮,只能回忆自己下河拖网捞虾的快感。

因此,幸福是一种感觉,不能说和物质生活无关,但至少不和物质生活成正比。幸福感是主观的,不能由外在的可量化的东西来度量。比如不能通过在身上装置一个仪器来测量,也不能以一个人拥有的财富来测量,而只能通过问“你感觉幸福吗?什么时候感觉幸福?.......”等问题来调查。

对于“你感觉幸福吗?”这个问题,问不同的人当然答案不同。即使问各种外在条件相当的人,得到的答案也可能不同,因为人的内在欲望是不同的,也就是感觉幸福的阀值每个人是不同的。阀值低的自然就容易感到幸福,知足常乐嘛。
上个月刚来长春出差的时候,前一个星期呆在机房里工作,每天坐在地上,笔记本架在弓起的腿上,或前面放一个纸箱,把笔记本放在上面,然后盘腿而坐,一天下来腰酸腿麻,差点去买哈腰六厂的盖中盖。一周后,终于临时办公室弄好了,搬到里面工作,有桌子、椅子,虽然和在北京的办公室相比天壤之别,但和机房相比又是天壤之别,以致一个兄弟幸福地晚上不想走了。而后来出差的同事一开始总会抱怨办公环境的恶劣,而我们这些老同志就会语重心长地对这些新兵痛陈革命家史,描述那一周的艰苦岁月。同样的办公环境,老同志会感到幸福,而新兵会觉得不满,这就是内在欲望的不同。前一周的痛苦,已经把我们的欲望阀值降到很低的水平,条件一提高便感到幸福。因此,一个兄弟总结出蹂躏定律:对于新兵先蹂躏一番,以后就老实了(好像军队里也是这么做的)。看来人真是很溅的动物:(

虽说这个蹂躏定律很简单,但很少有人愿意被蹂躏。想要幸福真的不容易,因为人的欲望是会水涨船高的,在条件低于期望的时候拼命想达到这个条件就幸福了,往往等真的达到这个条件后未等喘息内在的期望又提高了,于是又拼命追逐,条件渐好,欲望更高,到最后在他人眼里本该幸福的人只能望幸福兴叹。小学、中学、大学、工作、房子、车子、儿子.......何时是尽头?:(

欲望之所以会升级,是因为比较,往往是横向比较,每达到一个台阶,就会不自觉地和同一台阶上的人比较,而每一台阶上都会有很多人,于是不断爬高,不断和不同的人赛跑,忘记了休息,忘记了感觉幸福。直到跑进坟墓,不知到另一个世界会不会继续这个过程。因此很多人提出享受过程,而不是山顶,因为总是这山望着那山高。很多时候需要“灭人欲”,由于能力有限,又想幸福,这不失一个好方法。降低欲望,简单生活,体验幸福,不亦乐乎?

大多数人还有一个共性,那就是看别人总是幸福的,而看自己总是不如意的,殊不知在别人眼里却是相反。不知这是什么原因。也许是因为对自己自视太高,而对别人太轻视,总认为自己应该更XX,而别人就那条件,应该满足了,所以已经够幸福了。这种意识应该是潜意识的,所以看起来会像发自内心地一样羡慕别人的幸福,同时对自己的不幸感到沮丧。正所谓“人莫知其子之恶,莫知其苗之硕!”

对于“什么时候感觉幸福?”这个问题,那个节目里介绍一个专家研究的结果表明人在专注地做一件事情的时候最有可能感到幸福,只要专注,而不在于做什么。其中一个例证就是伦敦的一个松饼店里两国肯尼亚工人,十几年来没有休过一天假,一直做同一件事情:烤松饼。他们工作时感到很幸福,很专注,主动不休假。他们在专注工作中找到了幸福,找到了自信,自信他们做的松饼是全伦敦最好吃的松饼。很显然,这是一个良性循环,正反馈。

比较认同这个看法,当人能专注地做一件事情的时候,内心和行动是和谐一致的,在这个状态的人是快乐的。如何才能做事专注呢?当然不能强求,否则只是表面的专注,好比在老师眼皮底下读书,往往只是看起来很专注。同样,在老板眼皮底下工作,也有很多人是看起来很专注。能真正专注于做某件事情,一定是自己喜爱做的或者认为值得做的事。

就工作来说,选择一个自己内心喜爱的工作当然是很好的开始。这里指的喜爱是真正的爱好,而不是由于这个工作能带来高薪水、高社会地位而喜爱。一个爱数钱的人,而不是一个爱钱的人应该去做银行前台职员。大部分公司招聘的时候都会看重应聘者是否真的喜欢这个工作和行业也就是这个道理。

但一个喜欢这个工作的人招进来是否就一定能专注地工作了呢?不尽然。有很多公司行为会破坏这种专注。如下面情况:
1)努力做的东西(产品)没有价值,没有一个美好的愿景。虽然工作是自己喜爱的,但是没有人愿意做一个没有前途、没有价值的东西,即使做这个可以带来不错的薪水。
2)公司没有前途,导致员工没有安全感。在社会上没有好的声誉,在朋友和他人面前没有认同感和自豪感。
3)个人在组织内没有前途,提升机会渺茫。任何人都是有上进心的。上进不一定行政职位上的升迁,还可以是级别上的提升。管理者没有给员工清晰的职业规划,导致员工对前途感到迷茫。
4)长期做重复劳动,当然这条有人例外,比如上面提到的两个肯尼亚工人。大部分人还是希望在一段时间的重复工作后尝试其他的工作岗位。很多公司里会有岗位轮换制度,避免一个人对重复工作感到厌倦。
5)工作职责不清晰,导致每个人同时做很多事,并且都是没有预期的事,不能专注于特定工作。
6)薪水、福利不够,员工总是因为经济或其他的事情分心(比如房贷:( )。或者和同行业相比太低,让员工感到不平衡并采取用脚投票的方式抗议。

2006-10-02

Exception

看了一天的code,发现以前code inspection的目的还是没有完全达到,很多code还是写得很难理解。当时只是指出问题所在,并没有在事后检查是否修改。并且,当时由于很多新员工,这些code inspection meeting更多是编程教学,希望能够举一反三,现在看来没有完全达到目标,以后得继续努力。

例如:有人在一个方法中想返回两个返回值,一个返回值是对象,另一个是整型,于是便将整型设置到对象的某个域中,粗鲁地修改了该域的本意,以后会让维护的人以头戗键盘。

另外一个普遍的问题是方法的返回值代表了太多的含义,如查询价格的方法返回值定义了“该业务不存在”、“数据库操作错误”等的异常情况返回值。导致方法调用处理复杂。这地方应该直接抛出Exception,后继处理Exception就直观多了。项目开始没有明确定义什么时候用Exception,什么时候用返回值,下次得定个明确的规则:

1)正常情况用返回值,如价格查询只返回价格,只要能返回,一定是合法的价格。
2)异常情况抛异常,如业务不存在,抛业务不存在的异常。