这个作业要求来自于:https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178
第一章:概论
第一章讲了计算机科学的领域,软件工程与计算机科学的关系,如软件=程序+软件工程,软件的5个特性,软件工程的定义与组成部分。
我读了P15页的1.2.4节,软件工程的目标--创造“足够好”的软件,书上写:什么是好的软件?一些同学认为,就是软件没有缺陷(BUG),所谓软件工程,就是把软件中的BUG都消灭掉的过程。这的确是抓住了软件工程的一个要素。还有后面说明什么是BUG:简单点说,软件的行为和用户的期望值不一样,就叫做Bug。是否是Bug,取决于用户、开发者的不同角度。以前我一直以为,所谓的BUG就是在程序运行的时候出错,导致程序闪退,或者出现问题等都是BUG。但是看了这一章之后,我才知道所谓的Bug,是与用户的期望不相符就能说为BUG。但是到这里我就有疑问了,一个程序的用户有很多,但是不可能满足全部用户的要求,所以是不是存在完美的程序呢?
第二章:个人技术和流程
第二章主要讲了单人测试,回归测试,效能分析,个人软件开发流程(PSP)
我读了第二章,这一章讲述了单元测试的重要性,了解到了单元测试应该准确,快速,并且保证程序的基本模块的正确性。但是读到书上P26页,上面写道:单元测试应该产生可重复、一致的结果。如果单元测试的结果是错的,那么一定是程序出了问题,而且这个错误一定是可以重复的。为什么单元测试结果是错误,程序就一定出了问题呢?还有后面提到的:100%的代码覆盖率并不等同于100%的正确性!既然代码的覆盖率都100%了,表示单元测试把全部代码都测试到了并且返回了正确的值,既然全部代码都测试过了走了一遍,为什么还不能代表完全正确呢?
第三章:软件工程师的成长
第三章:讲了评价软件工程师水平的主要方法,技能的反面,TSP对个人的要求,软件工程师的思维误区。
在这个章节,主要是告诉我们作为一个工程师,如何正确的认识自己,就像P44页的对话所展示的道理一样,每职业都有自己的评判标准,例如职业篮球员一样,会有赛季数据显示出他出场次数、命中率、篮板、助攻、抢断等信息。我们软件工程师也有相应的数据例如:积累软件开发相关的知识,提升技术技能、积累问题领域的知识和经验、对通用的软件设计思想和软件工程思想的理解、提升职业技能、实际成果等。看了这章之后我想到了老师说的,在外面找工作的时候,我们这个专业,别人看重的不是文凭,是你的工作经验,还有工作的成果,那么问题来了,如果别人看重的是你的工作经验和参与项目的多少,那么我们考证还有用吗?
第四章:两人合作
第四章:讲了代码规范,极限编程,两人合作的不同阶段,影响他人的技巧。
在这一章里面,讲述了代码书写规范,因为很多程序都不是一个人自己完成的,一般都是有个团队的,最少也要2个人一起合作,所以书写格式的规范涉及到程序设计、模块之间的关系、设计模式等方方面面。在书上P79页,书上有句话:每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误,在结对编程中,因为有随时复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的哪一位。这句话点出了结对编程的好处,好处是这样所写的程序主要是以水平高的那一位为主导,可以减少前期的错误,但是有一个问题就是,每个人熟悉的编程环境都不一样,如果使用不一样的编程软件,这样结对之后的代码整合不会很麻烦吗?
第五章:团队和流程
第五章:讲的是典型的软件团队模式和开发流程有哪些,各有什么优缺点,TSP,MVP,MBP,RUP。
在这一章里面讲了很多团队模式,比如“一窝蜂模式”、“主治医生模式”、“社区模式”、“交响乐团模式”等等很多模式。还有讲述了软件开发的流程。发现优秀的模式和流程都有共同特点:1.使用妥善定义的流程,流程中的每一步都u是可以重复,可以衡量结果的。
2.团队的各位成员对团队的目标、角色、产品都有统一的理解
3.尽量多手机数据,并且用数据来帮主团队
4.尽量使用成熟的技术和做法
5.制定切合实际的计划和承诺
6.增加团队的自我管理能力
7.专注提高质量,争取在软件生命周期早期发现问题。并且解决。
那么看了这么多的模式和流程,我有个问题,要如何知道什么模式适合自己的开发团队,或者做一个项目,要用什么模式或者流程好呢?