一个L引起的惨案

前情简介

事情是这样的，公司有个比较老的SDK库，在我进公司三个月以后就交由我来维护了，因而呼我就勤勤奋奋的扛起了这份神圣手动黑人脸的职责。这个SDK主要是跟向APP提供后台的服务，相似这样的：

APP须要向server上传本身的Capability（App能支持的功能项，每一个APP可能不同）。而这个APP是一个long型，每个Bit表示一个功能项。

63	62	61	···	5	4	3	2	1	0

祖传代码里是这样写的：

public final static long CAP_0 = 0x01;
public final static long CAP_1 = 0x01 << 1;
public final static long CAP_2 = 0x01 << 2;
···
···
···
public final static long CAP_31 = 0x01 << 30;
复制代码

我接到的需求就是这样，提供后台新增的Capability,因而我就没动脑子写出了下面的代码：

public final static long CAP_0 = 0x01;
public final static long CAP_1 = 0x01 << 1;
public final static long CAP_2 = 0x01 << 2;
···
···
···
public final static long CAP_31 = 0x01 << 30;
public final static long CAP_31 = 0x01 << 31;
public final static long CAP_32 = 0x01 << 32;
public final static long CAP_33 = 0x01 << 33;
复制代码

事情就是这么个事情，状况就是这么个状况!

案件侦破

SDK的使用者，某APP开发（其实这个需求就分给我了）死活和后台调不通，现象就是若是APP正确上报某个Capability,点击APP上的按钮，会向server发出命令请求，实际是server一直报错。

按理说，这个事情只要后台告诉我具体是什么错误，也是很容易查出来的。然鹅...，日志上显示 error msg: deviceId not found ,咱们的公司后台在台湾，沟通起来特费劲，so我就一我的默默的排查...,朝着deviceId not found这个方向去查了。。。。

我：deviceId我有传呀，怎么仍是这个错误？
大佬：是否是，deviceId中途被改动了？
我：我去追踪一下看看。
……
我：deviceId是正确。
大佬：那你找台湾的后台看看吧。。
我：哦，我再看看吧。。
复制代码

就这样过了许久...，咦，等等，这个capability怎么是负的...，😯😯，内心一万只喜洋洋飘过。 改代码：

public final static long CAP_0 = 0x01L;
public final static long CAP_1 = 0x01L << 1;
public final static long CAP_2 = 0x01L << 2;
···
···
···
public final static long CAP_31 = 0x01L << 30;
public final static long CAP_31 = 0x01L << 31;
public final static long CAP_32 = 0x01L << 32;
public final static long CAP_33 = 0x01L << 33;
复制代码

案件总结

嗯，细节战胜爱（cheng）情（xu）啊（yuan）！

你能不能来找我一下，我准备了酒，也准备了故事！372702757