修数据修数据，近两年的产研经历，倒是不少听到开发提及修复数据，提sql。要知道这都是上帝之手，时光倒流，机关巧妙说不定就被触发了啊。
粗犷的研发初期，因为产品和运维方案的不完善、应急预案、兜底机制的缺失，不排除会导致从产品功能层面的数据不闭环，出现业务死锁。无法进行的局面，往往初创不规范的阶段会采用直接修数据，也称为“改库”。
修数据是什么？
一个产品是包含了业务逻辑、系统逻辑的解决方案集合。各种逻辑的实现又依赖程序，程序是按照一定的规则和顺序的任务执行过程，是一套 指令集合，在软件开发中，程序由数据结构和算法组成。由此可见，数据本身其实并不关心上层的各种指令集合和逻辑。数据它就以自己最优美而舒服的姿态存在就好。人为修数据，就是越过山和大海（各种业务逻辑、系统逻辑和校验、数据关联），直奔数据库改动值。比如：将日期类型的字段从2008-01-01改为2028-10-01、将数量从10改为1000。
这是一个什么级别和性质的动作？
数据可以说是在严密的业务、系统、程序逻辑结构框架中，经过业务输入+逻辑指令的框架构建和判断，最终形成数据的写入、修改、查询、删除。比如：在微信上手机充值，简单点需要最终把你微信账户余额的数字改小、手机卡账户余额的数字改大。如果你有修改数据的权限，可能出现的是，你的微信余额有多少钱你说了算。月光宝盒不过如此，你随意的穿梭时空，无视世界的运行和发展，修改天道玄机。
修数据有什么风险吗？
首先是体验秩序的打破，社会能够稳定运行是因为社会秩序的建立，法律、道德、组织、宗教、经历、历史各个维度互相交纵并拥有一套运行的规律。我们天天快乐耍手机，是因为有一套稳定的运行程序，可以给用户确定性的逻辑，如果faceid识别之后是关机、微信发图片是视频电话、删除聊天是自动转账。面对混沌的表现，用户侧面临巨大的隐患，没有用户行为输入而产生的结果，伤害的将会是用户最宝贵的信任。
无视系统逻辑、产品逻辑的数据修改，同时可能造成上层逻辑的短路、断路，反噬产品。也在削弱产品自身应该考虑和完善的东西。产品和程序的逻辑本身如果不能够完善，我只能说这是产品和技术必须承认的锅。
业务风险巨大，就如你有一双摸金手，怎么可能一直去搬砖呢？从管理的视角，我们希望体系的运行是基于完整的业务和逻辑框架，而非业务的断路+数据的操控，这本就是失败品。
为什么会需要修数据？
产品功能缺失、逻辑不闭环、代码bug、无法业务补偿还原、跨系统的数据不一致，以及系统闭环功能之外的业务诉求不得不去做的妥协...
怎么避免修数据？
从产品概念设计到产品架构设计、技术架构设计，功能框架设计、交互体验设计，实现容错、补偿等机制的考虑和建设，会大大降低修数据的概率。研发过程的质量把控更不容小觑，交付出具备可用性的产品是整个团队的目标。
网友评论