求教如何优雅解决IM中由群聊产生的循环拉取问题？

我们的服务端由于分布式设计所以发送给客户端的消息无顺序。这时候导致发送给客户端时我们由于业务要求需要判断是否拉取，而当拉取的时候又会返回需要拉取的结果，这导致我们拉取和推送之间，UI读取的时候都会有循环的代码，虽然现在处理好了这部分逻辑，但由于耦合过深，代码可读性和可维护性太低，不知如何解决？求各位大佬碰到如此代码逻辑的优化方案参考一下。

我现在的解决方案是首先将复用的代码逻辑降低if判断，因为有些逻辑判断不可能执行，但我的前辈为了复用代码全写进去了。

所以我又写了一个方法将两个互相嵌套的循环代码先变成两个不相干的嵌套代码。

引用：JackJiang 发表于 2020-12-03 13:29
出现一个bug，然后想办法凑，又搞出10个bug 哈哈哈

感觉最好的办法是建立一个专门处理弱网情况的模块，不然弱网情况加上分布式服务，两个加在一起代码和屎一样难搞，而且排序既然客户端要再排一次序那么服务端根本不需要去排序，只要服务端记住客户端拉取下来的消息有什么就行。这样架构起来还容易一点，至于过滤，服务端其实已经存放了sessionID。这样多个共同的服务端依然可以拉取消息下来，感觉公司架构的时候没考虑清楚。mqtt和我们的服务器都是分布式的，这样服务器时间肯定保证不了顺序，那么服务器去排序列号的顺序完全没必要的好吧，拉取的时候有没有序列号都差不多的好不，直接按照客户端时间去拉取然后redis根据sessionID去过滤自己的消息不好吗？

引用：完蛋 发表于 2020-12-03 08:14
移动客户端接受代码有延迟，而我们排序又是根据服务端的时间来排序，所以序列号2-1可能比序列号1-1先来， ...

出现一个bug，然后想办法凑，又搞出10个bug 哈哈哈

引用：Magicnana 发表于 2020-12-02 10:30
我觉得就不能无序，必须有序。 你在一个漏洞百出的基础上无论写多少代码都是写 bug

移动客户端接受代码有延迟，而我们排序又是根据服务端的时间来排序，所以序列号2-1可能比序列号1-1先来，也可能序列号1-1的消息丢了，这些可能是弱网环境肯定会有的，所以必须处理，兄弟，我也知道必须有序，但这个肯定会出现的。所以解决起来其实应该是再添加一个方法专门管理弱网的消息丢失和消息乱序。

引用：我们的服务端由于分布式设计所以发送给客户端的消息无顺序。

我觉得就不能无序，必须有序。 你在一个漏洞百出的基础上无论写多少代码都是写 bug

引用：完蛋 发表于 2020-11-24 16:55
优化整个客户端的代码量太大，而且业务层和我们是不同的模块调用。我现在还只是优化群聊方面的代码逻辑。 ...

具体到代码层，没看到你这些烂代码，给不了具体的意见，只能靠你自已啃了，表示同情。。

引用：JackJiang 发表于 2020-11-24 14:46
我感觉你的问题，只能针对代码先把逻辑理清楚，先全局读懂代码，否则无从下手。关键im这种代码，逻辑还不 ...

优化整个客户端的代码量太大，而且业务层和我们是不同的模块调用。我现在还只是优化群聊方面的代码逻辑。现在的方案就是先将导出函数和非导出函数集拆开，非导出函数集不会使用导出函数集中的函数。这样优化一个非导出函数不会更改导出函数的逻辑，与外部模块之间隔离开了。

引用：完蛋 发表于 2020-11-24 14:33
问题的关键就在这，重构代码的代价太大，并且上层代码调用的函数在内部也在调用，导出的函数和非导出函数 ...

我感觉你的问题，只能针对代码先把逻辑理清楚，先全局读懂代码，否则无从下手。关键im这种代码，逻辑还不只是一个端的事，可能跟服务端的逻辑才能构成完整的整体，单独优化客户端的代码怕是也不行

现在我觉得先把外部和内部同时调用的函数拆分成两个函数，这样我就不用改动的时候也改到模块外了

引用：JackJiang 发表于 2020-11-23 19:45
看你这段描述，我能想象你们那些代码，估计你这辈子都不想再回头看它第二眼。。。

我觉得代码逻辑乱的根 ...

问题的关键就在这，重构代码的代价太大，并且上层代码调用的函数在内部也在调用，导出的函数和非导出函数混在一起且导出函数中的条件判断在一些调用中没用可在另一个调用中又有用，且群聊的重传机制又导致该导出函数居然还有一个for循环，这个for循环中切断循环的条件又是和上面描述的一样有的调用有用，有的没用。所以我不清楚从何改起，刚改动就出现一个看不到的bug，且这个bug还定位不到是服务器还是客户端的问题。

引用：JackJiang 发表于 2020-11-23 19:45
看你这段描述，我能想象你们那些代码，估计你这辈子都不想再回头看它第二眼。。。

我觉得代码逻辑乱的根 ...

是的，最主要我是接管代码的，而且代码没有注释，一个函数有内部调用也有外部调用。然后我该内部调用的时候外部调用的判断语句和变量就没有实现，现在导致的问题是我改出了bug都不知道是为什么？由于这段代码已经应用到业务里面，也不能改动接口，但是有时候不一样的接口其内部调用是一样的函数就很烦。多余的判断条件可能这个接口没用到，但其他接口用到了。我改一个地方还需要测试另一个不相干的地方。

看你这段描述，我能想象你们那些代码，估计你这辈子都不想再回头看它第二眼。。。

我觉得代码逻辑乱的根源，还是方案不够优雅，应该跳出眼前的代码，从更大的局面重构一下整个算法和逻辑。

我觉得你有必要画一下现有的业务和逻辑关系，然后将复杂问题简单化，否则。。。。 你这代码，将来随便一个小需求，都可能寸步难行。。

我从头做过至少3遍im，我清楚im有些代码，没写好，如果再不优化好，那只能扔，没法再用了