-
-
手机阅读
系统开发的规范化问题
随着人才流动的加快和研发周期的缩短，我们个人需要快速高效的完成自己的设计，维护和升级，公司需要人走不影响项目进度、新员工很快就能接手。这就需要：一个系统设计完成以后，它不应该仅仅是一些源代码，还应该包括各种各样的开发文档。（这对以后自己对系统的维护和升级都有很好的参考作用。而且能最大情况的避免一种情况：你改了一个BUG，却发现又出现了很多个BUG。）一个系统开发完成，它究竟应该包含那些文档，这些文档一般是怎么完成的，应该包含哪些内容？这就是系统开发的规范化问题。系统开发的规范化不仅有利于自己，也有利于公司，更有利于新手。规范化的设计让工程师工作更高效，这已经是不用争论的事实。现在在大型软件工程开发方面，这已经做得相当好。但在单片机和嵌入式系统的开发方面，规范化的工作却有待我们共同探讨。一个不容否认的事实是：国内的大部分小系统开发工程师从来不写文档，一开始就是以功能完成为中心进行代码设计。
在香港的一些公司也是这样一种设计模式。在国内，一些公司的研发管理人员也有一种误导——快写代码，快让我看见功能，不要你做其他的，完成功能就好。这些都把我们的设计导入一种误区：大部分时间都在写代码，改代码。
在此提出系统开发的规范化问题，也是我个人的一点想法而已。仅供参考。不过，一切还得从实际出发，倒没有必要硬要把设计从写某些文档开始，太教条了不好。如果你感觉写某些文档是浪费时间，那就别写吧。
在这里，我给出一个小系统大致包括的文档，仅作参考。
PRODUCT SPECIFICATION 一般是市场部或者是客户提供的
PRODUCT SPECIFICATION ——》 PROJECT LEADER
PROJECT LEADER 给工程师分配方案
SOFTWARE SPECIFICATION ——》 HARDWARE ENGINEERS
HARDWARE SPECIFICATION ——》 SOFTWARE ENGINEERS
MECHANICAL SPECIFICATION ——》 MECHANICAL ENGINEER
一、 硬件工程师的芯片选择，原理图的设计
硬件工程师根据HARDWARE SPECIFICATION 来选择芯片（也可能是PROJECT LEADER 早已为你定了），再根据芯片说明来设计各功能模块电路。出一份文档
HARDWARE IMPLEMENTATION
并进行SCHEMATIC DESIGN
再把这些资料提供给SOFTWARE ENGINEER。
PCB LAYER 当然不需要文档了。
但有跟随的HARDWARE UPDATE REPORT
包括调试修改和最后的软硬联调，所做的任何工作都要出相应的说明。
（呵，呵，你自己保存一表格天天填吧，改动地方，修改原因，就两项，不难写的）
软件工程师得到芯片和电路资料，开始根据SOFTWARE SPECIFICATION 进行设计
首先我们应该出一文档：
SOFTWARE IMPLEMENTATION 这里大致包括软件采用的芯片，软件的功能模块及使用系统端口功能情况，仿真系统，原始数据资料，自己用其他语言写的数据处理工具。
在此文档完成后，我们进入了详细设计阶段：
MODULE DESIGN 开始写各模块的实现，包括各模块所要实现的功能，用到的系统资源（包括变量的定义，常量的定义），与其他模块的联系（*对系统的维护和升级很重要的）和时间间敉迹ㄓ泄潭ㄊ奔涞阌霉潭ㄊ奔涞悖挥泄潭ㄊ奔涞悖陀檬奔浼涓?nbsp;，用来设计主循环的）。这里表现的其实是你的思路，如果你思路清晰，做起事情来自然是事半功倍了。
MAINLOOP DESIGN：
主要是根据时间间隔图和各模块的重要性及响应优先级进行主监控程序的设计，确保各功能能顺利完成。
MIAN CHART FLOW
画出程序流程图
SOURCE CODE DESIGN。
这一部分才是代码的实现，要是你前面写得很详细了，这里你的思路很清晰，按照MAINLOOP DESIGN直接做就是了。当然，我们需要按照我们自己的〈编程语言规范〉来设计源程序。这是软件工程师的基本，我就不提了。
最后是软硬联调，需要两个人配合的，基本不出什么文档，但如果你作了什么修改，请记录在案，最后要更新你前面的设计文档。
最后是出FIRST SAMPLE ，MECHANICAL ENGINEER 会根据要求修改自己的设计。并出IMPLEMENTATION 和 UPDATE ME REPORT。
整个系统开发流程的规范化还应该包括项目的会审，软硬协调，成本的控制，货源的规划，测试规划，等等，由于我这里不是介绍一个现代研发部的研发流程，只想对系统软件规范化说得详细一点（这些可能是我们目前规范化面临的最大的问题吧），其他我都省掉了。
这里写的不详细，只给出一个简单的单片机开发文档(见后面的下载地址)，仅为抛砖引玉而已，希望有经验的各位同行修改补充。如有不明之处或者需要一些资料的，请给我留言(由于现在很忙,可能不会一一回复或者应答,请见谅)。
最近又多了一些台湾和印度的朋友,发现他们的程序书写习惯几乎一样,又多了很多的感触,觉得规范化的程序书写习惯也应该成为一门程序员的入门课程呢.正如我们说话的语法规范一样.不至于太乱吧.
1楼
0
0
回复
随着人才流动的加快和研发周期的缩短，我们个人需要快速高效的完成自己的设计，维护和升级，公司需要人走不影响项目进度、新员工很快就能接手。这就需要：一个系统设计完成以后，它不应该仅仅是一些源代码，还应该包括各种各样的开发文档。（这对以后自己对系统的维护和升级都有很好的参考作用。而且能最大情况的避免一种情况：你改了一个BUG，却发现又出现了很多个BUG。）一个系统开发完成，它究竟应该包含那些文档，这些文档一般是怎么完成的，应该包含哪些内容？这就是系统开发的规范化问题。系统开发的规范化不仅有利于自己，也有利于公司，更有利于新手。规范化的设计让工程师工作更高效，这已经是不用争论的事实。现在在大型软件工程开发方面，这已经做得相当好。但在单片机和嵌入式系统的开发方面，规范化的工作却有待我们共同探讨。一个不容否认的事实是：国内的大部分小系统开发工程师从来不写文档，一开始就是以功能完成为中心进行代码设计。
在香港的一些公司也是这样一种设计模式。在国内，一些公司的研发管理人员也有一种误导——快写代码，快让我看见功能，不要你做其他的，完成功能就好。这些都把我们的设计导入一种误区：大部分时间都在写代码，改代码。
在此提出系统开发的规范化问题，也是我个人的一点想法而已。仅供参考。不过，一切还得从实际出发，倒没有必要硬要把设计从写某些文档开始，太教条了不好。如果你感觉写某些文档是浪费时间，那就别写吧。
在这里，我给出一个小系统大致包括的文档，仅作参考。
PRODUCT SPECIFICATION 一般是市场部或者是客户提供的
PRODUCT SPECIFICATION ——》 PROJECT LEADER
PROJECT LEADER 给工程师分配方案
SOFTWARE SPECIFICATION ——》 HARDWARE ENGINEERS
HARDWARE SPECIFICATION ——》 SOFTWARE ENGINEERS
MECHANICAL SPECIFICATION ——》 MECHANICAL ENGINEER
一、 硬件工程师的芯片选择，原理图的设计
硬件工程师根据HARDWARE SPECIFICATION 来选择芯片（也可能是PROJECT LEADER 早已为你定了），再根据芯片说明来设计各功能模块电路。出一份文档
HARDWARE IMPLEMENTATION
并进行SCHEMATIC DESIGN
再把这些资料提供给SOFTWARE ENGINEER。
PCB LAYER 当然不需要文档了。
但有跟随的HARDWARE UPDATE REPORT
包括调试修改和最后的软硬联调，所做的任何工作都要出相应的说明。
（呵，呵，你自己保存一表格天天填吧，改动地方，修改原因，就两项，不难写的）
软件工程师得到芯片和电路资料，开始根据SOFTWARE SPECIFICATION 进行设计
首先我们应该出一文档：
SOFTWARE IMPLEMENTATION 这里大致包括软件采用的芯片，软件的功能模块及使用系统端口功能情况，仿真系统，原始数据资料，自己用其他语言写的数据处理工具。
在此文档完成后，我们进入了详细设计阶段：
MODULE DESIGN 开始写各模块的实现，包括各模块所要实现的功能，用到的系统资源（包括变量的定义，常量的定义），与其他模块的联系（*对系统的维护和升级很重要的）和时间间敉迹ㄓ泄潭ㄊ奔涞阌霉潭ㄊ奔涞悖挥泄潭ㄊ奔涞悖陀檬奔浼涓?nbsp;，用来设计主循环的）。这里表现的其实是你的思路，如果你思路清晰，做起事情来自然是事半功倍了。
MAINLOOP DESIGN：
主要是根据时间间隔图和各模块的重要性及响应优先级进行主监控程序的设计，确保各功能能顺利完成。
MIAN CHART FLOW
画出程序流程图
SOURCE CODE DESIGN。
这一部分才是代码的实现，要是你前面写得很详细了，这里你的思路很清晰，按照MAINLOOP DESIGN直接做就是了。当然，我们需要按照我们自己的〈编程语言规范〉来设计源程序。这是软件工程师的基本，我就不提了。
最后是软硬联调，需要两个人配合的，基本不出什么文档，但如果你作了什么修改，请记录在案，最后要更新你前面的设计文档。
最后是出FIRST SAMPLE ，MECHANICAL ENGINEER 会根据要求修改自己的设计。并出IMPLEMENTATION 和 UPDATE ME REPORT。
整个系统开发流程的规范化还应该包括项目的会审，软硬协调，成本的控制，货源的规划，测试规划，等等，由于我这里不是介绍一个现代研发部的研发流程，只想对系统软件规范化说得详细一点（这些可能是我们目前规范化面临的最大的问题吧），其他我都省掉了。
这里写的不详细，只给出一个简单的单片机开发文档(见后面的下载地址)，仅为抛砖引玉而已，希望有经验的各位同行修改补充。如有不明之处或者需要一些资料的，请给我留言(由于现在很忙,可能不会一一回复或者应答,请见谅)。
最近又多了一些台湾和印度的朋友,发现他们的程序书写习惯几乎一样,又多了很多的感触,觉得规范化的程序书写习惯也应该成为一门程序员的入门课程呢.正如我们说话的语法规范一样.不至于太乱吧.