老司机的实习
经手几个老项目之后，慢慢地熟悉起工作流程，渐渐在熟悉的领域得心应手
-
老项目的维护过程总是很漫长，而新的需求接踵而至，老项目的许多问题也开始堆积、被隐藏。
- 比如，有将近一年时间都使用了接手的前辈项目中的通信模块，移植到其他同平台产品上的。然而这个模块代码中的隐患也是无穷多，原因有下：
- 使用的接口是自己改写的。在不断地发现产品中出现的BUG现象后，开始深入接触前辈的通信模块代码，通过专业工具配置参数生成Demo后发现原来前辈的代码改动也是相当之大，Demo中的接口函数悉数被改写成自己封装的API，而有些配置过程却缺少了，即使依然可以“正常”使用。
- 通信模块的参数配置接触过的开发者应该都清除，需要主机通过无线模块自身的通信协议配置进去，这些在Demo中都封装得很到位了，但在前辈代码中全部被打散再自己组装，从稳定性正确性来说，原厂Demo都是比较稳定的发布版才会提供给用户使用的，自己写的难免有实现方式上的不同导致的偏差和隐患。（实际上不是因为Demo写的有多好，应该说Demo的移植性比较好 —— 通过软件生成的配置参数头文件可以直接放在工程里被它的代码替换使用，而前辈使用的是#define宏定义所有参数值，而一些射频参数的改动都会导致大量头文件参数被改动，都要手动找到并替换到自己定义的宏里面去，费时又费神… …）
- 公司使用的无线模块属于模组供应商提供的，即射频收发电路等等都已经由厂商搭建好，提供的是一块直接就能上板子工作的小模块，而后来因为功耗和成本问题换了一家模组供应商却发现，芯片的版本是不一样的，虽然代码都是兼容的，不同版本一些接口就有微小的差异，而经过我和同事的反复调试发现原来一些参数配置适用的在新模块上并不能很好的兼容，这也是前辈代码自己改写引发的麻烦
-
经过上述多种原因的考虑，我决定改写掉所有新工程中的通信模块代码，尤其是无线驱动方面改为与Demo代码兼容。即使心里知道有很多地方又要打散重组，但为了更长远调试开发工作的轻松和顺利，这是必须的…
由此在进行项目时，有几点要注意：1. 复用了以前的代码要确保这些部分是可以正常使用的，而要做到这点往往需要时间的累积，产品调试过程中出现相关问题需要把引用的代码可靠性考量进去 2. 前辈的代码风格不符合自己的，写的不够规范的，既然自己接手了就把它改好，这是基本的职业素养，在哪个公司都适用
