国内的嵌入式软件开发普遍沿袭传统做法，大多数非核心系统项目都倾向于先编程。开发者们往往直接进入编程阶段，忽略了软件架构、抽象化、建模和模拟等环节的讨论。特别是在微控制器领域，有些开发者既不设定代码风格规范，也不遵循设计原则和面向对象设计的标准。
传统开发原因剖析
产品上市面临巨大压力，企业急切地想要将产品推向市场，因此没有时间去关注更严谨的开发步骤。另外，建模和仿真工具的费用相当高昂，对众多企业而言，这样的成本实在难以承受。此外，嵌入式软件开发观念的转变颇为不易，开发者自职业生涯开始就习惯了传统的开发方式，要想改变这种思维模式，不仅需要漫长的时间，还要经过相应的教育培训。
编程先于测试问题
嵌入式软件一旦发布，修改起来颇为不易，出错空间有限，因此测试环节理应得到充分关注。然而，在实际操作中，开发者往往先编程，测试工作往往被推迟。以物联网应用为例，在那时，更新微控制器的固件还需亲自到设备所在的地方，代码的容错能力较低，尽管如此，开发流程依旧没有发生改变。
开发思维观念偏差
嵌入式软件工程师往往对建模和仿真方法持保留态度，也不倾向于采纳计算机科学领域的研究成果。他们的职业生涯多从功能有限的8位微控制器开始，觉得过于抽象和自动生成代码会引发不必要的冗余，并可能导致对代码控制力的下降。此外，他们普遍认为建模和仿真过程过于耗时，更倾向于直接编写代码。
新需求与旧模式矛盾
过去，微控制器的代码可以用简单的状态机来描述，但现在需要解决的是多维度的问题。在这种新的需求面前，以往的开发方法显得力不从心。比如，统一建模语言（UML）能够对应用进行建模和仿真，但它并不受开发者的青睐，因为他们难以适应这种新的开发流程。
开发改革解决办法
在理想状态下，建模技术可以同时解决开发阶段的设计和编程两个环节的问题。例如，实时面向对象建模（ROOM）和领域特定语言（DSL）就是这样的技术。它们专注于事件驱动的实时系统，不仅支持建模和模拟，还能生成适用于目标硬件的代码，从而推动嵌入式软件开发方法的革新。
你认为嵌入式软件开发团队需多久才能成功实现思维方式的转变？欢迎在评论区发表你的看法。同时，也请为这篇文章点赞并分享出去！
