看了年初写的总结，主要还是在于环境的搭建，底层的支撑。所做的事，大部分是从无到有的过程。这次继续参与项目，基本上是在搞业务层的东西。当然，除了研发外，还在做项目管理方面的工作。

由于精力分散了，不能花很多心思专门深究一项技术。很多时候，在写代码时被各种事干扰。
1、利用FFMPEG将h.264转成AVI封装格式的视频文件，然后传输到FTP服务器上。虽然网上文章很多，但都不符合项目应用。因为转换后的视频不能存放到磁盘上。FFMPEG支持FTP协议，但官网上说使用FTP协议会有问题。本质上还是FTP服务器对seek的不同表示的问题。无奈只好将转换的视频放到内存中再进行传输。从开始搞到最终解决，耗时2周多吧，中间还杂着部门一些任务。
2、FTP模块。这个模块是我大约4年前写，但经过多人之手，有些代码已经无从追踪根源了。这次有个不严谨造成的Bug。别人修改后，把我的超时时间单位由秒改为毫秒，但注释没改，同时删除了原有的send和receive函数的超时机制。后来我参考自己写的代码加进去，但没有留意到时间单位。后期测试发现设备开启FTP后有概率卡死，就是因为超时时间单位引发的，原本是5000毫秒变成了5000秒。另外新学到的是实现FTP的主动模式。原有代码只有被动模式，但项目需求方硬要加上主动模式，于是也学习了一下，做了些笔记。不过，实践发现，在传输时，还是被动模式相对好一些。
3、汉字编码问题。关于汉字编码，几年前就有接触，但工作上似乎不太需要，就没再研究了。只是在做汉字叠加时，研究过freetype，了解过unicode。这次又遇到了。sqlite数据库使用UTF8编码，而之前一直使用GB2312，查询数字和英文无问题，但当查询汉字时，就发现精准度不高。为了解决问题，使用UTF8，而由此带来的兼容性问题，又花费了很多时间实现。以后再遇到涉及汉字的东西，就要打起十二分精神。不过编码问题不是我解决的。我遇到的问题是传输带中英文字符到FTP服务器保存为TXT文件时会出现乱码，这还是无意中发现的，最后使用UTF8编码解决。测试验证后发现M$系统中的notepad都会有这问题。当保存的TXT有liantong、lanlu这类拼音的汉字时，会有乱码。不要问为什么会发现，谁叫我遇到“蓝鲁”的车牌呢。
4、除了上面的，就没有学到新技术了。由于人手问题，工程里很多模块都粗略过了一遍，当然不很熟悉，但至少，人家反映有问题，我也能大概知道是哪里有问题。无论怎样，也算对公司的架构有了解了。而在项目过程中，还遇到了一些已有工程架构代码的隐藏的bug。在验证、解决过程，也锻炼了我的能力。在业务架构诞生之时，我还在写外设接口，和业务程序无缘，后来慢慢发展，我还在写外设接口。如今主刀的人，要么走了，要么在做其它事。还好，最后能找到原因并解决。
5、再要说一点的就是，感谢粘人的各位同事，有问题第一时间问我。我也迫于面子和压力，要迅速做出反应，或是当面回复，或是自己看代码或百度后回复。这锻炼了我的分析问题能力。当问题发现时，第一时间要确定环境、条件，比如是在什么系统出现的，做了什么步骤后出现的，有概率出现还是必现，有无日志。其次，要初步定位涉及到的模块，因为不确定问题出在哪里，各方面都有可能，比如上位机、网络传输、设备端业务层、设备底层驱动、设备硬件问题，等等。定位后，再进一步排查、调试，直到问题解决。当然，有些问题最后的结果可能会让人吃一惊，因为可能是一些小疏忽造成的。但往往要花费大量时间排查，如果记录了，积累了，就成为属于自己的经验了。

对于项目管理，我做得很差。还是人手问题，我的主业是研发，其次才是项目管理。为此没少挨有关方面的抨击。如果要说学习到的东西，就是各种开会、各种扯皮都提高我的应变能力和找借口能力。另外我验证了公司流程制度的权威性(宁可花时间也要按流程走，但时间又怪到项目经理头上)，也验证了某些部门在公司地位的不可挑战性(只要某些部门验收不合格，就无法结项)。

说归说，事实上无论怎样，我还是从中学到不少东西，感谢公司的这次机会。

李迟 2015.9.3晚

近来经济拮据，如本文对阁下有帮助，可慷慨解囊赞助笔者以输出更多好文章。
[email protected] 或 微信fly_camel_fly 均可。感谢！
                                

本文固定链接: /code-life/a-project-note4.html