软件工程心得体会
曾经看过一本书叫《道法自然》,内容略记得一二,但我最欣赏的是它的书名。软件设计没什么太神秘有东西,只要用心体会,其实一切都很自然。软件的设计之“道”,也不在于设计有多么的华丽、精巧,而在于其朴实、自然,最终达到“以无招胜有招”,进入一个全新的境界。
一、软件设计理论的层次
以我的拙见,软件设计领域中的各种概念,可以分为以下几个层次来进行理解:
1、软件设计的目的:重用性、扩展性。
这是最高的层次,是应对软件危机的需要。
2、设计原则:低耦合、高聚合。
各种软件设计的原则,如依赖倒置原则、单一职则原则、面向接口等,以及各种设计模式,其根本的目的其实只是为了降低耦合这么简单。因为只有低耦合才能更好的适应变化,更好的重用和扩展。
3、实现方法:运用设计模式封装变化、降低耦合。
设计模式只是用来“封装变化、降低耦合”的工具而已。它是面向对象设计时代的产物,其本质就是充分运用面向对象的三个特性,即:封装、继承和多态,进行灵活的组合运用。
二、关于耦合
1、耦合的粒度
耦合无论如何也是不可避免的。当我们实现接口、继承父类的时候,就会不可避免的产生耦合。耦合是有不同粒度的,我们解耦到什么粒度为止,我认为应以模块的重用粒度为准。尽量解除重用模块或对象之间的耦合。而重用模块之内的耦合,应属于聚合的范畴,所以不要盲目的去解耦,否则就陷入了误区。
2、解耦的原理
怎样才能解耦呢,或者说为什么各种设计模式能达到解耦的目的呢?我觉得有以下几个思路:
(1)将具体的东西抽象处理
(2)将分散的东西集中处理
而面向对象中的接口、继承正为我们提供了这样的一种机制。通过访问接口或基类或抽象类,而不是具体的实现类,从而与具体的实现类达到了解耦的目的。我们还可以设计一些控制类,像润滑剂一样,协调各实现类之间的访问,也可以达到耦的目的。
事实上,各种设计模式的基本思想也就是这样。创建型模式是为了解除创建对象时产生的耦合,实际上是解除对类称名的依赖,而结构型和行为型是为了解除对象属性或方法的直接调用。不管什么设计模式,都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。
三、关于接口
这一节更具体,谈一谈接口,因为使用接口是软件设计的重要手段,但已经不属于“道”了~
1、接口与继承
接口描述的是对象某一个方面行为特征。使用接口与使用继承关系各有优缺点,使用子类继承可以继承父类的功能,体现了重用的精神。而接品更加灵活,因为它解除了子类与父类之间的高度耦合,它体现在灵活扩展的精神。
2、接口与纯虚类
理论上接口可以由纯虚基类实现类似的功能,那为什么还我们不去掉接口的概念,而直接使用虚类呢?
接口存在的理由就是它更加灵活,关系简单,易于理解。比如一个类可以实现十几个甚至几十个接口,但一般开发工具只支持单继承(由于多继承太容易导致混乱和冲突),如果要继承十几层,系统结构想必会无法理解了,我以为这是接口存在的最重要的原因。
如果接口和虚类继承结合使用,可以产生强大的威力,这也是许多设计模式的“杀手锏”。
以上算是总结一下自己的心得。肯定有不少片面之处,请各位指教。
第二篇:软件工程心得体会
软件工程心得体会
未接触软件工程之前一直都很想学这门课程,因为觉得这门课很牛,是那些有工程师称号的高手才摆弄的东西。学了一个学期的软件工程课,终于知道了个软件工程的大概。学的时候总觉得很抽象,理解起来好像不难,但总是摸不着头脑一种很茫然的感觉。
曾经以为程序就是软件,软件就是程序。学习这门课程第一个收获是,知道了二者的不同之处。以前做过的一些小型的软件比如加密软件,我也只是在程序旁边附上一个软件的说明,看来已经很接近作坊了。不过大的项目没有接触过,用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生,使得人们不得不探索新的解决方法。
经过倪老师的讲解,理解了软件工程,就是一套用于软件的团队开发,以提高软件质量和程序员工作效率为目的的规范。其核心就是,对于软件开发的5个重要组成部分:需求分析,设计,编码,调试,维护,如何组织这5个部分的工作,以及如何完成每一个工作。
吾生也有涯,而知也无涯,学习永无止境。起初,对软件工程处于一知半解的状态,分工比较混乱。在划分模块后明确了各自分工,渐渐形成良性循环。
在学习过程中,知道了团队合作十分重要,争议固然存在,但通过讨论、协商,群策群力,在不断磨合中能够达成一致与默契。团队成员中能力各有高下,互相尊重,各取所长,不宜妄自菲薄。组长多加协调,组员积极配合,才能合作愉快。
学习能力体现在能尽快接受新的知识,顺应变化,学为所用。上《软件工程导论》这门课,我的收获大概如下:
我们为什么需要软件工程呢?上面已经给出了一些原因。专业点讲,软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计,没有设计指导的编程是无序的忙碌的。根据开发的软件的规模,应该适当程度的运用软件工程化的思想,需要灵活,毕竟我们开发的软件大多数是中小型的,大型的并不多见(我是这么认为的)。但只要涉及人员间的交流和沟通,或多或少都要需要软件工程才能更有效率,工作成果更稳定。
其实开发软件,就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法,即我写的这个程序是要干什么的;然后就是对要实现的核心功能大概构思一种或多种实现方法,并从中选出一种自认为是较好的;接下来就是将涉及的各种主要或次要功能分成各个模块;最后就是分模块来编码和DEBUG。在我看来,除了第一步外,其余的步骤应该是一个循环的过程。在编码的过程中,你总是需要不断地回过头来修改原先的模块设计,甚至最初选定的实现算法。
具体到每一步的工作要怎样完成,是非常灵活的,只要把握住大体的方向就行。在进行分析,设计,编码,调试,维护这几部分的工作的时候,最核心的就是文档的编写。
1.可行性分析就是关于当前项目能不能干的分析结果。
2.项目描述这是在决定立项以后,对当前项目的一份扼要说明。
3.需求分析就是对客户要求的功能的定义。
4.软件设计这就是对程序的每一个模块的详细设计的说明文档。
5.开发日志我一直都认为这是文档中最有趣的部分。开发日志相当于编码阶段的文档,它的形式可以很随意,主要是记录一些在写程序时突然萌发的灵感,或对代码的一些微小的修改,或对程序结构的一些微小变动等,还要对上述这些修改变动作些说明。
6.测试分析 用于指出程序存在或潜在的缺陷和错误,以及程序性能的数字描述。