Another Java Geek

几乎所有的软件系统都有这样那样的Bug，如同几乎所有的组织机构都存在这样那样的问题和矛盾一样，很自然地，修改Bug对程序员来说是家常便饭。改Bug最主要的困难不在于如何修改，而在于去查明Bug产生的原因。有时候，我们花了好几天时间来跟踪调试某个Bug，而最后仅仅用几行甚至一行代码就可以搞定。所以，程序Bug，一旦查明原因，解决起来便是顺理成章。而当跨组织跨部门的Bug出现时，情况便截然不同。 假定在一个IT公司，有系统组、数据组、应用组等几个组（或部门），分别用S(System)、D(Data)、A(Application)来代替。用户U在使用过程中遇到了一个问题，反馈到A组。A组一查，发现是某条数据存在问题，于是反馈到D组。D组一查，发现是由于一个系统错误导致数据有误，于是反馈到S组。S组一查，发现这个系统错误是正常现象，无法预测。于是A、D、S几个组僵持不下，陷入拉锯战：A说这是数据问题，应该由D组确保数据正确无误；D说这是系统错误引起的，应该由S组解决；S说这个错误无法避免，应该由D、A组自行检测异常，剔除错误数据。 我们可以看到，在这个例子中，问题的原因是显而易见的，而要解决这种跨组织的“Bug”却非常困难。这跟单个程序员解决程序Bug时难查错易解决的情形形成鲜明对比。 遇到这种情况，我们总是把问题归结为相互推卸责任，并倾向于指责别人。可事实是，我们自己也处在这种怪圈之中，当我们在指责别人推卸责任时，自己又何尝不是如此呢？遗憾的是，很多人都把目光聚焦在别人身上，对自身的问题却视而不见。《技术领导之路》作者温伯格在书中指出，“看不到自己”（self-blindness）是解决问题的第一大障碍，“不能从旁观者的角度认识自己是个人发展的第一大障碍”。 在刚才的例子中，如果A、D、S组能从旁观角度审视一下局面，并首先在本组力所能及范围内对既已发现的问题进行修复，那么将会出现另一幕情形：当S组查明那个系统错误时，发现不能预测，但在出错时，却能够检测和报警，于是制定检测报警方案，着手实施并告知D、A组；D组得知S组的检测报警需要一定时间才能生效，于是增加数据合法性校验机制，并将已经出错的数据清理掉，告知A、S组；A组在应用层增加一个小特性，当用户使用中再次出现同样的问题时，给出一个友好的提示，并通知D、S组，将问题及处理方案记录到Bug系统以供其它人查阅。 不过这是理想状态，现实环境远比这要复杂得多，也并非“看不见自己”能够完全解释。即使我们能看见自己，又怎能保证别人也同样能看见自己呢？