本文主要是介绍一叶障目, 不见泰山------要对整个数据流有非常清晰的认识,避免走入死胡同!,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
俗话说: 一叶障目, 不见泰山。 很多时候, 我们缺乏全局上的整体认识, 在局部死胡同中瞎转, 耗费精力。 扯多了, 颇有点格局和细节的意味。
最近遇到这样一个问题, 如图:
从接入层开始, 我把数据"http://w.x.y.z/aaa"写入, 最终落地到data中, 随后, 我用查看存储的"标准工具"查看data数据, 非常意外地发现, 从data中读取出来的数据是“//w.x.y.z/aaa”, 非常意外啊!
于是, 我便认为, 肯定是写的时候, 改变了"http://w.x.y.z/aaa"的值, 于是寻找证据。
经抓包确认, 入接入层的数据没问题, 入逻辑层的数据没问题, 入适配层的数据没问题。 当时又觉得, 入存储层的数据不太好查, 于是就想当然地认为一定是适配层在写入的时候, 改变了"http://w.x.y.z/aaa"的值。
可是, 在适配层,在所有代码中的关键点中(写逻辑), 发现没有改动原串的代码, 那就加log吧, 看看哪里变了。 无奈, 适配层的逻辑还挺复杂, 这log要加到猴年马月呢?
停停吧。 如果走在做错的路上, 那么停止脚步就是进步!
貌似是思路错误, 走入了死胡同。 于是反思上述过程, 进行了一步关键的验证: 写入的时候, 入存储层的数据又没有变化, 用tcpdump抓出明文包, 发现写入的时候居然没有变化。看来, 写入的时候没有任何问题。
那就是“标准工具”读取的时候有问题了, 再看看“标准工具”读取的流程。 原来, 所谓的“标准工具”是从上图中的线路2读取的, 不是从线路1中读取的。 而我知道, 读取的时候, 在适配服务中, 确实有调用一个远程服务------实现从"http://w.x.y.z/aaa"到"//w.x.y.z/aaa"的转换。
原来如此!
最开始笃定是写逻辑有问题, 最后的结论是读逻辑在捣鬼。 值得反思。
实际上, 很多时候都有类似的悖论。 这让我想起了前段时间的svn提交二进制库的问题:你说你提交了, 但怎么保证你真正svn ci了呢? 不能仅仅看提交成功的提示, 而应该让人外一个人svn up一下, 看看是否有结果。
值得深思。
这篇关于一叶障目, 不见泰山------要对整个数据流有非常清晰的认识,避免走入死胡同!的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!