替人“擦屁股”

　　在企业工作了一年多，发现经常要替别人“擦屁股”，有时候别人也要替我“擦屁股”。这可能是以前我所在的学术圈（或者说学校）很少发生的事。在实验室里，大家各干各的，相互之间没什么交集。唯一接触过有印象的例子是，分析数据的时候，数据本身就不好，甚至是错误的。这时不管采用再强大的统计模型、再精良的软件都不可能分析出有价值的结果。悲剧的是我们数据分析人员往往是不敢质疑数据提供方的，因为现在是数据为王的时代，研究统计的往往得求着别人要数据。

　　还是说说我在公司的事。

　　刚来公司的时候我被分到了游戏逻辑组。游戏逻辑的特点是多变、复杂，因此代码架构一般并不优雅，模块与模块之间耦合度很高，逻辑错综复杂。往往我修掉了自己模块的一个bug，会给别人的模块带来另一个bug，甚至引发crash，因为我对那个模块不了解，可能会破坏那个模块里的“潜规则”。这时别人就要替我“擦屁股”了。而有时我会突然接到QA提的bug，看了bug描述之后会觉得愕然——怎么会有这样的事？！我的代码不可能会这样的！仔细一查代码——擦，被某人改坏掉了。

　　有时候这个别人并不是负责别的模块的同事，而是我所负责的模块的前任，我只是接手的人。今年初项目内测的时候，我负责的拾取模块让服务器崩了很多次（后来汇总崩溃情况，发现一半的崩溃都是我的代码造成的），就属于这种情况。前任在代码中留下了太多我不知道的“潜规则”，而我接手之后各种需求又接踵而来，必须马上实现。于是只好在对代码把握不到位的情况下匆忙改代码，于是就各种崩坏。这时就只好替前人“擦屁股”了。这是最郁闷的情况，没人能交流没人能沟通，能交流的人已经走掉了，把摊子留给了我。

　　后来我被调往了服务器组，不过“擦屁股”的事情可一点也没少。服务器程序员虽然一般不用掌握很具体的游戏逻辑，不用修太多游戏bug，但是却有一项重要职责：快速响应服务器崩溃——尽管绝大多数崩溃都是由游戏逻辑造成。可能大家对服务器组的期望是：掌握服务器底层代码，同时对各个游戏逻辑子系统又有一定的了解。当崩溃发生时，运维人员并不知道崩在了什么地方，更不知道是谁的代码造成了崩溃，所以第一时间只能是通知服务器组。于是我们不得不做好随时被召唤的准备，甚至三更半夜从睡梦中被叫醒，被抓到公司查看崩溃，提供紧急修复。在这一点上，服务器组组长可谓是悲催到极点。同时悲催的当然还有运维人员。这个月初我们受到了一波黑客攻击，导致服务器每天都会崩溃。黑客甚至似乎有意挑晚上和凌晨时间发起攻击。几天之后运维人员受不了了，抱怨如此频繁的崩溃很大程度影响了他们的夜间休息，增加了他们操作失误的概率。这就是运维人员在为程序员不安全的代码“擦屁股”，而服务器程序员则在为游戏逻辑程序员不严谨的代码“擦屁股”。（当然喽，绝无对游戏逻辑程序员不满的意思，事实上我现在仍兼任游戏逻辑程序员，并且我们也要替其他工种“擦屁股”。）

　　最近我还发现，我们不但会在团队内部相互“擦屁股”，还可能要为和我们团队没啥关系的外人“擦屁股”。上周我对客户端启动程序做了些更改，发布到外网后，发现一些网吧居然无法启动客户端了！大家第一时间自然怀疑是我加的代码引入了bug。可是当大家折腾几天之后，却逐渐发现，罪魁祸首可能是我们用的一个第三方软件，这个软件最近升级了……

　　看来，只要活在这个世界上，就不可能不替人“擦屁股”，然而替人“擦屁股”又的确是让人不爽的。所以——

　　从自身的角度讲：尽力做好自己的事，别给人家制造麻烦，别让人家替我擦屁股。同时，别人有过错时，也别太苛责；除非“擦屁股”次数多了，那就要提醒下对方了；如果次数很频繁，或者性质很严重，那就要管理者出面了。国庆前我们内网服务器经常出冲内存的bug，全体程序员和QA忙活了一个多星期，差点连国庆休假都要取消。最后发现居然是因为服务器的内存坏了，这时就是由项目经理出面对IT部门发表不满。

　　从管理的角度讲：尽量明确分割各人的职责，并监督其执行状况。事实上，职责分割越明确，监督起来也越容易。另外，多促进团队成员之间的沟通和交流，让大家多多互通有无。这样才能在不得不耦合的地方尽量减少因不了解对方业务逻辑而造成的错误，同时也能在万一出错的时候，更容易地协调各方尽快排查错误。不过我对管理没经验，这些都只是我的设想。

　　从软件架构的角度讲：对一个复杂的软件产品来说，没有完美的架构，没有任何架构能将模块和模块之间完全解耦。我们只能“尽量”，但无法“完全”。

　　不写了，明天上班恐怕还要继续为那个第三方软件擦屁股。