半个系统软件工程师的困惑

关注

原创最新推荐文章于 2026-08-17 09:08:23 发布 1.5k 阅读 AI 写同款· GEO 优化 ›

MBD与AUTOSAR：汽车电子工程师的系统化能力跃迁与职业发展路径在汽车电子和嵌入式系统开发领域，基于模型的设计（MBD）和汽车开放系统架构（AUTOSAR）代表了现代复杂系统开发的核心方法论。MBD通过模型仿真、自动代码生成和持续验证，将控制算法开发从手写代码转变为可预测、可验证的工程化流程，其核心价值在于提升开发效率、保证代码质量并降低后期修改成本。AUTOSAR则通过标准化软件组件接口、运行时环境和基础软件抽象，解决了多供应商软件集成与汽车电子电气架构复杂度管理的难题，为软件定义汽车提供了基础框架。掌握这两项技术，意味着工程师能够从模块级实现者转向系统级设计者，其技阅读详情

前言：这篇文章之前发布在弯曲评论，有很多大牛的评价，值得一看：

http://www.tektalk.org/2012/01/20/半个系统软件工程师的困惑/#comments

半个系统软件工程师的困惑
半个系统软件工程师，是对自己的评价，因为清楚成为一个系统软件工程师要求的掌握的知识实在太多了：OS,处理器，编译器，协议栈，硬件等，希望自己能达到半个的水平:)。
开宗明义，我是H公司的，06年进入，一直从事平台软件的开发。但现在对于如何发展却存在很大的困惑，因此，期望得到各位前辈的指点。
在公司，有幸听到了陈首席的一次讲座，题目好像叫系统软件工程师的方法论，当时印象比较深的有三点：1，在通信公司做系统软件，做好能掌握总线技术。总线技术是我的薄弱点，属于两眼一抹黑，一直心有戚戚；2，cache是最容易忽略，又是最容易犯错的。之前公关xscale的cache问题就很有印象，听了此话后，又赶紧回去翻翻arm，ppc的手册，把cache的相关章节好好过一遍；3，系统软件工程师比较容易受委屈，很多问题虽然不是你的问题，也要你去定位分析。这点特别有感触啊。
略举例一二：
有个简单的功能模块提供了索引机制，供业务模块使用，业务模块不停的有释放申请呼叫控制块的操作，通过索引功能，可以快捷的申请到控制块。有个问题发现申请到索引非值常大，超过了正常范围，经分析，为索引的数据结构被踩了（虽然有内存分段隔离机制，但还是避免不了啊），业务模块踩内存的可能性比较大，排查了好久，也没有找到。当时部门领导就说了：找不到问题就是你的问题。我在旁边听了，那个郁闷啊（此问题非我分析，由同组的另外一个兄弟操刀），但想想，还能拍桌子不成。
有一个ftp下载的问题，有个兄弟分析了几天也没用进展，我协助分析下，很快就找到原因。直接主管说了一句话：感觉你定位问题好有天分啊。虽然是表扬，但心里郁闷啊，他哪里知道以前的我，为了定位一个丢包问题（测试抱怨呼叫一晚上，总是有十几次的呼损，分析原因就是MOT（MessageOverTCP）丢包了，当时为了定位这个问题，窝在实验室抓包，分析码流，最后发现是接口板的微码做完五元组后重算校验和时，进位的那一行代码有BUG。后来其他的一些丢包断链问题，让我把红宝书翻了好几遍，TCP的实现代码也仔细分析了一把。领导只是看到了结果好像很轻松，哪里知道后面付出了多少代价。
之前的系统是基于vxworks的，为了能快速分析出现的问题，还把vxworks的源码分析了一遍，重点代码研究了好几次（任务调度切换，中断异常，信号量，内存）后，打开源码，顺着目录一个个文件的阅读。后来看到了士兵突击里许三多说按字母顺序看图书，鼻子一酸。
这两年整linux+x86，又是一次艰巨的任务。
抱怨了这么多，感觉走系统软件工程师这条路，实在太辛苦了，学的东西多，发展又慢，还需要给别人擦屁股，现在不知道何去何从。看着做业务的，个个上升的很快，实在是羡慕嫉妒恨啊。之前分析问题时，也浏览过部分业务软件，就是个大case啊，解析消息，回应答，心有不甘啊。
1，系统软件（偏向于OS方向）有多大的发展前途，感觉就只能在可靠性，可维护性，适配上下功夫。
2，去互联网公司（如百度，QQ，假设能去的话）整系统软件会比在H公司更有前途吗？
3，转行做APP呢？

新年来了，顺祝各位弯友龙马精神，家庭幸福。