最近在做一些项目（一个上位机和下位机通过串口通信，而下位机采用的是空闲中断接收处理的方式）的时候，从理论分析是能发现如果电脑侧上位机发送数据因为性能或外部环境的因素干扰而出现波动时，下位机由于采用的是空闲中断，且是一次性处理（没有收集组成一个完整包，是不是很low），这种情况下，肯定会出现这次处理异常的。
换做是我自己处理这种情况：
那么我的思路会是如下：
1，我应该不会采用这么low的处理方式，无论是否使用空闲中断，我都会仅仅当做一次接收的数据，使用一个队列来收集数据，然后再使用一个任务从接收队列中找到可以合理处理的包，然后加入到一个能够处理的队列中，再通知具体的处理业务处理
2，尽可能将外部环境想象的恶劣，例如长时间接收不到数据，亦或者接收一部分然后隔一会续上，甚至续上的也是乱序的之类的，然后想象这些情况该这样处理，并且走一遍之前的逻辑，看看能否构建这种异常的环境来触发想象的逻辑
3，将代码逻辑中不可预料到的情况尽可能做一些异常处理或留下log，例如本身就引入的超时重试逻辑用来规避或减少异常情况下的不良影响。
但是新同事的思想几乎是相反的：
1，他首先直接从使用者来思考这个问题，他认为使用者使用不好配置的可能性非常低，因此这个问题出现的概率就基本不可能，没必要关心
2，如果真的能出现，又不是没有超时逻辑处理，对使用者又没有影响

其实吧，作为一个弄技术的，我并不觉得他的想法很好，毕竟可以用技术解决的问题，明明不是什么大问题，明明是可以解决的，但是呢，从产品角度来思考这个问题，我也无法说服他多花点时间优雅得处理这个问题，毕竟对用户虽然有影响但又不是大问题，哎，是我对自己的要求太高了吗，为什么我总是对潜在的问题这么在意呢，为什么就不能像他们一样放低要求，没遇到就先不管呢，这种思维碰撞让我知道为什么有的人效率这么高了，而我总是不满意自己的作品，或许以后我也要平衡一下自己的想法，不是什么时候都需要那么优雅，适当得降低一下自己的标准，对自己也好

标签: 思维

添加新评论