海思平台项目经验总结

手上的这个项目终于快要结束了，已经忙碌了两个多月，每天不停地加班。趁着项目尾声赶紧总结一下项目经验，不然就没时间啦。在公司上班就是这样，上一个项目还没有来得及好好消化，又要马不停蹄地投入到下一个项目中去。

这个项目基于海思平台，我的职责是平台开发。项目的主要成员有平台组，CA组，bootloader组，app组等。其它几个组的开发都是基于我们平台组，因此我们组先投入，他们后续进场。下面说说项目的进行吧。

项目开始的第一步是信息搜集。要搜集的信息有很多，主要是：1.项目立项资料；2.项目的硬件原理图和PCB图；3.记录硬件的外围设备的IO口配置信息；4.确认工具链版本；5.确认sdk版本，也包括使用的内核版本等信息。我们的工具链和sdk都是原厂提供的，里面可能包含有多个不同的版本，使用之前一定要向原厂确认清楚使用哪个版本。

第二步就是任务清单。把项目的工作量拆分成一个个小任务，拆分得越细越好，最好让任务以0.5天为一个单位。如果我对某个模块不熟悉，那就找熟悉这个模块的人替我拆分。然后把所有的任务记录到excel表格里面，在这里我用的是腾讯文档，可以一键把文档分享给团队成员，使几个成员之间协同办公。现在这种团队项目管理的软件有很多，比如说teambition，worktile都很好用，就看个人的喜好了。记录到表格以后列出重要任务的完成时间节点，这个时间节点是根据项目立项的时间节点来定的，但是我们自己的重要任务的完成时间节点肯定要提前，因为要考虑到意外的事件导致的延迟情况。

第三部就是开始搭建开发环境了。首先建立SVN仓库，把原厂提供的干净的sdk上传到服务器端。然后熟悉原厂工具的使用，熟悉这个平台的编译和烧录过程，尽快把编译出来的程序烧录到开发板上让程序先跑起来。

第四步全力解决最重要的问题。最重要的问题一般是如果不解决其他人就没法干活的问题。我的这个项目是一个高清机顶盒的项目，程序跑起来后一直无法锁频播放。当时花了一天时间才解决这个问题，解决了之后平台组的其他伙伴才陆陆续续地投入到这个项目当中。

第五步是事先约定团队的协作方式。组员使用的服务器不一定都一样，那么我们首先会约定好文件共享的路径，放入驱动库及其它共享文件。建立一个叮叮群，拉入团队成员，把文件共享的路径放在群公告上面。文件共享的路径最好不要更改，否则容易导致其他人取错了文件。接下来就开始分配任务了。上面的任务清单已经公开，我们平台组的成员都很清楚所有的任务。第一次的任务由我指派，后面的任务谁先完成了谁自己到任务清单里面取出下一个任务接着做（这里假设我们的成员都是敬业的，工作积极的），这样能够动态地分配任务。每天下班后我会统计每个任务的完成进度，定时更新，让成员了解彼此之间的进度，起到一个互相督促的作用，或者有的成员遇到问题卡壳了，我们也能及时一起探讨。我让每个成员每天早上来先更新代码，每天晚上走之前最好上传当天修改的代码到SVN服务器，前提是自己验证过OK的。有的文件不能上传但是其他人也有用到，如果更改了，就要及时放到共享路径下。这样能避免一些由于成员之间文件不同步造成的问题。在做项目的过程中，我们对团队的成员很信任，觉得别人不可能犯这种低级的错误，但是往往这种错误犯的很多，而且有的时候还不好查出来。那么我们要汲取教训，尽量避免这种错误。我们的程序要经过平台的自测试用例的严格测试，我们会记录测试的结果，pass或者failed。后续的app或者bootloader遇到问题，我们会首先参照平台自测试用例有没有类似的问题，所以我们要维护好我们的自测试用例表格，不允许随意修改。一般是其他成员修改了问题并且代码上传了，我再验证，确实没有问题了，由我修改自测试用例表格，并且在表格里面加入SVN版本信息，确保可以追溯到修改了哪些代码解决了哪些问题。下面是一张自己画的项目进度的表格：

最后就是软件的开发和测试了，就是写代码，调试解bug的过程。写一个复杂的函数之前，我最好还是画一下流程图，写完之后走读一下代码逻辑，写一个测试函数，传入一些临界参数，测试一下写的函数，尽量减少重复debug的次数，提高效率。后面是进行所有平台模块的整体测试了，我们的平台的自测试用例很多，基本上对每个模块的每个函数接口都进行了测试。一般情况下，如果我们的自测试没有什么问题的话，app开发基本上也不会遇到多少底层驱动的问题。自测试完了之后开始梳理问题，哪些问题我们自己可以解决，哪些问题需要原厂解决。如果需要原厂解决的问题需要尽早报告给原厂，因为有的原厂遇到这种不是芯片方案开发阶段的问题可能处理起来会很慢。后面就是合并原厂的patch，并进行下一轮的平台自测试，尽量把自测试的问题解决到最少，这样后面开发遇到的问题会少很多。