年关将至，此刻的我本应该像一只挣脱猎人扑兽夹飞奔回家的兔子，然而现实画风却恰恰相反：此刻的我桌边放着一杯冷掉的咖啡，顶着熊猫眼，强忍着阵阵袭来的困意在寥寥无几人的办公室修改代码。边调试边咒骂：真是不怕神一样的对手，就怕猪一样的队友。
事情发生在一周前，本来已经欢快的着手准备过年回家的各项事宜，突然在某个夜黑风高的晚上接到一个阴气十足的电话“浙江项目出问题了，年前必须解决，你明天去公司和项目负责人联系下。”
“纳尼？那个...那个...领导你可能弄错了，浙江项目我之前并没有参与，是同事阳负责的。”
“恩，情况我了解，他现在去别的分公司了，你去盯一下。”
从那刻起我就开始无止境的填坑生涯。填坑填到我开始怀疑人生，并不是项目碰到的问题多难，而是同事阳的代码刷新了我的认知，尚且不说逻辑混乱，单从定义一堆无用的变量和方法来说就已经很难读下去，跟着代码逻辑走下去，你会发现很多方法被注释“此方法不用”，不用为何还让它苟活于代码中，难道写代码也有字数要求？我真想喊他回来，我保证不打死他。
自己要改的代码，含着泪也得改完呐。边改边告诫自己，以后写代码千万不能如此混乱，虽说功能实现了，但后续维护会变成一项非常庞大的工作量，好在这段时间的辛苦有了些回报，问题大部分已经解决，小部分可以再年后再解决。通过此事总结的几条建议分享给大家。
首先，自己分内的事一定要尽最大努力按规范完成，不懂多问问前辈，否则会给后续工作留下不可避免的隐患。
倘若阳在写代码之前有咨询过本公司的代码书写规范，则此次问题应该就能很快速定位，而不是浪费时间先去读一坨不知所云的东西，导致项目进度被严重的拖延。很想告诉阳：在这个看颜值的社会，代码也需紧跟潮流呀，你的代码太丑了。
其次，尽量多归纳总结，项目完成留项目文档，开发完成留开发文档，方便后人快速上手，否则时间久了自己回忆起来也会一脸懵逼。
如果此项目在上次结束后就有书面的文档生成，包括代码逻辑功能图和所碰到的问题及解决办法等，那将会给此次问题查找提供重要的依据，毋庸置疑效率会大大提高。
最后，倘若跳槽也请做好收尾和移交工作。虽说即将离开公司，但大部分人所跳职场圈子还是同一个，日后也许还有很多的交集，利人利己的事何乐而不为呢。
试想如果调离岗位前阳能将代码移交工作仔细完成，必然不会出现此次因问题修改时间过长而遭受各方追责的问题。
工作中看似很简单一个小问题引出了这一系列的连锁反应引人深思，问题已经发生，苦果也已酿成，唯有总结经验防微杜渐，不过值得高兴的是项目问题总算得到解决，明天终于可以回家过年啦。
网友评论