程序员沉思录 – ifeegoo 博客

摘要：Deep thinking is really important for a programmer!

Runtime Environment
OS: Human Brain

1.你不知道该怎么做，但是官方会告诉你怎么做。
You don’t know how to do,but the official will tell you the right choice.

今天在做 Android/iOS 的 Bluetooth SDK 的时候，为了保持代码和结构的一致性，Android 中有以下方法：

public boolean isBluetoothEnabled()
{
    return false;
}

我在 iOS 中的代码：

- (?)isBluetoothEnabled;

这个时候，我想起了 iOS 中有 BOOL / bool / Boolean / NSCFBoolean 这几个，一下子就头痛了，不知道该如何选择，然后就 Google 出这个：http://nshipster.cn/bool/ 也还是有点茫然。猛然间想到：为什么不去看看官方是怎么做的？然后去官方的 Bluetooth SDK 中的 CoreBluetooth/CBCentralManager.h 中找到以下方法声明：

/*!
 *  @property isScanning
 *
 *  @discussion Whether or not the central is currently scanning.
 *
 */
@property(nonatomic, assign, readonly) BOOL isScanning NS_AVAILABLE(NA, 9_0);

这样一下子就知道该用哪种返回值了！又比如，在 Android/iOS 中，你应该使用静态常量，还是枚举？不妨看看官方是怎么做的，虽然你不是很理解，但是这样至少保证你能够更加准确。又比如我曾经写的这篇文章：《推荐的移动应用的版本名称管理规范》，也是同样的道理！

2.IDE 提示的 Warning，千万不要忽略，因为这些细节正是你深入、提高的源泉。
Don’t miss the “Warning”!

我们总是选择性的忽略 IDE 提示的警告，因为一般情况下，这种警告的东西，并不影响项目的编译通过。但是这样，你恰巧会错过针对细节的技术问题的把控，还是错过了解决将来潜在的问题。因为 IDE 提示警告，一般来说有以下几个原因：
1.不规范的代码写法。
说明：不规范的代码写法始终会让你显得不专业。
2.使用了过期的代码或者处理方法。
说明：过期的代码或者处理方法，现在没有影响，并不代表将来没有影响。

所以，程序员一定要有所谓的强迫症，尽量不要让一个 Warning 出现。

3.“大神”的知识面不一定比你广，但是解决问题的能力，一定比你强！
The capability of solving problems is the most important for programmers.

这个观念，我最近在解决技术问题的时候，也是深有感悟，其实我已经差不多好几年没有写 Android 的代码了，但是最近我在解决一个外包项目的技术问题上，又有所收获。

1°.逆向思维。
举例：

最近一个 Android 蓝牙 App 项目上，有一个产品逻辑，就是如果蓝牙连接被动断开（超过了连接距离而断开），就需要开始两分钟的扫描，以便发现蓝牙设备时候，再次连接上。但是如果是人为主动断开蓝牙连接（App 端点击按钮断开），就没有必要再次回连了。

之前的开发人员一直纠结于“Android 的 API 是无法判断蓝牙是主动断开的还是被动断开的，连接状态回调中只会告知已经断开了！”，开发人员的坚持，让本来还很困惑的固件开发人员也不得不接受所谓的结论，最终反馈给项目管理者，项目管理者还向客户反馈当前 Android 确实做不到，但是 iOS 却“神奇”的做到了。

我接手这个项目之后，经过分析：Android 的 API 的蓝牙连接状态的回馈，的确是无法判断是主动断开，还是被动断开的。但是要知道一个细节就是：App 端主动断开只有一种情况，就是点击 App 上的断开按钮，抓住了这个核心点，就很好解决这个问题：当点击按钮的时候，做一个标记，连接断开的回调回来之后，我们就根据当前是否是主动断开的标记，来判断是否需要回连，这样就很好的解决这个问题了！

2°.抓住“根”。
举例：

还是上面的蓝牙项目，里面有一个需求就是：蓝牙在扫描的过程中，需要“闪烁”黄灯，然后连接上或者连接失败就显示蓝色和红色。但是测试的过程中发现，有些情况下，黄灯会一直闪，但是没有是没有在扫描，有的时候会出现没有灯显示的情况。

原来的开发人员实现“闪烁”的技术是：使用计时器每隔一秒钟来切换 View 的可见于不可见。以上问题，开发人员很不好复现，但是测试人员确实是复现了这个问题，也没有什么好的规律。但是，但是我们知道一个核心点：一直闪和没有灯显示的根本原因，就是用来控制“闪烁”的定时器和 View 的可见和不可见出现了问题，抓住这个根本原因之后，很快就发现并解决了问题：闪烁的过程中，判断是否处于扫描状态，如果不是，就停止闪烁，并且保证 View 可见，同时保证在启动一个新的定时器前，清除掉所有的之前的定时器。

我根本不需要复现以上问题，最终这样解决了这个问题。测试人员表达了敬佩之情，感觉我好像更厉害一些，其实我相比于之前的那个开发人员，技术上并没有他深入，但是为什么我能够解决这两个比较“顽固”的 Bug，除了所谓的用心一点之外，还有一个就是：解决问题的能力。我们要想尽各种各样的方式来解决问题，我技术可以不全面，不深入，但是解决问题的能力一定要强。

不断更新中！

打赏