简图记录-驱动模块设计开发 评价指标总结

简图记录总结~

    几年的驱动开发经历，我常常会停下来思考，什么是优秀的驱动代码？怎么评价当前的开发工作是优秀的？有没有相关的指标和方向进行参考。以下为个人整理的评价或者设计时应该参考的方向，共分六个维度。

一、可读性

    ”编程的本质是社交活动，代码写一遍却可能要阅读上百遍，可读性应该放在首位“

     参考要素：（1）有意义的命名，变量函数命名是否名副其实。（2）清晰的表达式，严格的对齐与缩进，尽量降低圈复杂度，如使用卫语句、表驱动、抽象函数等手段；（3）单一层次的函数抽象，函数应该短小单一，函数语句要在同一抽象层次；（4）合理的模块划分，分层分模块，高内聚低耦合，单向调用；（5）清晰合理的头文件包含关系，头文件是模块对外暴露的细节；

二、可维护性

    ”设计阶段就要充分考虑可维护性，完善问题定位策略，而非出了问题再修改代码加打印调试“

    参考要素：（1）充分利用芯片验证手段，驱动方案开发都是建立在芯片逻辑的基础上，芯片在验证过程有大量验证手段，如数据替换pattern、数据校验和、状态和调试寄存器等，一定要善加运用，多提出芯片测试支持改进建议；（2）要能时刻查看如对外接口入参、内部关键数据和 状态等信息，如利用proc系统和可以动态控制打印等级的信息输出；（3）要考虑长期测试支持，关键状态切换和异常上报应该有计数查看。

三、测试完整性

    ”测试投入要贯穿整个规格分析到编码实现过程，良好的测试覆盖能提升修改bug和重构信心，让你睡个好觉“

    参考要素：（1）贯穿整个设计开发过程的设计投入，规格分析后输出测试表单，对外接口定义后输出接口测试用例，编码实现过程配合单元测试；（2）驱动架构设计时考虑可测试性，从哪一层测试，是否需要设计测试桩；（3）良好的测试覆盖，对外接口/函数/分支/语句；（4）利用测试框架如Cunit尽可能提升自动化测试效率，缩短测试时间降低测试投入；

四、可扩展性

    ”设计驱动架构要充分考虑未来需求和芯片方案的发展方向，方案通用化，不要引入逻辑约束到业务层“

    参考要素：（1）数据和逻辑分离，更易扩展和修改维护，如表驱动法；（2）如果未来可能有这方面的需求，驱动对外尽量做到支持多进程多实例，即使当前芯片逻辑有约束；（3）处理好硬件的抽象和封装，不要将硬件差异化引入到业务层；

五、鲁棒性

    ”养成防御式编程的习惯，即使外部数据或者调用流程引起错误，也不能死在自己模块，注意异常状态资源回收“

    参考要素：（1）严格的入参和调用流程校验，假设别人是攻击你的模块。特别是外部数据作为 数组下标/循环条件/内存申请大小计算/格式化输出等；（2）注意字符串操作安全，必须NULL结尾/源或目标区域越界风险；（3）注意运算安全，避免计算溢出或截断错误/避免不同类型混合运算特别是有无符号；（4）注意格式化输出安全，字符和参数要匹配/避免外部参数作为转化数据。

六、可移植性

    ”同一份代码能否支持不同平台boot/linux/Android使用？能否支持32位/64位编译？是否针对需求考虑通用性和可裁剪？“

    参考要素：（1）做好设计分层，对系统平台接口应封装使用（如printk、sleep、memset、regist_irq）。（2）处理好软硬件交互界面，业务层要通用，硬件层封装差异；（3）内聚的功能模块一定要考虑组件化，在不同的产品线维护一套代码；（4）编码过程避免引 平台或编译差异化特性；（5）编码过程避免使用不定长数据（相比int类型使用s32更明确），避免引入隐藏数据类型如size_t;