程序员沉思录 2018-08-07 / 1,852 次 / 快抢沙发 /

摘要: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,除了所谓的用心一点之外,还有一个就是:解决问题的能力。我们要想尽各种各样的方式来解决问题,我技术可以不全面,不深入,但是解决问题的能力一定要强。


不断更新中!

打赏
本博客所有文章如无特别注明均为原创。复制或转载请以超链接形式注明转自ifeegoo,原文地址《程序员沉思录
上一篇: « 下一篇: »
暂无相关文章
Copyright © ifeegoo Time is limited, less is more! / 粤ICP备15109713号 / Theme by Hang & Ben / WordPress / 知识共享许可协议