|
[table][tr][td]
一家普通的证券基金公司
刚入职两周，就遇到了逆天功能
至于为啥不跑路，是因为之前躺了一段时间，空窗期太长了(一年半)，找了一个月才找到工作
前情提要可以看看这个帖子，
https://www.tsdm39.com/forum.php?mod=redirect&goto=findpost&pid=76728545
是我刚入职几天时发的，简单介绍了下逆天的开发环境
这里简要铺垫一下
1.因为数据保密，理论上分为开发环境，测试环境，uat环境，生产环境，各个环境之间数据和接口彼此隔离。因为各个项目服务之间都相互依赖，且还有一堆外围接口和服务。公司大部分人都嫌麻烦，再加上技术规范管理不严格，久而久之各个小组负责的项目的开发环境都缺少维护，相当于废了。最后大伙都把测试环境当开发环境来用。
那么问题来了，出了bug要怎么找出问题呢，因为没法本地运行打断点一步步排查，只能在写的时候祈求一把过，在关键节点加打印日志，出了问题就去服务器调取日志看报错信息排查问题
2.对于数据管理非常混乱，表和视图相关sql没有统一管理，导致一张表里的字段信息基本看当初创建表的人良不良心有没有写注释，枚举类字段没有文档说明，只能去看源码
3.代码规范更是重量级，乱中爆乱，基本上能在各大码农社区看到的吐槽代码规范混乱的段子你都能在我们公司见到(没开玩笑，认真的)
4.需求文档这种东西基本等于没有，除非要离职了，就会象征性的写个信息含量基本等于0的交接文档
好，铺垫到此结束，正文开始
========================
入手第二周，业务员发现了生产环境里有个“小”bug，这个功能已经在生产环境上部署了3个月才被业务员发现，由于时间太久了业务员自己甚至都不记得是怎么操作才会产生bug的
前面提到过，因为没法本地打断点，且文档基本等于0，且业务员忘记了怎么操作的，所以不知道bug复现步骤
全靠自己造测试数据，一步一步走，加打断点，才“初步发现”问题所在
有一个定时任务，根据脚本每日定时生成未确认的交易指令录入表中，推送给基金经理确认
生成的交易指令，没有主键，是根据三个字段拼成的一个key来当主键用(当天日期，指令序号，指令次序号)
然后这个业务流程有点长，且这个交易指令表还关联了一堆其他表的数据
然后在后续的一堆逻辑中，这三个字段能在那一坨业务里被“更新”，这就很恐怖了，因为会产生了“主键”相同的交易指令数据
然后这个指令表关联的其他表也是根据这个“主键”来进行各自的业务流程的
然后就炸了，那一堆关联数据被更新的乱七八糟，关联关系炸裂中的炸裂
我所在小组的技术组长一开始也以为是个小bug所以分给我看，但我在看的过程中因为有些地方理解不了就去问他让他看看，问多了才发现如此恐怖的地方
，他也震惊了，我边上看他排查，他频频脱口而出“我草”
然后我实在忍不住问了一句，当初为什么要这么设计，他带着哭腔说他也不知道能写的这么逆天，但现在已经错过了重构的机会，因为在生产环境上躺了几个月了，产生了一堆实际业务数据
现在只能看看在不重构的情况下，修复bug+把数据还原回正常数据，今天看了一天只是初见端倪，具体还有哪些问题+解决方案下周再说
今天是我入职第一次加班到9点，道心破碎，一个不怎么难的小功能，在一堆负面buff叠加下就已经如此恐怖了，之后要是遇到业务逻辑稍微复杂一些的，工作难度可想而知
看着项目启动时的banner，再看着聊天记录里技术组长那一句“我草”，只能感慨钱难赚shit难吃
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ | 
回复
发表于：