上一篇 谈谈这阵子忙的事一：关于design整个过程的感想
接下来谈谈具体coding的时遇到的问题.
本来设计已经做好了,而且思路已经很明确了,中间思考了那么多觉得实现起来应该问题不大.
三下五除二,在自己觉得应该该的地方改,尽量适应旧有的代码.运行起来却出现莫名crash.导致这个问题是在于Dictionary存在重复加同一个数据.最终发现原来自己在获得某条数据时,是通过拿到所有数据遍历的方式得到的,而没有调用现有提供的一个方法去cache里获得数据.而恰恰在那个方法里它清空了一下cache.一开始遇到这个问题的时候感觉真是莫名奇妙. 而且它整个处理的过程异常复杂, 判断的条件异常的多, 很多概念性的东西在那里让人看不清楚到底它在干什么.最终自己没办法只好象旧有的代码一样去获得数据,那些中间的逻辑处理的代码保证不碰它.
这些看不懂的代码遇到也算了, 反正无能为力. 然而遇到有些简单的代码处理,就觉得非要一吐为快.
一个组合control由combobox跟trackbar组成,两者一方在改变的时候需要同步另一方.然后通知外界.里面的做法是两个control selected value改变的时候都会fire event.由于当触发了combobox的selelectedchanged事件时需要去设置trackbar对应的值,所以也必将导致trackbar的selectedvaluechanged事件,为了避免导致fire2次event,每次都要设置一下当前是哪个control先改变值的,然后同步另一个control的值的时候使其不fire event.于是就明显多出了两个字段记录是谁先改变了value.
我在想,实际上两个control的值要保持同步,因为combobox的selelectedchanged必将导致trackbar的selectedvaluechanged事件触发,反过来也如此.那何不只由selelectedchanged handler去负责fire event呢,这样处理很简单又能避免2次fire event. 想想估计写这段代码的人没有进行充分的思考,相当于想到怎样就直接写了，以至于出现此类复杂的逻辑.
然而最令人看不懂的是两个control的value changed handler里有如下的代码,
m_queuedRequest = 1;
while ( m_queuedRequest > 0 )
{
//do something
m_queuedRequest = 0;
FireEvent();
}
实在看不懂为何如此写,而且代码注明了是为了防止丢失一些event. 看其P4上的版本注释是为了解决某个bug, 但已经是2年前的改动了. 搞得自己是没有勇气去重构这些代码了.
本身自己已经花了好大一些时间去搞清楚这些复杂的处理, 结果发现原来仅仅是为了实现某个功能.而现在想重构它们的时候却因为一些逻辑处理没能搞明白,怕引起功能回馈,却不敢动手,一直让这些复杂的代码依旧存在.而后人呢,当需要修改这个control,需要增加新的东西时,原本可能是一个简单的功能却要花去大半精力去弄懂这些复杂的处理,就象我现在一样.真是得不偿失啊.
所以说简洁是多么重要的一个事情, 这也反过来提醒自己在开始coding的时候不妨多想想, 尽量写出简洁优雅的代码,避免后来者看自己代码边看边唾骂.
况且愚以为简洁的代码能保证最小话的潜在bug, bug往往就是因为把问题弄复杂了,实现起来的时候又没有很好地考虑,以至于忽略了某些细节,导致的结果就是QA花老大力气去测试代码,Developer呢花老大力气去重现此bug去改bug.而且要命的是很多时候改bug的人不是原来负责这一块的人然后加上一些条件为了改bug而改bug，尽量不动现有的代码，更谈不上去重构下代码把缺失的状态合理的融入到原有的代码中，就相当于衣服破了，就往上面帖一块，补丁一大堆。像现在程序里到处充次着一些代码注释着此块代码是为了fix某某bug加入。这样一代一代的往上打补丁，等后来的人偶尔良心发现想梳理重构一下，发现已无能为例，异常复杂的逻辑搅在一起。除非你能搞清楚这些代码的来龙去脉，要不然轻易动它怕是会惹上麻烦。
所以说代码一开始保持简洁是多么的重要，而且修改现有代码时尽量重构下原有的代码，保持一样的简洁，而不是到处打补丁。
用重构的话总结就是，优秀的代码是让人看的懂的代码，而非只有机器看的懂。
高中的时候很喜欢的一般物理书上面说：凡是美的东西就是对的。那么对于代码来说，凡是简洁的代码就是对的，就是优秀的代码。