高通开发-前篇

从14年底接手高通项目，那时候刚毕业，刚接手的项目也是三星项目的，转到高通感觉很懵逼，主要那时候刚毕业没有多，水平很差，而且三星的android版本2.2，高通的项目android版本4.1，这导致linux版本相差太多，而且找的oem，没有高通case和文档，网上文档又少，只能瞎搞。后来跳到有case的公司，才发现高通开发并没有那么难。

吐槽完了，这一篇主要讲开发过程中碰到的一些问题，以及如何面对。

一. 项目立项，软件预研

工作中碰到很多这样的事情，硬件勒的板子到了，项目拿着板子，急着说，XX工，板子到了，赶快调好，把硬件的问题验证好。这一听，无休止的加班又开始的，尼玛，心里忍不住吐槽，软件开发又不是那么容易的，一下子需要问硬件要原理图，问layout要位号图，问项目要项目规格书，模块的init code，分发任务。。。反正就是坑。

其实项目立项的时候，软件也需要参与，但硬件初版原理图发出的时候，软件就应该收到项目规格书，以及硬件原理图，以及新的硬件模块的数据手册以及参考代码，以及FAE的联系方式，最好有个邮寄沟通，抄送大佬，这样方便要是调试过程中，出现问题，能快速与对方的FAE沟通，定位解决问题。

软件预研，这个其实很重要，能加快整个项目的进度，而且并不会占用软件的太多时间。预研，主要让软件心里有个数，哪方面是难点，哪些是以前没搞过的，哪些点是之前硬件埋的坑，可以减少硬件改版的次数，以及做好到板后的前期准备工作。例如，对于新的项目，下载高通的源码（网速不好的情况下，可能要下很久），搭建环境，新建git仓库，出原始的刷机包，并分发软件开发任务。我负责的那个项目，做了软件预研的，一个新的主控，以前没开发的，一个给客户的demo版，只有4-5个工作日，就给出，这个版本modem以及软件的大部分外设基本调通，满足客户的再次开发和送样。

二. 代码管理，邮件抄送

对于软件开发，最多的莫过于兼容、定制，一块板子N个版本，所以代码管理很主要，最早用的svn，后来习惯的git，这里主要讲的是代码控制的权限、及提交的规范。权限控制，用git搭建gitolite，这个就有权限控制，基本满足要求。提交规范，是解决一个问题，上传代码时的log规范，一般[project][module][change][user][bug_id] xxxxxx，这些具体可以自己去贴合项目定义。

1，有了这些规范,对于发布软件版本，提交改动的时候，把git log给研发助理整理出来即可，再也不用担心那个版本做了哪些改动。

2，对于其他的开发成员，能快速的查看以前项目是不是解决过现在遇到的问题，也能快速理解当前的改动点。

3. 当发现新版本存在以前不存在的问题，能加快定位问题的速度。

邮件沟通，这个比较复古的沟通方式，对于现在基本微信\QQ或者电话的情况下，它仍然很重要。

一般信息确认都是以邮件沟通为准。所以很多时候扯皮的时候，微信、QQ这些做不了准。

邮件沟通，抄送给老大或者合作公司的老大，能让上面的人，看到现在的项目进度，遇到的问题，知道你干了什么，需要给你协调什么资源。微信、qq,聊天消息一堆，不可能老大闲着会一条一条去看的。QQ、微信、电话只能作为加速沟通，但最后还是需要补上邮件的。

三、信息检索、问题处理

对于开发高通方案，信息检索很主要，那时候我带新人，我对他们说，碰到问题，一方面查看git的log，是否其他项目解决过，另一方面，查找高通网站solution，查找高通资料，以前高通的资料，网上没有这么多，而高通本身的资料库还是很齐全的，配合文档以及源码，还是好追溯、解决问题。

问题处理，碰到问题，工程师应该根据项目的进度去权衡，那会提case不要钱，我要求碰到问题，或则测试提出的bug，先复现现象，保存log，提case，提完case，自己再去解决，这样你自己解决问题的同事，高通的FAE也在解决，双方沟通，能更快的定位解决问题，同时也能想高通的人学习他们的丁文问题，解决问题的思路。

当然项目更赶，问题很难的时候，这就需要找老大，找资源去处理，一些以项目进度为第一准则。

四、项目总结、文档规整

项目做完的，或者失败的，在闲暇的时候，需要去做项目总结。这个项目碰到的难点，推延时间的点，或者失败的原因，哪些模块比较难调，简单的技术交流，并要求开发者写一些文档，要求研发助理整理好这些破碎的信息成文档。开发不能做完一个项目就完的，不仅项目需要回溯、整理，而且开发者也需要自己的收获等，其实有邮件和git log，还是比较好整理的，主要是形成文档，比较繁琐。