“需求——接口——实现”，最舒爽的代码阅读姿势

一朋友在学习我的GUI软件模块时，非常勤奋，用了很多时间逐行阅读GUI模块的实现代码，还请教了我很多问题，且做了很多注释。这位朋友学习态度很好，我想当然的认为他在使用GUI模块做具体应用界面时，会顺风顺水的，让人尴尬的是，他依旧是一头雾水。

为何会出现这个问题呢，这个现象引发了我的深思。

我记得自己很久前学习ucOS代码时，年少轻狂，也是不管三七二十一，上来就逐行阅读usOS代码，最后好不容易将所有代码理解了，尤其是弄明白那个颇具技巧的就绪列表后，还颇有成就感。

然而，遗憾的是，读懂ucOS代码并不等于会熟练使用强实时OS系统。刚开始使用OS只会笨笨的将传统前后台代码加个sleep延迟后放入任务中执行，出现莫名其妙的执行效率慢现象后，还想当然的找了一个看似合理的接口：OS消耗资源过大。不仅如此，后来发现使用OS还需要面对一堆同步互斥等细节问题时，内心甚至升起强烈的恐惧和抵触情绪。

环顾四周，我发现自己并不孤独，多少人没写几行linux程序呢，就开始捧着厚厚的书研究linux内核实现呢。我猜测，出现这种现象主要有两种原因吧。

其一，人性中的好奇心驱使，这类软件模块一般都比较有技术含量，我们可能会忍不住去一探究竟。

其二，可能源于人性中的不信任感吧。以前我做平台时，一开始将其提炼成了动态库，初心是提升大家编译效率，且便于代码管理，但竟然遭到了很多应用人员的抵触，大家非要调试时还能进入进入再进入，虽然可能将自己折腾的云里雾里，但依然会无比踏实。

人性不可违，好奇心和不信任感如果加以善用，可以帮助我们走的更高更远。但是，我们也不能完全任由人性撒野，效率很低，甚至不见成效。

我早期阅读ucOS代码时，也就刚阅读完毕的那一段时间还好，随着时间的流逝，当我再翻起那本做了无数笔记的书时，我会疑惑，这本书自己真的读过吗，为何会好陌生。

经历了无数年的挣扎后，当我在不知不觉中养成了一种新的代码阅读习惯后，蓦然回首间，才发现自己走了无数的弯路。

可能已经习惯从产品角度思考问题吧，现在，我看待一个软件模块时，首先思考的是站在整个产品角度，对这个软件模块有哪些需求。需求汇总提炼的过程，经常就是接口抽象的过程，如何让应用模块的程序