不要将事情复杂化

656 阅读6分钟

本周针对公司新版的移动办公产品,有需求要求可以直接点击推送栏调整到应用的指定页面,如消息推送推送的是一个新邮件提醒,则点击推送会进入到该封邮件的明细页面。在我看来,这个需要并不算复杂,于是我提给产品组实现可以在下个版本发布更新。

可是事情似乎并没有我想象的顺利,从产品组反馈过来的信息,我基本理解是存在什么问题难住了他们。每一条推送,要想打开就必须将该信息的上下文数据一并推送过来,而苹果之前的政策是只支持256字节的数据负载,而目前推送的参数信息已经明显超过256字节,消息无法正常推送到苹果服务器,这是下面的人给我的解释,但是他们补充了一条额外信息就是苹果在iOS10设备最大已经可以支持4k容量的内容推送了,但是测试下来好像不行。

下面讨论过程中制定了2套方案:

  1. 将额外的推送参数,进行编码压缩以减少字符长度。但是编码的长度不会变短,很快被否。
  2. 将推送的参数信息以键值对的形式存储在服务端,同时将该信息的key通过推送传递过来,这样就明显减少了推送内容的长度。制作一个中间页面,用来接收key和查询对于的参数信息,再来进行跳转。

第二种方案,我第一反应是非常排斥的,因为这样不仅仅降低了用户体验,而且会增加额外工作量来维护参数键值信息。我的理念是,如果可以一步到位做到的事情绝不能绕着弯子将事情复杂化。

我让iOS开发人员将推送的p12证书发给我,我自己验证apns推送的问题。公司以前的android和iOS推送方案都是我设计开发的,所以apns的推送机制还是比较熟悉的。我们之前后端推送采用的javapns的开源jar来实现苹果服务器的推送的,我知道目前公司统一消息中心肯定还是沿用了之前的方案。

第一步,就是还原作案现场,明确采用javapns到底是行还是不行。配置好证书路径,接着在payload里添加参数信息,让payload的大小超过256字节,看看是否能够顺利推送。很遗憾,控制台的提示我们发送了294字节的数据,但是其限制是256字节。我在心里想,难道真的不行,这次难道是我的判断有误。我开始分析javapns.jar包的源码,发现以上的限制异常是由PayloadMaxSizeExceededException抛出并打印的,我感觉事情似乎有转机,这代表超出限制反馈数据并非有苹果服务器之间反馈,而是客户端自己的提示。所以我判断,javapns.jar出问题了。

第二步,寻找替代方案。找到一个apns4j和apache的camel-apns的apns发送方案。经过验证可以顺利推送超过256字节的数据,最终决定采用camel-apns来替代javapns,该问题顺利得到解决。

这让我联想到到上周的另一件事情,有需求反馈要求在移动办公中增加离线通讯录功能,虽然我自己认为没有保留的必要,这只会让事情复杂化。于是,我让产品组在通讯录的右上角防止一个“断开的闪电”的图标,点击进入离线通讯录模块,该功能和目前的在线通讯录不要掺杂在一起。

周五产品组把改造成果拿给我看,并且介绍实现方案是将离线通讯录和在线通讯录做了合并展示,这样就不需要再增加入口,期待我的赞许。我体验了下,反问了一个问题:如果实际部门信息变更了(名称调整,部门删除,部门层次变更),你有没有考虑到离线数据和在线数据展现矛盾的问题,并且做兼容异常处理?得到的回答是暂时还没考虑!我立即把这个的方案给否决,并且要求按照之前既定的方式处理,就不会存在这样的问题,两块内容相互独立。更重要的是,我们的产品功能将来肯定会面对项目上诸多的个性化改造,一个考虑不全面的设计会将项目组拖进深渊,有的问题我们要知道提前规避。

第三件事,近期项目中我们在即时通讯产品中碰到了这样的需求,“在即时通讯客户端推送的待办,邮件的提醒,明明在系统中已经处理掉了,但是在即时通讯的角标数字却没有同步消除”。在即时通讯最初的版本中,我们将系统的消息与即时通讯整合,达到在即时通讯提醒系统消息的目的。就这样一个看似简单的需求,其实在我们在项目中是花费了很大力气在维护的,项目中的情况是复杂的,要达到与各种系统版本消息提醒的目的,就要与各种版本实现功能对接。系统升级了,消息推送方式变化了,单点登录方式改变了,那么就需要改造即时通讯以实现与各种新系统的适配。如果我们面对的需求不仅仅是一个项目,而是来自数十个甚至几十个项目的要求,这个结果是灾难性的,在有限的人力资源投入的情况下,软件的可靠性是无法保证的。

还是不要将事情复杂化,即时通讯就关注即时通讯本身,解决沟通的问题,不要附加其他内容。这样的好处是,无论是产品的部署实施,开发,维护都能够大大降低成本。所以在下个版本的即时通讯中,我们会尽可能取消其他不必要的内容,重点关注即时通讯本身,让一切归于简单。

“墨菲定律”在软件行业一样适用,你担心的问题在将来有很大可能会发生,有点类似于出来混迟早要还的。不要抱有侥幸心态来开发设计软件,有的明知道在某种状况下会出现问题,但是在心里确安慰自己应该不会那么巧吧,殊不知这样的思想将来会把自己害死的,也许将来会花几倍的精力来堵漏洞。如果你能预见到哪里将来可能有问题,那么最好的做法是静下心来仔细思考要用什么样的方式来处置来规避这些可能的问题,将它扼杀在萌芽状态。考虑问题时,尽量遵循“关注点分离”原则,同一时间尽量做好一件事情,不要将事情复杂化。