见微知著

见微知著，意思是根据一些微小的苗头能预知事务的发展。

很多时候我对微小异常通常都很少关注或者说觉得某件事或东西有些不太正常却都忽略掉了没有多想。在后来的事态发展中回想起来，如果之前多加留心就不会造成不好的结果了。

昨天经理要我将暂时不用的机器拿过来给新来的外援用。我就直接到之前分行测试的工位上把我借过来给分行人员用的机器拿下来给外援了。在拿机器的时候发现显示器上贴了标哥的名字，但我记得借过来的时候没有这个标签的，也没有多想就直接拿下来了。当标哥发现他放在那工位上的机器不见了，问我机器到哪了。我说给外援了。然后找外援，谁知他已经将系统重装，硬盘格式化了。崩溃，标哥说那是他们的服务器，上面有他项目组的开发软件和源码。这事情大了。还好标哥说幸亏还有备份，这也是不幸中的万幸。幸好有备份，又一次体会到备份的重要了。哎，要是之前多想下就不会出现这样的问题了。

也是昨天，UAT报了几个我负责那块需求的几个问题，被经理抓过去训话，问我为什么出现这么多问题？我说，没有考虑到。因当时我只是从大方向分析了需求影响的范围，没有全面搜索可能涉及的各个方面。所以程序中遗漏了一小块，造成了现在的几个Bug。经理要我写报告，深刻分析原因。看来问题是挺严重的。写吧。坐回位子后，我想为什么当时没有考虑到？还是不够细心，当时为什么就没有考虑搜索一下所以源代码来确认下呢？还是太大意了或者说没当回事，不负责任。还有一个问题是核心系统他们对一个比值已经扩充了，而我在需求分析时却没有考虑到。在编码过程中外援也提醒了我一下，我也么有在意，直接跟他说不用改，也没有跟核心去确认下。只是想当然的想着需求上没有说，也就不改了。最后还是得改，然后在UAT阶段做这样的变动，想想影响是多大。又一个深刻的教训。

还是昨天，我之前做的一个系统，正在投产阶段。发现了问题，也是我负责的那块出现了行号为空的记录。最后分析是在迁移阶段如果被迁移系统未传过来行号，我的程序就将行号直接赋值为空了。按逻辑应该是如果迁移过来没值应该从参考号取或赋‘0000’。这个问题在测试阶段也发现过，但没留意，以为是他们迁移过来的测试数据有问题，生产时就不会有问题了。又是一个未留意的异常造成了生产上的数据问题。

三件事情都碰到了一起而且还是同一个原因。一个微小的异常背后总会有一连串的原因，抓住这微小的异常你就能避免其造成的“严重”后果，用成语来说就是防微杜渐。

记此一笔，以观后效。