读书频道 > 系统 > 其他综合 > 嵌入式系统设计与实践
1.2.3 解决问题的原则
2013-06-20 11:24:58     我来说两句 
收藏    我要投稿   

本文所属图书 > 嵌入式系统设计与实践

O’Reilly Media通过图书、杂志、在线服务、调查研究和会议等方式传播创新知识。自1978年开始,O’Reilly一直都是前沿发展的见证者和推动者。超级极客们正在开创着未来,而我们关注真正重要的技术趋势...  立即去当当网订购

嵌入式系统就像个智力拼图,每一小部分都相互锁在一起(只能以一种方式)。有时候,虽然可以使用蛮力将各个部分拼在一起,但结果却可能和盒子上的图像相差甚远。我们应该摒弃这样的观点,即在项目结束时将最终的结果作为唯一发布的代码版本。

事实上,智力拼图有个时间维度揭示了其整个生命周期的不同变化:概念设计、原型化、电路板调试、系统调试、测试、发布、维护,如此循环往复。灵活性并不仅仅指代码现在能做什么,而且指在其整个生命周期里面能做什么。我们的目标是要做到足够灵活,这样才能在满足产品目标的同时能够很好地处理资源约束和其他一些嵌入式系统内在的设计挑战。

我们可以应用软件设计上的很多优秀的设计原则来让系统变得更加灵活。通过使用模块,我们将功能分离在子系统里,并隐藏各个子系统的数据。使用封装,我们设计子系统之间的接口,以使各个子系统相互独立。一旦我们拥有了松耦合的多个子系统(或者对象),就可以在修改软件的某一部分时相信这个修改不会影响其他部分。这样我们就可以分拆我们的系统,然后在需要的时候按照不同的方式再把它们组装起来。

知道在哪里将一个系统分解为各个部分需要更多的实践。一个比较好的原则是考虑哪些部分会独立地发生变化。在嵌入式系统里,应用这一原则需要我们考虑各个不同的物理对象。比如,如果传感器X需要通过通道通信Y通信,那么这两个独立的对象就是两个候选子系统(也是两个代码模块)。

我们把子系统分解为对象之后,就可以对这些对象进行测试。我很幸运,曾经在一些项目中有非常优秀的质量保证(QA)团队。在其他的一些项目中,不曾有过任何人在我的代码和那些将要使用我的系统的人们之间承担QA的角色。我发现在软件正式发布之前捕获的缺陷就像礼物一样。错误发现的越早,解决这些错误的成本越低,对大家越有好处。

当然,不必等着别人给我们送礼物。测试和质量向来是相互关联的。写测试代码对系统进行测试可以让系统质量更高,给代码提供一些文档,别人会认为我们开发出来的软件卓尔不群。

对代码文档化是另一个减少缺陷的方法。但如下这样注释代码,让人很难理解详细的程度。

i++;  // increment the index

不需要这样做,其实这样的代码行很少需要注释。写注释的目的是为了像你一样的开发人员,在一年之后再看你写的这些代码,那个时候的你可能正忙于其他事情并且忘记了当初你怎么想出这个创造性的解决方案,你可能甚至已经忘记了你写过这些代码。因此,请在代码里留下些痕迹以帮助你自己找回记忆(文件和函数头)。总的说来,假设读者和你具有相同的心智和背景,只需写清楚这段代码做了什么,而不是如何做。

最后,在资源有限的系统开发过程中,我们常常会有尽早和尽可能多地去优化代码的想法。抑制住这个欲望。实现所有的功能、让系统运行、完成测试,然后再回来按照要求让代码更小或者运行得更快。

时间是有限而宝贵的,因此在各个子系统能够运行后再来专注于那些最消耗资源的部分,看看能否得到更好的结果。为了运行速度去优化一个很少运行的函数不会带来任何好处,反而会减少花费在那些运行频率非常高的函数上的时间。有一点可以肯定的是,处理系统的资源约束需要一些优化。但在调优之前请务必搞清楚系统的资源消耗情况。

“我们应该忘记小的性能提升,在97%的情况下,不成熟的优化是万恶之源”

——Donald Knuth

点击复制链接 与好友分享!回本站首页
分享到: 更多
您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:1.2.2 更多挑战
下一篇:1.3 延伸阅读
相关文章
图文推荐
2.7.12 使用仿真器查
2.7.11 栈和寄存器组
2.7.8 出栈
2.7.7 压栈
排行
热门
文章
下载
读书

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训
版权所有: 红黑联盟--致力于做最好的IT技术学习网站