对软件开发过程的一些感想

窗体顶端

 

    软件工程说到底，就是如何省钱的问题。也有人说是为了做出优秀的软件,但优秀的软件最终还是要用经济来衡量.凡是能为软件开发省钱的技术办法，工作过程，人员搭配均属软件工程范畴。

 

        对于一些人而言，往往有一种误解，即认为软件工程不适合于小公司，新公司。有些人认为软件工程就是UML。其实任何一本软件工程书开始都会提到软件危机，及软件工程产生的原因（节约成本，提高效率，控制错误）。因此UML只是其中一种普通方法而已，有其适用范围，也就是一般的中等软件,同时要求人员的素质非常专业。大型软件和小型软件都不会去用UML，而对于大多数国内的软件公司，也缺乏素质非常专业的人员,不是说他们水平不高，而是大多数人都要从分析一直做到维护，缺少各阶段相应的经验积累。

   

        为什么软件工程要划分为分析，设计，编码，测试，维护五个阶段，我个人认为其中一个原因是因为开发软件是一个把现实世界映射到计算机世界里一个工作过程，对于比较大的项目，存在很多工序，需要很多人的参与，随着产品的逐渐成型，不同类型的人起的作用也不同，实际上是根据这种情况来划分软件开发各阶段。划分阶段的好处是不同阶段引入不同的人，可以减低人员成本，而且如果有多个项目，可以错开利用，更有效的利用各个类型人员的工作时间。而各个阶段的可见的标志性成果就是文档和程序。这也是文档的用途之一，标识各个阶段。

   

        既然把软件开发划分为不同阶段是可以省钱的。那么可以认为按阶段开发是合理的。每一个大的阶段也可以划分出许多小阶段，在这几个阶段内如何划分阶段呢？这是人员搭配的范畴，也是一个度的问题，没有标准，起决定性因素的是开发人员的人数和素质。比如常常使用的原型法，各个阶段可以同时存在，同时都需要很多各种类型的人，从用人曲线上来看，平滑期最长。这既是原型法的一个优点，大家都不闲着，也是一个缺点。缺点太明显了，很多人从头做到尾，太累。

   

接下来，就说系统分析。系统分析在软件开发过程中是空前重要的，他直接决定后面几个阶段的工作形态。因为系统分析的原因，很多项目都陷入迭代开发的旋涡。我们都知道，两点之间，直线最短，螺旋式的上升曲线肯定是要长一点的。既然不可能直线上升，至少也得能迅速的螺旋上升，否则费用会很高。

 

系统分析是什么？我认为是一个理解目标系统的过程，是把目标系统转化为系统分析员的认识的一部分的过程。就是说系统分析过程中，系统分析员不断的清晰目标系统，建立一个基本的系统框架，并且不断用各种可能输入，各种角色，各种功能，各种可能的系统变动来检验系统，直到完善。这个新的系统结构，会当然的拥有组成元素，部分间的联系，信息流动的过程。它已经基本上决定这个项目的未来了。

 

但是除了小项目，一般能完成以上过程的人不太多。做为一种方法，面向对象分析就开始应用了。面向对象不是从宏观上把握，而是通过种种办法寻找元素，通过搭建的方式构造新系统。但是不管用哪种方式最终结果都应该是一个能被各种用户使用，能实现规定功能，还能尽可能应付功能变动和处理信息的一个系统结构和组成元素的说明。

 

在我个人看来，系统分析员水平高不高就是看，他的抽象思维能力，理解速度，搭建的结构好不好！

 

系统分析这一层是用户层和程序员层的一个中间层。这一层的上半层，是和用户接触，和计算机关系很少的而且也没人会再这就去考虑实现。但是它和程序员层的接头的这一部分，就开始引入计算机环境了，能否平滑的把分析变为设计，计算机环境的因素是个重大的制约因素，这里会消耗工作量。因此系统分析的能力主要体现在快速建模、高度抽象、保持稳定、容易理解

 

系统设计承袭了系统分析，最终要实现详细设计文档。主要有几个组成部分，设计数据库，设计类库，设计界面，设计程序。

 

数据库里常常有几种类型的表，第一种和现实世界对应，有静态结构表，常见的有用户表，种类表，权限表等等。有工作业务表，对应处理流程和工作过程。第二种和计算机环境有关，又可以分系统设置表，中间数据优化表，界面设置表等等。

 

数据库的核心表往往对应着现实世界的类。因此核心表和表里的字段应该是有意义的，能在现实世界有对应的，尽量不要附加其他现实世界不存在的字段，比如附加的无意义的数字主键，因为表里的行对应现实世界的对象，对象总是可以非常自然的互相区分的。容易理解才能容易维护。正确的区分表的类型，把代表不同意义的字段放到不同类型的表里很有好处，最好把不同类型的字段混放在一个表里。

 

如果想写程序省事的话，类库是不能少的。做类库的步骤，我一般是首先是拆分系统，要按与应用有关和无关分，按界面层，应用层，数据层分，按程序类型分等等，就好象切西瓜一样，综合使用。到最后，就可以找到要写的小模块。只有有意义的模块才是有意义的。接着根据这些小模块可以设计类库，当然要把握“度”。实际中，很多系统设计员会重用以前的类库并且不会把粒度放到太小，多少也留下一些可以变动的地方。

 

 用了类库，程序员就少了很多工作了，我曾经工作的一个公司，就用了比较成熟的类库，工作也可以量化了，当时做的主要是信息系统，一般是一个单表维护5分钟，一个主从表维护15分钟，一个比较综合的30分钟。做起活来，又快又省事。

 

软件工程书上，多会给一些指标，扇入扇出数目，层次数目，函数数量，代码长度等等，其实不必过分追求。这些数字都是在其他环境测试得出的结果。而不同公司的人员素质，思维方式都有较大差异，因此，制定这些指标虽然有用，但具体数字一定要结合公司实际情况来制定。

 

界面设计，对于mis系统而言，重要的实现功能，界面的美观就不是第一位的问题。简化输入很重要，尤其对于信息录入部分。我觉得完成一个业务平均击键次数最少的设计应该更耐用。

 

设计的类，对象，过程，函数，事件，变量等等都必须有意义，都应该是可以追踪到现实系统的，这个意义一定是需要仔细思考的。（很多好程序员总是不假思索，下笔如飞，可能就没有十分仔细去思考所写的东西的意义。）同样一个问题，不同人有不同的看法，最接近本质的那个人设计的程序的后期维护工作量一定少一些。而能认识到本质就不能仅仅学计算机了，更应该向广阔的外部世界去学习。

 

设计出的模块应该是高内聚、低耦合的没错，也是衡量系统设计人员水平的重要标志。但是如何判断模块的耦合内聚程度，我认为关键看到给外部用到的函数个数和参数个数。

 

写程序就是按照系统设计的说明，来具体实现出程序代码的过程。如果按照正规的软件工程的说法，到写程序这一步已经没什么好说的了，大都会略过去的。这也说明在软件开发的过程中程序员起的作用会越来越小。

 

但是在目前，程序员光拿着文档就可以直接写出程序的还很少见，很多程序员还不得不做系统设计的事。这是导致维护费高的一个重要原因。

 

我认为程序员好不好，首先就是看他的责任心。程序的很多危险，第一个感觉到的是程序员，程序有bug，就象是着火，是面对，还是佯做不知，工作量往往差十倍不止。其次是好学，通常百分之九十九的程序，能用到的函数不会超过100个，一天学一个，搞清楚用法，什么时候会出错，用三个月也应该能熟练编程了。再次是合作的态度，命名和大家都用一个规则，程序和大家都用一个思路，不要炫耀技巧，这样的程序也好维护。

 

文档是软件工程的重要组成部分，各种分析设计文档，不是仅仅有结果，还要有原因，让人看到文档后不会知其然不知其所以然。文档必须要对人有用，才叫文档，光是套格式是不好的。用好文档的关键是理解各种文档的侧重点。

 

以上就是我做软件开发的一点体会，都很零散,也不成体系,但是每一部分都是独立思考出来的,一般书上有的我就不写了.请大家多提宝贵意见.