一个工程师的十年经历感悟

一个工程师的十年经历感悟

星期一, 09/13/2010 - 12:04 —南宫鱼

时间过得真快，转眼就做了十来年的技术。从当初的初出茅庐，一步步地走到了今天。在成长的路上，遇到了数个贵人，有过很多次的当头棒喝，也有过很多的徘徊、很多的无奈和很多的感悟。很早就有写点文字的想法，于自己是个总结，于后来者是个参考。因为工作上琐事缠身，一直没有机会落笔。这次，很多在头脑中长期潜伏的想法，一股脑地倒了出来。

本想用流水账的方式，把自己的经历写下，但写好后又大段地删掉了。因为我觉得，仅仅罗列自己的经历，能给自己什么帮助，又能给别人以什么启发呢？！最后斟酌决定，以自己在工程师路上的几点收获作为线索来动笔，这正是我最想与别人分享的。我的收获可以总结成下面三句话：

步步深入，水到渠成；

举一反三，触类旁通；

整合资源，提升自我。

步步深入，水到渠成

很多的初学电子工程师在面对新技术的时候总希望找到登堂入室的捷径。寻找捷径是人的本能，付出最小成本，换取最大的成就，这是无可厚非的。但电子技术是门很严谨的科学，靠捷径和技巧最终都会是无果而返，折腾了半天又回到了起点。

说说我自己学USB的过程。2001年的时候，公司的一个产品准备使用USB端口通信，我和几位同事自发开始学习USB的相关知识。我好几次计划仔细把USB协议从头看到尾，但每次都是看了前三章，就缺乏耐性，抑或因为其他专职工作的时间安排而中断。自此之后，至少10次，我一次又一次启动学USB设计的计划，但每次都是从阅读USB协议开始，然后阅读到第三章就停掉了，甚至只看了十几页。虽然花费了时间，但没有丝毫进展，所掌握的知识比当初从科普文章中得到的也没有增加多少。直到2003年的一天，部门来了一位对USB小有所成的新同事。一次偶尔的聊天中，他提到，“USB协议熟读第九章，再看些sample程序，就入门了”。于是，找来Cypress的USB HID的例子程序，对照USB协议的第九章来学习。那一周我不仅对USB 开发入了门，而且顿悟了不少东西。我一直后悔没有早些仔细研读Cypress提供的USB例子程序，因为只要硬着头皮去读，就能发现里面的代码很清楚的说明是由CH9协议实现的。我花了断断续续3年的时间学USB，最大的收获不是技术层面的，而是这曲折的学习之路让我领悟了——做技术，要扎实才行。只要步步深入，自然水到渠成。试图走捷径，实际却是在原地踏步。

我很早就把TCP/IP协议的那几本厚厚的书从书店抱回了家。然而晦涩的文字、复杂的协议，虽然也看过一些内容，不过更多的时候，这几本协议参考都是书柜上华丽的摆设。偶尔有个机会，找了块51单片机+RT8019的板子，抱着试试看的心态，就开始了调试。好在单片机的编程本身没有任何障碍，很快就入门了。在仔细学习TCP/IP协议栈的时候，就发现分层简直太奇妙了，可以把很多复杂的问题简单化，然后得以单独解决。TCP/IP分层带给我的认识，不再像OSI参考模型那样抽象，而是非常的直观。对于具体的应用，TCP/IP的四层甚至可以直接对应到我们的4个函数：链路层的任务是通过寄存器操作网卡芯片，IP层的主要工作居然只是打包，TCP就跟UART似的发个命令然后等应答，应用层就是我们的测试程序的主函数，原来这么复杂的技术居然可以化解成如此简单的几个模块。虽然我只是写了个TCP/IP测试程序，后来也没再做过以太网的开发，但这段学习经历带来的自信让我受益匪浅。

我首次做硬件的经历也很有意思，甚至有些幼稚。刚毕业2年一直做软件，觉得做硬件很有成就感。因为我们那个Team是一个硬件配十来个Firmware工程师。如果能看着很多软件工程师用自己做的开发板做开发调试，那成就感就甭提了。于是跟我的主管领导要求做硬件，甚至以消极怠工做威胁。当时部门经理也想调动我的工作积极性，于是同意了，而且一个新的项目很快就到了我手上。那时候，我的原理图设计还可以，但是Layout的经验基本没有。因为第一次设计硬件的缘故，我设计的开发板稳定性差些，但设计的跳线非常实用，跟Build的Debug和Release配置正好对应。项目组的好几个同事在项目协调会上说我做的Jumper好用。

得到Team内很多同事的肯定，对初入门的工程师绝对是莫大的鼓励。后来又陆陆续续地做开发板、产品板。一个硬件的初学者居然做了几个10万台以上的销量的产品。当我看到项目组的十几个同事用我设计的板子调试程序的时候，当我从营销部听到我负责设计的产品销量到了多少的时候，莫大的成就感和自我肯定对继续深入的学习也是一种动力。

技术是靠积累的，只要你朝正确的方向付出了努力，就会一步步靠近成功。当付出了足够的精力和时间后，取得进步是水到渠成的事情。努力过程中的偶然有利因素，要利用起来，要学会把机遇转化成能力。因为实用的跳线获得同事的认可，我就趁热打铁，把硬件的稳定性方面问题解决掉。

对捷径的无比向往和对技术复杂度的恐惧是初学路上最大的敌人。身边做技术的朋友或同事，有很多人是非常聪明的，然而真正在技术上能独挡一面的确实不多，为何？实际上，很多人是在学习新技术方面过多的希望走捷径，而一直无法有所突破。我也曾希望自己能找到捷径，不用辛苦的学习就可以掌握别人搞不定的技术。最后发现根本没有什么捷径，或者所谓捷径就是脚踏实地去做。很多的电子工程师不屑于学单片机，认为单片机是低级技术，以ARM、FPGA等为学习的目标。我做过的一个产

品原来用的是8位单片机，后来转用ARM实现，整个C代码是平滑移植过来的。从一个产品工程师的角度去看，ARM就是一个跑得比较快、片上资源以及接口比较丰富的单片机，使用ARM不是因为它是高档的芯片，而是因为它可以提高产品的性价比。举一反三，触类旁通

我一直认为，作为一个工程师，尤其是电子工程师，“照猫画虎”的类推能力是非常重要的。如果我们用举一反三的交叉方式去思考不同的技术，就会发现很多技术是有内在关联的。技术领域上较广泛的涉猎给我的感触是，很多技术是作为一个体系出现的，靠架构来组成的。而架构的存在，也使中间件的开发更有效率。下面我想分享一下，学习过程中感触到的架构在不同技术领域中的表现。

如果你做Windows WDM Driver，会发现WDM的架构是非常棒的，只要精通某一点并开发设计成一个小小的sys文件，就可以把它挂到操作系统中去。Windows的OS会在适当的时候调用你的sys文件，跟写应用程序的消息机制似的。我们再深入到WDM的这个sys驱动的内部看，有两个非常显著的特点：第一，把一系列的函数指针指向自己实现的函数，目的是把自身挂到驱动栈里去；第二，接受驱动栈上层驱动的请求，先处理，然后传递给驱动栈的下层驱动。正是架构的精心设计，让模块开发的劳动强度大大降低，于是连对PC硬件不甚熟悉的我，都有过几次做Driver的经历。

做嵌入式系统WinCE的工程师会注意到，WinCE的驱动架构，几乎完全是Windows WDM的简化版。WDM驱动的那两个特点在这里表现得淋漓尽致。当然，因为是嵌入式系统，肯定要比Windows系统简化很多，而且嵌入式的CPU提供的资源跟X86也是无法相比的。因为工作的缘故，我对WinCE没有更深入的学习。

我曾有机会做Windows Media的编程开发，这是Windws XP平台上一个视频特别处理，当然用到了DirectShow技术。我当初就感觉DS的架构怎么这么面熟，就是一时认不出来。原来DS使用了COM技术，变得神秘了。但透过COM这个接口技术看架构，原来又是跟WDM那么的相似，只是表现形式由Device变成了Filter而已。一个内核层的架构居然在应用层也能找到它的影子。

做Windows通信程序的时候，希望收到数据时才响应，例如向主窗口发个消息。这是APP级的，怎么做呢？对了，就用

FILE_FLAG_OVERLAPPED这个属性，我们只要以这个属性打开设备，如串口或者USB等，以后读取设备数据的时候，这个函数会立即Return，我们随后就可以等待事件（Read完成了或者Timeout了或者是某故障发生了）。配合多线程编程，很容易做成消息驱动型的，而不必用死循环浪费额外的CPU时间片。这里就借助了操作系统给我们提供的消息机制。