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

chinesedragon

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

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

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

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

可是，这事儿事实上跟你有关。
外差因素(Externalities)的负面效应

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

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

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

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

感觉如何？在接下来的一周里找一天时间，翻出一段代码，就当是走错了路，拐进了一条本不想走到胡同，修改一下。提交你的修改，并附加这样的注释：
/*
JKH 09/12/2012 - 重构了有问题的事务处理。如果这是你喜欢的，请将此做法传递！
*/

starwing83

万一改出bug就百口莫辩了——毕竟你可能并不是真的所有者。我觉得应该增加一条：在确认真正的所有者下了地狱以后再这么干~~

zylthinking

JKH 09/12/2012................
我一般将出现在我代码里的其他人加的注释中夹杂的日期， 添加人的姓名直接删掉， 然后将其修改的理由写的更详细些

windoze

毁掉代码的不是什么效应，而是待遇

chinesedragon

zylthinking 发表于 2012-09-25 11:16
JKH 09/12/2012................
我一般将出现在我代码里的其他人加的注释中夹杂的日期， 添加人的姓名直接 ...

这个只能给你拜了

linux_c_py_php

1, 同事代码架构完全没有问题, 并且代码清晰易懂, 是份好代码, 只有细节值得优化, 这种我愿意去优化细节, 很常见的是内存与数据结构的优化, 比如, 缓存回收的内存以便减少malloc分配的性能损耗(我不会无聊到给它程序加个内存池).

2, 烂代码, 也就是架构已经是错误的代码, 比如: 明明是可以懒惰删除的逻辑, 非要一个独立的线程去轮, 或者用一个错误的架构撑着不等量的请求, 甚至把阻塞的业务逻辑放在I/O loop里, 这种没必要改, 只要领导说给我时间重写(所谓重构), 那我就重写, 否则我毫无兴趣去读代码, 也不会当作自己的事.

幻の上帝

回复 5# chinesedragon


这个活更适合版本控制工具干。

cokeboL

要看待遇，要看公司管理流程，要看项目进度、以及测试相关。

1.钱给的少，有几个人能做到视如己出。

2.管理者怕出事经常是只要求维护，甚至技术领导会告诉不要乱动别人的代码，管理者只看功能，经常无视代码内部的实现。

3.如果项目紧，没充足时间进行大改动或者优化，就不搞。

2、3两条，大点的公司测试相对规范，已有的代码是经过测试认可的，如果大改动，可能进度来不及重新测保证覆盖，而项目结束后就更懒得管了。

chinesedragon

真的，代码的时间越长越不容易管理

cokeboL 发表于 2012-09-25 14:28
要看待遇，要看公司管理流程，要看项目进度、以及测试相关。

1.钱给的少，有几个人能做到视如己出。

linux_c_py_php

别人的代码基本都是当黑盒用, 没有外力推动谁去看, 除非真的很优秀, 真的值得学习一下.