收到短信number显示unknown的问题解决和调试BUG的几个建议

今天大部分时间都在解决一个问题，tester提交了一个bug:终端设备收到一条3GPP2 SMS短信，但是UI number显示的是unknown，如下图

第一感觉应该是PDU没有携带number造成的，原先就遇到过这个问题，收到的3GPP2的PDU如下：
0000021002040903c69a469cdaa0a190060100088b0003200020017c21e980836a0c8e7b1c629c29808a71d27eec5e0b0543b4236a0c8e7a8a2c6d9ff862b6f0018af80480d35e7ac9480190017001ba8a1b5e7b384001880180023802128b42b7eb6a0c8e7a982b3842982ff84001c001828a18017b3847f84ff864ccb33842f80480d3184ac94c5d0c69cff862b6f002a00223169329b00306180925111344
使用tool解析这个PDU后发现有number，如红色部分。

那就奇怪了，怎么PDU含有number但是，UI怎么不显示呢。马上check一下trace，发现从底层到UI显示因为sensitive信息不能泄露的原因，整个trace没有任何关于sms address的信息。从code检查看是否有针对number length的限制，也没有发现任何线索。这时候才发现没有trace或者log，很难解决任何问题。现在只有一个办法了，看看自己能否复现，如果能复现，那就添加在flow的各个部分添加trace好了。因为短信是网络发送的，只能使用一个work around的复现方法了，当终端设备收到任何短信后，将收到的短信PDU直接替换为上面的PDU即可。修改code后，问题能够复现，后面就是添加trace了，添加trace有一个小技巧，最好一次能够把flow的key point都添加trace，能够节省时间。在等build结束的过程中，对正常显示number的短信PDU也做了解析，居然发现了问题，正常显示number的PDU address是original address，而这个PDU是destination address，马上就猜到原因了，这条短信是收到的短信，address应该是original address(02)，而现在是destination address，没有将address进行保存和传递（code中对收到的短信只传递original address）。后面从build好的load复测问题的log也证明了猜测。问题转给更底层，看看为什么传递的PDU不对，皮球就踢走了。
整个复盘这个BUG，有几个调试BUG的感触：
1 问题发生后，不用急着马上动手解决，最好能够猜测一下原因，之后进行验证，这样能够使自己能够更了解和熟悉code。
2 尽快复现问题，如果能够复现问题，那离解决问题就不远了。
3 如果是不同的owner复现不同的层，那最好在接口处添加trace，那谁解决问题就不用相互推诿，并且能够更快定位是哪层出现了问题。
4 添加trace应该选择key flow和最关键的地方，开头结束一般也是需要的，如果对log的数量有限制，更应该如此。
5 最好能够保留正常flow的log，问题发生后，如果分析问题没有方向，最好将fail的log和pass的log进行比对，这样可能发现问题发生的原因。
6 对于曾经发生过的问题，复现方法，解决方法甚至如何发现root cause进行记录，如果后面发生类似的问题可以找一下曾经是否解决过类似的问题，是否有可以借鉴的地方。