最近的一个硬件项目 HR 出现了重大生产级问题被通报了, 对于对项目各个环节相对比较熟悉的我来说这个结果是必然的 (虽然有些马后炮).
暴露的问题:
1. QA环节不够强势, QA变成了开发人员的附属测试人员, 在开发人员能力不足且期望性不是很高的情况, 修改一点点内容, 然后让QA测试得到结果. 分工不够明确,导致QA怨言, 开发人员随意.
2. 开发人员能力不足问题明显.
最最明显的是一个录音外设的封装竟然几个月都有问题, 最后还是换个人一周就搞定了(其实从过往的项目上看, 原开发人员确实能力不足.).
EM应用开发人员明显嵌入式经验不足, 对OS都不够熟悉(都是从后端转过来的), 对使用一些库和应用的调用不够熟悉, 实现框架和流程不合理, 但开发人员和管理人员对于刚刚开始做嵌入式内容, 觉得自己的功能还可以, 甚至于对自己的框架和实现技术上的一些应用很得意. 但同时思想上有懈怠. . 发现问题而不能解决问题, 甚至于绕开问题的. 程序运行都有崩溃问题, 甚至于需要开启crontab 和 额外检测程序发现是否有程序崩溃需要重启的情况, 这说明对自己的系统有很大的不自信.
在要上线的时候还不能达到 90%的稳定性测试, 导致生产级事故是肯定的事情. 当时我给他们建议是花点时间把系统和代码进行一下重构, 有些人同意,但最终没有推行. 问题可能出在管理和开发的协调上以及开发人员内部认知一致性的人为因素上, 这有暴露了人多民主意见杂的问题, 所以团队有梯度也很重要.
1. ubuntu 命令模式下使用mplayer + pa 组合只为音频播放有些大材小用.
潜在的问题
1. 响应速度慢. 在ARM板子上竟然有 5秒都得不到响应的情况.
2. pa为用户态服务, 在 使用没有任何用户登录的情况下用是否有问题不太确认, 但实操过程中有出现过 mplayer 没有声音, 日志"get stock"的现象, 此时mplayer + ALSA播放没有问题, 说明确实是 pa出问题了.
2. FFMPEG库在系统内存在 2/3 两个版本.
3. 使用 /etc/rc.local, 竟然使用sudo, 使用sudo的原因不用则某些ros应用启动不起来. 而实际上QA那边的反馈是就算是用了sudo, 还有30%的可能性ros启动不全. 而根据我的经验, 某些ros应用启动不起来是因为DDS的问题, 替换一个DDS即可. 我有建议, 不明确原因没被采纳.
4. 软件件之间的HAL库调用 1. HAL库没有实现可重入. 2. 在callback环境上, 上位应用人员竟然采用长时阻塞造成二次调用无结果. 以及多线程多进程调用. 造成调用逻辑混乱现象, 这个问题竟然前后花了约合2个月.
5. 使用ROS框架, 但是应用不是通过ROS2 run启动, 我也不太明确这样会不会出问题, 但是他们出现了 domain id 设置无效的情况. 我觉得用了何种框架, 就需要最大化的使用框架内的规则, 否则出了问题怎么定位.
6. 应用人员对ROS开发不熟悉, 在库封装以及程序启用和 spin等内容上出了问题. 其实在ros的一些util 和 python脚本以及 executor 有很多第三方库以及运行容器, 另外在一些功能上比较适合action/service的都没有用上.
7. 编译环境还采用了异构机器上的交叉编译. 人为因素增加了异构环境搭建和部署的工作量以及问题. 说明开发人员对EM有些许了解, 但没有做到与时俱进.
影响项目成功与否的因素探讨, 在项目实现的这个环节上关于人为相关有几种大的现象.
1. 思想上的懈怠. 明明知道有问题,能解决的问题, 但是个人感觉还可以的, 反正功能可以用吗, 只是不好用而已. 到最后可能会走不了回头路.
2. 实现细节上的小得意. 明明走了弯路, 却觉得是个人创举的.
3. 发现问题而不能解决问题, 甚至于绕开问题的.
个人认为这些因素都能归属于个人能力和团队协作能力, 在团队合作的项目中, 任何一个关键环节上出现了问题都会整个项目的失败. 通过复盘对比, 其实还有更多的因素和现象值得思考和改进.
在各种项目中不断学习和应用新知识以及从其成败中沉淀技术和架构经验, 这就是学习的终极奥义.
阅读(700) | 评论(0) | 转发(0) |
