系统开发的规范化问题
随着人才流动的加快和研发周期的缩短,我们个人需要快速高效的完成自己的设计,维护和升级,公司需要人走不影响项目进度、新员工很快就能接手。这就需要:一个系统设计完成以后,它不应该仅仅是一些源代码,还应该包括各种各样的开发文档。(这对以后自己对系统的维护和升级都有很好的参考作用。而且能最大情况的避免一种情况:你改了一个BUG,却发现又出现了很多个BUG。)一个系统开发完成,它究竟应该包含那些文档,这些文档一般是怎么完成的,应该包含哪些内容?这就是系统开发的规范化问题。系统开发的规范化不仅有利于自己,也有利于公司,更有利于新手。规范化的设计让工程师工作更高效,这已经是不用争论的事实。现在在大型软件工程开发方面,这已经做得相当好。但在单片机和嵌入式系统的开发方面,规范化的工作却有待我们共同探讨。一个不容否认的事实是:国内的大部分小系统开发工程师从来不写文档,一开始就是以功能完成为中心进行代码设计。
在香港的一些公司也是这样一种设计模式。在国内,一些公司的研发管理人员也有一种误导——快写代码,快让我看见功能,不要你做其他的,完成功能就好。这些都把我们的设计导入一种误区:大部分时间都在写代码,改代码。
在此提出系统开发的规范化问题,也是我个人的一点想法而已。仅供参考。不过,一切还得从实际出发,倒没有必要硬要把设计从写某些文档开始,太教条了不好。如果你感觉写某些文档是浪费时间,那就别写吧。
在这里,我给出一个小系统大致包括的文档,仅作参考。
PRODUCT SPECIFICATION 一般是市场部或者是客户提供的
PRODUCT SPECIFICATION ——》 PROJECT LEADER
PROJECT LEADER 给工程师分配方案
SOFTWARE SPECIFICATION ——》 HARDWARE ENGINEERS
HARDWARE SPECIFICATION ——》 SOFTWARE ENGINEERS
MECHANICAL SPECIFICATION ——》 MECHANICAL ENGINEER |