“旁观者效应”是如何毁掉我们的代码的

1964年,纽约昆斯区,28岁的Kitty Genovese在经受了长达35分钟的性侵犯后最终被谋杀致死,共有38个本地区人性正常的居民经过,但没有一人提供帮助。

旁观者效应

犯罪

图片来源: Abu Badali, CC 2.5, via wikimedia

这个故事例证了‘旁观者效应’中的一个不幸的心理特:援助的几率与旁观者人数成反比。旁观者数量越多,他们当中任何一人进行援助的可能性越低。

作为程序员,我们几乎每天都能看到“旁观者效应”在起作用。如果你的代码库已经有了相当的体积和年月,你很可能知道它们会存在一些问题,比如缺乏封装或模块分离,类继承结构过于复杂,方法太长——读起来就像是Stephen King最近写的小说,未经测试或无法通过测试等等——但没人想去做点什么。

“旁观者效应”的问题根源

问题的根源是缺乏物主(所有者)身份。我们总是在假设别人会来修补这些问题。如果这些问题出现在我们的代码库中,我们很可能对之无动于衷,因为“这事儿跟我无关”。程序员对这样的问题通常的反应:这是别的程序员造成的问题,我才不管呢。这种“这事儿跟我无关”的态度很流行。

可是,这事儿事实上跟你有关。

外差因素(Externalities)的负面效应

经济学上有个词叫做“外差因素(Externalities)”,它形象的描绘了这样一个情况:A人从某件事情上获利,但B人却要为此买单或部分的买单。你作为B人,免不了会遇到要去修改A人所写的恐怖的类代码。你以为这个类应该是经过精心设计的,你以为它们都有相应的功能测试代码。但事实上,你为了一个小小的修改做了大量的工作。你的老板会奇怪,这样一个简单的任务为什么需要这么多的时间。别人犯下的愚蠢错误最终却要你来擦屁股——这就是“外差因素(Externalities)”的负面效应。

培养物主身份

纠正“外差因素“的负面作用的方法很简单:接受问题的所有者身份——不论问题是不是由你造成的。为什么要在意这个问题是谁的责任呢?造成这些问题的人很可能早就不知去向了。还在等待他们来修改这些问题吗?你永远都等不到。我们应该这样去想:除了我,没有人会来修改这些代码。

一旦你这样做了,一种所有者的身份就开始出现了。当你花了很大的功夫修改好了这些问题,而问题再次出现时,这些问题自然归你所有了,因为你为它们付出了汗水。

这样一来,我们就会开始”义务“的改进我们的代码库。你打开一段有问题的代码,你忧心忡忡的研究它,你忧心忡忡的心情很快云消雾散了,因为你发现有另外一个”圣人“已经把它修复了——多么美好的世界呀!这样的事情之所以能发生,是因为每个人都找到了自己的责任感。这是最美好的时刻。

行动起来!马上!

感觉如何?在接下来的一周里找一天时间,翻出一段代码,就当是走错了路,拐进了一条本不想走到胡同,修改一下。提交你的修改,并附加这样的注释:

/* 
JKH 09/12/2012 - 重构了有问题的事务处理。如果这是你喜欢的,请将此做法传递!
*/
[英文原文:How the Bystander Effect is Ruining Your Code ]
分享这篇文章:

12 Responses to “旁观者效应”是如何毁掉我们的代码的

  1. 无名 says:

    这种思想适合在大企业或是有明智的BOSS,而且我相信有责任心的程序员也都是这样做的,但时间长了后就会视而不见

    举个简单的例子,
    比如程序中的一个模块有一个小BUG
    你发现了,然后花费时间修改了
    对于某些BOSS来说,你在这段时间里做了无用功,因为他不觉得这个BUG有多大的影响或者说他根本从没遇到过这个BUG,那么他认为你偷懒了
    如果这个模块是同事写的,那么他可能会认为你在针对他,这样的事情多了后BOSS也会这样认为.

  2. lite3 says:

    其实跟自己代码有关系的,比如需要调用别人的方法,而这个方法却有bug的时候会去改,否则不会动别人的代码.呵呵.

  3. lys says:

    我觉得出现这种事情的原因有两点,
    1)去做会承担风险,改出问题肯定算到你头上;
    2)去做了没有好处,改好了个人也得不到什么实实在在的激励,因为没有实际的方法去度量你所做的修改带来的贡献;
    怎么办呢?还是要把产品质量,公司业绩同个人利益紧密联系起来,真正做到公司的价值即是个人价值,才会让员工自觉自愿,发自内心的去提高产品质量。像很多硅谷创业公司做的,每个进入公司的员工都持有公司期权,公司做好了大家一起发财,做不好大家一起完蛋。

  4. 秒大刀 says:

    美好,但有点难
    绝大多数团队遇到的都是非技术问题,其中最突出的之一就是政治风险
    环境或者说系统对项目的影响,会比其中的人更多更本质一些

  5. haitao says:

    关键还是看公司文化、制度

  6. ykkk says:

    修改别人的代码是有风险的。那种RP不好的员工会把错误的责任推卸到你身上。

  7. 深蓝空间 says:

    我们公司的做法是:每个人在每个项目中有维护自己模块的代码。不准修改其他人负责的代码。另外,老代码除非出现bug,不然不让修改,害怕修改让以前稳定的环境引入新的bug

  8. xylon says:

    在日企,如果碰到这种问题是绝对不允许你改代码的,必须报告上级并且用一个新的BUG单来处理这个问题。
    在国企,最好是哪个高手高手高高手跳出来说大家别动!整个模块我来重构一遍!然后此人能够加官进爵。

  9. lion lan 对这篇文章的反应是赞一个

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据