早些时候，有个同事离职，说要把他手头的一些工作交接给我。我一听有点突然。后来老板跟我解释说，先让我帮忙协调，等招到人了，再让他们接手。
交接时，那位同事说有一堆代码。现在还能用，他也不明白，也是像我现在这样被人塞的活。这一堆东西，他也不怎么懂的，就是知道在哪个路径，代码存在哪儿。他安慰我说，没事，他接手很长时间也没啥事，产品工艺稳定，一般不用改代码的。
我看了一下代码，发现是不同人写成的一个测试的工装代码，有些段落写得不错，逻辑清晰。而大多数几乎没什么代码规范，赋值很随意，很多命名规则极其不规范，甚至连嘻嘻哈哈都出现在代码里，几乎没注释。看了第一遍，就不想再看第二遍。
隔了一段时间，招了一些人，又走了一些人，招来的人里有好几个会写代码的，部门里也有好几个正在转向写代码的。
有位同事接手了测试设备维护，另外一个部门的同事也走了好几个，离职的离职，深造的深造，他又接手了那个部门的活。
然而，前不久，供应商说他们改了一些东西，需要我们配合。大家查了一遍，发现现有的工装某些程序不支持供应商的产品引入。我问同事谁去改？接手这个设备的同事一听是这个设备的程序，摇头。
我再问另外一个很了解这个工装系统的同事，也摇头，还扔出一句，让他再写一遍也不想看这个工装的代码。再问一遍，他就说很忙。
我看了一下，其实，需要改动的很少。不过因为我不熟悉这个系统，不知道怎么编译打包。就让真正使用和维护这个系统的同事帮我一起看。他还帮我约了一个很懂系统软件的同事来支援我们。
那天，我让系统维护同事备份了源代码，然后开始替换改动的代码，重新编译。发现有问题。这个陌生的系统，我看着眼生，而且好多年不写代码了，看到有问题，有点懵。
来支援的同事也愣在那里，虽然他是写代码和软件系统的能手，但是对这个工装代码不熟悉。系统维护的同事也愣在那里，嘴上嘟囔着，这可怎么办呢？
我跟他说，用备份的代码把替换的代码再替换回来，直接在备份的代码里改动。他一开始有点不敢。不过我没有给他任何的思考时间，嘴里飞快地说着，开始先怎么做，再怎么做，接着怎么做。
一开始他手忙脚乱的，我就在旁边说，不是这样啊，是那样啦。等他改完部分代码后，他说他明白我的意思了。然后，我就在旁边看他飞快地操作着，那架势，根本就是对这些代码看了又看的。
我笑他，明明对这个系统比我更熟悉，是我的师傅，非要找我麻烦，让我改代码，难道就是传说中的不自信的人，需要找些人壮壮胆吗。他有点不好意思，说他之前真不知道。我再让支援同事编译一下，他编译了一下，有点兴奋地说，过了。
我再请设备维护同事测试现在的产品和将要升级的产品能不能在这个设备上用改过的代码，运行一遍。他看到出来的结果，特别高兴，连声说，好了，好了。
然后我再请支援的同事用命令行敲下一行命令，编译可执行文件。半天没反应。这下轮到我着急了，我问他，这计算机为什么半天不理我？他俩说，老机器。等了一会儿，还是没反应，我请他们到文件夹里帮我找找看，有没有新生成的可执行文件。发现真的在那儿呢。
这次设备维护同事迫不及待地打开这个可执行文件，照着旧的产品配置验证一遍，没问题，又打算照着新的产品的配置再验证一遍，没想，还有权限设置。不过，他说他明白了原理了，等新产品上来的时候，他会验证一遍的。
我谢过了他俩，感谢他们让我学到了不少东西。和他俩说，这么一看，其实这个系统也没很多同事传说中的那么难的嘛。他俩也说真的学到好多了。确实，我们三人中在改程序和调试编译之前，没有任何一个人是对这个系统的调试，编译有一个全面了解的，短短半个小时，我们都学会了怎么调试，编译，程序打包的过程。也对那个系统有了进一步的了解。可能，设备维护同事也更有信心了。
网友评论