为什么程序员总说代码能跑就尽量别动我用我的亲身经历告诉你

其实，说这句话的前提应该是公司研发部门结构不全的情况下。比如一个正规的研发团队的项目组应该至少包含项目经理、产品经理、程序员、软件测试、软件实施、运维等等。但是，实际上很多公司可能一个研发团队的项目组只有项目经理和程序员！于是，问题就出现了！

正好，我目前所在的公司的研发团队的项目组就是只有研发组长（兼任项目经理）、程序员、软件实施三部分组成。因此，我就经常因为改代码而“中招”！

亲身经历

举个例子吧！我们公司有一个项目，其实项目本身比较小，所以研发经理开始定制的软件实现方案就比较草率。

当我第一个软件版本写出来以后，其实我是经过仔细测试的，按道理说怎么跑都没有问题。

但是，当我们的实施把软件部署到客户环境以后，客户一看感觉和他们想的不一样。于是，软件就被打回来要我们进行修改。

第一回合

此时的我感觉有点隐隐的不安，因为客户给我们的方案需要我改变之前的数据结构，可以说牵一发动全身！

但是我也只能硬着头皮改，于是改出问题了！基本上就是我改完数据结构以后，没有考虑周全导致其他地方的数据有问题，要么少写了数据进去，要么就直接报错了！

代码既然是在我手里出去的，不管我有没有经过严谨的测试，至少在我心里是过关的，可是难免会有疏忽的地方。可是，如果只把我当做质量的最后一道关的话，显然是有问题的！

我花了比较长的时间又从头到尾仔细测试了一下软件，最后确保从我手里出去的软件在数据上不再出现问题，然后才交给实施去部署。

第二回合

让我没想到的是，客户满意了，但是研发经理觉得软件在客户体验上不好，让我再按照他的思路再优化下用户体验。

与用户体验相关的一个模块跟数据也有关系，这里面牵涉到数据结构的导入和导出功能，以及数据字段的启用和停用。在原本的数据结构不满足导入和导出以及是否启用字段的情况下，我新增了几个新的字段用来满足这部分的需求。于是，又是牵一发动全身的操作！

因为有了前车之鉴，所以我这回把代码改完以后，可是仔仔细细测试了一下，确保数据没有问题以后才把软件交给实施去部署，但是谁知道问题又来了！

因为软件在客户那已经正式用了，这里涉及到新的数据结构跟旧的数据结构兼容的问题，因为旧的数据库缺少字段。如果使用ORM可能就不存在这个问题，但是我使用的是原生SQL。这就需要实施人员手动去把客户环境的每个数据库的字段都新增下。

第三回合

好不容易搞好了，项目经理跟客户沟通的时候一不小心说漏了嘴，一方面他跟客户说我们项目使用的是原生SQL以后新增字段比较麻烦，觉得使用ORM更好。

另外，他觉得研发经理提出的软件修改方案有缺陷，虽然支持导入导出以及启用停用字段，但是需要操作人员知道字段的对应关系。他的意思是可以做到让一个非专业人员也可以改变数据结构的关系。

客户听到项目经理这么说，自然是满心欢喜，于是项目经理又给了我一个最新的修改意见。

我到这里已经感觉自己被支配得团团转了，但是谁让我只是个普通研发呢？

于是我只能把数据读写改成了ORM，然后又修改了字段导入、导出、以及启用停用这部分的逻辑。

但是，这里的改动是很大的，几乎除了表现部分，其他部分都得重新写，那么问题自然也就随之而来了！只能再修复这部分的问题！

虽然这个项目最终还是通过了验收，但前后我写了四个版本，除了第一个版本，几乎每个版本都会出问题！

总结

通过我的这件事情你就知道为什么程序员会经常说“只要代码能跑就尽量别动！”的含义了吧？

这取决于研发团队的结构，如果软件每次版本发布之前都会有相应的产品经理去给出最合理的软件实现方案，程序员写完代码先过自己这一关，然后测试人员再进行缜密的测试再交到实施手里，这样大部分问题将会被杜绝，不至于在客户环境出现。虽然不能说百分百杜绝，但总归能把一些要命的Bug给解决掉！

尤其像一些小的修改，因为对整个产品进行测试太耗时间，所以程序员在自己测试的时候经常只测试一些自己认为可能会出问题的局部功能。因此，在没有“后盾”的情况下，出问题的可能性还是很大的！