最近算是急促的把《嵌入式系统开发之道》给看完了,因为出差的缘故,顺便在出差的路上将《质量无泪》看完了。发现质量的概念是在1970年代就已经广为制造业届推广。而那个时候软件的编写还在很基础的层面上,C语言可能还是刚刚出现。汇编还大行其道。Microsoft应该还在1MB的芯片上宣扬其程序的优秀。面向对象的概念可能还没有出现。
所以现在的软件工程中应该借鉴了当时很多制造业届的质量管控的概念,只是更多的融入了软件开发中。
软件工程中关于软件质量管控的书也随着软件业的兴起,积累的经验慢慢丰富起来。后来的软件编程模块化,单元测试,不知是否曾借鉴了质量管理里的“基体化(最小单元)”。单看概念是很像的。
软件开发中的体系比较清晰了,但是对于嵌入式系统开发,虽然也是计算机系统,但是由于其从底层硬件到固件程序,到系统层,到应用程序都需要完成一个开发小组完成。虽然应用程序的设计并没有PC端应用程序那么复杂,但是它要求设计者熟知的范围更广。PC端的操作系统高度将硬件抽象化(不必考虑硬件),只要专注于应用程序编写就可以。但是嵌入式系统中,需要设计者考虑硬件资源,考虑驱动问题,考虑系统,考虑应用设计。这些决定了嵌入式系统的设计者,要了解更多。虽然嵌入式设备无处不在,但是对于嵌入式设备的开发体系还是很少有专门的书籍介绍。《嵌入式系统开发之道》可以说是自己遇到的第一本书。
虽然书中对于各个部分着重于概念,但是从一个实践者的角度出发,具体细节是不需要的。具体的项目都是不一样的,但是开发的流程是相似的。
因此书中当然没有模拟电路的介绍,也没有高速电路的介绍,没有什么算法的介绍。因为具体的这些是时刻在改变的,每一个项目都是不一样的。但是每一个项目都要经历一些相似的开发过程。
操作系统不一样,但是操作系统的概念是一样的。SDK不一样,但是开发SDK是一样的。驱动程序不一样,但是设计驱动程序API,建立HAL层是一样的。具体实现不一样,但是整体的系统架构是相似的。产品不一样,但是保证产品质量安全可靠的流程是相似的。项目不一样,但是如何按期完成任务是相似的。
对于具体的操作细节而言,总会有不同。随着时间的推移,使用的技术表象也会变化。
书中写到在工作中遇到问题,解决问题,不做深入研究。
当然这是工程上的做法,按照规格完成任务。而不会更深入研究涉及的方面,对于工作需要这样。但是对于我们个人的成长需要有条主线。需要就某一个问题深入下去,形成自己的理解。这样有我们深入的一方面,也相当于打个牢固点的地基。不必对每一个问题都深入去看,但是要有我们自己想要深入去看的某一方面。
用户1724447 2013-11-29 10:13