自从9月20号开始进入机器人领域，一路的摸爬滚打，一路的酸甜苦辣，这里主要说说源码分析方面的感受吧。
第一步
先让源码先跑起来
真正开始源码分析，已经是11月后的事情了，因为之前源码还没拿到手，只有部署用的安装包，
在此期间，通过搭建运行环境，查看运行效果，把源码当作黑盒来理解，对源码的功能会有不错的认识。
第二步
源码拿到手后，总是有种跃跃欲试的冲动，但从哪入手还是有点讲究的；
简单的看了下各个模块的说明，知道各自负责的功能后，我就从自己擅长的部分开始—串口通讯，
其实选这个模块作为开始，还有一个原因就是有个相关问题需要解决 — 后面发现其实在此模块的上层进行更合理，带着问题去学习比无头苍蝇要好
第三步
分析源码，尤其要带着问题去修改，难免就要对其进行现有结构进行重构，以利于理解与解决问题。
对我而言，进入陌生的机器人领域，拿着一堆杂乱的代码，或者说是与自己风格格格不入的代码，难怪圈内人总是会有自己重写的冲动；
但现在没办法，入门者只能先学习才能继续啊；
好在ROS自带单元测试模块，简单配置后，通过测试先行的方法就可以放心的进行重构了。
第四步
啃完自己擅长或简单的模块，就到了啃硬骨头的时候了 — 系统的核心模块；
- 同样，先从简单的重构开始：把800多行的main函数分割成N个小函数，此时还不要通过新建文件来分类，这个动作后续进行比较好，因为新建文件会涉及到功能划分、文件组织、编译设置等等，先专注于化整为零吧；
- 然后就可以新建文件存放工具类的函数了，因为它常用，又信赖性比较小；
- 最后就是按具体的功能新建文件了，此时步伐要小，每个功能的依赖尽量控制到最小，依赖比较多的都留在主文件（main函数所在文件）中进行调用。
第五步
这是目前我所在的状态，核心模块中大部分已经整理完成，但有几处核心算法无法理解；目前能想到的方法是：
- 建立调试环境，逐步跟踪理解 — 我始终认为：理解自己写的代码可能单元测试就够了，但了解别人的思路，调试还是有它存在的价值；
- 使用ROS_DEBUG输出调试用的日志，而不是printf；
以上，就是我进入机器人世界进行源码分析的过程，其中当然有些是无心插柳的原因：
- 因为前期没有拿到源码，只能从运行开始；
- 因为ROS自带单元测试，很容易就可以测试先行；
- 因为涉及到串口通信，恰好可以从自己擅长的模块入手；