周三，我晚上加班给客户升级系统，我在是 19 点进行操作的，升级大概用了 5 分钟左右，因为系统是采用 docker 部署的，这次升级隔了 50 个小版本的镜像，不太确定会不会出现问题，所以我等到了 19 点半，看到已经有很多正常业务数据出来了，我就收拾东西回家了。
我快走到地铁站台时候，刚好有趟地铁在，只不过里面没多少人出来，心想这多半要关门了，于是我赶紧加快速度，想在关门之前，赶上那趟地铁。没想到我的脚刚好踩着黄色警戒线的时候，这门就开始关了，我也不敢往里冲了，只好等下一趟地铁。
悲催的事情来了。等车的时候，电话就打过来了，说出问题啦。_我感觉到万分惊讶，甚至开始怀疑人生。_后台都有正常业务数据了，怎么可能还会出问题。听那边扯了一堆，原来是有个屏幕上显示的字符有问题。例如 A1000，A1001 ，A1002，现在显示成了 A100，A100，A100。导致客户的用户无法看到自己的排队进度。没办法，我只能回去修复这个问题。
这个问题听销售说，之前也出现过，是 xxx 修复的，你可以问下他。那就神奇了，都修复过了怎么这次升级会出现这种问题。经过一番了解，原来是那个同事，直接把客户正式环境中的视图改了，但是没有在测试环境修改，导致这次升级还原回了原来的视图。而在测试环境，要超过 1000 才能暴露这个问题，没进行那么多的测试。于是乎，就只正式环境就出现了这么个问题。
真是令人苦笑不得。公司里的人很喜欢通过视图和存储过程来做一些逻辑处理，这就导致了有时候直接在正式环境改了，又忘记在测试环境改的情况。而项目组也没有做数据库语句变更的习惯，都是直接用工具同步正式和测试库结构，以测试库为准，将正式库结构同步成测试库结构。这种数据库直接同步结构的操作，我工作4年来，还是头一次在这公司见到。
这个系统是卖了多个客户的。如果每个客户特殊逻辑都写在视图里面，要修改视图，就需要找到最后一次修改的视图，因为如果不在最后一次的基础上修改，就会导致一些客户的逻辑代码丢失，就像今晚我出现的这种情况。
我是十分讨厌在视图和存储过程来做些逻辑处理，因为写在这里面的逻辑代码，完全处于是一个游离的状态，每次都需要人工的去找到最新版本去修改，万一测试库不是最新的视图，万一改错了，又不能查看历史版本，迟早要暴雷。
我抱着负责的心态和项目组长说了下我的看法，在视图里面写这种逻辑处理不好。他缺说：这样改起来快。我真是无语了，这完全忽视风险，只是为了追求对客户问题响应处理时间。这也是国内软件开发的普遍现象，一切为了快，有什么问题先上线了再说，技术债务也就是在这种环境中越积越高。除了大环境之外，公司对项目开发过程和开发技术规范不到位，没有技术总结，完全是一头脑搞业务，瞎 JB 搞。