为项目列表构建拖放重排功能意味着将新顺序发送到服务器并保存.
如果重排逻辑中甚至有小缺陷,那么保存可以悄悄地将数据与缺失或重复的项目相接.
注意:这里的"安全检查"是指一个轻量级的检查,一个过程的结果满足一个显然应该坚持的条件——不是彻底的验证,只是最后的检查"这显然是错误的吗?
重排序逻辑的形状 拖放交互产生的新顺序作为一系列ID到达服务器.
服务器重新排序现有数据以匹配 。
这种分两步走的结构本身是有道理的.
客户端发送的命令可能只覆盖被过滤或被搜索的数据子集.
在保留其现有相对位置的同时,将目前不可见的物品防止消失。
仍然存在的风险 问题是,如果"按部就班"和"补充其余部分"的结合有其自身缺陷,会发生什么.
ID的分解,字符串-转换边框的大小写,错误的条目——这个逻辑得到的越复杂,基础假设("每个项目在输出中都准确出现一次")就越有可能被打破.
如果这里有错误,重新排序后的数据最终可能比原始数据(丢失的项目)更短或更长(重复的项目).
修补 —— 在将重排序的结果写入磁盘之前, 在写到磁盘之前, 验证计数是否正确 。
如果计数不匹配,则出错日志同时记录输入和输出计数,而写入本身被中止.
没有必要精确地确定重排逻辑在哪里出错——结果是否安全可以被机械地确定.
为什么一个计数比赛就足够防守 这种重排操作不会改变任何项的内容——它只改变顺序.
这意味着在前后,这套要素应始终保持不变。
如果计数有变,则某事要么消失,要么被复制.
匹配计数并不能证明内容是完好无损的,但作为一种轻量级的方法来捕捉明显的腐败——物品丢失或被复制——比较计数是有用的.
这个设计有什么正确 这不是关于完美地写出重序逻辑,而是在它变成数据腐败之前抓住这个逻辑的一个缺陷,即使逻辑本身并不完美.
一条逻辑越复杂,就越难在测试中涵盖每个案例.
找出一个在测试之前和之后应该一直持有的无常物质, 并且只在最后才进行检查, 对测试没有预料到的虫子起到保险作用。
外观细节 一个使用拖放重排结果的API通过一系列的ID并重排现有数据来匹配"按顺序排列,然后附加其余"两步逻辑中的"风险A"缺陷,可以在写入前引起数据丢失或重复 Fix 对比输入和输出计数;中止并返回不匹配设计原理上的出错 不以完美的逻辑为目标,但机械地防止了一个写入,而一个不变量被破解的代码一次重写出一批项目往往会假设逻辑工作正确.
思考一下假设中断后会发生什么 才是真正保护数据的方法 诸如"done"等词的陷阱将多个不同的含义拼凑在一起,再次出现在将部署-完成与git-承诺-完成相融合的事件中.