提早暴露问题，做好层与层之间的责任划分

最近处理一个关于短信的问题，debug过程中有遇到一些障碍和弯路。问题是手机应该收到一条语音信箱的短信，但是一直没有收到。Modem已经上报了短信的PDU，但是framework解析之后进行dispatch失败了。对PDU的decode和dispatch都是Google AOSP的，第一感觉应该是framework应该没有问题，应该是PDU的格式不符合spec造成的，使用工具解析PDU后并没有发现什么问题，又回到error的地方，发现是一个service处理的PDU，这个service可以客户override，所以就马上怀疑应该是客户override的这个service出现的问题，service处理的PDU已经是framework decode后的user data了，但是service依然用这个数据create PDU，导致判读长度失败了。发现问题的根本原因后，当时就准备给客户一个temp patch，解决掉这个问题。在准备给客户详细的问题原因和temp patch的时候发现，对于正常的WAP PDU短信应该走不到出现error的地方，就又重新回到解析PDU的地方，发信原来这个PDU的teleservice id是WAP PUSH的，但是dest port不是，导致不能正常dispatch，而进入了正常短信的处理流程，而WAP pdu的处理和普通短信是不一样的。问题发信后，只能请底层的owner来查看问题了，是PDU的teleservice ID不对还是dest port不对。

如果对短信模块不熟悉，没有关系，问题其实就是如何确定问题发生的点，以及如何写code，是让问题尽快的暴露出来，还是做一些error handling让问题不发生在自己负责的模块里面呢？这个短信的问题，其实底层就可以check出当前的PDU是否符合spec，如果不符合spec就不要上报，打出为什么没有上报的原因，这样问题就会很容易查找。但是底层是直接把PDU发送给framework进行处理，而framework是处理不下去了，才出现的error，而从error出现的地方就很难知道为什么会出现error，为什么会走到这里。如果对code不熟悉，可能会添加一些error handling，让代码正常运转，但是真实的问题点可能就会掩盖掉，甚至问题只是不发生在自己的模块，而发生在别的模块了。

现在的软件都是分层的，数据在不同层进行传输，操作数据，这样每层可能都会带来问题，当自己身处于某个层的时候，对于接收到的数据，应该和自己的底层做好明确的定义，数据格式应该是什么，什么样的数据是正确的，什么样式错误，这样就能把责任划清。数据格式正确，问题发生在自己的层，那应该就是自己的代码逻辑的问题，如果数据格式错误，就应该传输数据层处理，为什么出入错误的数据。最讨厌的是，责任不明确，问题谁处理都可以，这样会造成讨论时间的浪费和相互扯皮，只是浪费时间和浪费情感。
从软件各种书籍看，问题越提早发现越好，越容易处理，但是有时候我们不能要求别人，只能自己管好自己，对传入的数据进行校验，保证自己的代码逻辑处理的是正确数据，如果是错误数据就马上停止运行，输出错误信息，可能需要自己添加一个数据校验层。

总结起来就是，层与层之间一定要做好定义，按照大家讨论好的标准来做，做好责任划分。如果责任一直没有划分好，我们尽可能地推动这件事件，如果推动不了，那就尽可能的让自己的代码逻辑足够的健壮和容易debug。另外如果有时间，可以适当了解上下层的处理逻辑，这样沟通起来更方便，更顺畅。