谁是敌人？

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

近日在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等把容易发现或可以预见的问题尽早发现和解决，带入到最后阶段的问题越多就越被动，直至失去理智把盟友当成敌人斗，岂不缪哉？！

世界是否需要超人？

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

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

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

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

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

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

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

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

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