20150409作业3 阅读《构建之法》1-5章 (Update:2015-04-16

以下是我看《构建之法》1-5章列出来的知识点和一些自己对部分知识的理解以及一些吐槽...和感受

1.1

软件 = 程序 + 软件工程 (软件工程 = 软件 - 程序(我知道软件是什么,也知道程序是什么,但是就是不懂什么是软件工程啊...个人觉得 软件工程 - 程序 = 0

程序 = 数据结构 + 算法 (突然觉得至今为止我们所写的作业都只是程序而还没达到软件的程度啊..就缺软件工程了..软件工程到底是啥~?!

∴软件 = 数据结构 + 算法 + 软件工程

去百度百科看了一下:（有些就直接省略了

定义

IEEE：在软件工程术语汇编中的定义：软件工程是：1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；2.在1中所述方法的研究

ISO 9000对软件工程过程的定义是：软件工程过程是输入转化为输出的一组彼此相关的资源和活动。

其它定义：1．运行时，能够提供所要求功能和性能的指令或计算机程序集合。2．程序能够满意地处理信息的数据结构。3．描述程序功能需求以及程序如何操作和使用所要求的文档。以开发语言作为描述语言，可以认为：软件=程序+数据+文档。

内涵

一、软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下四个方面：

1、P（Plan）——软件规格说明。规定软件的功能及其运行时的限制。

2、D（DO）——软件开发。开发出满足规格说明的软件。

3、C（Check）——软件确认。确认开发的软件能够满足用户的需求。

4、A（Action）——软件演进。软件在运行过程中不断改进以满足客户新的需求。

二、从软件开发的观点看，它就是使用适当的资源（包括人员，软硬件资源，时间等），为开发软件进行的一组开发活动，在活动结束时输入（即用户的需求）转化为输出（最终符合用户需求的软件产品）。

三个阶段：定义阶段：可行性研究初步项目计划、需求分析；开发阶段：概要设计、详细设计、实现、测试；运行和维护阶段：运行、维护、废弃

原则：1、抽象；2、信息隐蔽；3、模块化；4、局部化；5、确定性；6，一致性；7、完备性；8、可验证性

上面有条式子,我是不是能够代入解得 软件工程 = 数据 + 文档 呢?

 

后面还有小学数学题的那个故事,看来我们前两次的作业确实是有点像那样发展,做作业的过程中也发现,软件 - 程序 > 0,因为我做第一个作业的时候和做第二个作业的时候都是分开来做的,明明就是同一个内容的程序,但是我发现前一次的程序要修改和维护完全比再写一个难.深深地觉得写软件还是要事先设计好对象和方法.以便于以后的修改维护.

 

 

 软件企业 = 软件 + 商业模式

 

书上说商业模式的时候还提到了 腾讯和奇虎360 的梗(我猜的,书上没明确说是

这件事当年的我也是深有体会.两边打架,我们用户头疼...

 

1.2

软件工程师把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。

软件工程包括下列领域:软件需求分析、软件设计、软件构件、软件测试和软件维护。

软件工程和下列的学科相关:计算机科学、计算机工程、管理学、数学、项目管理学、质量管理、软件人体工学、系统工程、工业设计和用户界面设计。

 

 1.2.1

软件的特殊性:

1.复杂性.(这个深有体会,随便一点小程序都能复杂到头晕.

2.不可见性.(这个虽然是这么说,但是很多东西一旦摆上台来,大家都能看到或者看出其中的源代码..比如说网站的设计.

3.易变性.(这就是传说中的更新与维护?就是那个一修改或者添加一小段代码就要测试半天的东西吧?

4.服从性.(这个主要合适需求方面.嗯,客户是很难满足的,特别是要不断添加更改需求的客户

5.非连续性.(这个不懂.

 

 

软件工程的目标是尽量少的Bug,而Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。

 

 2.1

电脑没有VSTS,也不懂C#...

 

个人对团队的理解还是可以,但是就是不太懂怎样让整个团队一起分工、运作.

可以理解成 我做这个功能,写一个函数,然后告诉你,我的函数的各参数是什么,然后返回什么值吗?

 

2.1.2

单元测试应该在最低的功能/参数上验证程序的正确性。

单元测试必须由最熟悉代码的人(程序的作者)来写。

单元测试过后,机器状态保持不变。

单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)。

单元测试应该产生可重复、一致的结果。

独立性——单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性。

单元测试应该覆盖所有代码路径。

单元测试应该集成到自动测试的框架中。

单元测试必须和产品代码一起保存和维护。

 

这一节很多看不懂,但是总的来说应该就是程序模块的测试吧(我猜的...

 

2.1.3

回归测试

这个其实也是测试的那一块的吧...

 

2.2

效能分析

分析程序的时间复杂度和各模块的耗时情况

 

2.3

个人开发流程

个人感觉这个知识点很重要.特别是流程中的分析和设计那一块.感觉我还不怎么会.

 

3.1

 初级软件工程师的成长路线:

1.积累软件开发相关的只是,提升技术技能

2.积累问题领域的知识和经验

3.对通用的软件设计思想和软件工程思想的理解

4.提升职业技能(职业技能包括:自我管理的能力,表达和交流的能力,与人合作的能力,按质按量完成任务的执行力...)

5.实际成果.

 

衡量工作质量的指标
a.项目/任务有多大?
b.花了多少时间?
c.质量如何?
d.是否按时交付?

自我评价和跟踪 清单
http://www.cnblogs.com/xinz/p/3852177.html

4.2
代码风格规范(嗯,这个一般eclipse或者其他开发工具都会有能够自动缩进的..不过没办法完全规范,还是要靠自己的自觉...
缩进,行宽,括号,断行与空白的{ }行,分行,命名,下划线,大小写,注释.

4.3
代码设计规范
函数,goto,错误处理
(因为没有学C++,中间跳过了部分内容.不过自己看了下,好像说的跟java的没什么区别啊..只是多了个 struct 而已,还有就是不知道 虚函数 是什么鬼咯..

4.4
代码复审
自我复审,同伴复审,团队复审

复审目的:
1.找出代码的错误
如: 1)编码错误
2)不符合团队代码规范的地方
2.发现逻辑错误,程序可以编译通过,但是代码的逻辑是错的
3.发现算法错误 如:使用的算法不够优化,边界条件没有处理好
4.发现潜在的错误和回归性错误--当前的修改导致以前修复的缺陷又重新出现
5.发现可能需要改进的地方
6.教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉和应用领域相关的实际知识

复审步骤
1.代码必须成功地编译,在所有要求的平台上,同时编译Debug|Retail版本
2.程序员必须测试过代码,同时,也可以加上OutputDebugString等输出来监视程序的控制流
3.程序员必须提供新的代码,以及文件差异分析工具
4.复审者可以选择面对面的复审、独立复审或其他方式
5.在面对面的复审中,一般是开发者控制流程,讲述修改的前因后果.但是复审者有权在任何时候打断叙述,提出自己的意见.
6.复审者必须注意提供反馈意见

代码复审后
1.更正明显的错误
2.对于无法很快更正的错误,要在项目管理软件中创建Bug把它们记录下来
3.吧所有的错误记在自己的一个"我常犯的错误"表中,作为以后自我复审的第一步

代码附身的核查表
1.概要部分
1)代码能复合需求和规格说明么?
2)代码设计是否考虑周全?
3)代码可读性如何?
4)代码容易维护么?
5)代码的每一行都执行并检查过了吗?
2.设计规范部分
1)设计是否遵从已知的设计模式或项目中常用的模式?
2)有没有硬编码或字符串/数字等存在?(什么是硬编码啊...
3)代码有没有依赖于某一平台,是否会影响将来的移植?
4)开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现?在本项目中是否存在类似的功能可以调用而不用全部重新实现?
5)有没有无用的代码可以清除?
3.代码规范部分
修改的部分复合代码标准和风格么?
4.具体代码部分
1)有没有对错误进行处理?对于调用的外部函数,是否检查了返回值或处理了异常?
2)参数传递有无错误?字符串的长度是字节的长度还是字符的长度?是以0开始计数还是以1开始计数?
3)边界条件是如何处理的?switch语句的default分治是如何处理的?循环有没有可能出现死循环?
4)有没有使用断言???老保证我们认为不变的条件真的得到满足?(断言 是什么鬼?不懂啊..
5)对资源的利用,是在哪里申请,在哪里释放的?有无可能存在资源泄露(内存、文件、各种GUI资源、数据库访问的连接,等等)?有没有优化的空间?
6)数据结构中有没有用不到的元素?
5.效能(不懂具体的是什么
1)代码的效能如何?最坏的情况是怎样?
2)代码中特别是循环中是否有明显可优化的部分?
3)对于系统和网络的调用是否会超时?如何处理?
6.可读性
代码可读性如何?有没有足够的注释?
7.可测试性
代码是否需要更新或创建新的单元测试?

4.5结对编程(这个首先要有个大牛肯跟我结对啊...不然自己要做两份工呢...

对于结对编程的模式,我有很多要吐槽的..
1.并排坐在一台电脑前,面对同一显示器,使用同一键盘,统一鼠标一起工作(这个除了同一宿舍的,不然会很麻烦..顺便提一下..我的是台式..
2.一起分析,一起设计,一起写测试用例,一起编码,一起做单元测试,一起集成测试,一起写文档(这个嘛....除非有大牛..不然两个臭皮匠是比不过一个诸葛亮的..

如何结对编程
1.驾驶员:写设计文档(现在写程序还是没有设计的习惯..总是习惯脑里构思下,然后就直接敲了...),进行编码和单元测试等XP开发流程
2.领航员:审阅驾驶员的文档、驾驶员对编码等开发流程的执行;考虑单元测试的覆盖率;思考是否需要和如何重构;帮助驾驶员解决具体的技术问题
3.驾驶员和领航员不断轮换角色,不要连续工作超过一小时,没工作一小时休息15分钟.领航员要控制时间.
4.主动参与.任何一个任务都首先是两个人的责任,也是所有人的责任.没有"我的代码"、"你的代码"或"他/她的代码",只有"我们的代码".
5.只有水平上的差距,没有级别上的差异.两人结对,尽管可能大家的级别资历不同,但不管在分析、设计或编码上,双方都拥有平等的决策权力.
6.设计好结对编程的环境,座位、显示器、桌面等都要能允许两个人舒适地讨论和工作.如果是通过远程结对编程,那么网络、语音通讯和屏幕共享程序要设计好.

如何正确地给予反馈
1.最外层:行为和后果
2.中间层:习惯和动机
3.最内层:本质和固有属性(这就是老师说的那个做汉堡吧...哎我还没写呢...

5.1
团队共同的特点:
1.团队有一致的集体目标,团队要一起完成这目标.
2.团队成员有各自的分工,互相依赖合作,共同完成任务.

软件团队的模式
1.窝蜂模式
2.主治医师模式
3.明星模式
4.社区模式
5.业余剧团模式
6.秘密团队
7.特工团队
8.交响乐团模式
9.爵士乐模式
10.功能团队模式
11.官僚模式

开发流程
1.写了再改模式(这个感觉是原型模型....
2.瀑布模型
3.瀑布模型的各种变形
1)生鱼片模型
2)大瀑布带着小瀑布
4.Rational统一流程
5.老板驱动的流程
6.渐进交付的流程