自表达代码的特点——快速定位Bug

 

我们以Android平台下的输入法为例。

假设在OpenWnn输入法（代码请到http://source.android.com/source/downloading.html上找），接入硬件盘的时候，日文输入模式下，按下Shift + T键输入的不是T。

应该怎么定位？

onKeyDown(int keyCode,KeyEvent event)是入口，

然后找到硬件盘的处理方法onEvent();

然后再继续找processHardwareKeyboardInputChar()，

再继续...

再继续...

----

这种恶梦式的Bug定位主要原因是代码的架构问题。代码的架构不够清晰导致Bug发生时无法快速定位。

那么如何才能够快速定位呢？

本文将要介绍自表达代码的另外一个重要特点——Bug可以快速定位。

 

如果我来设计输入法，应该将输入法分层。

UI层    —— 键盘如何显示，候选如何显示

控制层 —— 软键盘按键动作，硬件盘按键动作

数据层 —— 键盘的输入的转换处理 Roma字 -> Kana

 

输入设备、键盘模式、语言类型应该是相互独立的扩展分支，这种方法叫作桥接模式(Bridge Pattern)，我们在前文曾经介绍过。

 

根据设计的结构来说，分层清楚的情况下，如果发生了Hiragana模式下SHIFT+T错误，而其它模式下没有错误的情况，那么就可以直接定位到Hiranaga类(该类继承自Language)。如果其它模式也有同样问题，那么就可以直接定位到HardKeyboard类（该类继承自InputDevice）。

 

设想，如果Bug定位快速了，修改快速了，那么效率会提高多少？时间会节省多少？

不过，就如之前所说，如果按照工时来收费，而延长工时会收取更多的费用的话，又哪来的动力这么做呢？