关于嵌入式系统的设计

中小型公司，需要照顾的东西比较多，每天救火都来不及，谈什么迭代改进？特别是自力更生发展起来的公司，除了一堆需要维护的老产品，还有一堆将要开发的产品特性。怎么弄？整天都在救火， 研发人员疲于奔命。难有心情和时间去总结。这都致使问题从一个版本继承到下一个版本，bug代代传。

类似的项目做多了，也有一些小心得。总结如下：

1.通过合理的设计简化业务模型。我们曾经设计一个RTOS系统的项目，原来的设计中大大小小用到了几十个信号量。通过深入的理解项目的需求，重新优化设计，将信号量的个数降低到十个以内。大大降低了系统同步的复杂度，减小了出错的可能性。 另外一个方面，同步要求的降低，实际上是模块间耦合程度的降低，降低带来的直接好处，调试、开发难度都大大降低。 接下来的好处就是项目交付质量的提高。

2. 过程是工具、方法、技术和人的有机结合。这个结合过程的关键是人。人的素质和格局决定了很多东西。有朋友曾今对我说过，软件的质量是测出来的。我不这么认为，质量应该是一场人民战争。设想一下，程序员的写得质量很糟糕，一堆问题交付到QA，QA测试用例能覆盖到所有问题吗？就算是能覆盖，一堆问题打回给研发，研发再改，又是一堆问题。收敛速度慢，QA面对大量的问题和有限的开发时间。只能是挑选主要的测试用例进行测试。 这么一来，怎么保证最终的质量？况且 QA的测试用例本身也有一个发展的过程，不可能测试到所有的问题。所以发动人民战争，群众的眼睛是雪亮的。
从需求开始，提高每个环节的人员素质。集思广益，不要把问题抛给QA，给兄弟部队减少负担。提高整个团队的战斗力。

3.项目要想缩短时间，就是要合理利用资源。很多企业里资源无法复用，效率较低。可以从一些核心的资源开始做起，如建立统一的业务平台。如应用RTOS的公司，一套RTOS肯定是不够的，产品高端的要用好的系统，低端的可能要用低端的系统。代码可能要维持两套。可以通过构建一套兼容库，或者中心库，完成对两个系统的兼容。中心库慢慢添加，以可靠，通用为前提，慢慢添加自己的业务模型，抽象出标准的业务模型，严格的测试。可以大幅度缩短项目的交付周期。统一的研发流程，统一的开发方法都能规避下个项目中可能出现的风险。
不一定一下子就上CMMI，敏捷。CMMi本身只是一个流程的指导，并不牵涉到具体细节的操作。并且在实践中，由于对cmmi的不熟悉和曲解，造成本浪费，成效甚微。可以从CMMI抽出一些好的方法，逐步去实践，以稳为主，慢慢地迭代改善。

本文出自 “夜来听风雨” 博客，请务必保留此出处http://coolbacon.blog.51cto.com/7777407/1279905