第一部分

我是一名刚入职半个月的新员工，新员工入职第一步肯定是先学习、了解工作相关的内容，尽可能快的上手。就谈一下前期熟悉公司项目的经验和感想吧。

作为新入职的一名程序员呢，我们需要学习公司的文档管理规则，项目流程管理和产品技术路线等，当然最重要，也是工作量最大的部分就是“读代码”。

我谈“读代码”并不是因为他的“重要”或是“难”，而是他的稀缺性。因为我平时经常在网上浏览各种技术类的文章，有编程语言的“优劣”讨论（其实编程语言只是一种工具，并无优劣之分，只有适不适合。这是网上很多人的观点，我也赞成这种观点），有具体的某种技术实现方法或思路，甚至还有程序员最后的归宿等。

但仔细回顾一下好像没看到过“读代码”的相关文章，所以我就来分享一下我的“读代码”的方法和思路（我们从事的是嵌入式开发，单个项目一般不会很庞大，基本上一个人就能完成），各位读者如果有不同的方法或思路欢迎讨论。

新员工入职一般不会直接上手新的项目，而是先维护公司现有的项目。在了解这个项目的技术框架和实现原理外（这部分主要是看文档），接下来就是需要钻到代码里去了。我看代码是先粗略的看一遍，主要是看用到了什么技术，第二步就是开始钻到各个模块里去研究具体的技术细节和实现原理。如果项目的整体框架设计合理，那么各个模块间相对独立，耦合的部分较少，看起来不会太费力。但是如果代码风格不好，写的很随意那看起来就会很痛苦了。

先说说我在第一家公司上手的经历，我入职的时候我前面的程序员已经离职了，所以我就只能自己看他留下来的代码（只有一个软件开发人员），那时候没什么经验而且他留下来的代码风格确实不怎么样，所以很难上手，刚好那段时间有一个项目需要做些修改，可我完全不知道怎么下手，然后我就和老板摊牌说这个项目太庞大了（其实项目并不大，甚至可以说是一个小项目），我改了这里那里就不行了，不知道怎么弄。老板就让人联系了我前面的工程师让他来帮忙。在一个周末，他来了后我们就一起调试，他三下五除二就找到了问题。原来是有些硬件上的线路接反了，泪崩...... 那天他告诉了我一些调试的方法，最最重要的是他教了我一个在后面的工作中经常使用的算法，线性回归（y=ax+b），就是把传感器中测量的模拟量线性值转换成实际使用的长度单位。经过这一次的沟通我一下子“开窍”了很多。在之后的一个更大的项目中把一些遗留的问题和客户提出的要求都顺利的解决了。

第二部分

能修改接手的项目只是胜任工作的第一步，第二步就需要开始研究项目里各个模块的细节。那时候工作时间经常要协助其他部门的同事处理一些技术相关的事情，留给自己的时间并不多，我只能利用碎片时间去研究代码，也经常会在晚上下班后一个人呆在公司加班。

我的策略就是一个模块一个模块的研究、测试。从最基本的 I/O 输入和输出开始，桌子上就放着控制板，根据原来已有的程序自己一行一行的过一遍，理解每一条语句的用意和功能，发现有待优化的部分自己试着优化。在不懂的地方，不理解为什么要这么做的地方，查看文档找出他的硬件特性。

花了两三个月的时间把所有的模块全部弄通，弄懂。在这个过程中也学到了不少东西。比如说关于串口的一个存储队列，里面有一个软件模块专门负责把从串口接收到的数据存储到一个缓存中，防止一下子接收的数据太多，导致数据溢出。应用层在读的时候按照先入先出的规则读取串口的数据，有了这个软件，读写串口的数据效率提高很多。

之后我再对公司的项目就轻车熟路了，不管是维护旧的项目，还是开发新的项目都能做到胸有成竹，不会再像刚开的时候那样总是心里没底，怕自己搞不定。后来我还根据自己的一些经验和见解优化了一部分项目里的代码。

最后总结一下我的读代码策略，就是先根据文档和代码对项目的整体框架有个理解，如果前期马上就需要上手维护项目，就再把相关的项目的细节了琢磨透，先让自己做到能维护项目。第二步就是一个长期性的让自己慢慢的熟悉其中的细节和实现原理。因为只有做到这两步才能有那种“兵来将挡，水来土掩”的自信和从容。当然我的这些经验只适合较小的项目，就是一个人负责一个项目的那种情况，如果是大型项目，一个小组或很多人一起合作完成的项目就不适用了。